[U-Boot] Question about relocation

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Le 17/04/2011 21:30, Alessandro Rubini a ?crit :

>>> Ori, simply, end-to-beginning when moving up. Or always
>>> end-to-beginning since we are expected to always move up (upper than
>>> the target address it can't run).
>
>> Since the 'issue' is caused by the code assuming one direction, I'd
>> prefer it not to assume the other now; I prefer choosing
>> end-to-beginning if target is dest than source, beginning-to-end otherwise.
>
> but the calculation is done to move to end of ram, so dest is always
> higher than source.

I guess I can live with this if you put a big fat comment in the code to 
explain *why* the copy is done end-to-beginning, so that if one day the 
assumption stops holding, readers of the code can tell if they should 
keep or change the direction.

>> Actually no, copying and fixing is not done in a single run. There is
>> the copying of the text+data+const area, then the fixing which runs
>> through the relocation table area; they are different.
>
> Yes, that's what I meant. It's not a memcpy, you also use the data
> after the copy so any overlap is an issue, indepentend of the order
> of copying.

Ok -- you're right, an end-to-beginning copy might trash the relocation 
info. The only solution, assuming we *know* when we are copying from 
RAM, would be to actually apply the relocation fixups to the origin 
location (but still compute them for the destination location!) then 
copy end-to-beginning. You can happily trash the relocation area now.

The only risk left is if the relocation code is going to trash itself 
over, and that will only happen if the origin is so high in RAM already 
that the destination base is below the end of the relocation code --this 
can be tested programatically. To make things easier, this test should 
be done in board_init_f() so that relocate_code() always gets a safe 
destination address. If board_init_f() finds it cannot relocate higher, 
it should just pass the current base address to relocate_code(), in 
which case no copy should happen but relocation should be done for the 
current location.

>>> Or, easier: if we are already high enough to overlap, don't relocate
>>> at all.  If it's acceptable, I'll patch for taht.
>
>> But then comes the question of how enough is "high enough". :)
>
> If there's no overlap, you can relocate. If the areas overal, you keep
> the current address which also is "high enough".
>
> If you ack (even offlist) I'll submit a patch tomorrow (monday)
> /alessandro

Can you submit along the lines of what I described here?

Amicalement,
-- 
Albert.