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

[Catalin Marinas]

On Tue, Jan 17, 2012 at 12:40:54PM +0000, Shilimkar, Santosh wrote:
> On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V <aneesh at ti.com> wrote:
> > Hi Catalin,
> >
> >
> > On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote:
> >>
> >> On Tue, Jan 17, 2012 at 08:54:44AM +0000, Joe Woodward wrote:
> >>>
> >>> So, is the upshot of this that the kernel isn't going to be in a
> >>> position to enable the L2/outer cache on OMAP3 (due to the need for
> >>> hacky/unmaintainable code)?
> >>>
> >>> Hence the bootloader/uBoot had better leave it enabled...
> >>
> >> It could but the Linux decompressor needs to be aware and either flush
> >> the L2 (more difficult as it doesn't have all the device information) or
> >
> > Cortex-A8 is aware of L2$ and can flush it, isn't it?
> >
> >> set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100).
> >
> > If the above is right, this is not needed right?
>
> Well the L2 can be configured as inner or outer, so above
> alone won't work.
> 
> Boot-loader disabling L2 cache ( all caches)  is still right thing
> and that's what kernel expect.
> 
> Since the early kernel code can't be patches for A8, may be
> delaying L2 enabled would work.

Ah, I missed the fact that the L2 is an inner cache on OMAP3+A8. In this
case, I would argue to just leave it enabled since as long as the MMU is
off it won't be accessed. Why does U-Boot need to disable the L2 (I
suspect via some auxiliary control register)?

> But then on A15, we are back to square one since there is no
> control to turn ON/OFF l2 cache.

Well, it's an inner cache, it gets disabled/enabled via the SCTLR.M bit
as is the L1 cache. It does not need to be disabled independently.

> On A15 infact there are other CP15 registers which needs to be set
> before MMU is enabled to have best configuration.

Yes, there are, and my view is that it is up to the platform firmware to
set things right.

-- 
Catalin