Hello Simon,
On Wed, 4 Feb 2015 20:00:48 -0700, Simon Glass <s...@chromium.org> wrote:
> Hi Albert,
>
> On 4 February 2015 at 01:48, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote:
> > Hello Tom,
> >
> > On Mon, 2 Feb 2015 13:56:57 -0500, Tom Rini <tr...@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.
See below (*)
> > "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.
Understood. But even console is not needed by board_init_f -- actually,
board_init_f *does* initialize the console. So the only thing that is
needed after resetting the core to a known state and before entering
board_init_f() is... To make sure board_init_f() can run, which is not
much: for instance, locking cache to be used as SRAM for stack and GD
-- basicaly what armv7 does.
> > 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:
[I think we should separate the hardware items (do we have DDR? do we
have PLLs? etc) from the program concepts (do we have a stack? Do we
have data write access? Do we have BSS?. My comments below reflect that]
> reset - no stack, no RAM ( (except SPL can presumably access data section)
More precisely: from a hardware viewpoint there would be no DDR, but
there could be SRAM, and from a program viewpoint, no stack and no
writable data: text, rodata and initialized data sections could be read
from, but should never be written to.
Plus, this stage should be strongly restricted to the role of saving
what is vital and urgent to save. If there is SRAM, the reset stage
could use it. If there is no SRAM but cache, the reset code could lock
the cache and use it as SRAM. But in most cases, there should be only a
few registers to save, and these could be saved inside the core (e.g. in
the FIQ banked registers), so the reset stage should really only be a
few assembly language instructions long.
> init - no stack, no RAM (except SPL can presumably access data section)
Same as reset. The difference is that we now have full use of
the core registers without fear of trashing something important.
This stage should limit itself to resetting the target to a known valid
state.
> layout - stack, RAM for global_data, but no DRAM
Not exactly. From a hardware standpoint, still no DDR, just like
previous stages; from a program perspective, we gain a stack and that's
all: we wtill cannot write to data and BSS, we still can only write to
GD.
> run - stack, DRAM, global data in DRAM
AKA "Full C environment" (whether in DRAM or in generous SRAM does not
matter).
"layout" does not entirely cover what board_init_f() does, though, and
I don't like "init" when what it does is actually resetting the board
to a known state -- yes, I know we often use "reset" for "restart". How
about this?
"start"
"init"
"forerun"
"run"
You've got the "f" that you wanted :) and the "run" in the third and
last stage are nice reminders that we do have a run-time C environment
there, except the third stage is not quite a running environment yet.
> Regards,
> Simon
Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
