On Fri, Jan 23, 2015 at 09:54:12AM +0100, Hans de Goede wrote: > Hi, > > On 22-01-15 22:03, Tom Rini wrote: > >On Thu, Jan 22, 2015 at 08:10:06PM +0100, Hans de Goede wrote: > >>Hi, > >> > >>On 22-01-15 17:20, Tom Rini wrote: > >>>On Wed, Jan 21, 2015 at 09:03:25PM +0100, Hans de Goede wrote: > >>> > >>>>On some SoCs / ARMv7 CPU cores we need to do some setup before enabling > >>>>the > >>>>icache, etc. Add a soc_init hook with a weak default which just calls > >>>>cpu_init_cp15. > >>>> > >>>>This way different implementations can be provided to do some extra work > >>>>before or after cpu_init_cp15, or completely replacing cpu_init_cp15. > >>>> > >>>>Signed-off-by: Hans de Goede <hdego...@redhat.com> > >>>>--- > >>>> arch/arm/cpu/armv7/start.S | 18 +++++++++++++++++- > >>>> 1 file changed, 17 insertions(+), 1 deletion(-) > >>>> > >>>>diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S > >>>>index fdc05b9..9882b20 100644 > >>>>--- a/arch/arm/cpu/armv7/start.S > >>>>+++ b/arch/arm/cpu/armv7/start.S > >>>>@@ -64,7 +64,7 @@ reset: > >>>> > >>>> /* the mask ROM code should have PLL and others stable */ > >>>> #ifndef CONFIG_SKIP_LOWLEVEL_INIT > >>>>- bl cpu_init_cp15 > >>>>+ bl soc_init > >>>> bl cpu_init_crit > >>>> #endif > >>> > >>>I like the direction here. And I want to make sure I get the sunxi > >>>direction right here too (as I agree with the need / desire for boot0 + > >>>U-Boot to be a valid combination). I think we can take this a step > >>>farther. cpu_init_crit (on armv7) is basically a call to s_init(). > >>> > >>>For am33xx (and I bet but need to do and test omap3+) we can, with > >>>Simon's patch to let us move stack to DDR a tiny bit later, in the SPL > >>>case make s_init empty, which just leaves us with (with your patch) > >>>soc_init. Is there some way we can put all of this together in a > >>>function? > >> > >>You mean essentially call s_init here and have s_init call cpu_init_cp15 > >>I guess we could do that, but it would require auditing all existing armv7 > >>users of s_init. This may require me to rethink how / when I do timer & > >>gpio init etc. for u-boot.bin on sunxi, but that should not be a (big) > >>problem. > > > >Basically. From my first pass audit of s_init, it's either empty > >(Kona), sunxi, or omap/etc so I get to deal with it. And the default > >soc_init would just be the call to cpu_init_cp15 as you have it and we > >drop the lowlevel_init hurdles. > > Ok, so what you're suggesting is a patch which: > > 1) Changes: > > #ifndef CONFIG_SKIP_LOWLEVEL_INIT > bl cpu_init_cp15 > bl cpu_init_crit > #endif > > Into: > > #ifndef CONFIG_SKIP_LOWLEVEL_INIT > bl lowlevel_init > #endif > > Which will setup the stack and then call the s_init C function > > 2) Adds a weak default s_init which calls cpu_init_cp15 > > 3) Patch all existing s_init functions to call cpu_init_cp15 > before doing anything else.
Pretty close. Simon's SPL DM series and related clean-ups got me thinking that yes, seemingly too much got shoved into "s_init" that really could have been done using an existing hook done slightly later. > And then in follow up patches we can: > > 4) Drop cpu_init_crit > > 5) Cleanup some s_init functions (this will be left to the individual > SoC maintainers) > > I think that is a good idea, Albert what do you think about this ? So I'd like to see 5 done "soon" afterwards as it's me (omap*) and sunxi. I think we can simplfy the call sequence too, to roughly: #ifndef CONFIG_SKIP_LOWLEVEL_INIT ... Set up stack for C, it's just a few instrs bl lowlevel_init #endif bl _main __weak asm lowlevel_init: bl cpu_init_cp15 return to caller And comment that anything called via lowlevel_init must be C-callable. I hope that once #5 is done no one actually has a lowlevel_init that's done in C but we've kept the door open should it be needed down the road (as I _think_ we can shuffle both the omap* and sunxi stuff to do their inits as needed in both SPL and full U-Boot from an early hook in board_init_r, top of my head is board_init calls some_other_func() in full U-Boot to ensure GPIOs, etc, on sunxi and spl_board_init() calls same func in SPL, and we can consolidate again further down the road as we get SPL and full U-Boot more in sync on the call chain). -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot