Multi-platform, and secure-only ARM errata workarounds

[Russell King - ARM Linux]

On Tue, Feb 26, 2013 at 11:30:08AM -0700, Stephen Warren wrote:
> On 02/26/2013 11:11 AM, Russell King - ARM Linux wrote:
> > On Tue, Feb 26, 2013 at 11:01:30AM -0700, Stephen Warren wrote:
> >> The conditional in that statement makes me wonder which of the following
> >> operations will fault in non-secure mode:
> >>
> >> 1) Reading from the diagnostic register.
> > 
> > Won't fault.
> > 
> >> 2) Writing to the diagnostic register, of a value the same as what's
> >> already there.
> > 
> > Will fault.
> > 
> >> 3) Writing to the diagnostic register, of a value different than what's
> >> already there.
> > 
> > Will fault.
> > 
> >> Would the following not fault in both secure and non-secure mode:
> >>
> >> read diagnostic register
> >> if desired bit already set:
> >>     b 1f
> >> set desired bit
> >> write value back to diagnostic register
> >> 1:
> > 
> > That is exactly what we do
> 
> Well, I asked because for the 3 WARs in question at least, that isn't
> what the code does. For example, from proc-v7.s:
> 
> #ifdef CONFIG_ARM_ERRATA_742230
> 	cmp	r6, #0x22		@ only present up to r2p2
> 	mrcle	p15, 0, r10, c15, c0, 1	@ read diagnostic register
> 	orrle	r10, r10, #1 << 4	@ set bit #4
> 	mcrle	p15, 0, r10, c15, c0, 1	@ write diagnostic register
> #endif
> 
> (unless that orrle affects the flags and hence skips the mcrle, but I
> don't think so.)

Hmm.  I've not really been taking much notice of how these work-arounds
all work - maybe it's safe to write this diagnostic register from
non-secure mode then?

I have noticed this kind of fishy thing with OMAP4430 running in non-secure
mode - some registers I thought would cause an exception don't.  No idea
why not...

> > - the problem is, that if you require
> > workaround X to be enabled, and a different platform has that errata
> > fixed, then the other platform will not enable the work-around, and
> > the bit will be clear.
> 
> The 3 WARs in question are conditional upon the CPU's revision and patch
> number (which I'll call rNpN). I assume that any Cortex-A9 with the
> affected rNpN would require the WAR enabled; is it possible that someone
> could have fixed a particular core bug directly (and hence not changed
> rNpN),

SoC folk are apparantly free to incorporate fixes into the ARM CPU
when they fabricate it, which means that the rNpN number doesn't
accurately reflect what workarounds are required.

We've had this discussion before - a few months ago - and the conclusion
that was arrived at was that the _only_ way out of this mess is to
require whatever runs _before_ the kernel to enable the appropriate
work-arounds in these apparantly secure-accessible only registers.

We've now been around this problem about three or four times, and we
ultimately end up coming back to the above, and/or talking about
ripping out the errata workarounds from the kernel which just set
bits in the register(s).