[U-Boot-Users] PPC ROM relocation and GCC GOT
Greetings,
The firmware update strategy we are planning for a product I am working on will work best if we can pre-build U-Boot images which can be run from either of two locations in ROM. A very small piece of code at the reset vector would choose the correct version to run.
It seems that the method GCC (eldk 2.0) uses for global variable reference does not lend itself to such relocation. The effect of the current GCC generated code is to reference the variables at the original linked address. This is in spite of the fact that the GOT itself is properly located by relative addressing techniques. The GOT can't be updated at runtime because, of course, it is in ROM.
Aside from our particular application, such "install time" relocation (including to ROM) would seem a useful capability to have in a boot loader. I've only been working with the PPC a few months, so please enlighten me I am completely wrong, but I don't see any way to cause GCC to generate code for full code relative or even simple global register+offset access to global constants.
I guess I could set up the BAT registers earlier and relocate the ROM image back to it's linked location. Is there any reason that wouldn't work, at least for the MPC8241?
If GCC were just a bit more flexible, this might be easier. Has anyone else solved (or even tried to solve) this problem?
BTW, the U-Boot documentation and code which imply that r30 is used by GCC to point to the GOT seem misleading. R30 is indeed used for access thru the GOT within each function, but r30 appears to be set up independently at the beginning of each function. In particular, I don't see the point in updating r30 in the following code from /cpu/mpc824x/start.S since it doesn't return to a C function anyway.
/* * Fix GOT pointer: * * New GOT-PTR = (old GOT-PTR - CFG_MONITOR_BASE) + Destination Address * * Offset: */ sub r15, r10, r4
/* First our own GOT */ add r14, r14, r15 /* the the one used by the C code */ add r30, r30, r15
Have I missed something obvious? Thanks for any insight anyone can provide.
--Brad Bosch
I solved this problem the easy way by simply making two images, compiled to run from different locations. Check our board, gth, to see how it was done.
To choose one of the two images, we use miniboot, http://opensource.se/projects/miniboot/index.html
/Thomas
Bradley A. Bosch wrote:
Greetings,
The firmware update strategy we are planning for a product I am working on will work best if we can pre-build U-Boot images which can be run from either of two locations in ROM. A very small piece of code at the reset vector would choose the correct version to run.
It seems that the method GCC (eldk 2.0) uses for global variable reference does not lend itself to such relocation. The effect of the current GCC generated code is to reference the variables at the original linked address. This is in spite of the fact that the GOT itself is properly located by relative addressing techniques. The GOT can't be updated at runtime because, of course, it is in ROM.
Aside from our particular application, such "install time" relocation (including to ROM) would seem a useful capability to have in a boot loader. I've only been working with the PPC a few months, so please enlighten me I am completely wrong, but I don't see any way to cause GCC to generate code for full code relative or even simple global register+offset access to global constants.
I guess I could set up the BAT registers earlier and relocate the ROM image back to it's linked location. Is there any reason that wouldn't work, at least for the MPC8241?
If GCC were just a bit more flexible, this might be easier. Has anyone else solved (or even tried to solve) this problem?
BTW, the U-Boot documentation and code which imply that r30 is used by GCC to point to the GOT seem misleading. R30 is indeed used for access thru the GOT within each function, but r30 appears to be set up independently at the beginning of each function. In particular, I don't see the point in updating r30 in the following code from /cpu/mpc824x/start.S since it doesn't return to a C function anyway.
/* * Fix GOT pointer: * * New GOT-PTR = (old GOT-PTR - CFG_MONITOR_BASE) + Destination Address * * Offset: */ sub r15, r10, r4 /* First our own GOT */ add r14, r14, r15 /* the the one used by the C code */ add r30, r30, r15Have I missed something obvious? Thanks for any insight anyone can provide.
--Brad Bosch
This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
participants (2)
-
Bradley A. Bosch -
Thomas Lange