Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorWarning when exception address is changed?
I'm working on a platform which will boot up RedBoot from flash (probably running in SDRAM using a ROMRAM startup model), and then RedBoot will load applications from flash and/or the network into SDRAM and start them.
The problem is that the default configuration seems to be for the exception address to be in flash. This seems like a singularly bad idea:[list][*]It needlessly couples application code to what's in flash. The exception handler would have to be shipped in flash as part of the bootloader, and there would have to be some global agreement between the bootloader and the application code about an exception vector table or something similar. [*]Although the bootloader is in flash along with the RedBoot bootloader, RedBoot doesn't actually use any exceptions or interrupts. Only the applications that are being loaded into RAM are going to use interrupts. [*]Flash is very slow compared to SDRAM, and we're currently running out of bus bandwidth during the execution of the exception handler in flash. [/list]Placing the exception handler in RAM makes a lot more sense: it runs about 4X faster and applications are decoupled from the bootloader because they can load their own exception handler if desired. We've tried to change the exception address from 0x00000020 (flash, just above the reset handler) to 0x08000000 (the start of SDRAM), but then we get this cryptic warning: <div class='quotetop'>QUOTE </div> --- Quote Start --- Changing the default reset address or exception address creates regions of unusable memory. Do not change the default address unless you are creating a system with multiple CPUs.[/b] --- Quote End --- I've absolutely no idea what that warning is supposed to mean. What "regions of unusable memory" are created by setting the exception address to the start of SDRAM?6 Replies
Altera_ForumPerhaps, I think that the setting of Exceation Addres is wrong of it of it with SOPC Builder.
It is necessary to adjust the address to 0x0*******20. niosii more cpu setting processor function memory module offset address reset addres ext_flash ext_flash 0x0 0x0 Exception Addres sdram 0x00000020 0x08000020 break location jtag makasete- Altera_Forum
Hi grante,
> What "regions of unusable memory" are created by setting the exception address to > the start of SDRAM? Take a look at the default linker command script -- the warning is just a conservative warning and from a practical point of view is really just a software issue -- provided your reset address is elsewhere. If the warning bothers you just do as makasete suggests and set it to whatever + 0000_0020. The first 0x20 bytes are just the first cache line following the reset address -- and the only line that gets invalidated at reset -- so that's where the linker scripts want to put the startup code that invalidates the rest of the instruction cache. Placing the exception address at +0x20 will help avoid any software link-time issues when you're playing around with different code models. Regards, --Scott - Altera_Forum
First, thanks for responding to my question.
>>> What "regions of unusable memory" are created by setting the >>> exception address to the start of SDRAM? > > Take a look at the default linker command script -- the warning > is just a conservative warning And my question is a warning about what? > and from a practical point of view is really just a software > issue -- provided your reset address is elsewhere. The reset address is elsewhere. Is that what the warning is about -- overlapping reset and exception areas? Quartus thinks that the reset handler in flash at 0x00000000 is going to overlap the exception handler which is in SDRAM at 0x08000000? > If the warning bothers you just do as makasete suggests and set > it to whatever + 0000_0020. It only bothers me because I still don't understand what it is I'm being warned about. The warning states that changing the exception address will create regions of unusable memory. I have to change the exception address to be in SDRAM, and I sort of need to know what regions of memory are being made unusable by changing the default exception address. I also don't understand why having an exception handler at 0x08000000 causes the warning and having it at 0x08000020 does not cause the warning? Both are "changing the default reset address or exception address". > The first 0x20 bytes are just the first cache line following > the reset address -- and the only line that gets invalidated at > reset -- so that's where the linker scripts want to put the > startup code that invalidates the rest of the instruction > cache. Yes, I'm aware of that. I don't see what that has to do with the exception handler location. In all cases (the default location and both values we've changed it to) it's outside of the 0x20 byte region assigned to the reset handler. > Placing the exception address at +0x20 will help avoid any > software link-time issues when you're playing around with > different code models. I'm afraid I must be a bit dim today -- I don't understand that statement either. How will having the exception address at 0x08000000 cause any link-time issues that would be avoided by having it at 0x08000020? In neither case will the .exceptions section overlap the .entry section. I can see how you could make an argument for a warning if the exception handler overlapped with the reset handler (e.g. if the exception address was within the 0x20 byte block following the reset address), but that's not the case in the situation where we see the warning. That said, I think I probably will leave the exception address at 0x08000020 so that I can make the entry point for my application be the same as the beginning of RAM at 0x00800000. Having the application load address and the start address the same makes the system more consistent with previous products in the family. - Altera_Forum
Hi Grant,
> It only bothers me because I still don't understand what it is > I'm being warned about. The warning states that changing the > exception address will create regions of unusable memory It's a somewhat prophylactic warning that you may be creating "holes" in your memory space where _code_ is never located -- that's all. Perhaps the wording could be better ;-) > How will having the exception address at > 0x08000000 cause any link-time issues that would be avoided by > having it at 0x08000020? In neither case will the .exceptions > section overlap the .entry section. The bottom 0x20 bytes is where the default linker scripts want to put the .reset section. In some cases, this will cause a problem -- if you use your own linker scripts you can do what you want. Just look at the manual for a description of the "possible issue". It's really not that big of deal. Regards, --Scott - Altera_Forum
>> It only bothers me because I still don't understand what it is
>> I'm being warned about. The warning states that changing the >> exception address will create regions of unusable memory > >It's a somewhat prophylactic warning that you may be creating >"holes" in your memory space where _code_ is never located -- >that's all. Perhaps the wording could be better ;-) It's not just the wording (which is bad), it's the fact that the warning is generated when there is no reason to generate it, and isn't generated when you _are_ creating a hole in memory Placing the exception handler at 0x08000000 creates no holes in memory yet the warning is generated. Placing the exception address at 0x08000020 _does_ create an "unusable region of memory" from 0x08000000 to 0x0800001f, and yet there is no warning in that case. >> How will having the exception address at 0x08000000 cause any >> link-time issues that would be avoided by having it at >> 0x08000020? In neither case will the .exceptions section >> overlap the .entry section. > >The bottom 0x20 bytes is where the default linker scripts want >to put the .reset section. No, the default linker script puts the .entry section (there is no .reset section) wherever the reset address is configured in the design. In our design, the reset address is at 0x00000000, so the .entry section ends up from 0x00000000 to 0x0000001F. That overlaps neither with an exception handler at 0x08000000 nor with on at 0x08000020. >In some cases, this will cause a problem -- if you use your own >linker scripts you can do what you want. You don't have to use your own linker scripts. All you have to do is choose addresses for the exception and reset addresses such that the .entry and .exceptions sections don't overlap. >Just look at the manual for a description of the "possible >issue". It's really not that big of deal. C'mon, admit it, the warning is just plain wrong. It's a bug. - Altera_Forum
Hi Grante,
> C'mon, admit it, the warning is just plain wrong. It's a bug. Personally, I don't consider this to be a bug. The first time I encountered this warning I did some investigation to understand the impact of moving the exception address. Then I concluded that in my application, I had nothing to be concerned about. AFAICT, you've arrived at the same conclusion. But ... this is irrelevant. I'm not a Quartus developer, nor am I even an Altera employee -- I'm just another Altera user trying to contribute to the forum -- maybe save you some time by sharing my notes -- that's all. If you feel so strongly about this issue you may want to consider submitting a bug report to Altera. Regards, --Scott
