[U-Boot] Question about relocation

Albert ARIBAUD
2011-04-17T19:47:17Z

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.