Errata on multiplatform kernels
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
Hi,
Quoted 7 lines · 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?
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
Quoted 11 lines · Olof Johansson
Hi,
Quoted 7 lines · 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?
Quoted 8 lines
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
Quoted 24 lines · Tony Lindgren
Quoted 11 lines · Olof Johansson
Hi,
Quoted 7 lines · 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?
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 32 lines · Jon Masters
Quoted 24 lines · Tony Lindgren
Quoted 11 lines · Olof Johansson
Hi,
Quoted 7 lines · 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?
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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.)
Quoted 32 lines · Jon Masters
Quoted 24 lines · Tony Lindgren
Quoted 11 lines · Olof Johansson
Hi,
Quoted 7 lines · 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?
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 41 lines · Russell King - ARM Linux
Quoted 32 lines · Jon Masters
Quoted 24 lines · Tony Lindgren
Quoted 11 lines · Olof Johansson
Hi,
Quoted 7 lines · 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?
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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 :)
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 11 lines · Jon Masters
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
0x4cb2e830This 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
Quoted 45 lines · Russell King - ARM Linux
Quoted 32 lines · Jon Masters
Quoted 24 lines · Tony Lindgren
Quoted 11 lines · Olof Johansson
Hi,
Quoted 7 lines · 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?
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
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
Quoted 6 lines
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 55 lines · Rob Herring
Quoted 45 lines · Russell King - ARM Linux
Quoted 32 lines · Jon Masters
Quoted 24 lines · Tony Lindgren
Quoted 11 lines · Olof Johansson
Hi,
Quoted 7 lines · 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?
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
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.)
Quoted 4 lines
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.