[U-Boot] ARM relocation, probably trivial mistake

[Heiko Schocher <hs@denx.de>]

Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <4CA57762.3000201@denx.de> you wrote:
>> If u-boot starts in RAM, then it is the task from the preloader
>> where it copies u-boot code, and if there is somewhere in IRAM
>> enough room for it, this would be an option. Otherwise it is a
>> problem if relocation results in overlapping source and destination
>> areas ... but you will fast detect this problem, when you see,
>> that u-boot no longer works ;-)
> 
> I think we have to be careful here.
> 
> Please keep in mind that the with the new setup the relocation address
> is not a constant, not even for systems that come with a fixed memroy
> configuration.
> 
> If you enable for example the protected RAM feature, the relocation
> address will be shifted down by the amount needed for the reserved
> PRAM area - which is variable, as it can be set through an
> environment variable.
> 
> So assume you have a system with a preloader, and you optimize your
> configuration to load U-Bot to the "final" position close to the end
> of the RAM.  Not the user defines "setenv pram 128" and reboots.
> Now U-Boot will try to relocate itself 128 kB down, which pretty
> reliably causes an overlap.

Good point ...

> Eventually we have to detect such situations and relocate twice then?

Hmm.. just an idea:

We calculate the relocation address in arch/arm/lib/board.c board_init_f()

So, it should be possible to add a check if

relocation_address + u-boot_len < TEXT_BASE

If this is not the case, we can try to relocate twice ... but this
will result in one more copy of u-boot ...

... easier would be, not to use such a setting (relocate address ==
TEXT_BASE) on a board which uses such features ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany