[U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme

[Aneesh V]

On Friday 11 February 2011 06:16 PM, Albert ARIBAUD wrote:
[snip...]
>>>
>>> Note also that there was a recent patch to ARM926's start.S (replacing
>>> 'adr r1, _start' with 'ldr r1, _TEXT_BASE' at line 284). The same should
>>> be done on arm1136.
>>
>> Is this going to happen for armv7 too? What is the real reason behind
>> this proposal. What is the case when _start is not same as _TEXT_BASE(I
>> looked at the archives but couldn't filter out the original discussion
>> on this)
>
> The difference is that _TEXT_BASE always contains the link-time address
> of _start, whereas references to _start may contain a different value if
> the code is executed somewhere else than at the link-time address.
>
> /Normally/, u-boot should always execute first at the link-time address
> -- that's a base constraint.
>
> /But/ this change makes it more resilient to out-of-link-time-address
> execution, and I want, at some time in the future, to find a way for
> u-boot to be able to start anywhere -- within reasonable limits:
> anywhere in NOR for a NOR-based U-boot, anywhere in RAM for a RAM-based
> U-boot, but I am not talking about a generic,
> run-in-RAM-or-NOR-or-anywhere, binary.
>
> Yet. :)
>
>> I see a problem with that. _TEXT_BASE is based on
>> CONFIG_SYS_TEXT_BASE. In our SPL's case CONFIG_SYS_TEXT_BASE indicates
>> the TEXT_BASE for u-boot and *CONFIG_SYS_SPL_TEXT_BASE* indicates the
>> TEXT_BASE for SPL. Both are defined and useful in SPL because one is
>> used for linking SPL while the other is used while loading u-boot from
>> MMC. So, CONFIG_SYS_TEXT_BASE used in the start.S of SPL will not be
>> correct.
>
> The change I indicate is under the #else of a #ifdef CONFIG_NAND_SPL, so
> it will not apply to SPL. Does that still cause an issue with armv7?

No. It doesn't. I am fine with this change if it applies only to u-boot.

br,
Aneesh