| Message ID | 20121114185335.GU6801@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Nov 14, 2012 at 10:53:35AM -0800, 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*. Fails because it can't write the diagnostic register from non-secure mode or fails later? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 :-( Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Russell King - ARM Linux <linux@arm.linux.org.uk> [121114 11:03]: > On Wed, Nov 14, 2012 at 10:53:35AM -0800, 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*. > > Fails because it can't write the diagnostic register from non-secure > mode or fails later? Hmm good question, it fails a bit later on during the boot just before __enable_mmu. But I just tried commenting out the setting of bit 11: @orrlt r10, r10, #1 << 11 @ set bit #11 And just trying to write the unmodified diagnostic register also makes it fail. So yeah it seems to be related to the secure crap instead :( Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Jon Hunter <jon-hunter@ti.com> [121114 11:09]: > > 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 :-( So it seems :( And I guess we still don't have a generic way to check if the core has secure mode or not, and what registers are accessible in secure mode. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Russell King - ARM Linux <linux@arm.linux.org.uk> [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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/14/2012 02:32 PM, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@arm.linux.org.uk> [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. Can you actually read the state of the diagnostic register in non-secure mode? If you can on the A9, is the same true on A8 or others? Multi-platform kernels present a new problem in that we basically need to enable all errata work-arounds. I've been meaning to look thru the errata work-arounds to figure out which ones can be selected for multi-platform kernels without side effects on unaffected parts (i.e. set a chicken bit based on core revision). For any in runtime paths, we may need to do runtime patching if they have performance impact. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -236,6 +236,8 @@ __v7_setup: mcreq p15, 0, r10, c15, c0, 1 @ write diagnostic register #endif #if defined(CONFIG_ARM_ERRATA_751472) && defined(CONFIG_SMP) + teq r5, #0x00100000 @ fails at least on r1p2 + beq 1f ALT_SMP(cmp r6, #0x30) @ present prior to r3p0 ALT_UP_B(1f) mrclt p15, 0, r10, c15, c0, 1 @ read diagnostic register
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*. Signed-off-by: Tony Lindgren <tony@atomide.com> --- Can somebody with access to the errata check if it has more info on which revisions this should be set on? Maybe it's just r2p* - r3p0? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html