[U-Boot] [PATCH] mx5: Add workaround for ARM erratum ID 468414
From: Fabio Estevam fabio.estevam@freescale.com
Add the software workaround for ARM erratum ID 468414.
According to mx53/mx51 errata document:
"ENGcm11133 - ARM: NEON load data can be incorrectly forwarded to a subsequent request
Description:
Under very specific set of conditions, data from a Neon load request can be incorrectly forwarded to a subsequent, unrelated memory request. The conditions are as follows: • Neon loads and stores must be in use • Neon L1 caching must be disabled • Trustzone must be configured and in use • The secure memory address space and the non-secure memory address space both use the same physical addresses, either as an alias or the same memory location or for separate memory locations The issue is reported by ARM, erratum ID 468414, Category 2"
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- arch/arm/cpu/armv7/mx5/lowlevel_init.S | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index 683a7b5..c1a04db 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -24,6 +24,13 @@ #include <generated/asm-offsets.h> #include <linux/linkage.h>
+.macro init_arm_erratum + /* ARM erratum ID #468414 */ + mrc 15, 0, r1, c1, c0, 1 + orr r1, r1, #(1 << 5) /* enable L1NEON bit */ + mcr 15, 0, r1, c1, c0, 1 +.endm + /* * L2CC Cache setup/invalidation/disable */ @@ -338,6 +345,8 @@ ENTRY(lowlevel_init) str r1, [r0, #0x4] #endif
+ init_arm_erratum + init_l2cc
init_aips
On 07/05/2012 22:56, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Add the software workaround for ARM erratum ID 468414.
According to mx53/mx51 errata document:
"ENGcm11133 - ARM: NEON load data can be incorrectly forwarded to a subsequent request
Description:
Under very specific set of conditions, data from a Neon load request can be incorrectly forwarded to a subsequent, unrelated memory request. The conditions are as follows: • Neon loads and stores must be in use • Neon L1 caching must be disabled • Trustzone must be configured and in use • The secure memory address space and the non-secure memory address space both use the same physical addresses, either as an alias or the same memory location or for separate memory locations The issue is reported by ARM, erratum ID 468414, Category 2"
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
arch/arm/cpu/armv7/mx5/lowlevel_init.S | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index 683a7b5..c1a04db 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -24,6 +24,13 @@ #include <generated/asm-offsets.h> #include <linux/linkage.h>
+.macro init_arm_erratum
- /* ARM erratum ID #468414 */
- mrc 15, 0, r1, c1, c0, 1
- orr r1, r1, #(1 << 5) /* enable L1NEON bit */
- mcr 15, 0, r1, c1, c0, 1
+.endm
/*
- L2CC Cache setup/invalidation/disable
*/ @@ -338,6 +345,8 @@ ENTRY(lowlevel_init) str r1, [r0, #0x4] #endif
- init_arm_erratum
I have only a small question. It is not for me to put this into MX5 stuff, but because it is ARM related should we not put it into arch/arm/cpu/armv7/start.S ?
Best regards, Stefano Babic
Am 09/05/2012 11:36, schrieb Stefano Babic:
On 07/05/2012 22:56, Fabio Estevam wrote:
From: Fabio Estevam fabio.estevam@freescale.com
Add the software workaround for ARM erratum ID 468414.
According to mx53/mx51 errata document:
"ENGcm11133 - ARM: NEON load data can be incorrectly forwarded to a subsequent request
Description:
Under very specific set of conditions, data from a Neon load request can be incorrectly forwarded to a subsequent, unrelated memory request. The conditions are as follows: • Neon loads and stores must be in use • Neon L1 caching must be disabled • Trustzone must be configured and in use • The secure memory address space and the non-secure memory address space both use the same physical addresses, either as an alias or the same memory location or for separate memory locations The issue is reported by ARM, erratum ID 468414, Category 2"
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
arch/arm/cpu/armv7/mx5/lowlevel_init.S | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index 683a7b5..c1a04db 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -24,6 +24,13 @@ #include <generated/asm-offsets.h> #include <linux/linkage.h>
+.macro init_arm_erratum
- /* ARM erratum ID #468414 */
- mrc 15, 0, r1, c1, c0, 1
- orr r1, r1, #(1 << 5) /* enable L1NEON bit */
- mcr 15, 0, r1, c1, c0, 1
+.endm
/*
- L2CC Cache setup/invalidation/disable
*/ @@ -338,6 +345,8 @@ ENTRY(lowlevel_init) str r1, [r0, #0x4] #endif
- init_arm_erratum
I have only a small question. It is not for me to put this into MX5 stuff, but because it is ARM related should we not put it into arch/arm/cpu/armv7/start.S ?
Checking again forgotten patches, I noted that the same issue is fixed separately in other SOCs directory (OMAP3). It is not bad to merge this, too, until we want to factorize it for all armv7 SOCs.
Applied to u-boot-imx, thanks.
Best regards, Stefano Babic
participants (2)
-
Fabio Estevam -
Stefano Babic