[U-Boot] Question about relocation

[U-Boot] Question about relocation

[Alessandro Rubini]

Hello.
I'm trying to make at91sam9261ek working again, but relocation
overlaps the destinatin address.

In this board, u-boot runs already in RAM. This is exactly like the
nhk8815 that I ported a few hours ago, but while there the IPL
loaded our code at the beginning of RAM, in this case the IPL
loaded us already at end of RAM.

Now, this is the printout of the situation:

    U-Boot code: 23F00000 -> 23F36EFC  BSS: -> 23F78570
    monitor len: 00078570
    ramsize: 04000000
    TLB table at: 23ff0000
    Top of RAM usable for U-Boot at: 23ff0000
    Reserving 481k for U-Boot at: 23f64000
    Reserving 180k for malloc() at: 23f37000
    Reserving 24 Bytes for Board Info at: 23f36fe8
    Reserving 144 Bytes for Global Data at: 23f36f58
    New Stack Pointer is: 23f36f50
    RAM Configuration:
    Bank #0: 20000000 64 MiB
    relocation Offset is: 00064000

Since "tor len: 00078570" and "relocation Offset is: 00064000" the
system data-aborts during relocation, as code overwrites relocation
tables.

What is the suggested solution? Changing the IPL is not acceptable for
me, because it is an external tool used by everyone: everybody knows
it loads and runs code at 23f0.0000.

Thanks
/alessandro

[U-Boot] Question about relocation

[Albert ARIBAUD]

Hi Alessandro,

Le 17/04/2011 03:19, Alessandro Rubini a ?crit :
> Hello.
> I'm trying to make at91sam9261ek working again, but relocation
> overlaps the destinatin address.
>
> In this board, u-boot runs already in RAM. This is exactly like the
> nhk8815 that I ported a few hours ago, but while there the IPL
> loaded our code at the beginning of RAM, in this case the IPL
> loaded us already at end of RAM.
>
> Now, this is the printout of the situation:
>
>      U-Boot code: 23F00000 ->  23F36EFC  BSS: ->  23F78570
>      monitor len: 00078570
>      ramsize: 04000000
>      TLB table at: 23ff0000
>      Top of RAM usable for U-Boot at: 23ff0000
>      Reserving 481k for U-Boot at: 23f64000
>      Reserving 180k for malloc() at: 23f37000
>      Reserving 24 Bytes for Board Info at: 23f36fe8
>      Reserving 144 Bytes for Global Data at: 23f36f58
>      New Stack Pointer is: 23f36f50
>      RAM Configuration:
>      Bank #0: 20000000 64 MiB
>      relocation Offset is: 00064000
>
> Since "tor len: 00078570" and "relocation Offset is: 00064000" the
> system data-aborts during relocation, as code overwrites relocation
> tables.
>
> What is the suggested solution? Changing the IPL is not acceptable for
> me, because it is an external tool used by everyone: everybody knows
> it loads and runs code at 23f0.0000.
>
> Thanks
> /alessandro

IIUC, the issue is with the moving of the image. One solution I see, and 
which is not 100% perfect, would be that the copy code perform either a 
beginning-to-end copy or an end-to-beginning copy depending on the 
source and destination addresses and size.

So, when copying say 256K from 0x01000000 to 0x03FC0000, the code could 
do the copy either way, beginning-to end (0x01000000 to 0x0103FFFF) or 
end-to-beginning (0x0103FFFF to 0x01000000); but when copying from 
0x03FB0000 to 0x03FC0000, only the end-to-beginning copy would be possible.

This still leaves holes in that copying U-Boot from RAM to RAM where the 
source is *really* near the end might actually trash the copy code 
itself. Maybe the instruction cache will help, but I won't bet on this 
without heavy testing.

Amicalement,
-- 
Albert.

[U-Boot] Question about relocation

[Alessandro Rubini]

> beginning-to-end copy or an end-to-beginning copy depending on the
> source and destination addresses and size.

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).

It is safer, but not safe. Also, it's difficult to accomplish bcause
copying and fixing addresses is done ina single run, so the relocation
tables are read from the old area. Possibly relocatng first and
copying then.

Or, easier: if we are already high enough to overlap, don't relocate
at all.  If it's acceptable, I'll patch for taht.

thanks
/alessandro

[U-Boot] Question about relocation

[Albert ARIBAUD]

Le 17/04/2011 19:57, Alessandro Rubini a ?crit :

>> beginning-to-end copy or an end-to-beginning copy depending on the
>> source and destination addresses and size.
>
> 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.

> It is safer, but not safe. Also, it's difficult to accomplish bcause
> copying and fixing addresses is done ina single run, so the relocation
> tables are read from the old area. Possibly relocatng first and
> copying then.

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.

> 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". :)

> thanks
> /alessandro

Amicalement,
-- 
Albert.

[U-Boot] Question about relocation

[Alessandro Rubini]

>> 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. 

> 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.
 
>> 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

[U-Boot] Question about relocation

[Albert ARIBAUD]

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.

[U-Boot] Question about relocation

[Alessandro Rubini]

Me:
>> but the calculation is done to move to end of ram, so dest is always
>> higher than source.

Albert:
> 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, I was wrong. Since the display buffer is allocated over
u-boot, we may already be too high.  This never happens for current
boards, which lived before relocation was there (I rember having
lowered the u-boot address to fit a bigger display buffer above it)
but may happen in the future.

So, with the comment the thing may work (like "please for new boards
load it low now that it relocates high by itself").

However, the copy is made in 35 assembly files. Only ARM has 14
almost-identical copies of the code (some of them are really
identical), so I won't dare touching it.

The only thing I can do is not making the copy by forcing dest =
source if we will overlap ourselves, because the assembly will detect
this:

	adr	r0, _start
	cmp	r0, r6
	beq	clear_bss		/* skip relocation */

[I don't understand why here is _start and in C is _TEXT_BASE, which
are different by 0x40 bytes, but it unexpectedly works]

For me it is working, but the code is not clean at all. I'm sending
the patches anyways.  I found the the overwrite was only for the
stack, which is the lowest address in the relocated place, so I
compared some space below the would-be stack with bss_start.

/alessandro