Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

Boot up questions

Altera_Forum
Honored Contributor II
1,080 Views

I just have a few issues with booting that I am hoping someone can shed some light on. 

 

First of all, here is my hardware design. Cyclone 1C6, 16 x 512K SRAM, EPCS4. 

You will probably notice that there is no Flash. Yes, if we had flash I wouldn't be having any trouble at all. But, that is out of my hands as the hardware is done. 

 

So, obviously I need to boot out of the EPCS. Right now I have flashed my entire program into the EPCS. That is working fine. But, what we really want is for the code to be downloaded from the host (it is always connected to a host SBC.) The boards are connected with a user logic interface (something to do with serdes and lvds, what do I know, I'm just the software guy.) Here is how I want booting to work: 

 

EPCS bootloader loads seconday boot code to RAM 

Secondary boot code downloads real code to RAM 

Jump to real code in RAM 

 

On to the questions: 

Where do I put the real code in RAM? After looking through the linker scripts I see that the 2ndary boot code will occupy the .text section. When I download the real code, how do I only place the new bits in RAM? Can I even do this? The .entry and.exceptions sections shouldn't have to change. I just want to place the new .text, .rodata, .rwdata, .bss sections into RAM. 

 

Am I totally off the mark here? Is there a simpler solution to my problem? Is there a way to skip over a section of RAM? 

 

I would like to try to do this without messing with the linker scripts. Though, I have a feeling that this will be impossible. 

 

Thanks,
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
396 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
396 Views

<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.
0 Kudos
Altera_Forum
Honored Contributor II
396 Views

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.
0 Kudos
Reply