[PATCH 1/3] ARM: MM: Add the workaround of Errata 774769

[PATCH 1/3] ARM: MM: Add the workaround of Errata 774769

[Boojin Kim]

This patch adds the workaround of Errata 774769 that configures write streaming
on versions of A15 affected by this erratum such that no streaming-write ever
allocates into the L2 cache.

Signed-off-by: Boojin Kim <boojin.kim@samsung.com>
---
 arch/arm/Kconfig             |   11 +++++++++++
 arch/arm/mach-exynos/Kconfig |    1 +
 arch/arm/mm/proc-v7.S        |   16 ++++++++++++++--
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9759fec..11a57e2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1417,6 +1417,17 @@ config ARM_ERRATA_775420
 	 to deadlock. This workaround puts DSB before executing ISB if
 	 an abort may occur on cache maintenance.

+config ARM_ERRATA_774769
+	bool "ARM errata: data corruption may occur with store streaming in a system"
+	depends on CPU_V7
+	help
+	  This option enables the workaround for the erratum 774769 affecting
+	  Cortex-A15 (r0p4).
+	  External memory may be corrupted on erratum 774769.
+	  The workaround is to configure write streaming on versions of A15
+	  affected by this erratum such that no streaming-write ever allocates
+	  into the L2 cache.
+
 endmenu

 source "arch/arm/common/Kconfig"
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index da55107..e1168fb 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -22,6 +22,7 @@ config ARCH_EXYNOS4
 config ARCH_EXYNOS5
 	bool "SAMSUNG EXYNOS5"
 	select HAVE_SMP
+	select ARM_ERRATA_774769
 	help
 	  Samsung EXYNOS5 (Cortex-A15) SoC based systems

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 846d279..06cbdfa 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -208,7 +208,7 @@ __v7_setup:
 	orreq	r10, r10, #(1 << 22)		@ set the Write Allocate disable bit
 	mcreq	p15, 1, r10, c9, c0, 2		@ write the L2 cache aux ctrl register
 #endif
-	b	3f
+	b	4f

 	/* Cortex-A9 Errata */
 2:	ldr	r10, =0x00000c09		@ Cortex-A9 primary part number
@@ -243,8 +243,20 @@ __v7_setup:
 	mcrlt	p15, 0, r10, c15, c0, 1		@ write diagnostic register
 1:
 #endif
+	b	4f

-3:	mov	r10, #0
+	/* Cortex-A15 Errata */
+3:	ldr	r10, =0x00000c0f		@ Cortex-A15 primary part number
+	teq	r0, r10
+	bne	4f
+#ifdef CONFIG_ARM_ERRATA_774769
+	teq	r6, #0x4			@ present in r0p4
+	mrceq	p15, 0, r10, c1, c0, 1		@ read aux control register
+	orreq	r10, r10, #1 << 25		@ set bit #25
+	mcreq	p15, 0, r10, c1, c0, 1		@ write aux control register
+#endif
+
+4:	mov	r10, #0
 	mcr	p15, 0, r10, c7, c5, 0		@ I+BTB cache invalidate
 	dsb
 #ifdef CONFIG_MMU
--
1.7.5.4

Re: [PATCH 1/3] ARM: MM: Add the workaround of Errata 774769

[Russell King - ARM Linux]

On Mon, Dec 10, 2012 at 08:58:35AM +0900, Boojin Kim wrote:
> 
> -3:	mov	r10, #0
> +	/* Cortex-A15 Errata */
> +3:	ldr	r10, =0x00000c0f		@ Cortex-A15 primary part number
> +	teq	r0, r10
> +	bne	4f
> +#ifdef CONFIG_ARM_ERRATA_774769

There's not much point testing for the part number of the work-around isn't
enabled.

> +	teq	r6, #0x4			@ present in r0p4
> +	mrceq	p15, 0, r10, c1, c0, 1		@ read aux control register

	tsteq	r10, #1 << 15

to avoid writing to the aux control register if the errata has already been
applied.

