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

[Tom Rini]

On Wed, Feb 04, 2015 at 09:48:32AM +0100, Albert ARIBAUD wrote:
> Hello Tom,
> 
> On Mon, 2 Feb 2015 13:56:57 -0500, Tom Rini <trini at 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?

I think this sounds about right.  I need to post what I have that is a
good clean up / re-org of some of the code now on a few platforms now
and we'll see how Hans' fixup for sunxi fits in again?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150210/81d15e74/attachment.sig>