ARM errata, 430973: update the affected revisions
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH RESEND 1/1 ARM errata, 430973: update the affected revisions
Hi,
Quoted 23 lines · Jeroen Hofstee
From: Jeroen Hofstee <[email protected]>
Update the list of revisions subject to this errata.
Cc Catalin Marinas <[email protected]>Cc Russell King <[email protected]>Cc Andreas Bie?mann <[email protected]>Signed-off-by Jeroen Hofstee <[email protected]>---
I don't have access to the AT400/AT401/AT490 document, but Andreas was kind enough to provide this information, see
https://www.mail-archive.com/u-boot at lists.denx.de/msg156620.htmlResending from an address which is subscribed to the ML...
--- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/Kconfig +0
-0
arch/arm/Kconfig config ARM_ERRATA_430973 · line 1069
Quoted 8 lines
arch/arm/Kconfig +1
-1@@ -1063,7 +1063,7 @@ config ARM_ERRATA_430973 depends on CPU_V7 help This option enables the workaround for the 430973 Cortex-A8 - (r1p0..r1p2) erratum. If a code sequence containing an ARM/Thumb + (r1p0..r1p3, r1p7) erratum. If a code sequence containing an ARM/Thumb interworking branch is replaced with another code sequence at the same virtual address, whether due to self-modifying code or virtual to physical address re-mapping, Cortex-A8 does not recover from the
It seems this is not applied yet. For completeness, this only updates the description
of the workaround, so should be safe to apply. At the moment people might disable
this workaround (since the description says its not applicable) even if the cpu does
need this workaround.
Please consider applying this,
Regards,
Jeroen
PATCH RESEND 1/1 ARM errata, 430973: update the affected revisions
Hi again,
Quoted 47 lines · Jeroen Hofstee
Hi,
Quoted 28 lines · Jeroen Hofstee
From: Jeroen Hofstee <[email protected]>
Update the list of revisions subject to this errata.
Cc Catalin Marinas <[email protected]>Cc Russell King <[email protected]>Cc Andreas Bie?mann <[email protected]>Signed-off-by Jeroen Hofstee <[email protected]>---
I don't have access to the AT400/AT401/AT490 document, but Andreas was kind enough to provide this information, see
https://www.mail-archive.com/u-boot at lists.denx.de/msg156620.htmlResending from an address which is subscribed to the ML...
--- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/Kconfig +1
-1@@ -1063,7 +1063,7 @@ config ARM_ERRATA_430973 depends on CPU_V7 help This option enables the workaround for the 430973 Cortex-A8 - (r1p0..r1p2) erratum. If a code sequence containing an ARM/Thumb + (r1p0..r1p3, r1p7) erratum. If a code sequence containing anQuoted 7 lines
ARM/Thumb
interworking branch is replaced with another code sequence at
the
same virtual address, whether due to self-modifying code or
virtual
to physical address re-mapping, Cortex-A8 does not recover
from theIt seems this is not applied yet. For completeness, this only updates the description
of the workaround, so should be safe to apply. At the moment people might disable
this workaround (since the description says its not applicable) even if the cpu does
need this workaround.
Quoted 2 lines
Please consider applying this,
ping
This still seems not be be applied. Please do update the documentation because it
causes segfaults when disabled wrongly. Below is a discussion about the topic as well.
Regards,
Jeroen
http://lists.denx.de/pipermail/u-boot/2014-December/198092.html
PATCH RESEND 1/1 ARM errata, 430973: update the affected revisions
Quoted 53 lines · Jeroen Hofstee
Hi again,
Quoted 47 lines · Jeroen Hofstee
Hi,
Quoted 28 lines · Jeroen Hofstee
From: Jeroen Hofstee <[email protected]>
Update the list of revisions subject to this errata.
Cc Catalin Marinas <[email protected]>Cc Russell King <[email protected]>Cc Andreas Bie?mann <[email protected]>Signed-off-by Jeroen Hofstee <[email protected]>---
I don't have access to the AT400/AT401/AT490 document, but Andreas was kind enough to provide this information, see
https://www.mail-archive.com/u-boot at lists.denx.de/msg156620.htmlResending from an address which is subscribed to the ML...
--- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/Kconfig +1
-1@@ -1063,7 +1063,7 @@ config ARM_ERRATA_430973 depends on CPU_V7 help This option enables the workaround for the 430973 Cortex-A8 - (r1p0..r1p2) erratum. If a code sequence containing an ARM/Thumb + (r1p0..r1p3, r1p7) erratum. If a code sequence containing anQuoted 7 lines
ARM/Thumb
interworking branch is replaced with another code sequence at
the
same virtual address, whether due to self-modifying code or
virtual
to physical address re-mapping, Cortex-A8 does not recover from
theIt seems this is not applied yet. For completeness, this only updates the description
of the workaround, so should be safe to apply. At the moment people might disable
this workaround (since the description says its not applicable) even if the cpu does
need this workaround.Quoted 2 lines
Please consider applying this,
Quoted 6 lines
ping
This still seems not be be applied. Please do update the documentation because it
causes segfaults when disabled wrongly. Below is a discussion about the topic as well.
No. If you read the discussion that the OMAP people are having, it is unclear whether r3p2 is actually affected by this errata or not.
In the discussion with OMAP people, we've come up with a potentially better solution to this, which is to rearrange the code so that only Cortex-A8 executes this workaround, and the BTB flush is always present (which Tony says fixes the problem.)
However, due to the lack of audience participation in that thread, Tony's patch to do the last bit is still sitting around. I quote from April 8th:
"Boots just fine for me on n900, but let's wait for comments from Sebastian."
and we're doing just that, we're waiting...
Meanwhile, OMAP people are seeing about updating uboot to set/clear the auxiliary control register bit appropriately for the revision of the core.
In any case, adding the patch and suggesting people enable this for more Cortex-A8's (eg, non-OMAP) won't actually do anything in a multiplatform kernel.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
PATCH RESEND 1/1 ARM errata, 430973: update the affected revisions
Hello Russell, +Tony,
Thanks for taking the time to respond,
Quoted 39 lines · Russell King - ARM Linux
Quoted 30 lines · Jeroen Hofstee
Quoted 29 lines · Jeroen Hofstee
Quoted 28 lines · Jeroen Hofstee
From: Jeroen Hofstee <[email protected]>
Update the list of revisions subject to this errata.
Cc Catalin Marinas <[email protected]>Cc Russell King <[email protected]>Cc Andreas Bie?mann <[email protected]>Signed-off-by Jeroen Hofstee <[email protected]>---
I don't have access to the AT400/AT401/AT490 document, but Andreas was kind enough to provide this information, see
https://www.mail-archive.com/u-boot at lists.denx.de/msg156620.htmlResending from an address which is subscribed to the ML...
--- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/Kconfig +1
-1@@ -1063,7 +1063,7 @@ config ARM_ERRATA_430973 depends on CPU_V7 help This option enables the workaround for the 430973 Cortex-A8 - (r1p0..r1p2) erratum. If a code sequence containing an ARM/Thumb + (r1p0..r1p3, r1p7) erratum. If a code sequence containing anQuoted 8 lines
Quoted 8 lines
Quoted 7 lines
ARM/Thumb
interworking branch is replaced with another code sequence at
the
same virtual address, whether due to self-modifying code or
virtual
to physical address re-mapping, Cortex-A8 does not recover from
the
Quoted 2 lines
No. If you read the discussion that the OMAP people are having, it is unclear whether r3p2 is actually affected by this errata or not.
I scanned through it, but that is a different issue it seems. This patch only adds r1p3 and r1p7 to the documentation, since according to ARM they are affected by this errata. Newer revision should not be affected by this errata (or ARM reintroduced it).
The patch is _not_ adding r3p2 as an affected version. And is also not about how to deal with cores no longer needing this workaround.
Quoted 4 lines
In the discussion with OMAP people, we've come up with a potentially better solution to this, which is to rearrange the code so that only Cortex-A8 executes this workaround, and the BTB flush is always present (which Tony says fixes the problem.)
The am3517 / r1p7 is a Cortex-a8 and is affected by this errata. I fail to see why making this cortex-a8 specific will help anything about the revision not being mentioned in the help text. (unless the CONFIG option gets completely
removed).
Quoted 3 lines
Meanwhile, OMAP people are seeing about updating uboot to set/clear the auxiliary control register bit appropriately for the revision of the core.
Well almost appropriately. [1] suggest "the bootloaders can be fixed Cortex-A8
revisions later than r1p2 to not set the IBE bit.". That should have been r1p7 as
well.
Quoted 4 lines
In any case, adding the patch and suggesting people enable this for more Cortex-A8's (eg, non-OMAP) won't actually do anything in a multiplatform kernel.
Can you give an example of a r1p7 not needing the workaround?
Regards,
Jeroen
PATCH RESEND 1/1 ARM errata, 430973: update the affected revisions
Quoted 46 lines · Jeroen Hofstee
Hello Russell, +Tony,
Thanks for taking the time to respond,
Quoted 39 lines · Russell King - ARM Linux
Quoted 30 lines · Jeroen Hofstee
Quoted 29 lines · Jeroen Hofstee
Quoted 28 lines · Jeroen Hofstee
From: Jeroen Hofstee <[email protected]>
Update the list of revisions subject to this errata.
Cc Catalin Marinas <[email protected]>Cc Russell King <[email protected]>Cc Andreas Bie?mann <[email protected]>Signed-off-by Jeroen Hofstee <[email protected]>---
I don't have access to the AT400/AT401/AT490 document, but Andreas was kind enough to provide this information, see
https://www.mail-archive.com/u-boot at lists.denx.de/msg156620.htmlResending from an address which is subscribed to the ML...
--- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/Kconfig +1
-1@@ -1063,7 +1063,7 @@ config ARM_ERRATA_430973 depends on CPU_V7 help This option enables the workaround for the 430973 Cortex-A8 - (r1p0..r1p2) erratum. If a code sequence containing an ARM/Thumb + (r1p0..r1p3, r1p7) erratum. If a code sequence containing anQuoted 8 lines
Quoted 8 lines
Quoted 7 lines
ARM/Thumb
interworking branch is replaced with another code sequence at
the
same virtual address, whether due to self-modifying code or
virtual
to physical address re-mapping, Cortex-A8 does not recover from
theQuoted 2 lines
No. If you read the discussion that the OMAP people are having, it is unclear whether r3p2 is actually affected by this errata or not.
Quoted 7 lines
I scanned through it, but that is a different issue it seems. This patch only adds r1p3 and r1p7 to the documentation, since according to ARM they are affected by this errata. Newer revision should not be affected by this errata (or ARM reintroduced it).
The patch is _not_ adding r3p2 as an affected version. And is also not about how to deal with cores no longer needing this workaround.
Right.. But it seems that having the aux ctrl register bit enabled without doing the flush btac part leads into a different set of issues.
Quoted 19 lines
Quoted 4 lines
In the discussion with OMAP people, we've come up with a potentially better solution to this, which is to rearrange the code so that only Cortex-A8 executes this workaround, and the BTB flush is always present (which Tony says fixes the problem.)
The am3517 / r1p7 is a Cortex-a8 and is affected by this errata. I fail to see why making this cortex-a8 specific will help anything about the revision not being mentioned in the help text. (unless the CONFIG option gets completely
removed).Quoted 3 lines
Meanwhile, OMAP people are seeing about updating uboot to set/clear the auxiliary control register bit appropriately for the revision of the core.
Well almost appropriately. [1] suggest "the bootloaders can be fixed Cortex-A8
revisions later than r1p2 to not set the IBE bit.". That should have been r1p7 as
well.
Quoted 5 lines
Quoted 4 lines
In any case, adding the patch and suggesting people enable this for more Cortex-A8's (eg, non-OMAP) won't actually do anything in a multiplatform kernel.
Can you give an example of a r1p7 not needing the workaround?
Do you have some pointer for the documentation mentioning r1p7 is affected? It is possible that the revision range is wrong.. But I'm more likely to believe it is correct and we're hitting a different problem.
I'm hoping that with Russell's patch and my patch in the thread below, you don't necessarily need to enable 430973. That's these two patches:
http://www.spinics.net/lists/arm-kernel/msg411433.html
http://www.spinics.net/lists/arm-kernel/msg411038.html
If what Russell and I are saying is correct, with the above two patches your system should behave properly with 430973 even if bit 6 in the aux ctrl register is set (or unset) by the bootloader.
If r1p7 is behaves with bit 6 cleared and errata 430973 set, then we know r1p7 is unaffected by 430973.
Regards,
Tony
PATCH RESEND 1/1 ARM errata, 430973: update the affected revisions
Quoted 96 lines · Tony Lindgren
Quoted 46 lines · Jeroen Hofstee
Hello Russell, +Tony,
Thanks for taking the time to respond,
Quoted 39 lines · Russell King - ARM Linux
Quoted 30 lines · Jeroen Hofstee
Quoted 29 lines · Jeroen Hofstee
Quoted 28 lines · Jeroen Hofstee
From: Jeroen Hofstee <[email protected]>
Update the list of revisions subject to this errata.
Cc Catalin Marinas <[email protected]>Cc Russell King <[email protected]>Cc Andreas Bie?mann <[email protected]>Signed-off-by Jeroen Hofstee <[email protected]>---
I don't have access to the AT400/AT401/AT490 document, but Andreas was kind enough to provide this information, see
https://www.mail-archive.com/u-boot at lists.denx.de/msg156620.htmlResending from an address which is subscribed to the ML...
--- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/Kconfig +1
-1@@ -1063,7 +1063,7 @@ config ARM_ERRATA_430973 depends on CPU_V7 help This option enables the workaround for the 430973 Cortex-A8 - (r1p0..r1p2) erratum. If a code sequence containing an ARM/Thumb + (r1p0..r1p3, r1p7) erratum. If a code sequence containing anQuoted 8 lines
Quoted 8 lines
Quoted 7 lines
ARM/Thumb
interworking branch is replaced with another code sequence at
the
same virtual address, whether due to self-modifying code or
virtual
to physical address re-mapping, Cortex-A8 does not recover from
theQuoted 2 lines
No. If you read the discussion that the OMAP people are having, it is unclear whether r3p2 is actually affected by this errata or not.
Quoted 7 lines
I scanned through it, but that is a different issue it seems. This patch only adds r1p3 and r1p7 to the documentation, since according to ARM they are affected by this errata. Newer revision should not be affected by this errata (or ARM reintroduced it).
The patch is _not_ adding r3p2 as an affected version. And is also not about how to deal with cores no longer needing this workaround.
Right.. But it seems that having the aux ctrl register bit enabled without doing the flush btac part leads into a different set of issues.
Quoted 19 lines
Quoted 4 lines
In the discussion with OMAP people, we've come up with a potentially better solution to this, which is to rearrange the code so that only Cortex-A8 executes this workaround, and the BTB flush is always present (which Tony says fixes the problem.)
The am3517 / r1p7 is a Cortex-a8 and is affected by this errata. I fail to see why making this cortex-a8 specific will help anything about the revision not being mentioned in the help text. (unless the CONFIG option gets completely
removed).Quoted 3 lines
Meanwhile, OMAP people are seeing about updating uboot to set/clear the auxiliary control register bit appropriately for the revision of the core.
Well almost appropriately. [1] suggest "the bootloaders can be fixed Cortex-A8
revisions later than r1p2 to not set the IBE bit.". That should have been r1p7 as
well.Quoted 5 lines
Quoted 4 lines
In any case, adding the patch and suggesting people enable this for more Cortex-A8's (eg, non-OMAP) won't actually do anything in a multiplatform kernel.
Can you give an example of a r1p7 not needing the workaround?
Do you have some pointer for the documentation mentioning r1p7 is affected? It is possible that the revision range is wrong.. But I'm more likely to believe it is correct and we're hitting a different problem.
I'm hoping that with Russell's patch and my patch in the thread below, you don't necessarily need to enable 430973. That's these two patches:
http://www.spinics.net/lists/arm-kernel/msg411433.html
http://www.spinics.net/lists/arm-kernel/msg411038.html
Quoted 6 lines
If what Russell and I are saying is correct, with the above two patches your system should behave properly with 430973 even if bit 6 in the aux ctrl register is set (or unset) by the bootloader.
If r1p7 is behaves with bit 6 cleared and errata 430973 set, then we know r1p7 is unaffected by 430973.
Sorry let's take this part again:
If r1p7 is behaves with bit 6 cleared and errata 430973 _unset_, then we know r1p7 is unaffected by 430973.
Regards,
Tony
Quoted 1 line
PATCH RESEND 1/1 ARM errata, 430973: update the affected revisions
Quoted 5 lines · Tony Lindgren
Quoted 4 lines · Tony Lindgren
If what Russell and I are saying is correct, with the above two patches your system should behave properly with 430973 even if bit 6 in the aux ctrl register is set (or unset) by the bootloader.
Quoted 7 lines
Quoted 2 lines
If r1p7 is behaves with bit 6 cleared and errata 430973 set, then we know r1p7 is unaffected by 430973.
Sorry let's take this part again:
If r1p7 is behaves with bit 6 cleared and errata 430973 _unset_, then we know r1p7 is unaffected by 430973.
I've asked. The errata applies to _all_ Cortex A8 r1pX versions. This is actually what the code in the kernel does today, but the documentation does not reflect it. So, I've updated the documentation to reflect (a) the code and (b) the info I received:
http://ftp.arm.linux.org.uk/cgit/linux-arm.git/commit/?id=59552cc87cb6
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
PATCH RESEND 1/1 ARM errata, 430973: update the affected revisions
Quoted 14 lines · Russell King - ARM Linux
Quoted 5 lines · Tony Lindgren
Quoted 4 lines · Tony Lindgren
If what Russell and I are saying is correct, with the above two patches your system should behave properly with 430973 even if bit 6 in the aux ctrl register is set (or unset) by the bootloader.
Quoted 7 lines
Quoted 2 lines
If r1p7 is behaves with bit 6 cleared and errata 430973 set, then we know r1p7 is unaffected by 430973.
Sorry let's take this part again:
If r1p7 is behaves with bit 6 cleared and errata 430973 _unset_, then we know r1p7 is unaffected by 430973.
Quoted 6 lines
I've asked. The errata applies to _all_ Cortex A8 r1pX versions. This is actually what the code in the kernel does today, but the documentation does not reflect it. So, I've updated the documentation to reflect (a) the code and (b) the info I received:
http://ftp.arm.linux.org.uk/cgit/linux-arm.git/commit/?id=59552cc87cb6
OK thanks for checking it, that should clear quite a bit of confusion.
Regards,
Tony
PATCH RESEND 1/1 ARM errata, 430973: update the affected revisions
In reply to Russell King - ARM LinuxHello Russell,
Quoted 10 lines · Russell King - ARM Linux
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Tony Lindgren
If what Russell and I are saying is correct, with the above two patches your system should behave properly with 430973 even if bit 6 in the aux ctrl register is set (or unset) by the bootloader.
If r1p7 is behaves with bit 6 cleared and errata 430973 set, then we know r1p7 is unaffected by 430973.
Sorry let's take this part again:
Quoted 9 lines
Quoted 2 lines
If r1p7 is behaves with bit 6 cleared and errata 430973 _unset_, then we know r1p7 is unaffected by 430973.
I've asked. The errata applies to _all_ Cortex A8 r1pX versions. This is actually what the code in the kernel does today, but the documentation does not reflect it. So, I've updated the documentation to reflect (a) the code and (b) the info I received:
http://ftp.arm.linux.org.uk/cgit/linux-arm.git/commit/?id=59552cc87cb6
Good, that also matches with the patch I posted, [r1p4 .. r1p6] are not necessarily not affected, they simply are not mentioned in the errata. r1p7 is the last from the r1pX range. From r2p1 on things should no longer need to workaround.
Regards,
Jeroen