configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
PATCH v2 1/2 configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
From: Fabio Estevam <[email protected]>
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
---
Changes since v1:
- Improve commit log
include/configs/mx6_common.h | 2 ++ 1 file changed, 2 insertions(+)
include/configs/mx6_common.h +2 -0
@@ -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
Signature · 1 line
1.8.1.2
PATCH v2 2/2 mx6slevk: Include "mx6_common.h"
From: Fabio Estevam <[email protected]>
Include "mx6_common.h" so that some ARM errata are applied and also the vddsoc regulator can be changed.
---
Changes since v1:
- None
include/configs/mx6slevk.h | 1 + 1 file changed, 1 insertion(+)
include/configs/mx6slevk.h +1 -0
@@ -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
Signature · 1 line
1.8.1.2
PATCH v2 1/2 configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
In reply to Fabio EstevamHi Fabio,
Quoted 5 lines · Fabio Estevam
From: Fabio Estevam <[email protected]>
According to
e9fd66defd(ARM: mx6: defineCONFIG_ARM_ERRATA_742230), theCONFIG_ARM_ERRATA_742230option 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
Quoted 42 lines
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: defineCONFIG_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
Signed-off-by Fabio Estevam <[email protected]>---
Changes since v1:
- Improve commit loginclude/configs/mx6_common.h | 2 ++ 1 file changed, 2 insertions(+)include/configs/mx6_common.h +2
-0@@ -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
PATCH v2 1/2 configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
Hi Dirk,
Quoted 3 lines · Dirk Behme
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
PATCH v2 1/2 configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
In reply to Fabio EstevamQuoted 29 lines
-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Wednesday, January 08, 2014 10:00 PM
To: sbabic at denx.de
Cc: shawn.guo at linaro.org; Liu Hui-R64343; u-boot at lists.denx.de; Estevam Fabio-R49496
Subject: [PATCH v2 1/2] configs:mx6_common: RestrictCONFIG_ARM_ERRATA_742230for multi-coreFrom: Fabio Estevam <[email protected]>
According to
e9fd66defd(ARM: mx6: defineCONFIG_ARM_ERRATA_742230), theCONFIG_ARM_ERRATA_742230option 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: defineCONFIG_ARM_ERRATA_742230) to turn on the erratum for imx6 dual/quad.
Quoted 6 lines
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
Quoted 27 lines
Signed-off-by Fabio Estevam <[email protected]>---
Changes since v1:
- Improve commit loginclude/configs/mx6_common.h | 2 ++ 1 file changed, 2 insertions(+)include/configs/mx6_common.h +2
-1@@ -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
PATCH v2 1/2 configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
Quoted 1 line · Hui.Liu at freescale.com
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.
Quoted 2 lines
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.
Quoted 3 lines
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
PATCH v2 1/2 configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
Quoted 5 lines · Shawn Guo
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
PATCH v2 1/2 configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
Hi Fabio,
Quoted 8 lines · Fabio Estevam
Quoted 5 lines · Shawn Guo
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.
Quoted 5 lines
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
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v2 1/2 configs: mx6_common: Restrict CONFIG_ARM_ERRATA_742230 for multi-core
In reply to Shawn GuoHi Shawn,
Quoted 9 lines · Shawn Guo
Quoted 1 line · Hui.Liu at freescale.com
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: replaceimx6q_restart()withmxc_restart()). The real change is that we do not callof_iomap()in restart hook now.
Quoted 6 lines
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.
Quoted 7 lines
Quoted 2 lines
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
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================