Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorModifying EPCS bootloader
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)18 Replies
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:
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).// 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. - Altera_Forum
What is CODE_BASE, and why is it initialized to 0x00 ?
What is width, base and end please ?
