Hi,
On 05-02-15 04:00, Simon Glass 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.
"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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
