[U-Boot] [PATCH 12/26] ARM: add relocation support
Albert ARIBAUD
albert.aribaud at free.fr
Fri Sep 17 14:58:15 CEST 2010
Le 17/09/2010 13:05, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4C9307C4.40208 at free.fr> you wrote:
>>
>> Things do change indeed, hence my attempt à 1) making sure I detect the
>> change, 2) design things so that they are as resilient to change as
>> possible. One example of such a resilience is making sure the u-boot
>> code designed to run in FLASH can run *anywhere* in FLASH.
>
> As for 1), just follow the postings on this mailing list.
Check. :)
> As for 2), you need to implement the following features (none of which
> are supported yet, AFAICT):
>
> [This is based on the assumption that you want to use the very same
> binary image fom different addresses]
>
> - The code must be completely position-independent.
This is indeed what I am trying to achieve by suggesting qualifying
const init_sequence and any other constant data used by u-boot while
executing from FLASH.
> - 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
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.
> - 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?
>>>> As for what I am trying to do: ironically, I am trying to find a way
>>>> that the entry point of u-boot be at the reset vector location, just as
>>>> it should.
>>>
>>> There it is.
>>
>> Yes. And you are opposing this, which I do not understand since I'm
>> trying to make this SoC/board perform exactly as you specify while
>> maintaining balance with the hardware's constraints.
>
> I do not understand what you mean. Unless loaded by some other
> mechanism (like when booting from NAND flash etc.), the entry point
> to U-Boot *is* of course at the reset vector location - or how would
> the CPU be able to execute the code?
Yes, u-boot needs to be stored in FLASH so that at execution time the
_start symbol is mapped at the physical location of the reset vector.
But no, u-boot does not necessarily need to be linked so that the _start
symbol maps at the vector reset location; not, at least, if the startup
code is position-independent.
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.
>>> If you can live with the wasted 64 kB of empty space "behind" the
>>> reset vector, then it is not worse than counting the number of flash
>>> sectors needed for the image (which you have to do anyway to
>>> determine the TEXT_BASE). And moving a number of static,
>>> never-changing objects into that free area is no real rocket science
>>> either. Say, half an hour of efforts including basic testing.
>>
>> Precisely, I do not want to live with wasting 64 out of 512 KB of FLASH.
>
> OK, se put a few objects in that "hole" to fill it.
This is a bad approach, as I explain below.
>> Regarding counting the flash sectors for mapping u-boot to flash to
>> determine TEXT_BASE, I never had to, thanks to u-boot being (albeit
>> accidentally) able to run from anywhere in FLASH (I can't help seeing
>> irony in the fact that this ability was broken by adding a flag which is
>> supposed to allow running from anywhere).
>
> 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".
>> 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.
> That means you just need to
> perform this task once to improve the platform-specific linker script,
> and it will automatically work for all other users of that
> architecture as well.
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.
>> This statement does not contradict the proposal that U-boot, despite
>> being linked for some address in FLASH, should be able to run, from
>> _start to relocation, at any FLASH location at least for architectures,
>> CPUs, SoCs or boards which trivially allow this. I do believe this
>> requirement is both reasonable and useful.
>
> If you know how to implement this in a clean way, then please go
> forward and do it. Patches are welcome. All I can say is that I don't
> know how to do that, but then, I'm not an ARM expert. Eventually it
> might be easier on ARM than on PowerPC, where we don't have this
> feature yet either.
I do know how to implement this indeed -- I actually have a working (and
thoroughly tested) implementation, but valid for the master branch,
without Heiko's patches; I am working on making it work with Heiko's
patches right now. I can send a patch set based on master to the list as
an RFC.
>> Anyway: there is a bottom line on which I think we agree now:
>>
>> 1) init_sequence is a constant array and should thus be qualified 'const';
>>
>> 2) any data accessed between _start and relocation should be const as well.
>
> I think you mean the right thing, but the wording is wrong again.
>
> You can fully access (read and write) data in the special "global
> data" or "initial data" structure.
In that respect I may indeed have expressed myself inadequately. When I
said that a driver's _f init function could pass data via 'globals space
allocated below the stack, I should have said 'above' -- but I had
clearly expressed that I was talking about the memory area where gd lives.
> You can perform read-accesses to
> any data in the text and/or data segments. You cannot write to data in
> the the text and/or data segments. You must not attempt to access any
> data in the bss segment because this does not even exist, so you're
> accessing random addresses.
I think none of this contradicts either of points 1) and 2) above. Or
does it?
> Best regards,
>
> Wolfgang Denk
Amicalement,
--
Albert.
More information about the U-Boot
mailing list