[U-Boot] [PATCH 1/2] configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
According to e9fd66defd (ARM: mx6: define CONFIG_ARM_ERRATA_742230), the CONFIG_ARM_ERRATA_742230 option should only be applied to multi-core variants, so restrict its usage for quad and dual-lite only.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- include/configs/mx6_common.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 514d634..0b8db85 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -17,7 +17,9 @@ #ifndef __MX6_COMMON_H #define __MX6_COMMON_H
+#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6DL) #define CONFIG_ARM_ERRATA_742230 +#endif #define CONFIG_ARM_ERRATA_743622 #define CONFIG_ARM_ERRATA_751472 #define CONFIG_BOARD_POSTCLK_INIT
Include "mx6_common.h" so that some ARM errata are applied and also the vddsoc regulator can be changed.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- include/configs/mx6slevk.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h index 7abad08..b29f78c 100644 --- a/include/configs/mx6slevk.h +++ b/include/configs/mx6slevk.h @@ -11,6 +11,7 @@
#include <asm/arch/imx-regs.h> #include <asm/sizes.h> +#include "mx6_common.h"
#define CONFIG_MX6 #define CONFIG_DISPLAY_CPUINFO
Hi Fabio,
On 06/01/2014 14:14, Fabio Estevam wrote:
According to e9fd66defd (ARM: mx6: define CONFIG_ARM_ERRATA_742230), the CONFIG_ARM_ERRATA_742230 option should only be applied to multi-core variants, so restrict its usage for quad and dual-lite only.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
include/configs/mx6_common.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 514d634..0b8db85 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -17,7 +17,9 @@ #ifndef __MX6_COMMON_H #define __MX6_COMMON_H
+#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6DL) #define CONFIG_ARM_ERRATA_742230 +#endif #define CONFIG_ARM_ERRATA_743622 #define CONFIG_ARM_ERRATA_751472 #define CONFIG_BOARD_POSTCLK_INIT
In Kernel I cannot read that the errata is related to a multicore processor. Indeed, it is related to the Cortex-A9 version.
"This option enables the workaround for the 742230 Cortex-A9 (r1p0..r2p2) erratum. Under rare circumstances, a DMB instruction between two write operations may not ensure the correct visibility ordering of the two writes. This workaround sets a specific bit in the diagnostic register of the Cortex-A9 which causes the DMB instruction to behave as a DSB, ensuring the correct behaviour of the two writes. "
The fix was merged in kernel since a lot of time, before having multicore processors for ARM. At least the commit message does not seem coherent with the explanations in kernel. Maybe has solo a upgraded core version as dual/quad ?
Best regards, Stefano
On Wed, Jan 08, 2014 at 09:55:10AM +0100, Stefano Babic wrote:
Hi Fabio,
On 06/01/2014 14:14, Fabio Estevam wrote:
According to e9fd66defd (ARM: mx6: define CONFIG_ARM_ERRATA_742230), the CONFIG_ARM_ERRATA_742230 option should only be applied to multi-core variants, so restrict its usage for quad and dual-lite only.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
include/configs/mx6_common.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 514d634..0b8db85 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -17,7 +17,9 @@ #ifndef __MX6_COMMON_H #define __MX6_COMMON_H
+#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6DL) #define CONFIG_ARM_ERRATA_742230 +#endif #define CONFIG_ARM_ERRATA_743622 #define CONFIG_ARM_ERRATA_751472 #define CONFIG_BOARD_POSTCLK_INIT
In Kernel I cannot read that the errata is related to a multicore processor. Indeed, it is related to the Cortex-A9 version.
"This option enables the workaround for the 742230 Cortex-A9 (r1p0..r2p2) erratum. Under rare circumstances, a DMB instruction between two write operations may not ensure the correct visibility ordering of the two writes. This workaround sets a specific bit in the diagnostic register of the Cortex-A9 which causes the DMB instruction to behave as a DSB, ensuring the correct behaviour of the two writes. "
The fix was merged in kernel since a lot of time, before having multicore processors for ARM. At least the commit message does not seem coherent with the explanations in kernel. Maybe has solo a upgraded core version as dual/quad ?
The sololite has the same core version as dual/quad - r2p10. The help text of erratum 742230 in kernel suggests that only version r1p0..r2p2 are affected. So it sounds like the erratum 742230 should be irrelevant to i.MX6 SoCs. However we were running into a reboot issue on multi-core i.MX6 SoCs. There was a quite long discussion [1] about it. Though we did not reach a conclusion in the thread, one ARM people sent me a private message, suggesting this should be an ARM core issue and workaround for erratum 742230 might help. And it turns out what he said is true. And that's why I came up with the commit e9fd66defd (ARM: mx6: define CONFIG_ARM_ERRATA_742230) to turn on the erratum for imx6 dual/quad.
Shawn
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/thread.htm...
Hi Fabio,
On 08/01/2014 13:10, Shawn Guo wrote:
On Wed, Jan 08, 2014 at 09:55:10AM +0100, Stefano Babic wrote:
Hi Fabio,
On 06/01/2014 14:14, Fabio Estevam wrote:
According to e9fd66defd (ARM: mx6: define CONFIG_ARM_ERRATA_742230), the CONFIG_ARM_ERRATA_742230 option should only be applied to multi-core variants, so restrict its usage for quad and dual-lite only.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
include/configs/mx6_common.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h index 514d634..0b8db85 100644 --- a/include/configs/mx6_common.h +++ b/include/configs/mx6_common.h @@ -17,7 +17,9 @@ #ifndef __MX6_COMMON_H #define __MX6_COMMON_H
+#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6DL) #define CONFIG_ARM_ERRATA_742230 +#endif #define CONFIG_ARM_ERRATA_743622 #define CONFIG_ARM_ERRATA_751472 #define CONFIG_BOARD_POSTCLK_INIT
In Kernel I cannot read that the errata is related to a multicore processor. Indeed, it is related to the Cortex-A9 version.
"This option enables the workaround for the 742230 Cortex-A9 (r1p0..r2p2) erratum. Under rare circumstances, a DMB instruction between two write operations may not ensure the correct visibility ordering of the two writes. This workaround sets a specific bit in the diagnostic register of the Cortex-A9 which causes the DMB instruction to behave as a DSB, ensuring the correct behaviour of the two writes. "
The fix was merged in kernel since a lot of time, before having multicore processors for ARM. At least the commit message does not seem coherent with the explanations in kernel. Maybe has solo a upgraded core version as dual/quad ?
The sololite has the same core version as dual/quad - r2p10. The help text of erratum 742230 in kernel suggests that only version r1p0..r2p2 are affected. So it sounds like the erratum 742230 should be irrelevant to i.MX6 SoCs. However we were running into a reboot issue on multi-core i.MX6 SoCs. There was a quite long discussion [1] about it. Though we did not reach a conclusion in the thread, one ARM people sent me a private message, suggesting this should be an ARM core issue and workaround for erratum 742230 might help. And it turns out what he said is true. And that's why I came up with the commit e9fd66defd (ARM: mx6: define CONFIG_ARM_ERRATA_742230) to turn on the erratum for imx6 dual/quad.
Shawn, thanks for explanations. Fabio, can you extend the commit message, pointing out that the version itself of the ARM core is not the real cause. Maybe improving with part of Russel's answer to the thread, that catches the point.
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113353.htm...
This is a fix that I will merge for release. I am quite astonished what can still happens in User Space, if the compiler issues a dmb instruction...
Best regards, Stefano Babic
participants (3)
-
Fabio Estevam -
Shawn Guo -
Stefano Babic