[U-Boot] Dump questions about u-boot relocation

Hello,
1) If a code section (from an abolutely linked executable) is linked at address "x" but is instead loaded at address "y" would it still execute fine? Considereding the absolute branching, gloab variable access etc.
2) If not, then how does u-boot work after relocation? All the uboot code & data section is linked to the flash addresses. But after relocation is running from RAM?
3) I need to write some code that shall be linked at address "x" but shall be running while sitting at address "y". What are the precautions in my code that if I take, will I be able to achieve this?
Thanks,
Rajat Jain
PS: IN the above, whereever I write address, I actually mean "virtual address" not physical.

Le 22/09/2010 19:10, Rajat Jain a écrit :
Hello,
- If a code section (from an abolutely linked executable) is linked
at address "x" but is instead loaded at address "y" would it still execute fine? Considereding the absolute branching, gloab variable access etc.
This question has no definite answer, because it strongly depends on the arch and cpu, code generation options, etc; but the most likely answer is 'no, it will not execute fine', and will require modifications ('fixups').
- If not, then how does u-boot work after relocation? All the uboot
code& data section is linked to the flash addresses. But after relocation is running from RAM?
This depends on architectures and cpus. For ARM, relocation options added to build (-fPIC, -fPIE) minimize the fixup work needed to relocate, and produce a GOT -- global offset table -- which basically lists the address of each location in the binary which requires fixing up. After relocation and before jumping to RAM, u-boot must go through this table and perform the fixups.
- I need to write some code that shall be linked at address "x" but
shall be running while sitting at address "y". What are the precautions in my code that if I take, will I be able to achieve this?
Patience, all relevant datasheets (and I mean *all* of them), knowledge of assembly language for your target and a JTAG debugger are a minimum. :)
The problem is that when you run at a different location than the one specified at link time, you cannot fixup the code using the GOT as required.
This means any data holding a pointer will be wrong if you do nothing about it.
Note also that the code does not always use relocation where you would expect it to. For instance, on ARM targets, board_init_f() uses a table of pointers to functions, init_sequence[]. These pointers were computed at link time, and thus point to link-time locations; looking at the disassembled code will show you that they don't go through GOT relocation. They're used as-is, and so are wrong if you don't execute from the link-time location.
Thanks,
Rajat Jain
PS: IN the above, whereever I write address, I actually mean "virtual address" not physical. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Amicalement,
participants (2)
-
Albert ARIBAUD
-
Rajat Jain