[U-Boot] OMAP3 performance regression in 2011.12

[Aneesh V <aneesh@ti.com>]

Hi Joe,

On Monday 09 January 2012 09:18 PM, Joe Woodward wrote:

<snip>

>
> (apologies for previous top posting, wasn't paying attention to what I was doing!)
>
> I'm fairly certain...
>
> If I take the 2011.12 uBoot release the kernel takes about twice the time to boot (compared to 2011.09), and the device is noticably slower.
>
> Then if I comment out the v7_out_cache_disable() line in cpu.c and rebuild uBoot then everything speeds up again.
>
> I thought the kernel would turn on the cache again too...
>
> Is there any easy way from userspace to determine if the cache is on?

It won't be easy I believe, unless you have a debugger that allows you
to see CP15 registers.

>
> I did a bit of Googling and found:
> http://www.spinics.net/lists/arm-kernel/msg50064.html
> http://www.spinics.net/lists/arm-kernel/msg50083.html
>
> It may be that the kernel is re-enabling the L1 cache, but expecting L2 to be on?

Ideally kernel should be enabling L2 too. But looks like L2 was enabled
by ROM code itself in OMAP3, but D-cache disabled globally. So, it gets
enabled as soon as the D-cache is enabled globally.

L2$ in OMAP3 is a bit tricky. The cache is known to ARM but
enabling/disabling it and affecting secure entries needs ROM
assistance. So, while ARMv7 generic code can flush L2, we need OMAP
specific code to enable/disable it.

So, before my patch and before cache-support came to U-boot L2$ always
remained enabled. Since de-compressor's flush indeed flushed L2$ we
didn't get into any coherency problems.

Let the discussion in l-o conclude. I think fixing it in kernel is the
right thing to do. But if that's not possible, we can have a patch in
U-boot to work around it.

br,
Aneesh