OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?

[Russell King - ARM Linux]

On Mon, Jan 16, 2012 at 01:43:03PM +0100, Shilimkar, Santosh wrote:
> This code will be in assembly and that's what I have
> been using. Not having stack shoudn't be a blocker
> and can be work-around in this code. And this API
> has to be anyway called before MMU is enabled.

What about SMC on OMAP potentially corrupting most of the integer
registers?  What if it corrupts an integer register which we depend
upon?  You don't have a stack here to save those registers.  We'd
need at least one additional register to save the old 'lr' value.

What about other secure monitors?  Some implementations require you to
give parameters via memory.  How do you obtain that memory that early
on in the kernel boot (you haven't parsed anything here.)

Not only that but you're asking to make the kernel boot a _lot_ more
fragile, when people start stuffing all kinds of utter shite into this
hook - and then we're burdened again with the old 'my kernel won't
boot and it remains silent, well your debug code is utter shite get rid
of it' crap that we used to have in the early 2000s.

I really don't want to go anywhere near that situation.

> Am not sure what you mean because secure API
> as such isn't a problem. If you mean one standard interface
> for all the ARM SOC's then that's something won't be
> easy to handled because it is tied up the security architecture
> which can vary across SoCs.

The latter.  This is exactly the kind of pain I forsaw with this security
shite, and when I heard about it I was utterly dismayed at ARM Ltd for
coming up with such a brain-dead lack of design here.

You're having to struggle with the results of that by having lots of
SoC specific hooks all around the place to fiddle with this that and the
other.  Your need to have something called from the early assembly code
is just yet more of that disease caused by ARM Ltd's lack of forsight
on this matter.

I have no solution for you on this.