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?
I did a bit of Googling and found: 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? Or the way v7_out_cache_disable() disables L2 is not compatible with the way the kernel expects to re-enable it?
Cheers, Joe
-----Original Message----- From: Tom Rini tom.rini@gmail.com To: Joe Woodward jw@terrafix.co.uk Cc: u-boot@lists.denx.de Date: Mon, 9 Jan 2012 08:11:07 -0700 Subject: Re: [U-Boot] OMAP3 performance regression in 2011.12
On Mon, Jan 9, 2012 at 3:27 AM, Joe Woodward jw@terrafix.co.uk wrote:
Commit "armv7: disable L2 cache in cleanup_before_linux()" on 6th Dec
2011 by Aneesh V adds the following:
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.
However, when running with a stock 3.2 Linux kernel on an OMAP3 it
has the effect of massively reducing system performance (when running using an OMAP3-
only 3.2 Linux Kernel on a GUSMTIX Overo OMAP3530).
Therefore, I assume this means that the kernel isn't turning the L2
cache back on for an OMAP3 (at least with my kernel build)!
So, my question is...
Are there any Kconfig options in Linux that will re-enable the L2
cache (something obvious that I've missed), or is this commit just bad-news for OMAP3?
Are you certain that this is the commit that's causing your problem? The kernel is responsible for turning the cache back on and has for a long time, iirc.
-- Tom