[U-Boot] [PATCH 1/3] ARmv7: Add a soc_init hook to start.S

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hello Tom,

On Mon, 2 Feb 2015 13:56:57 -0500, Tom Rini <trini@ti.com> wrote:

> And (and this is being split into
> different email threads, sigh), it would be good, possibly, if we have
> something that means "very early init things, but we can be written in
> C".

"Very early" -- and "early" too, BTW -- is way too vague for me to be
sure we're talking about the same thing, so let's find out what various
earlinesses mean to us. My own view:

"Starting early": the 'start', or 'reset', entry point, can't get
earlier than that. This is where U-Boot resets the target to a known
state (cache disable and invalidate, for instance). For some SoCs, at
this point core registers have to be saved somewhere because they
contain informative values that we want to keep, so we need to be able
to hook this stage. There is no C environment.

"Flipping early": after the entry point but before the DDR is usable.
That's where PLLs/clocks are set up minimaly to get going and have
access to the needed resources including DDR. Still no C environment.

"Effing early": after the DDR was made usable but before relocation.
That's when board_init_f() starts. It's there to get the relocation
right. We have a C environment of sorts, with a stack but without
writable data and without BSS; only GD is writable. That's because
the current *running* address may be in Flash, hence the "_f".
Code called from board_init_f() may set up some more PLLs/clocks,
devices, peripherals, etc. as long as it's needed for relocation
(e.g. querying a display's characteristics in order to compute how
much memory it will reserve from top).

"Erring early": after relocation. That's board_init_r. We have a
full C environment and we're running entirely from RAM ("_r"). 
There, U-Boot does whatever initializations are still needed to
get the payload running.

The actual setting up of environments between stages is supposed
to happen in some architecture code -- for ARM it would all be in
arch/arm/lib/crt0.S.

(if more official names were needed -- and my point sort of *is*
that they /are/ needed, to replace all these "early something"
names we've been using so far -- I'd suggest "reset", "init",
"layout" and "run" respectively.)

So... for me, Tom, your "very early but written in C" maps to my
"effing early" / "layout"; something that has to run first in that
stage should just be first in init_sequence_f[]. OTOH, it /cannot/
be something needed to reset or initialize the target.

Now, /some/ SoCs might be able to set up a C environment of sorts in
place between the "reset" and "init" phases - SRAM, locked cache...
This could be invoked before calling the "init" stage. Generic init
code would not assume any C env, but SoC init code would be able to
use it.

Comments?

> -- 
> Tom

Amicalement,
-- 
Albert.