* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [121114 12:24]: > 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. Checking for the bit already set should work in this case, I'll post a patch for that shortly. 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
