Nios reset behavior

I am trying to understand the low level startup sequence on a custom 
Nios board. When the Nios (3.2) resets, what determines where it fetches 
its very first instruction? Is it always from the onchip bootstrap area 
or is this configurable? I don't have the OCI so I assume I can't just 
step thru from reset on my target (with gdb).

As I understand it, SOPC(4.0) compiles my custom bootstrap and Quartus 
(4.0sp1) adds this code to the pof, but not to the application srec. I 
am confused that the objdump for the bootstrap shows it is compiled for 
my SRAM base, not the onchip area. The Nios manuals say the code is not 
generally relocatable so this does not seem right. I don't see how to 
fix this base in the Nios dialog - it appears to be set correctly.

TIA

In SOPC builder you set the Reset Location in the Nios More tab.

This is where the system will reset to.

I always set this an internal ram that holds either Germs or my program.
That program can load a larger program out of flash and then jump to it.
(or whatever you want it to)

The new NiosII has fancier automatic boot options but I haven't used it for
that yet.

Ken

"tns1" <tns1@cox.net> wrote in message news:hSwJc.974$ml.802@lakeread05...
> I am trying to understand the low level startup sequence on a custom
> Nios board. When the Nios (3.2) resets, what determines where it fetches
> its very first instruction? Is it always from the onchip bootstrap area
> or is this configurable? I don't have the OCI so I assume I can't just
> step thru from reset on my target (with gdb).
>
> As I understand it, SOPC(4.0) compiles my custom bootstrap and Quartus
> (4.0sp1) adds this code to the pof, but not to the application srec. I
> am confused that the objdump for the bootstrap shows it is compiled for
> my SRAM base, not the onchip area. The Nios manuals say the code is not
> generally relocatable so this does not seem right. I don't see how to
> fix this base in the Nios dialog - it appears to be set correctly.
>
> TIA
>

Thanks. I see where I can pick the reset location. My configuration is 
just as you describe - a bootstrap routine onchip, and an app that gets 
copied from flash to external sram before execution.

My earlier statement about the bootstrap base address was wrong - the 
base address is correct for this onchip code image.

However, there is a bug in the way either my bootstrap or app gets 
built, that causes the application to jump from sram to flash addresses 
for any function call in main() (ISRs too). The base address for my app 
is correctly set to sram, not flash.

I believe the problem has to do with the initialization code before 
main(), either the routines that set up new stack frames and the CWP 
handler. To track down this bug I have been trying to make use of gdb 
(no jtag port for OCI) for either my hw target or the cpu simulator 
target. I'd like to step thru the init stuff. Using gdb for target hw 
debug does work, but so far I can't step thru the init stuff (it locks 
when stepping into flash - no surprise).

Has anyone gotten the nios cpu simulator to work under gdb? I can load 
an image and source but I can't step. I can't find the sim.ld script 
that is mentioned in the gdb docs.



Kenneth Land wrote:
> In SOPC builder you set the Reset Location in the Nios More tab.
> 
> This is where the system will reset to.
> 
> I always set this an internal ram that holds either Germs or my program.
> That program can load a larger program out of flash and then jump to it.
> (or whatever you want it to)
> 
> The new NiosII has fancier automatic boot options but I haven't used it for
> that yet.
> 
> Ken
> 
> "tns1" <tns1@cox.net> wrote in message news:hSwJc.974$ml.802@lakeread05...
> 
>>I am trying to understand the low level startup sequence on a custom
>>Nios board. When the Nios (3.2) resets, what determines where it fetches
>>its very first instruction? Is it always from the onchip bootstrap area
>>or is this configurable? I don't have the OCI so I assume I can't just
>>step thru from reset on my target (with gdb).
>>
>>As I understand it, SOPC(4.0) compiles my custom bootstrap and Quartus
>>(4.0sp1) adds this code to the pof, but not to the application srec. I
>>am confused that the objdump for the bootstrap shows it is compiled for
>>my SRAM base, not the onchip area. The Nios manuals say the code is not
>>generally relocatable so this does not seem right. I don't see how to
>>fix this base in the Nios dialog - it appears to be set correctly.
>>
>>TIA
>>
> 
> 
> 

