* Matthijs van Duin <matthijsvanduin@xxxxxxxxx> [150406 20:50]: > On 7 April 2015 at 04:23, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > Oops, sorry user error.. I was trying to clear IBE as a banked register > > like L2 enable bit and of course it did not get cleared.. Clearing it > > with a smc call really clears it. And in that case my test case seems to > > work reliably on r3p2 without erratum 430973 enabled. > > So if I understand correctly, you actually had crashes which only > occurred with IBE enabled and the 430973 workaround disabled? That's right. It seems to happen at least with r3p2 that has 430973 fixed. > That's quite interesting, since it seems to me that can only be the > result of erratum 687067, which means > 1. secrom indeed fails to implement the 687067 workaround. > 2. "BTB invalidate by MVA" is used somewhere in the kernel. > The 430973 workaround would likely conceal this problem due to > regularly flushing the whole BTB, but I'm not sure how wise it is to > rely on that... Yes it seems to be hidden behind 430973. Anyways, we can print some warnings in the kernel for incorrect revision and IBE handling. > > I'm now thinking the kernel should just always set the 430973 specific > > cpu_v7_switch_mm for all cortex-a8 if IBE bit is set. > > And simply take the performance hit if secrom bogusly sets it and the > bootloader doesn't fix it? Yes it seems Russell's patch should do that for cortex-a8. > Sounds reasonable enough to me, given how platform-specific the > appropriate auxcr config is, as well as the means by which it can be > changed. Right, we have quite a few combinations already for omap3.. 34xx/36xx, HS/GP, TI vs Nokia bootrom.. Just proves how useless all these "security" "features" are in the long run :) They will just keep biting people over and over in the long run even if not used. > There's more secrom misconfiguration that the bootloader should fix > anyhow to make optimal use of the processor... Yeah. > > This will work as long as we can read the aux ctrl register IBE > > bit using mrc, which I believe is the case for all cortex-a8 based > > omap variants. > > Aux control is always readable, only write is an issue. OK, hopefully that's the case for 36xx HS version too.. I recall some registers reading as zero on N9 but hopefully not for the aux control register. > On 7 April 2015 at 05:12, Sebastian Reichel <sre@xxxxxxxxxx> wrote: > > If I understood it correctly we can simply call the BTB flush on > > cortex-a8 if IBE bit is not set, since it would be translated as > > nop. > > Indeed you can safely use the BTB-flushing context switch on any cortex-a8. > > There's still value in checking if IBE is set on r2p1 or later, and if > so emit a warning about suboptimal performance. > > > So it should be safe to include the call on all cortex-a8 based > > cpus. We may need a non-BTB-flushing function for non-cortex-a8 > > based cpus, though. > > I just looked it up, apparently BTB-flushing on context switch is not > needed architecturally in ARMv7 (though it was in ARMv6), so that > version should probably indeed only be used for the cortex-a8. OK Regards, Tony -- 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
