On Tue, Jan 17, 2012 at 12:40:54PM +0000, Shilimkar, Santosh wrote: > On Tue, Jan 17, 2012 at 1:27 PM, Aneesh V <aneesh@xxxxxx> wrote: > > Hi Catalin, > > > > > > On Tuesday 17 January 2012 05:41 PM, Catalin Marinas wrote: > >> > >> On Tue, Jan 17, 2012 at 08:54:44AM +0000, Joe Woodward wrote: > >>> > >>> So, is the upshot of this that the kernel isn't going to be in a > >>> position to enable the L2/outer cache on OMAP3 (due to the need for > >>> hacky/unmaintainable code)? > >>> > >>> Hence the bootloader/uBoot had better leave it enabled... > >> > >> It could but the Linux decompressor needs to be aware and either flush > >> the L2 (more difficult as it doesn't have all the device information) or > > > > Cortex-A8 is aware of L2$ and can flush it, isn't it? > > > >> set the page table attributes to outer non-cacheable (TEX[2:0] = 0b100). > > > > If the above is right, this is not needed right? > > Well the L2 can be configured as inner or outer, so above > alone won't work. > > Boot-loader disabling L2 cache ( all caches) is still right thing > and that's what kernel expect. > > Since the early kernel code can't be patches for A8, may be > delaying L2 enabled would work. Ah, I missed the fact that the L2 is an inner cache on OMAP3+A8. In this case, I would argue to just leave it enabled since as long as the MMU is off it won't be accessed. Why does U-Boot need to disable the L2 (I suspect via some auxiliary control register)? > But then on A15, we are back to square one since there is no > control to turn ON/OFF l2 cache. Well, it's an inner cache, it gets disabled/enabled via the SCTLR.M bit as is the L1 cache. It does not need to be disabled independently. > On A15 infact there are other CP15 registers which needs to be set > before MMU is enabled to have best configuration. Yes, there are, and my view is that it is up to the platform firmware to set things right. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
