On 11/14/2012 04:21 PM, Tony Lindgren wrote: > * Rob Herring <robherring2@xxxxxxxxx> [121114 13:59]: >> On 11/14/2012 02:32 PM, Tony Lindgren wrote: >>> >>> 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? > > Looks like it can be read on at least TI omap 4430 which is A9. > But it reads as zero, so the below patch is what I came up with. > > No idea if assuming that zero value for the diagnostic register > is safe.. What's the default value of the diagnostic register supposed > to be? RTFM. Oh, wait it's a super secret, undocumented register. We shouldn't even be talking about it. It could vary by rev, but I see 0 for the reset value, so this would not work if the bootloader did not do any setup of the diagnostic register. One way to determine secure mode on the A9 would be seeing if you can change the auxcr register. Something like this (untested): mrc p15, 0, r0, c1, c0, 1; Read ACTLR eor r1, r0, #0x100 ; Modify alloc in 1 way mcr p15, 0, r1, c1, c0, 1 mrc p15, 0, r2, c1, c0, 1; Read ACTLR mcr p15, 0, r0, c1, c0, 1 ; Restore original value cmp r1, r2 bne skip_errata It would be good to do this test for all the errata rather than just this one. Rob >> 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. > > Yeah that's how I ran into it as multiplatform enabled omap booted > on other omaps but not on omap4. > > Regards, > > Tony > > > From: Tony Lindgren <tony@xxxxxxxxxxx> > Date: Tue, 13 Nov 2012 16:57:42 -0800 > Subject: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 for secure mode > > Looks like enabling CONFIG_ARM_ERRATA_751472 causes TI omap4 blaze > to not boot when enabled. The ARM core on it is an earlier r1p2. > > This seems to be caused by the write to the diagnostic register > that shortly after causes an exception as writing to the diagnostic > register on systems with secure mode is not allowed. > > Also it seems that reading the diagnostic register results zero > so we may not be able to check if bit #11 is already set. > > Let's assume that if the diagnostic register is zero, we don't > want to touch it as it seems to hint secure mode at least on > TI omaps. If it's non-zero, check if bit #11 is set and only > attempt to set it if not set. > > --- a/arch/arm/mm/proc-v7.S > +++ b/arch/arm/mm/proc-v7.S > @@ -238,9 +238,13 @@ __v7_setup: > #if defined(CONFIG_ARM_ERRATA_751472) && defined(CONFIG_SMP) > ALT_SMP(cmp r6, #0x30) @ present prior to r3p0 > ALT_UP_B(1f) > - mrclt p15, 0, r10, c15, c0, 1 @ read diagnostic register > - orrlt r10, r10, #1 << 11 @ set bit #11 > - mcrlt p15, 0, r10, c15, c0, 1 @ write diagnostic register > + bge 1f @ not needed for r3p0 and later > + mrc p15, 0, r10, c15, c0, 1 @ read diagnostic register > + teq r10, #0 @ zero for secure mode? > + beq 1f @ bail out for secure mode > + tst r10, #1 << 11 @ bit #11 already set? > + orreq r10, r10, #1 << 11 @ set bit #11 if not set > + mcreq p15, 0, r10, c15, c0, 1 @ write diagnostic register > 1: > #endif > > -- 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
