[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:57 PM, Albert ARIBAUD <albert.aribaud at free.fr> wrote:
> 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.

Ok, I know what the difference between our opinion now...
You means the uboot should always loaded to TEXT_BASE(for nand case,
as you said).
So when we run to board_init_f, we don't need any relocation.

I am just feel put the code arrange like this would lose a good
feature as original, tftp the uboot to
a different place and use the go command to debug it.

Another question here, why the original implementation now call as
CONFIG_SYS_ARM_WITHOUT_RELOC?
I think CONFIG_SYS_ARM_WITH_RELOC is correct, for it do the relocation
at the very begining. :-p
>
> 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.

Best regards,
Lei