On Thu, Sep 17, 2009 at 10:53 PM, Wolfgang Denk wd@denx.de wrote:
Dear Joakim Tjernlund,
In message OF680476D5.A9D9D259-ONC1257634.00449AC4-C1257634.0045177E@transmode.se you wrote:
But why has the GOT table to fit "into built-in CPU memory"? When we are about to relocate U-Boot to RAM, we already have RAM working. So we should also be able to copy the GOT table to RAM and modify it there as needed before we use it?
Before you get RAM working there are lots of references to global data and string literals. These point to their link address so if you have loaded u-boot at a different address than you link address you have to adjust for the offset. Hard to do that when GOT is in flash :(
Ah, I finally GOT you :-)
Hm... but being able to load (and start) U-Boot from an arbitrary RAM location would be a big benefit, too, even if we still have to copy it to the correct (linked) address when storing it in flash.
Things are starting to make a lot of sense to me now - I thought all this relocation work on PPC was full relocation, but I see now that it only relates to relocation of code segments.
The biggest problem (for me anyway) in not relocating data segments (particularly .rodata) is that any time you attempt to lock or erase the flash, U-Boot can crash. This prevents (again, for me) updating the U-Boot image in flash on-board from within U-Boot itself.
I am working on full relocation on the x86 port (about 85% done) - It is a real pita because not only do you need to update the GOT, you also need to worry about any other references not known to the linker - Jumping to C interupt handlers from inline asm is my big headache at the moment
I hope to have a patch out in the next few weeks for x86 which will illustrate the concepts of full relocation.
Regards,
G