> +	orreq	r10, r10, #1 << 25		@ set bit #25
> +	mcreq	p15, 0, r10, c1, c0, 1		@ write aux control register
> +#endif
> +
> +4:	mov	r10, #0
>  	mcr	p15, 0, r10, c7, c5, 0		@ I+BTB cache invalidate
>  	dsb
>  #ifdef CONFIG_MMU
> --
> 1.7.5.4
> 
> 
> 

RE: [PATCH 1/3] ARM: MM: Add the workaround of Errata 774769

[Boojin Kim]

Russell King - ARM Linux wrote:

> > -3:	mov	r10, #0
> > +	/* Cortex-A15 Errata */
> > +3:	ldr	r10, =0x00000c0f		@ Cortex-A15 primary part number
> > +	teq	r0, r10
> > +	bne	4f
> > +#ifdef CONFIG_ARM_ERRATA_774769
>
> There's not much point testing for the part number of the work-around isn't
> enabled.
The errata 773022 on second patch series is also required to checking the part number.
In my opinion, the testing for Cortex-A15 primary part number is required
before working the work-around to support several A15 errata.

>
> > +	teq	r6, #0x4			@ present in r0p4
> > +	mrceq	p15, 0, r10, c1, c0, 1		@ read aux control register
>
> 	tsteq	r10, #1 << 15
>
> to avoid writing to the aux control register if the errata has already been
> applied.
Do you mean "tsteq	r10, #1 << 25" ?
If yes, it needs to branch and will make a little complicated
And, I think maybe this function could be the first step to configure this erratum.

Thanks for your review

>
> > +	orreq	r10, r10, #1 << 25		@ set bit #25
> > +	mcreq	p15, 0, r10, c1, c0, 1		@ write aux control register
> > +#endif
> > +
> > +4:	mov	r10, #0
> >  	mcr	p15, 0, r10, c7, c5, 0		@ I+BTB cache invalidate
> >  	dsb
> >  #ifdef CONFIG_MMU
> > --
> > 1.7.5.4
> >
> >
> >
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/3] ARM: MM: Add the workaround of Errata 774769

[Santosh Shilimkar]

On Monday 10 December 2012 05:28 AM, Boojin Kim wrote:
> This patch adds the workaround of Errata 774769 that configures write streaming
> on versions of A15 affected by this erratum such that no streaming-write ever
> allocates into the L2 cache.
>
> Signed-off-by: Boojin Kim <boojin.kim@samsung.com>
> ---
>   arch/arm/Kconfig             |   11 +++++++++++
>   arch/arm/mach-exynos/Kconfig |    1 +
>   arch/arm/mm/proc-v7.S        |   16 ++++++++++++++--
>   3 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9759fec..11a57e2 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1417,6 +1417,17 @@ config ARM_ERRATA_775420
>   	 to deadlock. This workaround puts DSB before executing ISB if
>   	 an abort may occur on cache maintenance.
>
> +config ARM_ERRATA_774769
> +	bool "ARM errata: data corruption may occur with store streaming in a system"
> +	depends on CPU_V7
> +	help
> +	  This option enables the workaround for the erratum 774769 affecting
> +	  Cortex-A15 (r0p4).
> +	  External memory may be corrupted on erratum 774769.
> +	  The workaround is to configure write streaming on versions of A15
> +	  affected by this erratum such that no streaming-write ever allocates
> +	  into the L2 cache.
> +
>   endmenu
>
>   source "arch/arm/common/Kconfig"
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index da55107..e1168fb 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -22,6 +22,7 @@ config ARCH_EXYNOS4
>   config ARCH_EXYNOS5
>   	bool "SAMSUNG EXYNOS5"
>   	select HAVE_SMP
> +	select ARM_ERRATA_774769
>   	help
>   	  Samsung EXYNOS5 (Cortex-A15) SoC based systems
>
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 846d279..06cbdfa 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -208,7 +208,7 @@ __v7_setup:
>   	orreq	r10, r10, #(1 << 22)		@ set the Write Allocate disable bit
>   	mcreq	p15, 1, r10, c9, c0, 2		@ write the L2 cache aux ctrl register
>   #endif
> -	b	3f
> +	b	4f
>
>   	/* Cortex-A9 Errata */
>   2:	ldr	r10, =0x00000c09		@ Cortex-A9 primary part number
> @@ -243,8 +243,20 @@ __v7_setup:
>   	mcrlt	p15, 0, r10, c15, c0, 1		@ write diagnostic register
>   1:
>   #endif
> +	b	4f
>
> -3:	mov	r10, #0
> +	/* Cortex-A15 Errata */
> +3:	ldr	r10, =0x00000c0f		@ Cortex-A15 primary part number
> +	teq	r0, r10
> +	bne	4f
> +#ifdef CONFIG_ARM_ERRATA_774769
> +	teq	r6, #0x4			@ present in r0p4
> +	mrceq	p15, 0, r10, c1, c0, 1		@ read aux control register
> +	orreq	r10, r10, #1 << 25		@ set bit #25
> +	mcreq	p15, 0, r10, c1, c0, 1		@ write aux control register
This will fault on kernels booted in non-secure mode. The comment is
applicable for other two patches in series as well.

