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

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 <redacted>
---
 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

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

Russell King - ARM Linux wrote:

quoted

-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.

quoted

+	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

quoted

+	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 at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On Monday 10 December 2012 05:28 AM, Boojin Kim wrote:

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

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.

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:

quoted

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