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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
