Boot up questions

If you are using a secondary bootloader, running from RAM, to load another piece of code into the same RAM, there are a few issues that need resolution.

1.) The first issue is how you want your memory map to look when you finally branch to the new (real) code? You obviously can't overwrite the secondary bootloader with the real code because at the point of branch, both need to exist. You'll probably have to partition your RAM so that 2ndary bootloader and real code have their own isolated sections, with the bootloader section clearly being much smaller. You may even be able to fit your 2ndary bootloader in on-chip RAM, which will make this problem a lot simpler as you wont have to worry about booting code from the EPCS at all since M4K memories in Cyclone parts are initializable with the FGPA configuration stream.

2.) I imagine the real code will be in the form of an .elf file created by Nios II IDE correct? For the secondary bootloader to get this .elf into RAM, it will need to stored on the host as some kind of boot record, meaning something that the bootloader can easliy translate into a series of "copy this data to address X" operations. Typically, you'll start by converting the .elf to an .srec using nios2-elf-objcopy. From there you can create a boot record. There is a bootcopier example posted on this forum that uses this kind of boot record. Check out "EPCS boot loader" under the "Post your own IP" downloads.

3.) Lastly, once the real code (including all data sections) is in place, you simply have to branch to it's starting address. If the code was built using Nios II IDE, all the system initialization will taken care of including stack pointer, heap, and the like.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

You&#39;ll probably have to partition your RAM so that 2ndary bootloader and real code have their own isolated sections, with the bootloader section clearly being much smaller.[/b]

--- Quote End ---

How do I partition the RAM? Specifically, how do I make the linker think that the RAM is smaller than it really is? I am worried about overwriting the heap or stack of the 2ndary boot loader with the real code. How to I limit the amount of RAM left over for the heap and stack?

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

You may even be able to fit your 2ndary bootloader in on-chip RAM, which will make this problem a lot simpler as you wont have to worry about booting code from the EPCS at all since M4K memories in Cyclone parts are initializable with the FGPA configuration stream.[/b]

--- Quote End ---

This would be ideal, but I don&#39;t have any free M4Ks. We have a lot of dual-port memory in our system.

The .elf to .srec conversion is what I expected. Thanks.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

Lastly, once the real code (including all data sections) is in place, you simply have to branch to it&#39;s starting address. If the code was built using Nios II IDE, all the system initialization will taken care of including stack pointer, heap, and the like.[/b]

--- Quote End ---

Won&#39;t the IDE generate new .entry and .exceptions sections? Doesn&#39;t the .exceptions section have to be at 0x20 (assuming I haven&#39;t changed the default in SOPC Builder?)

Thanks for your help.

OK, I thought I understood the .elf to .srec but after looking at it I have some questions:

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

I imagine the real code will be in the form of an .elf file created by Nios II IDE correct?[/b]

--- Quote End ---

Yes.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

For the secondary bootloader to get this .elf into RAM, it will need to stored on the host as some kind of boot record, meaning something that the bootloader can easliy translate into a series of "copy this data to address X" operations. Typically, you&#39;ll start by converting the .elf to an .srec using nios2-elf-objcopy. From there you can create a boot record.[/b]

--- Quote End ---

Included in the .elf file is the .entry section that goes in the EPCS. Should I strip this out? Is it benign since I can&#39;t write to it anyway? Now, presumably, I&#39;ll want to place the real code at a differnet address that the one in the .elf file. If I use

nios2-elf-objcopy -v -O srec --change-addresses 0x2000 --srec-forceS3 boardxxx.elf boardxxx.srec

then it seems like 0x2000 gets added to all addresses. Is this correct? It also adds 0x2000 to the previously mentioned .entry section. Is there a way to selectively add an offset so I can exclude the EPCS part?

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

There is a bootcopier example posted on this forum that uses this kind of boot record. Check out "EPCS boot loader" under the "Post your own IP" downloads.[/b]

--- Quote End ---

After looking through the EPCS boot loader code I can&#39;t possibly see how it works. It expects a 4 byte length followed by a 4 byte address. I only see a 1 byte length in the epcs_controller_boot_rom.flash file that gets generated for my code followed by a 4 byte relative offset. What am I missing?

thanks again for your help.