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

[Simon Glass]

Hi Albert,

On 4 February 2015 at 01:48, Albert ARIBAUD <albert.u.boot at aribaud.net> 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.

This is the current lowlelvel_init() I think. I don't believe it
should set up DDR.

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

At present board_init_f() ses up DDR and I'd prefer we keep that, e.g.
with console output before DDR is ready.

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

For 'layout' could we have a word that starts with 'f'? Flash? Frame?
Is it better to use relocated rather than run? Still, run is shorter.

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

Some sort of RAM has to exist before board_init_f() is called. Your
suggestion was to not allow a stack in the 'init' phase I think. So
perhaps we should lock these down more tightly:

reset - no stack, no RAM ( (except SPL can presumably access data section)
init - no stack, no RAM (except SPL can presumably access data section)
layout - stack, RAM for global_data, but no DRAM
run - stack, DRAM, global data in DRAM

Regards,
Simon