Errata on multiplatform kernels

[jonathan@jonmasters.org (Jon Masters)]

On 12/11/2012 01:01 PM, Tony Lindgren wrote:
> * Olof Johansson <olof@lixom.net> [121210 21:38]:
>> Hi,
>>
>> On Mon, Dec 10, 2012 at 9:20 PM, Tony Prisk <linux@prisktech.co.nz> wrote:
>>> How are errata handled on multiplatform kernels?
>>>
>>> There don't appear to be any errata selected by default in any of the
>>> current multiplatform options, but presumably it will happen eventually.
>>>
>>> Does that mean the errata will be applied to all machines that boot with
>>> the errata selected, even if not required?
>>
>> Yes. To date I believe most errata we have are just performance hits
>> on platforms that don't need it.
>>
>> Other architectures have in some cases added runtime patching (out) of
>> workarounds that aren't needed on the current platform for the ones
>> that have significant performance impact. I'm guessing we'll end up
>> with something similar eventually but until then we'll try to just go
>> with the superset of needed errata.
> 
> We can't enable any of the errata if there's a chance that it will behave
> in a different way for secure mode devices compared to non-secure devices.
> 
> The discussion is in the thread "[PATCH] ARM: Fix errata 751472 handling
> on Cortex-A9 r1p*".
> 
> The conclusion was that we cannot enable any errata for multiplatform,
> and must assume the errata is handled by the bootloader. Multiplatform
> image is already broken for at least omap4 as 751472 is selected.

On some platforms with a PL310 we have errata 588369 and 727915
(especially enabled on OMAP4 targets) which will cause an external abort
when enabled and then booted on highbank systems. This has taken the
last couple of days on and off to track down. So I guess we need to
basically disable these in our (Fedora) multiplatform kernel and then
assume that e.g. PandaBoard will implement some U-Boot fix if it needs
to have one? Not sure exactly what that fix is going to look like :)

Jon.