On 6/27/05, Wolfgang Denk wd@denx.de wrote:
Dear Andreas,
in message 3YJEA6HGSNLF3264765ZTQSQYSRNJI43.42bffa31@pc-block you wrote:
It's just that not many people really understand all the details how the relocation works.
<stuff deleted>
I guess you can probably tell GCC to add GOT entries for these pointers, but I have to admit that I don't know off-hand what's the most efficient way.
Just to satisfy my curiosity...
What is the design decision behind u-boot building as a single relocatable binary (with all the complexities associated with relocation)? As opposed to a a two stage process with a small chunk of bootstrap code encapsulating the main u-boot image. The bootstrap code being linked seperatly from the main image so each image runs in the address space it is linked to. (like a Linux zImage; bootstrap code only responsible for initializing RAM, copying the main image and jumping to it).
I can see that a two stage scheme would sidestep the relocation issues mentioned above and should make probing with a debugger simpler. What are the advantages of the single binary approach? Image size perhaps?
Cheers, g.