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

[Russell King - ARM Linux]

On Mon, Jan 16, 2012 at 11:18:21AM +0100, Shilimkar, Santosh wrote:
> + linux-arm, Russell and Catalin
> 
> On Mon, Jan 16, 2012 at 11:03 AM, Joe Woodward <jw at terrafix.co.uk> wrote:
> > The latest uBoot release (2011.12) disables the L2/outer cache during boot on OMAP boards.
> >
> > uBoot commit: "armv7: disable L2 cache in cleanup_before_linux()" on 6th Dec 2011 by Aneesh V adds the following to
> > uBootSources/arch/arm/cpu/armv7/cpu.c:cleanup_before_linux():
> >  ...
> >  v7_out_cache_disable();
> >
> > The commit message implies this change was to make booting reliable on OMAP4 by disabling L2 cache before jumping to Linux. Sadly
> > this commit also affects OMAP3-based boards...
> >
> > Since switching to uBoot 2011.12 I'm seeing about half the performance on my GUSMTIX Overo (OMAP3530).
> >
> > In the kernel sources there seem to be OMAP4 specific functions for re-enabling the L2 cache (omap4-common.c:omap_l2_cache_init()),
> > but none for OMAP3.
> >
> > So my question is... do we expect that Linux should be re-enabling the L2/outer cache during boot after uBoot has disabled it on OMAP3?
> >
> Yes. Kernel already does enabled L2 on A8 CPU's but OMAP3 needs a
> secure call and then the patching becomes
> that much difficult.
> 
> We need some kind of generic hook in proc*_setup() function where in
> such secure bits can be turned ON.

You can't have that kind of hook: there is no stack here to call other
functions, plus we aren't running with the MMU on at that point so
only carefully crafted assembly could be used.

Why is it soo difficult to issue the secure call?

This just proves my point that the lack of consistent secure monitor API
for these kinds of basic service _are_ a big problem, one which ARM Ltd
should have addressed when they invented this stuff.  My view continues
to be that the secure monitor API is a total abortion, one which should
never have been allowed to happen.