Errata on multiplatform kernels

Errata on multiplatform kernels

[Tony Prisk]

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?

Regards
Tony P

Errata on multiplatform kernels

[Olof Johansson]

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.


-Olof

Errata on multiplatform kernels

[Tony Lindgren]

* 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.

Regards,

Tony

Errata on multiplatform kernels

[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.

Errata on multiplatform kernels

[Russell King - ARM Linux]

On Tue, Dec 11, 2012 at 07:41:18PM -0500, Jon Masters wrote:
> 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 :)

Neither 588369 nor 727915 are something a boot loader can do - they have
to be done in the kernel.  If they're causing highbank systems to fail
that needs to be debugged.

My guess is that highbank is another non-secure system, and the L2x0
code is trying to use pl310_set_debug() which will fail on non-secure
systems as the 'set_debug' hook is not being overriden.

If there was a way to tell that we're running on a non-secure system,
we could automatically point set_debug() to a nop function, but it
would be far more preferable for highbank to provide the hook.  (That
could be itself a no-op if it doesn't require the work-around.)

Errata on multiplatform kernels

[Jon Masters]

On 12/11/2012 07:41 PM, Jon Masters wrote:
> 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 :)

And for the (Google) record, if you see an imprecise external abort at
boot time on recent multiplatform kernel:

[   22.141268] Unhandled fault: imprecise external abort (0xc06) at
0x4cb2e830

This may well be that your kernel is running in non-secure mode and does
not have access to undocumented/unexposed registers that it is trying to
write into, and consequently is causing this error. There. That should
save some other poor sucker many wasted hours. Could this, perhaps,
sometime be documented somewhere? :)

Jon.

Errata on multiplatform kernels

[Jon Masters]

On 12/11/2012 07:51 PM, Russell King - ARM Linux wrote:
> On Tue, Dec 11, 2012 at 07:41:18PM -0500, Jon Masters wrote:
>> 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 :)
> 
> Neither 588369 nor 727915 are something a boot loader can do - they have
> to be done in the kernel.  If they're causing highbank systems to fail
> that needs to be debugged.

Exactly. I can see no way this can be done in the bootloader code either.

> My guess is that highbank is another non-secure system, and the L2x0
> code is trying to use pl310_set_debug() which will fail on non-secure
> systems as the 'set_debug' hook is not being overriden.

Right, and right again.

> If there was a way to tell that we're running on a non-secure system,
> we could automatically point set_debug() to a nop function, but it
> would be far more preferable for highbank to provide the hook.  (That
> could be itself a no-op if it doesn't require the work-around.)

I leave that one to Rob :)

Jon.

Errata on multiplatform kernels

[Tony Lindgren]

* Jon Masters <jonathan@jonmasters.org> [121211 16:59]:
> And for the (Google) record, if you see an imprecise external abort at
> boot time on recent multiplatform kernel:
> 
> [   22.141268] Unhandled fault: imprecise external abort (0xc06) at
> 0x4cb2e830
> 
> This may well be that your kernel is running in non-secure mode and does
> not have access to undocumented/unexposed registers that it is trying to
> write into, and consequently is causing this error. There. That should
> save some other poor sucker many wasted hours. Could this, perhaps,
> sometime be documented somewhere? :)

Hmm how about we add a handler for that that would just set the
booted CPU to have non-secure flag set for other code to use?
That is assuming it's the same abort for all ARMs..

Tony

Errata on multiplatform kernels

[Rob Herring]

On 12/11/2012 06:51 PM, Russell King - ARM Linux wrote:
> On Tue, Dec 11, 2012 at 07:41:18PM -0500, Jon Masters wrote:
>> 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 :)
> 
> Neither 588369 nor 727915 are something a boot loader can do - they have
> to be done in the kernel.  If they're causing highbank systems to fail
> that needs to be debugged.
> 
> My guess is that highbank is another non-secure system, and the L2x0
> code is trying to use pl310_set_debug() which will fail on non-secure
> systems as the 'set_debug' hook is not being overriden.
> 
> If there was a way to tell that we're running on a non-secure system,
> we could automatically point set_debug() to a nop function, but it
> would be far more preferable for highbank to provide the hook.  (That
> could be itself a no-op if it doesn't require the work-around.)

Actually, we should check the pl310 revision and set .set_debug to NULL
on r3p1 and later. This will fix highbank and any other platform that
doesn't need the work-around. I'd assume platforms that are non-secure
and need this work-around will override .set_debug. I'll work on a patch.

Rob

> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Errata on multiplatform kernels

[Jon Masters]

On 12/11/2012 10:01 PM, Rob Herring wrote:
> On 12/11/2012 06:51 PM, Russell King - ARM Linux wrote:
>> On Tue, Dec 11, 2012 at 07:41:18PM -0500, Jon Masters wrote:
>>> 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 :)
>>
>> Neither 588369 nor 727915 are something a boot loader can do - they have
>> to be done in the kernel.  If they're causing highbank systems to fail
>> that needs to be debugged.
>>
>> My guess is that highbank is another non-secure system, and the L2x0
>> code is trying to use pl310_set_debug() which will fail on non-secure
>> systems as the 'set_debug' hook is not being overriden.
>>
>> If there was a way to tell that we're running on a non-secure system,
>> we could automatically point set_debug() to a nop function, but it
>> would be far more preferable for highbank to provide the hook.  (That
>> could be itself a no-op if it doesn't require the work-around.)
> 
> Actually, we should check the pl310 revision and set .set_debug to NULL
> on r3p1 and later. This will fix highbank and any other platform that
> doesn't need the work-around. I'd assume platforms that are non-secure
> and need this work-around will override .set_debug. I'll work on a patch.

Ok. But Tony had a good idea too on the secure vs. non-secure thing. For
those cases where a fix can't be done in pre-boot platform code I think
that's a good idea for future errata.

Jon.