[U-Boot] ARM relocation, probably trivial mistake
Heiko Schocher
hs at denx.de
Fri Oct 1 10:28:38 CEST 2010
Hello Wolfgang,
Wolfgang Denk wrote:
> Dear Heiko Schocher,
>
> In message <4CA57762.3000201 at 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
More information about the U-Boot
mailing list