[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 09/10/2010 09:53, Lei Wen a ?crit :
> Hi Albert,
>
> On Sat, Oct 9, 2010 at 3:43 PM, Albert ARIBAUD<albert.aribaud@free.fr>  wrote:
>> Le 09/10/2010 07:50, Lei Wen a ?crit :
>>> Hi,
>>>
>>> I recently try to port our board code to new uboot, which has been
>>> changed to use new relocation scheme.
>>> But I found a very strange thing, that is if the uboot is loaded to
>>> the TEXT_BASE address, it could run without
>>> problem. But if it is loaded to a different place, it fail to boot up...
>>>
>>> I check the code, and found that in the board_init_f, it calls the
>>> init_sequence which is stored as a data sector
>>> in the u-boot.bin file. While the new scheme use the fPIC, the code
>>> could locate the GOT table correctly,
>>> and it seem to forgot what the GOT table stores is context that is
>>> meaningful in TEXT_BASE, not the loaded base.
>>> That is to say, if the TEXT_BASE is 0xf00000, and loaded base is
>>> 0x500000, I found the GOT table also filled
>>> with 0xf0****, not the 0x50****. This leads the cpu loading wrong
>>> function address in the init_sequence table, and
>>> cause pc become invalid...
>>>
>>> Am I missing something to switch to the new relocation scheme?
>>>
>>> Thanks,
>>> Lei
>>
>> Can you indicate which hardware (architecture, cpu, SoC, etc) you're
>> running this code on?
>>
> I am running the code on Marvell aspen soc, which is arm926ejs compatible core.

For arm926, TEXT_BASE should be the FLASH location (if booting from NOR) 
or a location in DRAM (for NAND and other methods).

I have had little difficulty in running the .got relocation code in a 
Marvell oront5x (arm926ejs too), except for some functions called from 
board_init_f which did not respect the general rule that code run before 
relocation should only access gd; one place in orion5x wrote to global 
variables, which always was a no-no and only happened to work because 
the arm926ejs init sequence did not run in proper order.

However, .got relocation has shortcomings of its own; mainly, it 
requires manual fixups in many places within the code. I have provided 
patches which replace .got relocation with ELF relocation (look up 
[ELF-RELOC] tags in the posts), which eliminates the need for any manual 
fixup; you may want to try this, as it might eventually replace the .got 
patches.

> Best regards,
> Lei

Amicalement,
-- 
Albert.