Hi,
On 26-01-15 16:18, Tom Rini wrote:
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).
Sounds good to me, and I'm fine with working the sunxi side of things.
Since you seem to have this all in your head can you do a patch for this
replacing my patchset ?
Regards,
Hans
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
