On Tue, Jan 31, 2012 at 11:57 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > On Tue, 31 Jan 2012, Shilimkar, Santosh wrote: [...] >> I also understand that patching early common code is going to be tricky >> and of-course against the single zImage. >> >> So the option mentioned by Nicolas and Catalin about 1:1 mapping >> and configuring the registers in platform specific code was looking >> a way forward. So was asking more questions about whether this can >> work in all cases. Specifically for A15. > > So far this is apparently your best option. And luckily the code to > create a 1:1 mapping, turn off MMU, then turn MMU back on and tear down > the 1:1 mapping already exists. All you need to do is to insert the > cache workaround activation in the middle of that instead of shutting > the CPU down. > thanks. >> As per Catalin's email, it is best to handle those cases before MMU is >> enabled with boot-monitor or pre-load code. > > These days bootloaders are turning the MMU on for themselves, so you'll > need pre-load code for the bootloader already. Either that, or the > issue is not necessarily _that_ critical in which case you can afford to > enable your workaround a bit later during the kernel boot. > This is indeed a good point. The mainline u-boot(denx) now a days have MMU support so we need to have the necessary WA before that code anyways. We will attempt the 1:1 mapping option as well but to be 100 % safe for the previous 3 statges of MMU ON ( 1. Bootloader, 2. De-compressor and 3. Kernel setup), looks like moving all of this security settings before all 3 stages is most appropriate. Thanks for the good discussion. Regards Santosh -- 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
