Modifying EPCS bootloader

[Altera_Forum]

Skip to tl;dr at the bottom if so inclined. Background and such is there to cover some possible questions. 

 background: (Developing in Q10.1) I am developing a project with two separate firmware images(FW1, FW2) and two separate software images (SW1,SW2).   In the EPCS the images are stored as follows: 0x000000 FW1 (After FW1) SW1 0x800000 FW2 0x900000 SW2 (this location can be moved without problems)  On boot, FW1 (which includes a NIOS CPU) will load from an EPCS. The software automatically loads using the default boot loader generated by Quartus/sopc. At this time SW1 will do stuff and issue a reconfigure command via the reconfiguration component.  FW2 starts up from the reconfiguration. At this point, the default boot loader (in FW2) points (by calculating the size of FW at address 0) to SW1 and loads it. (my problem)  desired solution: I would like to modify the boot loader hex file stored in the EPCS boot loader ram to point to my second software location.  From what I have gathered (on these forums and elsewhere) the boot loader software is compiled from the assembly code found here: <Quartus_install_dir>\nios2eds\components\altera_nios2\boot_loader_sources\.  I would like to modify the boot loader code, recompile it, and replace the default hex file in the EPCS component. I will probably be able to figure out how to set a fixed offset to the boot loader software on my own, but help is always appreciated.  tl;dr How exactly do you "re-compile" the boot loader software and generate the hex file? There is a makefile in the directory, but I am not sure how to use it. (just typing make using the nios2 command shell in the directory will not work)

[Altera_Forum]

Figures, I search for hours for a solution and finally ask for help and I make progress not 30 minutes later. :oops: 

 I am half way there (I hope).  I managed to find the "make help" option when running in the nios2 command shell. This generated srec files. (I sort of expected that)  Now I need to figure out which SREC file to use and to convert it into my hex file.  The hardware I am using is an EPCS128 and a Cyclone IV. (should work the same as a Cyclone III)

[Altera_Forum]

The following script is what I am using to generate a hex file for the bootloader on Cyclone IV:#!/bin/sh make clean make CODE_BASE=0 elf2hex --input-file=obj/boot_loader_epcs_sii_siii_ciii.elf --output boot.hex --width=32 --base=0 --end=0x3FF

[Altera_Forum]

Kevin, 

 Thanks for the script! That worked great. Thanks for the help.  -

[Altera_Forum]

I've exactly the same issue here. 

But if I try my modified bootloader it does not start the NiosII code.  When I try to build the original bootloader and replace it in the SOPC directory, do a MIF/HEX Update in Quartus and regenerate the SOF it works... so the compilation and conversion of files works correctly. Are you willing to share you code or can you point me out what you've changed in boot_loader_epcs_bits_sii_siii_ciii.S?

[Altera_Forum]

I still haven't found a solution.  

 I create one JIC file with following images: BLOCK START ADDRESS END ADDRESS hwimage_app1.hex 0x00000000 0x0002FEB3 swimage_app1.hex 0x0002FEB4 0x00038C83 hwimage_app2.hex 0x00090000 0x000BF762 swimage_app2.hex 0x000BF763 0x000C8502  I would be really helped by some code where I can give an offset in the bootloader files.  I think in file boot_loader_epcs_bits_sii_siii_ciii.S the following should have an offset: line 96:  // 1) Open EPCS-device at flash-offset zero.  movi r_flash_ptr, 0 line 145:  // Close & re-open EPCS where we will start extracting the length  movi r_flash_ptr, 48 line 182:  // Close & re-open EPCS at byte 33  movi r_flash_ptr, 33  It should not be too difficult?! But I cannot manage it to get it working!

[Altera_Forum]

Question: Are you guys able to debug and step through the code in the boot loader? If so, can you please let me know how you are doing this.

[Altera_Forum]

No, I'm not debugging step by step.  

But I'm afraid I've to.  First need to understand the complete working of the boot_loader because my simple changes do not work...

[Altera_Forum]

