[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 10:24, Lei Wen a ?crit :

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

Watch out: TEXT_BASE does not define where u-boot will run, only where 
it will *start running*. With relocation, u-boot will run as high in RAM 
as can be.

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

Not sure I understand what you mean here. U-boot is assumed to *start* 
located at TEXT_BASE, then moved up in RAM, so there should *never* be 
issues with starting u-boot at its TEXT_BASE.

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

Short answer is relocation brings a way to fix all the code and data for 
correct relocation.

Note however, that when board_init_f runs, relocation has not happened 
yet, but OTOH, board_init_f is running at TEXT_BASE, so no relocation is 
needed yet. We need relocation fixup only once the code is moved to top 
of DRAM, and we want to execute board_init_r there.

If you flash u-boot at its TEXT_BASE intended NOR FLASH location, then 
any issue within board_init_f will probably be caused by the code trying 
to write to a global other than gd.

> Thanks,
> Lei

You're welcome.

Amicalement,
-- 
Albert.