Nios reset behavior

T

tns1

Guest
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
Click to expand...
 
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
Click to expand...
 
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
Click to expand...
 
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).
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top