--- Quote Start ---  I still haven't found a solution.   I create one JIC file with following images: BLOCK START ADDRESS END ADDRESS hwimage_app1.hex 0x00000000 0x0002FEB3 swimage_app1.hex 0x0002FEB4 0x00038C83 hwimage_app2.hex 0x00090000 0x000BF762 swimage_app2.hex 0x000BF763 0x000C8502  I would be really helped by some code where I can give an offset in the bootloader files.  I think in file boot_loader_epcs_bits_sii_siii_ciii.S the following should have an offset: line 96:  // 1) Open EPCS-device at flash-offset zero.  movi r_flash_ptr, 0 line 145:  // Close & re-open EPCS where we will start extracting the length  movi r_flash_ptr, 48 line 182:  // Close & re-open EPCS at byte 33  movi r_flash_ptr, 33  It should not be too difficult?! But I cannot manage it to get it working!  --- Quote End ---   There's a bit of code further down where it copies the length in bits to r_flash_ptr and converts it to a length in bytes. I think you'll need to add your hwimage offset to this value to get the swimage offset.  N.B.: I haven't tried it. ;)

[Altera_Forum]

--- Quote Start ---  The following script is what I am using to generate a hex file for the bootloader on Cyclone IV:#!/bin/sh make clean make CODE_BASE=0 elf2hex --input-file=obj/boot_loader_epcs_sii_siii_ciii.elf --output boot.hex --width=32 --base=0 --end=0x3FF   --- Quote End ---    Could somebodey explain me, what the meaning of "CODE_BASE=0" is?  Thanks sim

[Altera_Forum]

It will assign the 'make' variable 'CODE_BASE' the value 0. 

This assignment will not be overridable from within the makefile. What happens next depends on the contents of the makefile.

[Altera_Forum]

--- Quote Start ---  Could somebodey explain me, what the meaning of "CODE_BASE=0" is?  Thanks sim  --- Quote End ---   It seems to be just an option to build the elf file with a particular offset for debugging purposes. This only affects the ELF headers, as the actual assembled code is position-independent.

[Altera_Forum]

The nios code won't be position independant - that is only done for shared libraries. 

However it could well be there to force the physical address be different from the logical address - this will affect the elf program headers. Typically the physical and logical addresses are different when the code will be copied after being loaded, or when the memory maps seen by the cpu and loader are different.

[Altera_Forum]

--- Quote Start ---  The nios code won't be position independant - that is only done for shared libraries. However it could well be there to force the physical address be different from the logical address - this will affect the elf program headers. Typically the physical and logical addresses are different when the code will be copied after being loaded, or when the memory maps seen by the cpu and loader are different.  --- Quote End ---   I must admit to be being fairly ignorant of NiosII assembler, but the comments in the boot loader Makefile claims the code is fully relocatable. That doesn't mean the same thing as position-independant, but I assumed that's what they meant, unless SOPC Builder (or whatever) relinks the code to the EPCS boot ROM base address. The boot loader code is rather special - it doesn't even have a stack!

[Altera_Forum]

The compiler output files (*.o) are relocatable, the linking stage will assign fixed addresses (virtual addresses) at which the code is expected to run. The linker output for a program (do 'objdump -p' to get the program headers) can be copied into memory (at the correct address) and then run without any further fixups). 

So for the EPCS boot code, it will be the address the the nios cpu accesses the boot rom.

[Altera_Forum]

I only just failed to get gcc to compile C without any reference to a stack. Quite possibly I could have modified the code generator to not write the function prologue (that saves registers) for functions that are known to not return. 

I did think of doing that - as it would free up %sp for use as a general register!

[Altera_Forum]

So you'd have to regenerate the boot.hex file if you move the EPCS to a different address?

[Altera_Forum]

I agree with ljabbott's earlier comment: 

--- Quote Start ---  It seems to be just an option to build the elf file with a particular offset for debugging purposes. This only affects the ELF headers, as the actual assembled code is position-independent.  --- Quote End ---  The assembler code in the boot loader was very carefully written to avoid any absolute memory addresses as indicated in the code comments:// This is not a very complex job, but there is one requirement // that makes this program tricky: // // (*) We want to make the exact-same binary code run on any system, // at any (cache-line-aligned) address, and still work properly. // // Thus, this program must be position-independent, use no // memory-variables, and derive all payload-specific data from the // payload itself.No matter what CODE_BASE you specify, the resulting hex file should be the same. You do not need to recompile the boot loader if you change the EPCS controller address (unless you modified the stock boot loader to include absolute references).

[Altera_Forum]

What is CODE_BASE, and why is it initialized to 0x00 ? 

What is width, base and end please ?