On Tue, 31 Jan 2012, Shilimkar, Santosh wrote: > On Tue, Jan 31, 2012 at 3:26 PM, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: > > So, as many people have said, we're not going to go down the route of > > allowing platforms to hook into this code. There's plenty of other > > solutions to this problem in different parts of the system that would > > be more than adequate, and would benefit everyone not just the kernel. > > > Sure. The marco has missed those details. Thanks for the > useful information. At least I can fix the stack size for internal > use. If you intend to ignore our advises and continue with the quick and dirty solution for your internal tree, then at least don't brag on a public list about it. > > Your continued resistance to every alternative suggestion but your > > (broken) hook is getting extremely frustrating. Please try some of > > these other approaches which are being proposed. Thanks. > > I was just trying to get more information about the alternatives and > trying to bring out possible issues. I know for sure that boot-loader is > not an option since we have had many instances where it has not worked. > > 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. > 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. Nicolas