Russell/Catalin,
Whats the stand on such erratas ? I saw on one of thread one of
you suggesting to stop patching kernel where secure/non-secure
kernel will need different errata WA.

Regards
Santosh

Re: [PATCH 1/3] ARM: MM: Add the workaround of Errata 774769

[Russell King - ARM Linux]

On Mon, Dec 10, 2012 at 07:40:06PM +0530, Santosh Shilimkar wrote:
> Whats the stand on such erratas ? I saw on one of thread one of
> you suggesting to stop patching kernel where secure/non-secure
> kernel will need different errata WA.

Well, yes, there's that too.  I think were we got to was deciding that
it is impossible to tell whether an errata is required for any particular
SoC: even when you know the rXpX number of the core, you don't know if,
as part of the design, the manufacturer incorporated some fix.

So, the conclusion we came to was that the _only_ place that work-arounds
like these can be enabled is before we get anywhere near the kernel - in
whatever pre-kernel code the platform has, and doing whatever platform
specific magic is required to get those work-arounds enabled.

What that means is that having the work-arounds in the kernel is pretty
pointless when it's a matter of enabling a bit or two in some secure-only
register.

I don't think I heard any objections to removing those work-arounds which
fall into this category from the kernel; I think that's something we need
to schedule for a few kernel versions time, after we've put them into the
feature-removal file, and marked them in the config as going away.

Re: [PATCH 1/3] ARM: MM: Add the workaround of Errata 774769

[Santosh Shilimkar]

On Monday 10 December 2012 07:46 PM, Russell King - ARM Linux wrote:
> On Mon, Dec 10, 2012 at 07:40:06PM +0530, Santosh Shilimkar wrote:
>> Whats the stand on such erratas ? I saw on one of thread one of
>> you suggesting to stop patching kernel where secure/non-secure
>> kernel will need different errata WA.
>
> Well, yes, there's that too.  I think were we got to was deciding that
> it is impossible to tell whether an errata is required for any particular
> SoC: even when you know the rXpX number of the core, you don't know if,
> as part of the design, the manufacturer incorporated some fix.
>
> So, the conclusion we came to was that the _only_ place that work-arounds
> like these can be enabled is before we get anywhere near the kernel - in
> whatever pre-kernel code the platform has, and doing whatever platform
> specific magic is required to get those work-arounds enabled.
>
> What that means is that having the work-arounds in the kernel is pretty
> pointless when it's a matter of enabling a bit or two in some secure-only
> register.
>
> I don't think I heard any objections to removing those work-arounds which
> fall into this category from the kernel; I think that's something we need
> to schedule for a few kernel versions time, after we've put them into the
> feature-removal file, and marked them in the config as going away.
>
Thanks for confirming it. All the patches in the $subject series falls
into secure/non-secure category and hence subject to the same issues.

Regards
Santosh