Hi Albert,
On 5 February 2015 at 08:14, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote:
> 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.
That's right, I didn't mean the console is needed by board_init_f(),
just that it is set up by board_init_f(), before init_dram().
>
>> > 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.
I can see in some rare cases we would want to store data here (as you
say in the next paragraph) and in that case, initialised data is a
good option - we cannot use BSS and it is ugly to write to memory
directly. My sunxi patches store lr and sp, for example.
>
> 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.
All of the above sounds good to me. Yes forerun has an f. I think it
is better than the other things I can think of (find, furnish,
formulate, fabricate, former)
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
