Changing the bootloader HEX file in the NIOS II IDE

[Altera_Forum]

This is with NIOS II 8.1 although I'll be moving to 10.1 and will need to do this: 

 I'm trying to use a custom bootloader (loaded in EPCS) without changing the hardware (in SOPC Builder). The reason for this is the design was done 18 months ago and the hardware build is proven. I also have concluded that the EPCS on-chip memory is simply loaded like any other on-chip Cyclone III memory.  I see the post-processing step which I believe is finalizing the HEX .flash file which contains the configuration and application. Therefore I think I should just be able to replace the boot_loader_epcs.srec file with mine and be good to go.  The problem is, where is boot_loader_epcs.srec? The ones I find in the 'boot_loader_sources' folder aren't it because I renamed it so as to cause an error and there is no error.  Thanks for any insight into this one! Bill

[Altera_Forum]

The SREC location that gets pulled in during EPCS component generation can vary, but for the last few versions (9.1 onwards) it's been at: 

"$ENV{QUARTUS_ROOTDIR}/../ip/altera/nios2_ip/altera_nios2/boot_loader_epcs_sii_siii_ciii.srec"  Incidentally, you can determine this for yourself by just looking at the em_epcs.pl Perl file responsible for generating the component.  Best Regards,  -- slacker

[Altera_Forum]

Thanks. I think where I went wrong is my assumption that the EPCS bootloader is loaded like onchip memory. It's not and must be part of the hardware (SOF) information. The memory (512 bytes) where the EPCS module is located is not read/write. Therefore, it is not loaded by the data in the .flash file created by the NIOS II tools. I thought it was added to the .flash at this time but it appears to be in the SOF to begin with. 

 I suspect if you want to include the bootloader in the application (specifying an onchip RAM section for it's location) then you could point the reset vector to this onchip RAM section. I'm not the hardware builder here so I can't test it. It might be nice to know if this works. Then the RAM used by the bootloader could then be reused by the application once it's up and running.  Bill

[Altera_Forum]

Yes, you can do that to. 

 See one of my more recent posts regarding just this issue in another thread. There's some C code that implements a simple bootloader expecting the boot record payload to be located at a fixed offset in the EPCS device rather than just after the SOF.  Regards,  -- slacker

[Altera_Forum]

The IDE tends to link the initialisation data for 'other' memory sections to immediately follow the .code - then add instructions to copy it into the relevant memory area. This might be what you want if your code is in SDRAM, but doesn't work in many other cases [1]. 

 In your case you'll need to rebuild the fpga image in order to change the actual memory contents of the memory cells.  I've not tried to use the EPCS loader (we load through the PCIe slave) but I suspect Altera try to make it appear as something other than a small memory block! (Much like the way they hid the code/data areas inside the JTAG unit)  [1] I had problems using the JTAG loader for a system with 8k of tightly coupled instruction memory and a 12k data area containing lookup tables. The linker/loader were trying to load it all to the code space the copy the data area. I had to use a custom linker script (that generated multiple program segments) in order to get the JTAG loader to load the image.

[Altera_Forum]

--- Quote Start ---  Yes, you can do that to.  See one of my more recent posts regarding just this issue in another thread. There's some C code that implements a simple bootloader expecting the boot record payload to be located at a fixed offset in the EPCS device rather than just after the SOF.  Regards,  -- slacker  --- Quote End ---    You mean this post? http://www.alteraforum.com/forum/showpost.php?p=100698&postcount=2  I already have to do a copy if there is an update application. It works as follows:  1. Boot factory configuration and factory (EPCS offset 0) application.  2. The factory application checks the remote update register and if it is the update configuration boot:  3a. It checks an onchip RAM address to see if the copy has been done. If the copy was not done, it copies EPCS (offset 0x100000) to SDRAM and runs the just-copied update application. This step also sets the magic onchip memory address for this "already copied" flag.  3b. If the copy was done, it does nothing, the update application is running.  4. If the remote update is in factory boot, it checks EPCS offset 0x100000 for an update application  5a. If an update configuration/application is present it reconfigures the remote update at EPCS offset 0x100000 which comes back in step 1 above.  5b. If no update configuration/application is present the factory application continues normally.  I want the EPCS bootloader to read the remote update register and load the application from offset 0 or offset 0x100000. It's a simple 4 line change to the bootloader. I was thinking to include the bootloader in the actual application code and place it in the bootloader EPCS memory, but it appears to not be able to be replaced.  It's a bit kludgey to have to run the update configuration and the factory application to do the copy, and then have the update check a RAM location to see if the copy has been done.  I know people have updated the bootloader to do this but they rebuilt the PTF/SOF or SOPCINFO. I want to change the bootloader without this change. Am I correct that this is impossible?  Thanks! Bill

[Altera_Forum]

--- Quote Start ---  The IDE tends to link the initialisation data for 'other' memory sections to immediately follow the .code - then add instructions to copy it into the relevant memory area. This might be what you want if your code is in SDRAM, but doesn't work in many other cases [1].  In your case you'll need to rebuild the fpga image in order to change the actual memory contents of the memory cells.  I've not tried to use the EPCS loader (we load through the PCIe slave) but I suspect Altera try to make it appear as something other than a small memory block! (Much like the way they hid the code/data areas inside the JTAG unit)  [1] I had problems using the JTAG loader for a system with 8k of tightly coupled instruction memory and a 12k data area containing lookup tables. The linker/loader were trying to load it all to the code space the copy the data area. I had to use a custom linker script (that generated multiple program segments) in order to get the JTAG loader to load the image.  --- Quote End ---    There are not multiple data records in the boot EPCS image - it's one big block of data. What then copies the various initialized code and data to onchip memory? I have 10k of onchip memory code and initialized variables. If I break in crt0.s, they are already initialized. Maybe the jtag loads them, but when running from EPCS, how do they get initialized? Did they become part of the hardware configuration?  If I read you right, you're saying the EPCS 512 bytes is not memory per se, but logic that is initialized by SOPC builder and just looks like memory to the Cyclone?  Thank you, Bill

[Altera_Forum]

The nios reset vector could point to one of two places: 

1) Somewhere in EPCS memory 2) Into a 'private' M9K/M4K memory block within the EPCS interface block. If you look carefully at the SOPC builder page it ought to be possibly to work out which, I suspect the latter. This boot code will then copy the data from the EPCS memory into appropriate other places. It might be that some of the copying is actually done by code from within the program image - you'll probably need to disassemble the elf program file to see it.