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

[Lei Wen]

On Sat, Oct 9, 2010 at 4:10 PM, Albert ARIBAUD <albert.aribaud at free.fr> wrote:
> 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 at 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).

Yeah, got that. The TEXT_BASE of 0xf00000 in my case is the exactly what I want
to uboot run during its run time.

>
> 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.

Have you tried load the uboot to different place with tftp or something else?
When I load the uboot to the TEXT_BASE and run, there is also no issue...

>
> 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.

Glad to hear this. :-) But my problem is before relocating, the new scheme call
the init_sequence in board_init_f, while the TEXT_BASE keep the function entry
as static value during compile time. Does the ELF relocation could bring us
a relative jump when call the init_sequence table?

Thanks,
Lei