Warning when exception address is changed?

Question

I&amp;#39;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&amp;#39;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&amp;#39;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&amp;#39;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&amp;#39;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: &lt;div class='quotetop'&gt;QUOTE &lt;/div&gt;  --- 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&amp;#39;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?

altera_forum · Answer

Perhaps, 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 · Answer

Hi grante,  &gt; What "regions of unusable memory" are created by setting the exception address to &gt; 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&amp;#39;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&amp;#39;re playing around with different code models.  Regards, --Scott

altera_forum · Answer

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 · Answer

Hi Grant,  &gt; It only bothers me because I still don&amp;#39;t understand what it is &gt; I&amp;#39;m being warned about. The warning states that changing the &gt; exception address will create regions of unusable memory  It&amp;#39;s a somewhat prophylactic warning that you may be creating "holes" in your memory space where _code_ is never located -- that&amp;#39;s all. Perhaps the wording could be better ;-)  &gt; How will having the exception address at &gt; 0x08000000 cause any link-time issues that would be avoided by &gt; having it at 0x08000020? In neither case will the .exceptions &gt; 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&amp;#39;s really not that big of deal.  Regards, --Scott

altera_forum · Answer

&gt;&gt; It only bothers me because I still don&amp;#39;t understand what it is &gt;&gt; I&amp;#39;m being warned about. The warning states that changing the &gt;&gt; exception address will create regions of unusable memory &gt; &gt;It&amp;#39;s a somewhat prophylactic warning that you may be creating &gt;"holes" in your memory space where _code_ is never located -- &gt;that&amp;#39;s all. Perhaps the wording could be better ;-)  It&amp;#39;s not just the wording (which is bad), it&amp;#39;s the fact that the warning is generated when there is no reason to generate it, and isn&amp;#39;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.  &gt;&gt; How will having the exception address at 0x08000000 cause any &gt;&gt; link-time issues that would be avoided by having it at &gt;&gt; 0x08000020? In neither case will the .exceptions section &gt;&gt; overlap the .entry section. &gt; &gt;The bottom 0x20 bytes is where the default linker scripts want &gt;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.  &gt;In some cases, this will cause a problem -- if you use your own &gt;linker scripts you can do what you want.  You don&amp;#39;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&amp;#39;t overlap.  &gt;Just look at the manual for a description of the "possible &gt;issue". It&amp;#39;s really not that big of deal.  C&amp;#39;mon, admit it, the warning is just plain wrong.  It&amp;#39;s a bug.

Forum Discussion

Warning when exception address is changed?

6 Replies

Recent Discussions

Debug Know-How: Ashling RiscV NIOS V debug using Command Line

AshlingRISCFree IDE Build system: 'source directory does not appear to contain CMakeLists.txt"

Correct way to use mSGDMA with a NIOSV/m processor on a MAX10 FPGA

University Program IP for NiosV

Nios-V on Cyclone IV