On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote: > > On 11/14/2012 12:53 PM, Tony Lindgren wrote: > > Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze > > to not boot when enabled. The ARM core on it is an earlier r1p2: > > > > CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d > > > > Unfortunately I don't have the details of errata 751472, but I'm > > guessing we need to disable it for r1p*. > > I checked the CA9MP errata document and this erratum impacts all > r0/r1/r2 CPUs. I am wondering if the problem is because the workaround > requires you to set a bit in the Diagnostic Control register and the > read-modify-write sequence provided in the workaround is for secure > mode. Not sure if there is a non-secure workaround available :-( Most likely, and there's not a lot that the kernel can sanely do about that. We have ended up deciding (through being forced to because of how the security stuff works) that the stages prior to the kernel will implement the work-around enables because those stages are already platform specific, and the kernel will implement a "test for the work-around already enabled." The net result is, if you enable an Errata in the kernel which your earlier boot stages has not already configured, the kernel will hang. Not much we can do about the hanging aspect, because the kernel takes an exception which we can't trap at those early stages in the boot process. I'm not particularly happy about that design, but that's what we've ended up with through the 'design' of the security stuff forced onto us. -- 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
