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? > -- > Tom Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot