RE: Passing mem=1G to kernel on Panda, system is unstable.

[Santosh Shilimkar <santosh.shilimkar@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> Sent: Friday, January 14, 2011 1:43 PM
> To: Bryan Wu; linux-omap@vger.kernel.org; Ricardo Salveti de Araujo
> Subject: RE: Passing mem=1G to kernel on Panda, system is unstable.
>
> Bryan,
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Bryan Wu
> > Sent: Tuesday, January 11, 2011 10:22 PM
> > To: linux-omap@vger.kernel.org; Ricardo Salveti de Araujo
> > Subject: Passing mem=1G to kernel on Panda, system is unstable.
> >
> > Hi folks,
> >
> > We are trying to build kernel package or GCC natively on OMAP4
> panda
> > board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35
> based
> > kernel, we met same instabilities on the system when we try to use
> > mem=1G on the board.
> >
> > Please find our bug tracker here:
> > https://bugs.launchpad.net/ubuntu/+source/linux-ti-
> omap4/+bug/633227
> > and I think another bug is also related:
> > https://bugs.launchpad.net/ubuntu/+source/linux-ti-
> > omap4/+bug/690370.
> > System will freeze at all when building GCC natively on Panda.
> >
> > Did any folks meet this issue? or we need more simple test case to
> > catch the root cause of this issue.
> >
> Haven't seen this issue on my SDP with 2.6.37.
> Have you enabled HIGHMEM, when tried mem = 1G on 2.6.37 ?

This patch may not be relevant but last week while scanning
errata's I came across one which is applicable to OMAP4 ES2.x

Am attaching it. Please give a try. Have boot tested with latest
mainline tree.

Regards,
Santosh

[-- Attachment #2: 0001-ARM-l2x0-Errata-fix-for-flush-by-Way-operation-can.patch --]
[-- Type: application/octet-stream, Size: 3844 bytes --]

From 38406dbf0ed3f4b25369daea7d797292e00f3f0e Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Fri, 14 Jan 2011 14:16:04 +0530
Subject: [PATCH] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption

PL310 implements the Clean & Invalidate by Way L2 cache maintenance
operation (offset 0x7FC). This operation runs in background so that
PL310 can handle normal accesses while it is in progress. Under very
rare circumstances, due to this erratum, write data can be lost when
PL310 treats a cacheable write transaction during a Clean & Invalidate
by Way operation.

Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register)
Clean & Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/Kconfig            |   11 +++++++++++
 arch/arm/mach-omap2/Kconfig |    1 +
 arch/arm/mm/cache-l2x0.c    |   16 ++++++++++------
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9678ee5..a7dfc05 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1181,6 +1181,17 @@ config ARM_ERRATA_743622
 	  visible impact on the overall performance or power consumption of the
 	  processor.
 
+config PL310_ERRATA_727915
+	bool "Background Clean & Invalidate by Way operation can cause data corruption"
+	depends on CACHE_L2X0 && ARCH_OMAP4
+	help
+	  PL310 implements the Clean & Invalidate by Way L2 cache maintenance
+	  operation (offset 0x7FC). This operation runs in background so that
+	  PL310 can handle normal accesses while it is in progress. Under very
+	  rare circumstances, due to this erratum, write data can be lost when
+	  PL310 treats a cacheable write transaction during a Clean &
+	  Invalidate by Way operation Note that this errata uses Texas
+	  Instrument's secure monitor api to implement the work around.
 endmenu
 
 source "arch/arm/common/Kconfig"
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index d02a068..d6380a6 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -46,6 +46,7 @@ config ARCH_OMAP4
 	select CPU_V7
 	select ARM_GIC
 	select PL310_ERRATA_588369
+	select PL310_ERRATA_727915 
 	select ARM_ERRATA_720789
 	select ARCH_HAS_OPP
 	select PM_OPP if PM
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 170c9bb..c7c8fbe 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -67,7 +67,7 @@ static inline void l2x0_inv_line(unsigned long addr)
 	writel_relaxed(addr, base + L2X0_INV_LINE_PA);
 }
 
-#ifdef CONFIG_PL310_ERRATA_588369
+#if defined(CONFIG_PL310_ERRATA_588369) || defined(CONFIG_PL310_ERRATA_727915)
 static void debug_writel(unsigned long val)
 {
 	extern void omap_smc1(u32 fn, u32 arg);
@@ -78,7 +78,14 @@ static void debug_writel(unsigned long val)
 	 */
 	omap_smc1(0x100, val);
 }
+#else
+/* Optimised out for non-errata case */
+static inline void debug_writel(unsigned long val)
+{
+}
+#endif
 
+#ifdef CONFIG_PL310_ERRATA_588369
 static inline void l2x0_flush_line(unsigned long addr)
 {
 	void __iomem *base = l2x0_base;
@@ -91,11 +98,6 @@ static inline void l2x0_flush_line(unsigned long addr)
 }
 #else
 
-/* Optimised out for non-errata case */
-static inline void debug_writel(unsigned long val)
-{
-}
-
 static inline void l2x0_flush_line(unsigned long addr)
 {
 	void __iomem *base = l2x0_base;
@@ -119,9 +121,11 @@ static void l2x0_flush_all(void)
 
 	/* clean all ways */
 	spin_lock_irqsave(&l2x0_lock, flags);
+	debug_writel(0x03);
 	writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_INV_WAY);
 	cache_wait_way(l2x0_base + L2X0_CLEAN_INV_WAY, l2x0_way_mask);
 	cache_sync();
+	debug_writel(0x00);
 	spin_unlock_irqrestore(&l2x0_lock, flags);
 }
 
-- 
1.6.0.4