Hi Tom,
On 10 February 2015 at 15:07, Tom Rini <tr...@ti.com> wrote:
> 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 <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.
>>
>> "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?
Related, I sent a v4 series which collects the various gdata/early init patches.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
