[U-Boot] [PATCH 12/26] ARM: add relocation support

[Albert ARIBAUD]

Le 17/09/2010 16:52, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4C9365E7.50505 at free.fr>  you wrote:
>>
>>> - You need a way to detect if you are running on a virgin CPU fresh
>>>     out of reset or on a pre-initialized system.
>>> - You need to isolate parts in the initialization sequence that must
>>>     not be repeated.
>>> - You must make sure such steps are not re-run on a pre-initialized
>>>     system.
>>
>> This is not required per se to 'start from any location'. It is required
>> to 'start in any state', which is another requirement -- also
>
> "start in any state" is only possible by going through the hardware
> reset.

Depends on the processor I guess; but still, my point is that "start at 
any location" does not require that you detect whether you are fresh out 
of reset or not.

> There are messed up situations where you cannot recover the
> processor any more by software.

Possibly. So what?

> You probably mean "virgin state after reset" versus "some other, but
> sane state, for example while running U-Boot". You cannot separate
> these.

Yes, I mean start in any sane state, and I think this is a different 
problem that "start from any location".

> If you want to start from another location, you must run some
> other code before that (as the CPU will always start from the boot
> vector only), so your system state has been changed.

On ARM, the other code could be a single branch instruction, in which 
case for all practical purposes the only part of the state that would 
changed is the pc, which is already prone to changing a lot.

>> commandable since it increases resilience to varying conditions. I think
>> the 'start from anywhere' requirement can be fulfilled without
>> fulfilling (yet) the 'start in any state' one.
>
> But not without being able to "start in another, non-virgin state".

Maybe on some architectures this other state is considerably different 
to the point that u-boot could not start properly; on arm926ejs (and, I 
suspect, on other ARMs as well) the 'non-virginity' can be limited to 
"having done some reads, writes and branches" without preventing u-boot 
from starting using exactly the same code as it would if executed 
directly on reset. That's tested, and actually used in production on 
several arm926ejs based boards.

>>> - You need to implement a way with the different behaviour in terms of
>>>     resources.
>>
>> This requirement sounds very general; can you be more precise on it?
>
> After reset you have no RAM, no stack, no BSS, no writable data
> segment, etc. etc. When starting from some other code, conditions may
> be different.

On orion5x the DRAM controller can be fully reinitialized, and I suspect 
it is not the only one which can do this.

>> Now, for arm926ejs, it so happens that prior to Heiko's relocation
>> patches, u-boot's startup code *was* position-independent, and is not
>> any more, but that making init_sequence (and other data read during
>> startup) onst makes it p-i again.
>
> OK.
>
>>> I lost you.  If you put the U-Boot image at an arbitrary location in
>>> flash, the CPU will not start it because the CPU begins execution at
>>> the reset vector.
>>
>> You're mistaking "putting the image anywhere in FLASH" and "putting
>> _start anywhere in FLASH".
>
> _start is integral part of the U-Boot image...

I did not sayt it wasn't -- but this point shall be better understood 
when I publish my patch above Heiko's code, with consts added where due.

>>>> As for the half-hour of effort, the half-hour part is an assumption
>>>> which would need supporting, and even if it is only half an hour, it is
>>>> half an hours for each person configuring u-boot for arm; a burden that
>>>
>>> No. Only for those who have a system with such a reset vector
>>> location,
>>
>> That is, all people using orion5x for instance.
>>
>>> and I seriously doubt that any of these changes to the
>>> linker script have to be board specific.
>>
>> I did not say board-specific, I said config-specific.
>
> It does not depend on board configuration or such. It depends only on
> your system's memory map (location of the reset vector), and this is
> constant - for example - for all orion5x boards.

Reminder: here we're talking about fitting a >64 KB u-boot in flash, 
with _start at the reset vector (0xffff0000 on orion5x), without wasting 
the space above the reset vector (64 KB on orion5x) and with minimal 
waste in the rest of the mapping.

You suggested tweaking the linker file to manually place the _start 
symbol at the reset location, and then bin-pack the rest of the code -- 
some of which will have to go above _start, some below. This can only be 
achieved by defining 'MEMORY' regions in the linker file, and then you 
have to decide what sections go in the top region with the start.o .text 
section, and define another region big enough for what's left. And then, 
if you add or remove a configuration option, you section sizes will 
either grow or shrink; you risk a 'region full' link failure or a hole 
growing in the mapping, so you have to do it all over again.

This is why I say that the proposed solution of manually tweaking the 
linker file is sensitive to configuration changes.

>> Only for a given u-boot configuration. Change it, and that changes the
>> image content, thus the mapping, and you've got to fix _start again.
>
> Why should I?

Your change may overfill one of the 'MEMORY' regions that would have to 
be defined to get _start mapped to the reset vector location. 
Personally, I hate it when I enable some configuration option and it 
results in a link-time mapping error.

>  Did you not state that the reset vector is at a fixed
> location? Then we can use constant data (comon to all board
> configurations) to fill the gap between there and end of physical
> memory space.

That will not fill it properly and consistently unless that constant 
data is 1) really constant across all configuration option choices for 
all boards and 2) nicely filling the gap up to 64 KB.

> Best regards,
>
> Wolfgang Denk

As I said, I have a solution for my problem which puts _start at the 
reset vector location without changing the linker file at all, and with 
little, contained and controlled changes to the start.S file. I will 
post this as a [PATCH][NEXT] ([RFC] also if you will), clearly exposing 
the issue it addresses and the solution it uses, and we can discuss its 
merit then.

Amicalement,
-- 
Albert.