[U-Boot] [PATCH v2 1/2] configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
From: Fabio Estevam fabio.estevam@freescale.com
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.
Quoting Shawn Guo [2]:
"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..."
[2] http://lists.denx.de/pipermail/u-boot/2014-January/170424.html
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- Changes since v1: - Improve commit log
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
From: Fabio Estevam fabio.estevam@freescale.com
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 --- Changes since v1: - None
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 08.01.2014 14:59, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
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.
Just for my understanding: Is there a technical reason not to use this errata on single core (solo/sololite)? I.e. do you see any real issues using this errata on solo/sololite?
Or is this patch "just out of formal" aspects? I.e. there are no positive/negative issues seen on solo/sololite, but the documentation tells that it shouldn't be used on solo/sololite, so disable it?
Best regards
Dirk
Quoting Shawn Guo [2]:
"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..."
[2] http://lists.denx.de/pipermail/u-boot/2014-January/170424.html
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Changes since v1:
Improve commit log
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
Hi Dirk,
On Wed, Jan 8, 2014 at 12:07 PM, Dirk Behme dirk.behme@de.bosch.com wrote:
Just for my understanding: Is there a technical reason not to use this errata on single core (solo/sololite)? I.e. do you see any real issues using this errata on solo/sololite?
No real issue. It is unneeded for single core mx6 as explained by Shawn.
My real goal on this series was to enable the other ARM errata available at mx6_common.h for sololite.
While reviewing the errata list, I learned that CONFIG_ARM_ERRATA_742230 is not needed for solo/solo-lite, so that's why I came up with this 1/2 patch.
Regards,
Fabio Estevam
-----Original Message----- From: Fabio Estevam [mailto:festevam@gmail.com] Sent: Wednesday, January 08, 2014 10:00 PM To: sbabic@denx.de Cc: shawn.guo@linaro.org; Liu Hui-R64343; u-boot@lists.denx.de; Estevam Fabio-R49496 Subject: [PATCH v2 1/2] configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
From: Fabio Estevam fabio.estevam@freescale.com
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.
Quoting Shawn Guo [2]:
"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.html#113096"
[2] http://lists.denx.de/pipermail/u-boot/2014-January/170424.html
The commit log really get me confused, why we need enable one ERRATA which should not be applied? This will make customer confused at all. We need find the real root-cause for it other than hack it Otherwise, you will get more and more problems sooner or later...
If you looking at the link in [1], it said, this issue only affected with v6+v7 one zImage kernel, And not exist with v7 only kernel, which means something should be wrong with v6+v7 one zImage kernel.
Jason Liu
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
Changes since v1:
- Improve commit log
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
1.8.1.2
On Thu, Jan 09, 2014 at 03:50:06AM +0000, Hui.Liu@freescale.com wrote:
The commit log really get me confused, why we need enable one ERRATA which should not be applied?
It's been enabled as a workaround for the reboot issue we were seeing before. But I get reminded that the workaround may not be needed anymore, because of the recent kernel commit 87a84b69 (ARM: imx: replace imx6q_restart() with mxc_restart()). The real change is that we do not call of_iomap() in restart hook now.
Fabio,
Can you give it a test to see if reboot works fine with v3.13-rc kernel with dropping the ERRATA from u-boot? If reboot works and nothing else breaks, we may want to just remove the ERRATA selection from u-boot.
This will make customer confused at all. We need find the real root-cause for it other than hack it Otherwise, you will get more and more problems sooner or later...
If you go through the thread [1], you will see that the root-cause had pretty much been identified, - issuing dmb instructions in a tight loop causes the problem. But people did not reach a conclusion how it should be fixed.
If you looking at the link in [1], it said, this issue only affected with v6+v7 one zImage kernel, And not exist with v7 only kernel, which means something should be wrong with v6+v7 one zImage kernel.
Again, if you go though the discussion, you will find the issue could be easily made up on v7 only kernel.
Shawn
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/180876
On Thu, Jan 9, 2014 at 4:28 AM, Shawn Guo shawn.guo@linaro.org wrote:
Fabio,
Can you give it a test to see if reboot works fine with v3.13-rc kernel with dropping the ERRATA from u-boot? If reboot works and nothing else breaks, we may want to just remove the ERRATA selection from u-boot.
Tested on mx6sl and mx6q and I could run 'reboot' from Linux without CONFIG_ARM_ERRATA_742230.
To be in the safe side I will send a v3 targeted for the upcoming 2014.01 release that only adds the 3 errata to mx6sl.
Regards,
Fabio Estevam
Hi Fabio,
On 09/01/2014 11:55, Fabio Estevam wrote:
On Thu, Jan 9, 2014 at 4:28 AM, Shawn Guo shawn.guo@linaro.org wrote:
Fabio,
Can you give it a test to see if reboot works fine with v3.13-rc kernel with dropping the ERRATA from u-boot? If reboot works and nothing else breaks, we may want to just remove the ERRATA selection from u-boot.
Tested on mx6sl and mx6q and I could run 'reboot' from Linux without CONFIG_ARM_ERRATA_742230.
To be in the safe side I will send a v3 targeted for the upcoming 2014.01 release that only adds the 3 errata to mx6sl.
Full agree.
Regards, Stefano Babic
Hi Shawn,
On 09/01/2014 07:28, Shawn Guo wrote:
On Thu, Jan 09, 2014 at 03:50:06AM +0000, Hui.Liu@freescale.com wrote:
The commit log really get me confused, why we need enable one ERRATA which should not be applied?
It's been enabled as a workaround for the reboot issue we were seeing before. But I get reminded that the workaround may not be needed anymore, because of the recent kernel commit 87a84b69 (ARM: imx: replace imx6q_restart() with mxc_restart()). The real change is that we do not call of_iomap() in restart hook now.
Fabio,
Can you give it a test to see if reboot works fine with v3.13-rc kernel with dropping the ERRATA from u-boot? If reboot works and nothing else breaks, we may want to just remove the ERRATA selection from u-boot.
+1
If the workaround must be set for dual/quad, it is not clear to me if there are some disadvantages to let it enabled for solo.
This will make customer confused at all. We need find the real root-cause for it other than hack it Otherwise, you will get more and more problems sooner or later...
If you go through the thread [1], you will see that the root-cause had pretty much been identified, - issuing dmb instructions in a tight loop causes the problem. But people did not reach a conclusion how it should be fixed.
Exactly, and more frightening IMHO is what can happen is user space if gcc uses dmb.
Regards, Stefano
participants (5)
-
Dirk Behme -
Fabio Estevam -
Hui.Liuļ¼ freescale.com -
Shawn Guo -
Stefano Babic