Patchwork [U-Boot] mx5: Add workaround for ARM erratum ID 468414

login
register
mail settings
Submitter Fabio Estevam
Date May 7, 2012, 8:56 p.m.
Message ID <1336424160-17256-1-git-send-email-festevam@gmail.com>
Download mbox | patch
Permalink /patch/157461/
State Awaiting Upstream
Delegated to: Stefano Babic
Headers show

Comments

Fabio Estevam - May 7, 2012, 8:56 p.m.
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(-)
Stefano Babic - May 9, 2012, 9:36 a.m.
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
Stefano Babic - Oct. 17, 2012, 4:28 p.m.
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

Patch

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