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++
12602 Discussions

Multiple .sof and .flash images in Flash Mem

Altera_Forum
Honored Contributor II
997 Views

I have a custom board where we have a flash device connected to a single FPGA and then multiple other FPGAs resident. 

The FPGA hooked to flash will boot from flash upon power up. Thus, there is at the base of flash an image that gets copied in with the custom boot loader and executed on the this FPGA as the controller. 

This controller, after being told what to do, will copy from different locations in flash .sof and .flash files for use on the other FPGAs resident on the board. 

 

Creating the flash image for the controller is no big deal. The problem is using the existing Altera tools to create images that reside in different locations of flash WITHOUT a boot loader strapped on. 

 

elf2flash doesn't allow me to state the flash address to program the code to 

 

bin2flash does but doing an objcopy on the .elf file to make it binary increases the size of the file 16x and then running bin2flash so I can relocate the image increases it another 2.5x (leaving me with a huge flash file to wait for during a download...not likely) 

 

running objcopy with the --change-address option works at relocating the image but the elf2flash script wont let me not add in a boot loader (because --reset=0x0 --base=0x0 and the code is supposed to run out of SDRAM as defined in my SOPC Builder...remember this is on a different FPGA from the controller but stored in a single flash device attached only to the controller) 

 

nios2-srec2flash doesn't work because it asks me for a nios1 style cpu_sdk directory 

 

on the nios1 we got around this by taking the output elf, running srec2flash on it, carving out the boot loader with a perl script and then running nios-run on the resultant file. that was easy because the boot loader code was very easy to parse through after srec2flash was done and srec2flash allowed me to relocate the code.  

 

 

any ideas?
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
276 Views

barring an answer from someone else, is there a reason you haven't tried legacy SDk with Nios II? 

I know the IDE ahd many great functions, but it seems that you need the leg SDK functionality now.
0 Kudos
Altera_Forum
Honored Contributor II
276 Views

Regards, 

 

I'm working with Nios I. My application (a video codec) requires 2 hardware configurations and 2 programs, one for the encoder and the other one for the decoder. The problem is that I don't really know how to download the 2 software flash images into one Flash memory and execute them from the SRAM. The advantage is that the programs shall run separately, that is, not at the same time.  

Will it be necessary to change the address in GERMS monitor in order to begin the right program? 

 

Any help? http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/unsure.gif  

 

Thanks in advance.
0 Kudos
Altera_Forum
Honored Contributor II
276 Views

The "relocate" line in the .srec can point the image to your flash. This line starts with "r".  

Then you can program the flash in different locations. The application receiving the image, GERMS, should translate this and copy your executable into flash. 

 

It sounds like you&#39;ll need to have some sort of loader application that comes up on startup that is built into your FW image. The FW will come up via CPLD on power up and then execute this code that then somehow knows which image to load (perhaps each FW image has a register that indicates which image to get???). We had everything in SDRAM so it we didn&#39;t have to parse out any memory sections. Our image was copied verbatim into the front section of SDRAM and then we jumped to our application. 

 

If you have multiple memory sections you&#39;ll need to get more elaborate. On our platform we have an "elf loader" that knows how to parse the sections out of an elf file. The elf loader has access to a C-style array that contains our target executable. Our boot code copies from flash into the middle of SDRAM and then jumps to the application there. That code is the elf loader which then parses the elf in the array and sets up the different sections of memory and then jumps to its entry point. You can find free elf parsers on the web. 

 

Hope this helps. 

Dez...
0 Kudos
Reply