-----Original Message----- From: Philip Balister <phi...@balister.org> To: Joe Woodward <j...@terrafix.co.uk> Date: Fri, 13 Jan 2012 15:53:37 -0500 Subject: Re: OMAP3 performance regression in 2011.12
> Did you find out anymore info on this? I may have a customer who is > seeing this on a 3.o based overo. > (CC'ing in the mailing list again). Sadly not, no more replies to this. I think either this change needs reverting (but that'll break OMAP4) or at least encasing in #ifdefs so that it isn't applied for OMAP3. I was going to ask on the Linux OMAP mailing list if the L2/outer cache is enabled on OMAP3 in Linux but haven't got round to it yet! Cheers, Joe > Philip > > On 01/09/2012 10:48 AM, Joe Woodward wrote: > >> -----Original Message----- > >> From: Tom Rini <tom.r...@gmail.com> > >> To: Joe Woodward <j...@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 <j...@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 > > > > (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? > > > > 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? > > Or the way v7_out_cache_disable() disables L2 is not compatible with > the way the kernel expects to re-enable it? > > > > Also, in the Linux there seem to be OMAP4 specific functions for > re-enabling the L2 cache (omap4-common.c:omap_l2_cache_init()), but > none for OMAP3. I'm > > assuming this is because up to now OMAP3 is assumed to have the L2 > left enabled? Either that, or there is some generic Cortex-A8 method > for enabling the L2 > > cache in the kernel soures that I've not found... > > > > Cheers, > > Joe > > > >> > >> _______________________________________________ > >> U-Boot mailing list > >> U-Boot@lists.denx.de > >> http://lists.denx.de/mailman/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot