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