* Errata on multiplatform kernels @ 2012-12-11 5:20 Tony Prisk 2012-12-11 5:32 ` Olof Johansson 0 siblings, 1 reply; 10+ messages in thread From: Tony Prisk @ 2012-12-11 5:20 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Errata on multiplatform kernels 2012-12-11 5:20 Errata on multiplatform kernels Tony Prisk @ 2012-12-11 5:32 ` Olof Johansson 2012-12-11 18:01 ` Tony Lindgren 0 siblings, 1 reply; 10+ messages in thread From: Olof Johansson @ 2012-12-11 5:32 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Errata on multiplatform kernels 2012-12-11 5:32 ` Olof Johansson @ 2012-12-11 18:01 ` Tony Lindgren 2012-12-12 0:41 ` Jon Masters 0 siblings, 1 reply; 10+ messages in thread From: Tony Lindgren @ 2012-12-11 18:01 UTC (permalink / raw) To: linux-arm-kernel * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Errata on multiplatform kernels 2012-12-11 18:01 ` Tony Lindgren @ 2012-12-12 0:41 ` Jon Masters 2012-12-12 0:51 ` Russell King - ARM Linux 2012-12-12 0:52 ` Jon Masters 0 siblings, 2 replies; 10+ messages in thread From: Jon Masters @ 2012-12-12 0:41 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Errata on multiplatform kernels 2012-12-12 0:41 ` Jon Masters @ 2012-12-12 0:51 ` Russell King - ARM Linux 2012-12-12 0:54 ` Jon Masters 2012-12-12 3:01 ` Rob Herring 2012-12-12 0:52 ` Jon Masters 1 sibling, 2 replies; 10+ messages in thread From: Russell King - ARM Linux @ 2012-12-12 0:51 UTC (permalink / raw) To: linux-arm-kernel 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.) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Errata on multiplatform kernels 2012-12-12 0:51 ` Russell King - ARM Linux @ 2012-12-12 0:54 ` Jon Masters 2012-12-12 3:01 ` Rob Herring 1 sibling, 0 replies; 10+ messages in thread From: Jon Masters @ 2012-12-12 0:54 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Errata on multiplatform kernels 2012-12-12 0:51 ` Russell King - ARM Linux 2012-12-12 0:54 ` Jon Masters @ 2012-12-12 3:01 ` Rob Herring 2012-12-12 4:56 ` Jon Masters 1 sibling, 1 reply; 10+ messages in thread From: Rob Herring @ 2012-12-12 3:01 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Errata on multiplatform kernels 2012-12-12 3:01 ` Rob Herring @ 2012-12-12 4:56 ` Jon Masters 0 siblings, 0 replies; 10+ messages in thread From: Jon Masters @ 2012-12-12 4:56 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Errata on multiplatform kernels 2012-12-12 0:41 ` Jon Masters 2012-12-12 0:51 ` Russell King - ARM Linux @ 2012-12-12 0:52 ` Jon Masters 2012-12-12 1:28 ` Tony Lindgren 1 sibling, 1 reply; 10+ messages in thread From: Jon Masters @ 2012-12-12 0:52 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Errata on multiplatform kernels 2012-12-12 0:52 ` Jon Masters @ 2012-12-12 1:28 ` Tony Lindgren 0 siblings, 0 replies; 10+ messages in thread From: Tony Lindgren @ 2012-12-12 1:28 UTC (permalink / raw) To: linux-arm-kernel * 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-12-12 4:56 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-11 5:20 Errata on multiplatform kernels Tony Prisk 2012-12-11 5:32 ` Olof Johansson 2012-12-11 18:01 ` Tony Lindgren 2012-12-12 0:41 ` Jon Masters 2012-12-12 0:51 ` Russell King - ARM Linux 2012-12-12 0:54 ` Jon Masters 2012-12-12 3:01 ` Rob Herring 2012-12-12 4:56 ` Jon Masters 2012-12-12 0:52 ` Jon Masters 2012-12-12 1:28 ` Tony Lindgren
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.