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

[Hans de Goede]

Hi,

On 05-02-15 04:00, Simon Glass wrote:
> 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.

Ack, DRAM setup is iffy, and we definitely want to have (early) console
output working at that point. I do not even want to think about having
to debug DRAM setup without console output.

Regards,

Hans