From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Tue, 17 Jan 2012 18:49:09 +0530 Subject: [U-Boot] OMAP3 performance regression in 2011.12 In-Reply-To: References: Message-ID: <4F15754D.1070203@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Joe, On Monday 09 January 2012 09:18 PM, Joe Woodward wrote: > > (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