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

[Wolfgang Denk]

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.

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.
- 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.
- You need to implement a way with the different behaviour in terms of
  resources.

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

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

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

> 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, and I seriously doubt that any of these changes to the
linker script have to be board 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.

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

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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Common sense and a sense of humor  are  the  same  thing,  moving  at
different speeds.  A sense of humor is just common sense, dancing.
                                                        - Clive James