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

[Wolfgang Denk]

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. There are messed up situations where you cannot recover the
processor any more by software.

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

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


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

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

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

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

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
If a train station is a place where a train stops,
                                           then what's a workstation?