I don't know.  *that* part :) has always worked for me.  Let me just
describe what I do and maybe you will see something.

This is NiosI BTW.

1. Small bootloader code in onchip ram at the reset location.  This gets
built and placed there during the SOPC generate and QII build process.  In
SOPC onchip ram contents I select build bootloader.c

2. bootloader.c wakes up and checks if I have any srec data in the unused
portion (well unused isn't the correct word, but the non-harware
configuration portion) of the asmi.  I think I used the midway point of my
4Mbit asmi chip. Would/should work the same for any flash.

3. If it finds some then it blindly processes each srec by blindly
memcpy'ing the srec data wherever it says it goes.  (The srecs addresses are
set during the build/link/creation of the srec file that has been copied to
the asmi chip)

4. I'm a little fuzzy here since I wrote this a few months back, but I
believe the last srec contains a start address and I jmp there and boom -
I'm booted and running.  (do a seach for srec on google and you'll find
a/the spec for srec's)

If it should work but doesn't try lowering your cpu clock and see if it
works then.

Ken

"tns1" <tns1@cox.net> wrote in message news:SWAJc.1005$ml.940@lakeread05...
> Thanks. I see where I can pick the reset location. My configuration is
> just as you describe - a bootstrap routine onchip, and an app that gets
> copied from flash to external sram before execution.
>
> My earlier statement about the bootstrap base address was wrong - the
> base address is correct for this onchip code image.
>
> However, there is a bug in the way either my bootstrap or app gets
> built, that causes the application to jump from sram to flash addresses
> for any function call in main() (ISRs too). The base address for my app
> is correctly set to sram, not flash.
>
> I believe the problem has to do with the initialization code before
> main(), either the routines that set up new stack frames and the CWP
> handler. To track down this bug I have been trying to make use of gdb
> (no jtag port for OCI) for either my hw target or the cpu simulator
> target. I'd like to step thru the init stuff. Using gdb for target hw
> debug does work, but so far I can't step thru the init stuff (it locks
> when stepping into flash - no surprise).
>
> Has anyone gotten the nios cpu simulator to work under gdb? I can load
> an image and source but I can't step. I can't find the sim.ld script
> that is mentioned in the gdb docs.
>
>
>
> Kenneth Land wrote:
> > In SOPC builder you set the Reset Location in the Nios More tab.
> >
> > This is where the system will reset to.
> >
> > I always set this an internal ram that holds either Germs or my program.
> > That program can load a larger program out of flash and then jump to it.
> > (or whatever you want it to)
> >
> > The new NiosII has fancier automatic boot options but I haven't used it
for
> > that yet.
> >
> > Ken
> >
> > "tns1" <tns1@cox.net> wrote in message
news:hSwJc.974$ml.802@lakeread05...
> >
> >>I am trying to understand the low level startup sequence on a custom
> >>Nios board. When the Nios (3.2) resets, what determines where it fetches
> >>its very first instruction? Is it always from the onchip bootstrap area
> >>or is this configurable? I don't have the OCI so I assume I can't just
> >>step thru from reset on my target (with gdb).
> >>
> >>As I understand it, SOPC(4.0) compiles my custom bootstrap and Quartus
> >>(4.0sp1) adds this code to the pof, but not to the application srec. I
> >>am confused that the objdump for the bootstrap shows it is compiled for
> >>my SRAM base, not the onchip area. The Nios manuals say the code is not
> >>generally relocatable so this does not seem right. I don't see how to
> >>fix this base in the Nios dialog - it appears to be set correctly.
> >>
> >>TIA
> >>
> >
> >
> >
>

This was wrong too. The Nios vector table entries are all right shifted 
addresses, so they look wrong in a memory dump. Function pointers will 
likewise be only half the value you expect. This plus the 5bit/11bit 
operations, the register windows, etc. all add to the chore of debug.

tns1 wrote:

> However, there is a bug in the way either my bootstrap or app gets 
> built, that causes the application to jump from sram to flash addresses 
> for any function call in main() (ISRs too).