[PATCH 0/7] omap4: Fixes, hacks for es2.0

[PATCH 0/7] omap4: Fixes, hacks for es2.0

[Santosh Shilimkar]

This series has few fixes, hacks to get omap4 es2.0 working
on mainline. The patches are generated against the mainline 
2.6.36-rc3. 


The series is boot tested tested on 4430 SDP, Blaze with 
omap_4430sdp_defconfig with file over NFS and MMC.

Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
SDPs. Same observation with Panda

With omap3_defconfig, MMC while mounting the rootfs over MMC, the
boot hangs. Same observation with Panda

[    5.794616] regulator_init_complete: incomplete constraints, leaving VUSIM on
[    5.802764] regulator_init_complete: incomplete constraints, leaving VPP on
[    5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:53:12 UTC (9      )
[    5.849304] mmc0: new high speed MMC card at address 0001
[    5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
[    5.862091]  mmcblk0: unknown partition table
[    6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate latency 0: 6
[   18.424407] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2)
[   18.431823] Please append a correct "root=" boot option; here are the available      ons:
[   18.440643] b300         7757824 mmcblk0 driver: mmcblk
[   18.446166] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown

All these patches are also available at:
	http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=summary
	head: omap4-for-tony

David Anders (1):
  omap4: Panda: Add DEBUG_LL support

Eric Dumazet (1):
  KS8851: Correct RX packet allocation

Madhusudhan Chikkature (1):
  omap4: Workaround for CMD line reset.

Santosh Shilimkar (4):
  omap4: Update id.c and cpu.h for es2.0
  omap4: Temporary fix silicon version detection
  omap4: l2x0: Fix init parameter for ES2.0
  omap4: Fix bootup crash observed with higher CPU clocks

 arch/arm/mach-omap2/id.c                     |   39 +++++++++++++++++++++----
 arch/arm/mach-omap2/omap4-common.c           |    5 ++-
 arch/arm/plat-omap/dmtimer.c                 |    2 +-
 arch/arm/plat-omap/include/plat/cpu.h        |    5 ++-
 arch/arm/plat-omap/include/plat/uncompress.h |    1 +
 drivers/mmc/host/omap_hsmmc.c                |    8 +++++
 drivers/net/ks8851.c                         |   39 ++++++++++++++------------
 7 files changed, 71 insertions(+), 28 deletions(-)

[PATCH 1/7] omap4: Update id.c and cpu.h for es2.0

[Santosh Shilimkar]

This patch updates the id.c and cpu.h files to support
omap4 ES2.0 silicon detection.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/id.c              |   29 ++++++++++++++++++++++-------
 arch/arm/plat-omap/include/plat/cpu.h |    5 ++++-
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 9a879f9..a423c7f 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -298,7 +298,6 @@ static void __init omap4_check_revision(void)
 	u32 idcode;
 	u16 hawkeye;
 	u8 rev;
-	char *rev_name = "ES1.0";
 
 	/*
 	 * The IC rev detection is done with hawkeye and rev.
@@ -309,14 +308,30 @@ static void __init omap4_check_revision(void)
 	hawkeye = (idcode >> 12) & 0xffff;
 	rev = (idcode >> 28) & 0xff;
 
-	if ((hawkeye == 0xb852) && (rev == 0x0)) {
-		omap_revision = OMAP4430_REV_ES1_0;
-		omap_chip.oc |= CHIP_IS_OMAP4430ES1;
-		pr_info("OMAP%04x %s\n", omap_rev() >> 16, rev_name);
-		return;
+	switch (hawkeye) {
+	case 0xb852:
+		switch (rev) {
+		case 0:
+			omap_revision = OMAP4430_REV_ES1_0;
+			omap_chip.oc |= CHIP_IS_OMAP4430ES1;
+			break;
+		case 1:
+			omap_revision = OMAP4430_REV_ES2_0;
+			omap_chip.oc |= CHIP_IS_OMAP4430ES2;
+			break;
+		default:
+			omap_revision = OMAP4430_REV_ES2_0;
+			omap_chip.oc |= CHIP_IS_OMAP4430ES2;
+	}
+	break;
+	default:
+		/* Unknown default to latest silicon rev as default*/
+		omap_revision = OMAP4430_REV_ES2_0;
+		omap_chip.oc |= CHIP_IS_OMAP4430ES2;
 	}
 
-	pr_err("Unknown OMAP4 CPU id\n");
+	pr_info("OMAP%04x ES%d.0\n",
+			omap_rev() >> 16, ((omap_rev() >> 12) & 0xf) + 1);
 }
 
 #define OMAP3_SHOW_FEATURE(feat)		\
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 2e2ae53..9b38e4b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -391,6 +391,7 @@ IS_OMAP_TYPE(3517, 0x3517)
 
 #define OMAP443X_CLASS		0x44300044
 #define OMAP4430_REV_ES1_0	0x44300044
+#define OMAP4430_REV_ES2_0	0x44301044
 
 /*
  * omap_chip bits
@@ -417,10 +418,12 @@ IS_OMAP_TYPE(3517, 0x3517)
 #define CHIP_IS_OMAP4430ES1		(1 << 8)
 #define CHIP_IS_OMAP3630ES1_1           (1 << 9)
 #define CHIP_IS_OMAP3630ES1_2           (1 << 10)
+#define CHIP_IS_OMAP4430ES2		(1 << 11)
 
 #define CHIP_IS_OMAP24XX		(CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
 
-#define CHIP_IS_OMAP4430		(CHIP_IS_OMAP4430ES1)
+#define CHIP_IS_OMAP4430		(CHIP_IS_OMAP4430ES1 | \
+						 CHIP_IS_OMAP4430ES2)
 
 /*
  * "GE" here represents "greater than or equal to" in terms of ES
-- 
1.6.0.4

[PATCH 2/7] omap4: Temporary fix silicon version detection

[Santosh Shilimkar]

Few initial omap4 es2 samples IDCODE is same as es1. This patch
uses ARM cpuid register to detect the ES version for such samples

This patch can be reverted once all the samples gets replaced
with new lot.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/id.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a423c7f..487e8d6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -308,6 +308,16 @@ static void __init omap4_check_revision(void)
 	hawkeye = (idcode >> 12) & 0xffff;
 	rev = (idcode >> 28) & 0xff;
 
+	/*
+	 * FIXME: This patch should be reverted later.
+	 * Few initial ES2.0 samples IDCODE is same as ES1.0
+	 * Use ARM register to detect the correct ES version
+	 */
+	if (!rev) {
+		idcode = read_cpuid(CPUID_ID);
+		rev = (idcode & 0xf) - 1;
+	}
+
 	switch (hawkeye) {
 	case 0xb852:
 		switch (rev) {
-- 
1.6.0.4

[PATCH 3/7] omap4: l2x0: Fix init parameter for ES2.0

[Santosh Shilimkar]

On ES2.0 the L2 cache init parameter ineeds to be changed to take
care of cache size. The cache size is 1MB on ES2.0 vs 512KB on ES1.0

This patch fixes the init parameter to update the same using
dynamic cpu version check

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/omap4-common.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 13dc979..2b32229 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -64,7 +64,10 @@ static int __init omap_l2_cache_init(void)
 	 * 32KB way size, 16-way associativity,
 	 * parity disabled
 	 */
-	l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
+	if (omap_rev() == OMAP4430_REV_ES2_0)
+		l2x0_init(l2cache_base, 0x0e070000, 0xc0000fff);
+	else
+		l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
 
 	return 0;
 }
-- 
1.6.0.4

[PATCH 4/7] omap4: Panda: Add DEBUG_LL support

[Santosh Shilimkar]

From: David Anders <x0132446@ti.com>

Add support for use of DEBUG_LL for use with PandaBoard.

Signed-off-by: David Anders <x0132446@ti.com>
---
 arch/arm/plat-omap/include/plat/uncompress.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h
index ddf723b..57dffa7 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -153,6 +153,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
 
 		/* omap4 based boards using UART3 */
 		DEBUG_LL_OMAP4(3, omap_4430sdp);
+		DEBUG_LL_OMAP4(3, omap4_panda);
 
 		/* zoom2/3 external uart */
 		DEBUG_LL_ZOOM(omap_zoom2);
-- 
1.6.0.4

[PATCH 5/7] omap4: Fix bootup crash observed with higher CPU clocks

[Santosh Shilimkar]

This patch is temporary fix to below crash. This is observed when
CPU is clocked more than 600 MHz.

Unhandled fault: imprecise external abort (0x1406) at 0xbf9ef65c
Internal error: : 1406 [#1] PREEMPT SMP
last sysfs file:
Modules linked in:
CPU: 0    Not tainted  (2.6.36-rc3+ #18)
PC is at kernel_thread_helper+0x0/0x14
LR is at kernel_thread_helper+0x0/0x14
pc : [<c003ce14>]    lr : [<c003ce14>]    psr: 00000093
sp : dc83bff8  ip : 00000000  fp : 00000000
r10: 00000000  r9 : 00000000  r8 : 00000000
r7 : 00000013  r6 : c003ce28  r5 : c008935c  r4 : 00000000
r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000
Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7f  Table: 8000404a  DAC: 00000017
Process swapper (pid: 2, stack limit = 0xdc83a2f0)
Stack: (0xdc83bff8 to 0xdc83c000)
bfe0: 00000000 ffffffff
[<c003ce14>] (kernel_thread_helper+0x0/0x14) from [<fffffffe>] (0xfffffffe)
Code: c03a0ba3 c03a5fcb c045c880 c0394035 (eb017701)
---[ end trace 1b75b31a2719ed1c ]---

The timer hwmod adaptation will eventually fix it in a proper way.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/plat-omap/dmtimer.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 44bafda..1d706cf 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -581,7 +581,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
 	 * When the functional clock disappears, too quick writes seem
 	 * to cause an abort. XXX Is this still necessary?
 	 */
-	__delay(150000);
+	__delay(300000);
 
 	return ret;
 }
-- 
1.6.0.4

[PATCH 6/7] omap4: Workaround for CMD line reset.

[Santosh Shilimkar]

From: Madhusudhan Chikkature <madhu.cr@ti.com>

Add a delay after CMD line reset to accomdate the reset to complete.
The SYSCTL seems to reflect SRC immediately which might not really
be indicating the complete of reset. This is observed only with ES2.0
silicon

Signed-off-by: Madhusudhan Chikkature <madhu.cr@ti.com>
---
 drivers/mmc/host/omap_hsmmc.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4a8776f..1c359f0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -986,6 +986,14 @@ static inline void omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host *host,
 		(i++ < limit))
 		cpu_relax();
 
+	/*
+	 * On OMAP4 ES2 the SRC is zero in the first loop itself strangely
+	 * vs on ES1 it takes some time.
+	 * Could be a an issue on ES2 to indicate reset complete even before
+	 * it is complete.
+	 */
+	udelay(500);
+
 	if (OMAP_HSMMC_READ(host->base, SYSCTL) & bit)
 		dev_err(mmc_dev(host->mmc),
 			"Timeout waiting on controller reset in %s\n",
-- 
1.6.0.4

[PATCH 7/7] KS8851: Correct RX packet allocation

[Santosh Shilimkar]

From: Eric Dumazet <eric.dumazet@gmail.com>

Use netdev_alloc_skb_ip_align() helper and do correct allocation

Tested-by: Abraham Arce <x0066660@ti.com>
Signed-off-by: Abraham Arce <x0066660@ti.com>
---
 drivers/net/ks8851.c |   39 +++++++++++++++++++++------------------
 1 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index b4fb07a..51919fc 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -503,30 +503,33 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
 		ks8851_wrreg16(ks, KS_RXQCR,
 			       ks->rc_rxqcr | RXQCR_SDA | RXQCR_ADRFE);
 
-		if (rxlen > 0) {
-			skb = netdev_alloc_skb(ks->netdev, rxlen + 2 + 8);
-			if (!skb) {
-				/* todo - dump frame and move on */
-			}
+		if (rxlen > 4) {
+			unsigned int rxalign;
+
+			rxlen -= 4;
+			rxalign = ALIGN(rxlen, 4);
+			skb = netdev_alloc_skb_ip_align(ks->netdev, rxalign);
+			if (skb) {
 
-			/* two bytes to ensure ip is aligned, and four bytes
-			 * for the status header and 4 bytes of garbage */
-			skb_reserve(skb, 2 + 4 + 4);
+				/* 4 bytes of status header + 4 bytes of
+				 * garbage: we put them before ethernet
+				 * header, so that they are copied,
+				 * but ignored.
+				 */
 
-			rxpkt = skb_put(skb, rxlen - 4) - 8;
+				rxpkt = skb_put(skb, rxlen) - 8;
 
-			/* align the packet length to 4 bytes, and add 4 bytes
-			 * as we're getting the rx status header as well */
-			ks8851_rdfifo(ks, rxpkt, ALIGN(rxlen, 4) + 8);
+				ks8851_rdfifo(ks, rxpkt, rxalign + 8);
 
-			if (netif_msg_pktdata(ks))
-				ks8851_dbg_dumpkkt(ks, rxpkt);
+				if (netif_msg_pktdata(ks))
+					ks8851_dbg_dumpkkt(ks, rxpkt);
 
-			skb->protocol = eth_type_trans(skb, ks->netdev);
-			netif_rx(skb);
+				skb->protocol = eth_type_trans(skb, ks->netdev);
+				netif_rx(skb);
 
-			ks->netdev->stats.rx_packets++;
-			ks->netdev->stats.rx_bytes += rxlen - 4;
+				ks->netdev->stats.rx_packets++;
+				ks->netdev->stats.rx_bytes += rxlen;
+			}
 		}
 
 		ks8851_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr);
-- 
1.6.0.4

Re: [PATCH 6/7] omap4: Workaround for CMD line reset.

[kishore kadiyala]

Hi Madhu,

On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> From: Madhusudhan Chikkature <madhu.cr@ti.com>
>
> Add a delay after CMD line reset to accomdate the reset to complete.
> The SYSCTL seems to reflect SRC immediately which might not really
> be indicating the complete of reset. This is observed only with ES2.0
> silicon
>
> Signed-off-by: Madhusudhan Chikkature <madhu.cr@ti.com>
> ---
>  drivers/mmc/host/omap_hsmmc.c |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 4a8776f..1c359f0 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -986,6 +986,14 @@ static inline void omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host *host,
>                (i++ < limit))
>                cpu_relax();
>
> +       /*
> +        * On OMAP4 ES2 the SRC is zero in the first loop itself strangely
> +        * vs on ES1 it takes some time.
> +        * Could be a an issue on ES2 to indicate reset complete even before
> +        * it is complete.
> +        */
> +       udelay(500);

Since the above work around is applicable only for OMAP4 ES2 ,
shouldn't this udelay be avoided for other OMAP versions

Regards,
Kishore
> +
>        if (OMAP_HSMMC_READ(host->base, SYSCTL) & bit)
>                dev_err(mmc_dev(host->mmc),
>                        "Timeout waiting on controller reset in %s\n",
> --
> 1.6.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 6/7] omap4: Workaround for CMD line reset.

[Madhusudhan]

> -----Original Message-----
> From: kishore kadiyala [mailto:kishorek.kadiyala@gmail.com]
> Sent: Tuesday, September 14, 2010 10:47 AM
> To: Madhusudhan Chikkature; Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; tony@atomide.com;
> khilman@deeprootsystems.com
> Subject: Re: [PATCH 6/7] omap4: Workaround for CMD line reset.
> 
> Hi Madhu,
> 
> On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> > From: Madhusudhan Chikkature <madhu.cr@ti.com>
> >
> > Add a delay after CMD line reset to accomdate the reset to complete.
> > The SYSCTL seems to reflect SRC immediately which might not really
> > be indicating the complete of reset. This is observed only with ES2.0
> > silicon
> >
> > Signed-off-by: Madhusudhan Chikkature <madhu.cr@ti.com>
> > ---
> >  drivers/mmc/host/omap_hsmmc.c |    8 ++++++++
> >  1 files changed, 8 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/mmc/host/omap_hsmmc.c
> b/drivers/mmc/host/omap_hsmmc.c
> > index 4a8776f..1c359f0 100644
> > --- a/drivers/mmc/host/omap_hsmmc.c
> > +++ b/drivers/mmc/host/omap_hsmmc.c
> > @@ -986,6 +986,14 @@ static inline void
> omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host *host,
> >                (i++ < limit))
> >                cpu_relax();
> >
> > +       /*
> > +        * On OMAP4 ES2 the SRC is zero in the first loop itself
> strangely
> > +        * vs on ES1 it takes some time.
> > +        * Could be a an issue on ES2 to indicate reset complete even
> before
> > +        * it is complete.
> > +        */
> > +       udelay(500);
> 
> Since the above work around is applicable only for OMAP4 ES2 ,
> shouldn't this udelay be avoided for other OMAP versions
> 
I did not post this to Linux omap at all. What patch are you talking about?

Regards,
Madhu

> Regards,
> Kishore
> > +
> >        if (OMAP_HSMMC_READ(host->base, SYSCTL) & bit)
> >                dev_err(mmc_dev(host->mmc),
> >                        "Timeout waiting on controller reset in %s\n",
> > --
> > 1.6.0.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 6/7] omap4: Workaround for CMD line reset.

[Shilimkar, Santosh]

Madhu,
> -----Original Message-----
> From: Chikkature Rajashekar, Madhusudhan
> Sent: Tuesday, September 14, 2010 9:28 PM
> To: 'kishore kadiyala'; Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; tony@atomide.com;
> khilman@deeprootsystems.com
> Subject: RE: [PATCH 6/7] omap4: Workaround for CMD line reset.
> 
> 
> 
> > -----Original Message-----
> > From: kishore kadiyala [mailto:kishorek.kadiyala@gmail.com]
> > Sent: Tuesday, September 14, 2010 10:47 AM
> > To: Madhusudhan Chikkature; Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; tony@atomide.com;
> > khilman@deeprootsystems.com
> > Subject: Re: [PATCH 6/7] omap4: Workaround for CMD line reset.
> >
> > Hi Madhu,
> >
> > On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar
> > <santosh.shilimkar@ti.com> wrote:
> > > From: Madhusudhan Chikkature <madhu.cr@ti.com>
> > >
> > > Add a delay after CMD line reset to accomdate the reset to complete.
> > > The SYSCTL seems to reflect SRC immediately which might not really
> > > be indicating the complete of reset. This is observed only with ES2.0
> > > silicon
> > >
> > > Signed-off-by: Madhusudhan Chikkature <madhu.cr@ti.com>
> > > ---
> > >  drivers/mmc/host/omap_hsmmc.c |    8 ++++++++
> > >  1 files changed, 8 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/omap_hsmmc.c
> > b/drivers/mmc/host/omap_hsmmc.c
> > > index 4a8776f..1c359f0 100644
> > > --- a/drivers/mmc/host/omap_hsmmc.c
> > > +++ b/drivers/mmc/host/omap_hsmmc.c
> > > @@ -986,6 +986,14 @@ static inline void
> > omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host *host,
> > >                (i++ < limit))
> > >                cpu_relax();
> > >
> > > +       /*
> > > +        * On OMAP4 ES2 the SRC is zero in the first loop itself
> > strangely
> > > +        * vs on ES1 it takes some time.
> > > +        * Could be a an issue on ES2 to indicate reset complete even
> > before
> > > +        * it is complete.
> > > +        */
> > > +       udelay(500);
> >
> > Since the above work around is applicable only for OMAP4 ES2 ,
> > shouldn't this udelay be avoided for other OMAP versions
> >
> I did not post this to Linux omap at all. What patch are you talking
> about?
> 
I have posted this patch on Tony and Kevin's request keeping the original
author. This is needed to get MMC working on ES2.0 samples.

Do you have fresh version of this patch?

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 6/7] omap4: Workaround for CMD line reset.

[Madhusudhan]

> -----Original Message-----
> From: Shilimkar, Santosh [mailto:santosh.shilimkar@ti.com]
> Sent: Tuesday, September 14, 2010 11:49 AM
> To: Chikkature Rajashekar, Madhusudhan; 'kishore kadiyala'
> Cc: linux-omap@vger.kernel.org; tony@atomide.com;
> khilman@deeprootsystems.com
> Subject: RE: [PATCH 6/7] omap4: Workaround for CMD line reset.
> 
> Madhu,
> > -----Original Message-----
> > From: Chikkature Rajashekar, Madhusudhan
> > Sent: Tuesday, September 14, 2010 9:28 PM
> > To: 'kishore kadiyala'; Shilimkar, Santosh
> > Cc: linux-omap@vger.kernel.org; tony@atomide.com;
> > khilman@deeprootsystems.com
> > Subject: RE: [PATCH 6/7] omap4: Workaround for CMD line reset.
> >
> >
> >
> > > -----Original Message-----
> > > From: kishore kadiyala [mailto:kishorek.kadiyala@gmail.com]
> > > Sent: Tuesday, September 14, 2010 10:47 AM
> > > To: Madhusudhan Chikkature; Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; tony@atomide.com;
> > > khilman@deeprootsystems.com
> > > Subject: Re: [PATCH 6/7] omap4: Workaround for CMD line reset.
> > >
> > > Hi Madhu,
> > >
> > > On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar
> > > <santosh.shilimkar@ti.com> wrote:
> > > > From: Madhusudhan Chikkature <madhu.cr@ti.com>
> > > >
> > > > Add a delay after CMD line reset to accomdate the reset to complete.
> > > > The SYSCTL seems to reflect SRC immediately which might not really
> > > > be indicating the complete of reset. This is observed only with
> ES2.0
> > > > silicon
> > > >
> > > > Signed-off-by: Madhusudhan Chikkature <madhu.cr@ti.com>
> > > > ---
> > > >  drivers/mmc/host/omap_hsmmc.c |    8 ++++++++
> > > >  1 files changed, 8 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/mmc/host/omap_hsmmc.c
> > > b/drivers/mmc/host/omap_hsmmc.c
> > > > index 4a8776f..1c359f0 100644
> > > > --- a/drivers/mmc/host/omap_hsmmc.c
> > > > +++ b/drivers/mmc/host/omap_hsmmc.c
> > > > @@ -986,6 +986,14 @@ static inline void
> > > omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host *host,
> > > >                (i++ < limit))
> > > >                cpu_relax();
> > > >
> > > > +       /*
> > > > +        * On OMAP4 ES2 the SRC is zero in the first loop itself
> > > strangely
> > > > +        * vs on ES1 it takes some time.
> > > > +        * Could be a an issue on ES2 to indicate reset complete
> even
> > > before
> > > > +        * it is complete.
> > > > +        */
> > > > +       udelay(500);
> > >
> > > Since the above work around is applicable only for OMAP4 ES2 ,
> > > shouldn't this udelay be avoided for other OMAP versions
> > >
> > I did not post this to Linux omap at all. What patch are you talking
> > about?
> >
> I have posted this patch on Tony and Kevin's request keeping the original
> author. This is needed to get MMC working on ES2.0 samples.
> 
> Do you have fresh version of this patch?
> 
Yes. There is a TRM update lately that explains the procedure for CMD line
reset changes in ES2. I will post that patch.

Regards,
Madhu

> Regards,
> Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/7] omap4: l2x0: Fix init parameter for ES2.0

[Gadiyar, Anand]

On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On ES2.0 the L2 cache init parameter ineeds to be changed to take
> care of cache size. The cache size is 1MB on ES2.0 vs 512KB on ES1.0
>
> This patch fixes the init parameter to update the same using
> dynamic cpu version check
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>  arch/arm/mach-omap2/omap4-common.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
> index 13dc979..2b32229 100644
> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -64,7 +64,10 @@ static int __init omap_l2_cache_init(void)
>         * 32KB way size, 16-way associativity,
>         * parity disabled
>         */
> -       l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
> +       if (omap_rev() == OMAP4430_REV_ES2_0)
> +               l2x0_init(l2cache_base, 0x0e070000, 0xc0000fff);
> +       else
> +               l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);


It's probably better to invert this check - you need 512 kB on ES1
alone, but ES2 and newer will need more. You need the exception only
for the ES1 case.

(else you will end up patching this section again with newer revisions as well).

- Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 3/7] omap4: l2x0: Fix init parameter for ES2.0

[Shilimkar, Santosh]

> -----Original Message-----
> From: Gadiyar, Anand
> Sent: Monday, September 13, 2010 9:58 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; tony@atomide.com;
> khilman@deeprootsystems.com
> Subject: Re: [PATCH 3/7] omap4: l2x0: Fix init parameter for ES2.0
> 
> On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> > On ES2.0 the L2 cache init parameter ineeds to be changed to take
> > care of cache size. The cache size is 1MB on ES2.0 vs 512KB on ES1.0
> >
> > This patch fixes the init parameter to update the same using
> > dynamic cpu version check
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > ---
> >  arch/arm/mach-omap2/omap4-common.c |    5 ++++-
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-
> omap2/omap4-common.c
> > index 13dc979..2b32229 100644
> > --- a/arch/arm/mach-omap2/omap4-common.c
> > +++ b/arch/arm/mach-omap2/omap4-common.c
> > @@ -64,7 +64,10 @@ static int __init omap_l2_cache_init(void)
> >         * 32KB way size, 16-way associativity,
> >         * parity disabled
> >         */
> > -       l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
> > +       if (omap_rev() == OMAP4430_REV_ES2_0)
> > +               l2x0_init(l2cache_base, 0x0e070000, 0xc0000fff);
> > +       else
> > +               l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
> 
> 
> It's probably better to invert this check - you need 512 kB on ES1
> alone, but ES2 and newer will need more. You need the exception only
> for the ES1 case.
> 
> (else you will end up patching this section again with newer revisions as
> well).
> 
Good point
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Felipe Balbi]

Hi,

On Thu, Sep 09, 2010 at 06:23:10AM -0500, Santosh Shilimkar wrote:
>@@ -308,6 +308,16 @@ static void __init omap4_check_revision(void)
> 	hawkeye = (idcode >> 12) & 0xffff;
> 	rev = (idcode >> 28) & 0xff;
>
>+	/*
>+	 * FIXME: This patch should be reverted later.
>+	 * Few initial ES2.0 samples IDCODE is same as ES1.0
>+	 * Use ARM register to detect the correct ES version
>+	 */

I wonder if it actually doesn't make sense to keep this in tree, the
overhead is minimum when rev is set correctly and it's safe for the
initial es2.0 samples which are buggy.

-- 
balbi

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Cousson, Benoit]

Hi Santosh,

On 9/9/2010 1:42 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Sep 09, 2010 at 06:23:10AM -0500, Santosh Shilimkar wrote:
>> @@ -308,6 +308,16 @@ static void __init omap4_check_revision(void)
>> 	hawkeye = (idcode>>  12)&  0xffff;
>> 	rev = (idcode>>  28)&  0xff;
>>
>> +	/*
>> +	 * FIXME: This patch should be reverted later.
>> +	 * Few initial ES2.0 samples IDCODE is same as ES1.0
>> +	 * Use ARM register to detect the correct ES version
>> +	 */
>
> I wonder if it actually doesn't make sense to keep this in tree, the
> overhead is minimum when rev is set correctly and it's safe for the
> initial es2.0 samples which are buggy.

Yep, I agree with that, if some early ES2 samples are already out there, 
we will have no way to control the device upgrade in the future. So we 
will still have to support these early buggy devices just in case.

Benoit

RE: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Shilimkar, Santosh]

> -----Original Message-----
> From: Cousson, Benoit
> Sent: Thursday, September 09, 2010 5:17 PM
> To: Balbi, Felipe
> Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org; tony@atomide.com;
> khilman@deeprootsystems.com
> Subject: Re: [PATCH 2/7] omap4: Temporary fix silicon version detection
> 
> Hi Santosh,
> 
> On 9/9/2010 1:42 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Sep 09, 2010 at 06:23:10AM -0500, Santosh Shilimkar wrote:
> >> @@ -308,6 +308,16 @@ static void __init omap4_check_revision(void)
> >> 	hawkeye = (idcode>>  12)&  0xffff;
> >> 	rev = (idcode>>  28)&  0xff;
> >>
> >> +	/*
> >> +	 * FIXME: This patch should be reverted later.
> >> +	 * Few initial ES2.0 samples IDCODE is same as ES1.0
> >> +	 * Use ARM register to detect the correct ES version
> >> +	 */
> >
> > I wonder if it actually doesn't make sense to keep this in tree, the
> > overhead is minimum when rev is set correctly and it's safe for the
> > initial es2.0 samples which are buggy.
> 
> Yep, I agree with that, if some early ES2 samples are already out there,
> we will have no way to control the device upgrade in the future. So we
> will still have to support these early buggy devices just in case.
> 
Felipe is suggesting not to add this support where as you want to
have this support.

Sorry if I haven't understood the comment. Care to clarify

Regards,
Santosh

 

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Felipe Balbi]

Hi Santosh,

On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:
>Felipe is suggesting not to add this support where as you want to
>have this support.
>
>Sorry if I haven't understood the comment. Care to clarify

no, I suggested not to revert :-) So, just change the comment saying why
you need that extra check and remove the "this patch should be reverted
later" part :-)

-- 
balbi

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Cousson, Benoit]

On 9/9/2010 2:07 PM, Balbi, Felipe wrote:
> Hi Santosh,
>
> On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:
>> Felipe is suggesting not to add this support where as you want to
>> have this support.
>>
>> Sorry if I haven't understood the comment. Care to clarify
>
> no, I suggested not to revert :-) So, just change the comment saying why
> you need that extra check and remove the "this patch should be reverted
> later" part :-)

We are fully aligned. On the other hand if the number of buggy devices 
is very limited and not available outside TI, we'd better drop that 
patch. But I'm afraid it is not the case :-(

Benoit

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Jon Hunter]

On 9/9/2010 7:47 AM, Cousson, Benoit wrote:
> On 9/9/2010 2:07 PM, Balbi, Felipe wrote:
>> Hi Santosh,
>>
>> On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:
>>> Felipe is suggesting not to add this support where as you want to
>>> have this support.
>>>
>>> Sorry if I haven't understood the comment. Care to clarify
>>
>> no, I suggested not to revert :-) So, just change the comment saying why
>> you need that extra check and remove the "this patch should be reverted
>> later" part :-)
>
> We are fully aligned. On the other hand if the number of buggy devices
> is very limited and not available outside TI, we'd better drop that
> patch. But I'm afraid it is not the case :-(

I believe that just this week we had a case of a "buggy device" turning 
up on one of our customer's blaze boards that was upgraded to ES2.0 but 
appeared to be ES1.0. So this patch is good to have in the mainline.

Cheers
Jon

RE: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Shilimkar, Santosh]

> -----Original Message-----
> From: Balbi, Felipe
> Sent: Thursday, September 09, 2010 5:38 PM
> To: Shilimkar, Santosh
> Cc: Cousson, Benoit; Balbi, Felipe; linux-omap@vger.kernel.org;
> tony@atomide.com; khilman@deeprootsystems.com
> Subject: Re: [PATCH 2/7] omap4: Temporary fix silicon version detection
> 
> Hi Santosh,
> 
> On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:
> >Felipe is suggesting not to add this support where as you want to
> >have this support.
> >
> >Sorry if I haven't understood the comment. Care to clarify
> 
> no, I suggested not to revert :-) So, just change the comment saying why
> you need that extra check and remove the "this patch should be reverted
> later" part :-)
> 
Ok. I agree. We can actually keep this code.

Will change the comment and send V2

Regards,
Santosh 

RE: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Shilimkar, Santosh]

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

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Thursday, September 09, 2010 6:32 PM
> To: Balbi, Felipe
> Cc: Cousson, Benoit; linux-omap@vger.kernel.org; tony@atomide.com;
> khilman@deeprootsystems.com
> Subject: RE: [PATCH 2/7] omap4: Temporary fix silicon version detection
> 
> > -----Original Message-----
> > From: Balbi, Felipe
> > Sent: Thursday, September 09, 2010 5:38 PM
> > To: Shilimkar, Santosh
> > Cc: Cousson, Benoit; Balbi, Felipe; linux-omap@vger.kernel.org;
> > tony@atomide.com; khilman@deeprootsystems.com
> > Subject: Re: [PATCH 2/7] omap4: Temporary fix silicon version detection
> >
> > Hi Santosh,
> >
> > On Thu, Sep 09, 2010 at 07:02:46AM -0500, Shilimkar, Santosh wrote:
> > >Felipe is suggesting not to add this support where as you want to
> > >have this support.
> > >
> > >Sorry if I haven't understood the comment. Care to clarify
> >
> > no, I suggested not to revert :-) So, just change the comment saying why
> > you need that extra check and remove the "this patch should be reverted
> > later" part :-)
> >
> Ok. I agree. We can actually keep this code.
> 
> Will change the comment and send V2
> 
Updated version attached. 

Regards,
Santosh

[-- Attachment #2: 0002-omap4-Fix-silicon-version-detection-for-early-sampl.patch --]
[-- Type: application/octet-stream, Size: 1093 bytes --]

From 54acd6e278fd58a119a238b9821604e7a3299491 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Thu, 9 Sep 2010 13:11:12 +0530
Subject: [PATCH 2/7 v2] omap4: Fix silicon version detection for early samples

Few initial omap4 es2 samples IDCODE is same as es1. This patch
uses ARM cpuid register to detect the ES version for such samples

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/id.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a423c7f..91d7df4 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -308,6 +308,15 @@ static void __init omap4_check_revision(void)
 	hawkeye = (idcode >> 12) & 0xffff;
 	rev = (idcode >> 28) & 0xff;
 
+	/*
+	 * Few initial ES2.0 samples IDCODE is same as ES1.0
+	 * Use ARM register to detect the correct ES version
+	 */
+	if (!rev) {
+		idcode = read_cpuid(CPUID_ID);
+		rev = (idcode & 0xf) - 1;
+	}
+
 	switch (hawkeye) {
 	case 0xb852:
 		switch (rev) {
-- 
1.6.0.4

Re: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Felipe Balbi]

Hi,

On Thu, Sep 09, 2010 at 08:24:12AM -0500, Shilimkar, Santosh wrote:
>Updated version attached.

attaching is generally not a good idea, but if you do so, at least use
.diff as extension (or .patch or .txt) so that most mutt users will see
it dumped onto the messaged.

I think that if you attach, you're also breaking Tony's 'fwiendly
wobot'.

-- 
balbi

RE: [PATCH 2/7] omap4: Temporary fix silicon version detection

[Shilimkar, Santosh]

> -----Original Message-----
> From: Balbi, Felipe
> Sent: Friday, September 10, 2010 6:04 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; Cousson, Benoit; tony@atomide.com;
> khilman@deeprootsystems.com; Balbi, Felipe
> Subject: Re: [PATCH 2/7] omap4: Temporary fix silicon version detection
> 
> Hi,
> 
> On Thu, Sep 09, 2010 at 08:24:12AM -0500, Shilimkar, Santosh wrote:
> >Updated version attached.
> 
> attaching is generally not a good idea, but if you do so, at least use
> .diff as extension (or .patch or .txt) so that most mutt users will see
> it dumped onto the messaged.
> 
The attachment is with .patch extension.

> I think that if you attach, you're also breaking Tony's 'fwiendly
> wobot'.
> 

Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Kevin Hilman]

Santosh Shilimkar <santosh.shilimkar@ti.com> writes:

> This series has few fixes, hacks to get omap4 es2.0 working
> on mainline. The patches are generated against the mainline 
> 2.6.36-rc3. 

Hi Santosh, thanks for this...

> The series is boot tested tested on 4430 SDP, Blaze with 
> omap_4430sdp_defconfig with file over NFS and MMC.
>
> Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> SDPs. Same observation with Panda
>
> With omap3_defconfig, MMC while mounting the rootfs over MMC, the
> boot hangs. Same observation with Panda

On my ES2.0 Panda, rootfs on MMC is now working with this series.

However, rootfs over NFS is not yet working, presumably because the
OMAP4 EHCI support is needed for the USB-attached smsc95xx to work properly.

Kevin

> [    5.794616] regulator_init_complete: incomplete constraints, leaving VUSIM on
> [    5.802764] regulator_init_complete: incomplete constraints, leaving VPP on
> [    5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:53:12 UTC (9      )
> [    5.849304] mmc0: new high speed MMC card at address 0001
> [    5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
> [    5.862091]  mmcblk0: unknown partition table
> [    6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate latency 0: 6

Based on this message, this is not a mainline kernel, but one where the
omap_device conversion for MMC has been applied.

> [   18.424407] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2)
> [   18.431823] Please append a correct "root=" boot option; here are the available      ons:
> [   18.440643] b300         7757824 mmcblk0 driver: mmcblk
> [   18.446166] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown
>
> All these patches are also available at:
> 	http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=summary
> 	head: omap4-for-tony
>
> David Anders (1):
>   omap4: Panda: Add DEBUG_LL support
>
> Eric Dumazet (1):
>   KS8851: Correct RX packet allocation
>
> Madhusudhan Chikkature (1):
>   omap4: Workaround for CMD line reset.
>
> Santosh Shilimkar (4):
>   omap4: Update id.c and cpu.h for es2.0
>   omap4: Temporary fix silicon version detection
>   omap4: l2x0: Fix init parameter for ES2.0
>   omap4: Fix bootup crash observed with higher CPU clocks
>
>  arch/arm/mach-omap2/id.c                     |   39 +++++++++++++++++++++----
>  arch/arm/mach-omap2/omap4-common.c           |    5 ++-
>  arch/arm/plat-omap/dmtimer.c                 |    2 +-
>  arch/arm/plat-omap/include/plat/cpu.h        |    5 ++-
>  arch/arm/plat-omap/include/plat/uncompress.h |    1 +
>  drivers/mmc/host/omap_hsmmc.c                |    8 +++++
>  drivers/net/ks8851.c                         |   39 ++++++++++++++------------
>  7 files changed, 71 insertions(+), 28 deletions(-)

RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Shilimkar, Santosh]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, September 09, 2010 8:52 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; tony@atomide.com
> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> 
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> 
> > This series has few fixes, hacks to get omap4 es2.0 working
> > on mainline. The patches are generated against the mainline
> > 2.6.36-rc3.
> 
> Hi Santosh, thanks for this...
> 
> > The series is boot tested tested on 4430 SDP, Blaze with
> > omap_4430sdp_defconfig with file over NFS and MMC.
> >
> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> > SDPs. Same observation with Panda
> >
> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the
> > boot hangs. Same observation with Panda
> 
> On my ES2.0 Panda, rootfs on MMC is now working with this series.
>
I observed the same with MMC. Ramdisk boot worked for me on PANDA.
 
> However, rootfs over NFS is not yet working, presumably because the
> OMAP4 EHCI support is needed for the USB-attached smsc95xx to work
> properly.
>
This is correct. We need to get the MMC fixed o.w panda is unusable in
it's current form.
 
> 
> > [    5.794616] regulator_init_complete: incomplete constraints, leaving
> VUSIM on
> > [    5.802764] regulator_init_complete: incomplete constraints, leaving
> VPP on
> > [    5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01
> 00:53:12 UTC (9      )
> > [    5.849304] mmc0: new high speed MMC card at address 0001
> > [    5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
> > [    5.862091]  mmcblk0: unknown partition table
> > [    6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate
> latency 0: 6
> 
> Based on this message, this is not a mainline kernel, but one where the
> omap_device conversion for MMC has been applied.
> 
This is mainline 2.6.36-rc3.... 
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap4-for-tony

Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Kevin Hilman]

"Shilimkar, Santosh" <santosh.shilimkar@ti.com> writes:

>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> Sent: Thursday, September 09, 2010 8:52 PM
>> To: Shilimkar, Santosh
>> Cc: linux-omap@vger.kernel.org; tony@atomide.com
>> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
>> 
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>> 
>> > This series has few fixes, hacks to get omap4 es2.0 working
>> > on mainline. The patches are generated against the mainline
>> > 2.6.36-rc3.
>> 
>> Hi Santosh, thanks for this...
>> 
>> > The series is boot tested tested on 4430 SDP, Blaze with
>> > omap_4430sdp_defconfig with file over NFS and MMC.
>> >
>> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
>> > SDPs. Same observation with Panda
>> >
>> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the
>> > boot hangs. Same observation with Panda
>> 
>> On my ES2.0 Panda, rootfs on MMC is now working with this series.
>>
> I observed the same with MMC. Ramdisk boot worked for me on PANDA.

Note that I said "now working".  I think you read my message as "not
working."

IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
your series to current l-o master, and it works.

>> However, rootfs over NFS is not yet working, presumably because the
>> OMAP4 EHCI support is needed for the USB-attached smsc95xx to work
>> properly.
>>
> This is correct. We need to get the MMC fixed o.w panda is unusable in
> it's current form.
>
>> 
>> > [    5.794616] regulator_init_complete: incomplete constraints, leaving
>> VUSIM on
>> > [    5.802764] regulator_init_complete: incomplete constraints, leaving
>> VPP on
>> > [    5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01
>> 00:53:12 UTC (9      )
>> > [    5.849304] mmc0: new high speed MMC card at address 0001
>> > [    5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
>> > [    5.862091]  mmcblk0: unknown partition table
>> > [    6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate
>> latency 0: 6
>> 
>> Based on this message, this is not a mainline kernel, but one where the
>> omap_device conversion for MMC has been applied.
>> 
> This is mainline 2.6.36-rc3.... 
> http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap4-for-tony

Then I don't understand where the 'omap_device: mmci-omap-hs.1:...'
message is coming from in your kernel boot log.

It should not be present in a mainline kernel as the MMC conversion to
hwmod/omap_device is not in mainline, or linux-omap.

That's why I assumed your boot log excerpt came from an internal kernel
and not a mainline kernel.

Kevin

RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Shilimkar, Santosh]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, September 09, 2010 9:25 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; tony@atomide.com
> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> 
> "Shilimkar, Santosh" <santosh.shilimkar@ti.com> writes:
> 
> >> -----Original Message-----
> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >> Sent: Thursday, September 09, 2010 8:52 PM
> >> To: Shilimkar, Santosh
> >> Cc: linux-omap@vger.kernel.org; tony@atomide.com
> >> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> >>
> >> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> >>
> >> > This series has few fixes, hacks to get omap4 es2.0 working
> >> > on mainline. The patches are generated against the mainline
> >> > 2.6.36-rc3.
> >>
> >> Hi Santosh, thanks for this...
> >>
> >> > The series is boot tested tested on 4430 SDP, Blaze with
> >> > omap_4430sdp_defconfig with file over NFS and MMC.
> >> >
> >> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> >> > SDPs. Same observation with Panda
> >> >
> >> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the
> >> > boot hangs. Same observation with Panda
> >>
> >> On my ES2.0 Panda, rootfs on MMC is now working with this series.
> >>
> > I observed the same with MMC. Ramdisk boot worked for me on PANDA.
> 
> Note that I said "now working".  I think you read my message as "not
> working."
> 
Yes I read it otherway ... Second time today :)

> IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
> your series to current l-o master, and it works.
> 
Cool!!

> >> However, rootfs over NFS is not yet working, presumably because the
> >> OMAP4 EHCI support is needed for the USB-attached smsc95xx to work
> >> properly.
> >>
> > This is correct. We need to get the MMC fixed o.w panda is unusable in
> > it's current form.
> >
> >>
> >> > [    5.794616] regulator_init_complete: incomplete constraints,
> leaving
> >> VUSIM on
> >> > [    5.802764] regulator_init_complete: incomplete constraints,
> leaving
> >> VPP on
> >> > [    5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01
> >> 00:53:12 UTC (9      )
> >> > [    5.849304] mmc0: new high speed MMC card at address 0001
> >> > [    5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
> >> > [    5.862091]  mmcblk0: unknown partition table
> >> > [    6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate
> >> latency 0: 6
> >>
> >> Based on this message, this is not a mainline kernel, but one where the
> >> omap_device conversion for MMC has been applied.
> >>
> > This is mainline 2.6.36-rc3....
> > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> base.git;a=shortlog;h=refs/heads/omap4-for-tony
> 
> Then I don't understand where the 'omap_device: mmci-omap-hs.1:...'
> message is coming from in your kernel boot log.
> 
> It should not be present in a mainline kernel as the MMC conversion to
> hwmod/omap_device is not in mainline, or linux-omap.
> 
> That's why I assumed your boot log excerpt came from an internal kernel
> and not a mainline kernel.
> 
I might have mixed kernel Images ... Just too many things together :(

Regards,
Santosh 

RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Ghorai, Sukumar]

> -----Original Message-----
[..snip..]
> > >>
> > >> > The series is boot tested tested on 4430 SDP, Blaze with
> > >> > omap_4430sdp_defconfig with file over NFS and MMC.
> > >> >
> > >> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> > >> > SDPs. Same observation with Panda
> > >> >
> > >> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the
> > >> > boot hangs. Same observation with Panda
> > >>
> > >> On my ES2.0 Panda, rootfs on MMC is now working with this series.
> > >>
> > > I observed the same with MMC. Ramdisk boot worked for me on PANDA.
> >
> > Note that I said "now working".  I think you read my message as "not
> > working."
> >
> Yes I read it otherway ... Second time today :)
> 
> > IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
> > your series to current l-o master, and it works.
> >
> Cool!!

[Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine.

And omap_4430sdp_defconfig also ok omap4.

> 
> > >> However, rootfs over NFS is not yet working, presumably because the
> > >> OMAP4 EHCI support is needed for the USB-attached smsc95xx to work
> > >> properly.
> > >>
> > > This is correct. We need to get the MMC fixed o.w panda is unusable in
> > > it's current form.
> > >
> > >>
> > >> > [    5.794616] regulator_init_complete: incomplete constraints,
> > leaving
> > >> VUSIM on
> > >> > [    5.802764] regulator_init_complete: incomplete constraints,
> > leaving
> > >> VPP on
> > >> > [    5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01
> > >> 00:53:12 UTC (9      )
> > >> > [    5.849304] mmc0: new high speed MMC card at address 0001
> > >> > [    5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
> > >> > [    5.862091]  mmcblk0: unknown partition table
> > >> > [    6.325500] omap_device: mmci-omap-hs.1: new worst case
> deactivate
> > >> latency 0: 6
> > >>
> > >> Based on this message, this is not a mainline kernel, but one where
> the
> > >> omap_device conversion for MMC has been applied.
> > >>
> > > This is mainline 2.6.36-rc3....
> > > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> > base.git;a=shortlog;h=refs/heads/omap4-for-tony

[..snip ..]

RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Shilimkar, Santosh]

> -----Original Message-----
> From: Ghorai, Sukumar
> Sent: Friday, September 10, 2010 4:00 PM
> To: Shilimkar, Santosh; Kevin Hilman
> Cc: linux-omap@vger.kernel.org; tony@atomide.com
> Subject: RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> 
> 
> 
> > -----Original Message-----
> [..snip..]
> > > >>
> > > >> > The series is boot tested tested on 4430 SDP, Blaze with
> > > >> > omap_4430sdp_defconfig with file over NFS and MMC.
> > > >> >
> > > >> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> > > >> > SDPs. Same observation with Panda
> > > >> >
> > > >> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the
> > > >> > boot hangs. Same observation with Panda
> > > >>
> > > >> On my ES2.0 Panda, rootfs on MMC is now working with this series.
> > > >>
> > > > I observed the same with MMC. Ramdisk boot worked for me on PANDA.
> > >
> > > Note that I said "now working".  I think you read my message as "not
> > > working."
> > >
> > Yes I read it otherway ... Second time today :)
> >
> > > IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
> > > your series to current l-o master, and it works.
> > >
> > Cool!!
> 
> [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430
> ES2.0 SDP, Blaze and Panda and all booting fine.
> 
> And omap_4430sdp_defconfig also ok omap4.
> 
Thanks Sukumar!!
So with this testing data, the series works fine on 
all boards now with rootfs over MMC.

Regards,
Santosh

Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Ricardo Salveti]

On Fri, Sep 10, 2010 at 7:30 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>
>
>> -----Original Message-----
> [..snip..]
>> > >>
>> > >> > The series is boot tested tested on 4430 SDP, Blaze with
>> > >> > omap_4430sdp_defconfig with file over NFS and MMC.
>> > >> >
>> > >> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
>> > >> > SDPs. Same observation with Panda
>> > >> >
>> > >> > With omap3_defconfig, MMC while mounting the rootfs over MMC, the
>> > >> > boot hangs. Same observation with Panda
>> > >>
>> > >> On my ES2.0 Panda, rootfs on MMC is now working with this series.
>> > >>
>> > > I observed the same with MMC. Ramdisk boot worked for me on PANDA.
>> >
>> > Note that I said "now working".  I think you read my message as "not
>> > working."
>> >
>> Yes I read it otherway ... Second time today :)
>>
>> > IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
>> > your series to current l-o master, and it works.
>> >
>> Cool!!
>
> [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine.
>
> And omap_4430sdp_defconfig also ok omap4.

Which Panda version are you using during your tests? I tried
omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm
unable to detect the MMC.

Do I need any other patch to make the MMC work with Panda?

Thanks,
-- 
Ricardo Salveti de Araujo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Ghorai, Sukumar]

> -----Original Message-----
> From: Ricardo Salveti [mailto:rsalveti@rsalveti.net]
> Sent: Friday, September 10, 2010 8:34 PM
> To: Ghorai, Sukumar
> Cc: Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org;
> tony@atomide.com
> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> 
> On Fri, Sep 10, 2010 at 7:30 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
> >
> >
> >> -----Original Message-----
> > [..snip..]
> >> > >>
> >> > >> > The series is boot tested tested on 4430 SDP, Blaze with
> >> > >> > omap_4430sdp_defconfig with file over NFS and MMC.
> >> > >> >
> >> > >> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> >> > >> > SDPs. Same observation with Panda
> >> > >> >
> >> > >> > With omap3_defconfig, MMC while mounting the rootfs over MMC,
> the
> >> > >> > boot hangs. Same observation with Panda
> >> > >>
> >> > >> On my ES2.0 Panda, rootfs on MMC is now working with this series.
> >> > >>
> >> > > I observed the same with MMC. Ramdisk boot worked for me on PANDA.
> >> >
> >> > Note that I said "now working".  I think you read my message as "not
> >> > working."
> >> >
> >> Yes I read it otherway ... Second time today :)
> >>
> >> > IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
> >> > your series to current l-o master, and it works.
> >> >
> >> Cool!!
> >
> > [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430
> ES2.0 SDP, Blaze and Panda and all booting fine.
> >
> > And omap_4430sdp_defconfig also ok omap4.
> 
> Which Panda version are you using during your tests? I tried
> omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm
> unable to detect the MMC.
> 
> Do I need any other patch to make the MMC work with Panda?
[Ghorai] I have tested based on following tree/branch and using ES2.0 PANDA only. Can you share bootlog enabling mmc/sd debug message?
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap4-for-tony

> 
> Thanks,
> --
> Ricardo Salveti de Araujo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Ricardo Salveti]

On Fri, Sep 10, 2010 at 12:09 PM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>> -----Original Message-----
>> On Fri, Sep 10, 2010 at 7:30 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>> >> -----Original Message-----
>> > [..snip..]
>> >> > >> > The series is boot tested tested on 4430 SDP, Blaze with
>> >> > >> > omap_4430sdp_defconfig with file over NFS and MMC.
>> >> > >> >
>> >> > >> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
>> >> > >> > SDPs. Same observation with Panda
>> >> > >> >
>> >> > >> > With omap3_defconfig, MMC while mounting the rootfs over MMC,
>> the
>> >> > >> > boot hangs. Same observation with Panda
>> >> > >>
>> >> > >> On my ES2.0 Panda, rootfs on MMC is now working with this series.
>> >> > >>
>> >> > > I observed the same with MMC. Ramdisk boot worked for me on PANDA.
>> >> >
>> >> > Note that I said "now working".  I think you read my message as "not
>> >> > working."
>> >> >
>> >> Yes I read it otherway ... Second time today :)
>> >>
>> >> > IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
>> >> > your series to current l-o master, and it works.
>> >> >
>> >> Cool!!
>> >
>> > [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430
>> ES2.0 SDP, Blaze and Panda and all booting fine.
>> >
>> > And omap_4430sdp_defconfig also ok omap4.
>>
>> Which Panda version are you using during your tests? I tried
>> omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm
>> unable to detect the MMC.
>>
>> Do I need any other patch to make the MMC work with Panda?
> [Ghorai] I have tested based on following tree/branch and using ES2.0 PANDA only. Can you share bootlog enabling mmc/sd debug message?
> http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap4-for-tony

My boot log:
http://paste.ubuntu.com/491645/

Using x-loader from
http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and
upstream u-boot.

Cheers,
-- 
Ricardo Salveti de Araujo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Ghorai, Sukumar]

[snip]
> >> >
> >> > [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3,
> 4430
> >> ES2.0 SDP, Blaze and Panda and all booting fine.
> >> >
> >> > And omap_4430sdp_defconfig also ok omap4.
> >>
> >> Which Panda version are you using during your tests? I tried
> >> omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm
> >> unable to detect the MMC.
> >>
> >> Do I need any other patch to make the MMC work with Panda?
> > [Ghorai] I have tested based on following tree/branch and using ES2.0
> PANDA only. Can you share bootlog enabling mmc/sd debug message?
> > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> base.git;a=shortlog;h=refs/heads/omap4-for-tony
> 
> My boot log:
> http://paste.ubuntu.com/491645/
> 
[Ghorai] can you use this bootargs?
setenv bootargs root=/dev/mmcblk0p2 rw rootwait mem=463M console=ttyS2,115200n8
And here is the log from my setup.
[    2.493194] Waiting for root device /dev/mmcblk0p2...
[    2.502960] mmc0: host does not support reading read-only switch. assuming write-enable.
[    2.523895] mmc0: new high speed SDHC card at address e1ed
[    2.531616] mmcblk0: mmc0:e1ed SD04G 3.75 GiB
[    2.539550]  mmcblk0: p1 p2
[    2.607360] EXT3-fs: barriers not enabled

> Using x-loader from
> http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and
> upstream u-boot.
[Ghorai] can you try with this x-loader
https://docs.google.com/leaf?id=0B8fdjBBEQ4lDZGE3ZTBjNzEtOTQ0Ni00ZmFlLTlhODgtN2QzNjUwMzBkNDI2&hl=en
In the mean time I will try with yours!

> 
> Cheers,
> --
> Ricardo Salveti de Araujo

Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Ricardo Salveti]

On Mon, Sep 13, 2010 at 12:06 PM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>> >> > [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3,
>> 4430
>> >> ES2.0 SDP, Blaze and Panda and all booting fine.
>> >> >
>> >> > And omap_4430sdp_defconfig also ok omap4.
>> >>
>> >> Which Panda version are you using during your tests? I tried
>> >> omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm
>> >> unable to detect the MMC.
>> >>
>> >> Do I need any other patch to make the MMC work with Panda?
>> > [Ghorai] I have tested based on following tree/branch and using ES2.0
>> PANDA only. Can you share bootlog enabling mmc/sd debug message?
>> > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
>> base.git;a=shortlog;h=refs/heads/omap4-for-tony
>>
>> My boot log:
>> http://paste.ubuntu.com/491645/
>>
> [Ghorai] can you use this bootargs?
> setenv bootargs root=/dev/mmcblk0p2 rw rootwait mem=463M console=ttyS2,115200n8
> And here is the log from my setup.
> [    2.493194] Waiting for root device /dev/mmcblk0p2...
> [    2.502960] mmc0: host does not support reading read-only switch. assuming write-enable.
> [    2.523895] mmc0: new high speed SDHC card at address e1ed
> [    2.531616] mmcblk0: mmc0:e1ed SD04G 3.75 GiB
> [    2.539550]  mmcblk0: p1 p2
> [    2.607360] EXT3-fs: barriers not enabled
>
>> Using x-loader from
>> http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and
>> upstream u-boot.
> [Ghorai] can you try with this x-loader
> https://docs.google.com/leaf?id=0B8fdjBBEQ4lDZGE3ZTBjNzEtOTQ0Ni00ZmFlLTlhODgtN2QzNjUwMzBkNDI2&hl=en
> In the mean time I will try with yours!

I'm unable to boot with your x-loader at my ES2.0 (6 and 8 layers),
however I'm able to boot it with ES1. Are you sure you're testing it
at an ES2 board?

This is what I get, it just hangs:
Texas Instruments X-Loader 1.41 (Aug 11 2010 - 10:51:13)
Could not read bootloader!
X-Loader hangs

Cheers,
-- 
Ricardo Salveti de Araujo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Ghorai, Sukumar]

> -----Original Message-----
> From: Ricardo Salveti [mailto:rsalveti@rsalveti.net]
> Sent: Tuesday, September 14, 2010 12:22 AM
> To: Ghorai, Sukumar
> Cc: Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org;
> tony@atomide.com; Bryan Wu
> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> 
> On Mon, Sep 13, 2010 at 12:06 PM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
> >> >> > [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3,
> >> 4430
> >> >> ES2.0 SDP, Blaze and Panda and all booting fine.
> >> >> >
> >> >> > And omap_4430sdp_defconfig also ok omap4.
> >> >>
> >> >> Which Panda version are you using during your tests? I tried
> >> >> omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and
> I'm
> >> >> unable to detect the MMC.
> >> >>
> >> >> Do I need any other patch to make the MMC work with Panda?
> >> > [Ghorai] I have tested based on following tree/branch and using ES2.0
> >> PANDA only. Can you share bootlog enabling mmc/sd debug message?
> >> > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> >> base.git;a=shortlog;h=refs/heads/omap4-for-tony
> >>
> >> My boot log:
> >> http://paste.ubuntu.com/491645/
> >>
> > [Ghorai] can you use this bootargs?
> > setenv bootargs root=/dev/mmcblk0p2 rw rootwait mem=463M
> console=ttyS2,115200n8
> > And here is the log from my setup.
> > [    2.493194] Waiting for root device /dev/mmcblk0p2...
> > [    2.502960] mmc0: host does not support reading read-only switch.
> assuming write-enable.
> > [    2.523895] mmc0: new high speed SDHC card at address e1ed
> > [    2.531616] mmcblk0: mmc0:e1ed SD04G 3.75 GiB
> > [    2.539550]  mmcblk0: p1 p2
> > [    2.607360] EXT3-fs: barriers not enabled
> >
> >> Using x-loader from
> >> http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and
> >> upstream u-boot.
> > [Ghorai] can you try with this x-loader
> >
> https://docs.google.com/leaf?id=0B8fdjBBEQ4lDZGE3ZTBjNzEtOTQ0Ni00ZmFlLTlhO
> DgtN2QzNjUwMzBkNDI2&hl=en
> > In the mean time I will try with yours!
> 
> I'm unable to boot with your x-loader at my ES2.0 (6 and 8 layers),
> however I'm able to boot it with ES1. Are you sure you're testing it
> at an ES2 board?
> 
> This is what I get, it just hangs:
> Texas Instruments X-Loader 1.41 (Aug 11 2010 - 10:51:13)
> Could not read bootloader!
> X-Loader hangs
[Ghorai] format the card and copy MLo and followed by u-boot, uImage
And yes I am using EX 2.0 6-layer board.

> 
> Cheers,
> --
> Ricardo Salveti de Araujo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Bryan Wu]

On Tue, Sep 14, 2010 at 12:01 PM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>
>
>> -----Original Message-----
>> From: Ricardo Salveti [mailto:rsalveti@rsalveti.net]
>> Sent: Tuesday, September 14, 2010 12:22 AM
>> To: Ghorai, Sukumar
>> Cc: Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org;
>> tony@atomide.com; Bryan Wu
>> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
>>
>> On Mon, Sep 13, 2010 at 12:06 PM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
>> >> >> > [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3,
>> >> 4430
>> >> >> ES2.0 SDP, Blaze and Panda and all booting fine.
>> >> >> >
>> >> >> > And omap_4430sdp_defconfig also ok omap4.
>> >> >>
>> >> >> Which Panda version are you using during your tests? I tried
>> >> >> omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and
>> I'm
>> >> >> unable to detect the MMC.
>> >> >>
>> >> >> Do I need any other patch to make the MMC work with Panda?
>> >> > [Ghorai] I have tested based on following tree/branch and using ES2.0
>> >> PANDA only. Can you share bootlog enabling mmc/sd debug message?
>> >> > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
>> >> base.git;a=shortlog;h=refs/heads/omap4-for-tony
>> >>
>> >> My boot log:
>> >> http://paste.ubuntu.com/491645/
>> >>
>> > [Ghorai] can you use this bootargs?
>> > setenv bootargs root=/dev/mmcblk0p2 rw rootwait mem=463M
>> console=ttyS2,115200n8
>> > And here is the log from my setup.
>> > [    2.493194] Waiting for root device /dev/mmcblk0p2...
>> > [    2.502960] mmc0: host does not support reading read-only switch.
>> assuming write-enable.
>> > [    2.523895] mmc0: new high speed SDHC card at address e1ed
>> > [    2.531616] mmcblk0: mmc0:e1ed SD04G 3.75 GiB
>> > [    2.539550]  mmcblk0: p1 p2
>> > [    2.607360] EXT3-fs: barriers not enabled
>> >
>> >> Using x-loader from
>> >> http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and
>> >> upstream u-boot.
>> > [Ghorai] can you try with this x-loader
>> >
>> https://docs.google.com/leaf?id=0B8fdjBBEQ4lDZGE3ZTBjNzEtOTQ0Ni00ZmFlLTlhO
>> DgtN2QzNjUwMzBkNDI2&hl=en
>> > In the mean time I will try with yours!
>>
>> I'm unable to boot with your x-loader at my ES2.0 (6 and 8 layers),
>> however I'm able to boot it with ES1. Are you sure you're testing it
>> at an ES2 board?
>>
>> This is what I get, it just hangs:
>> Texas Instruments X-Loader 1.41 (Aug 11 2010 - 10:51:13)
>> Could not read bootloader!
>> X-Loader hangs
> [Ghorai] format the card and copy MLo and followed by u-boot, uImage
> And yes I am using EX 2.0 6-layer board.
>
>>
>> Cheers,
>> --
>> Ricardo Salveti de Araujo
>

I also tried Santosh's patches on my ES2.0 8 layers board. It's the
same as Ricardo:
http://pastebin.ubuntu.com/493938/

And Ghorai, I got the same error as Ricardo when I'm trying your MLO.

Thanks,
-Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Shilimkar, Santosh]

> -----Original Message-----
> From: Ricardo Salveti [mailto:rsalveti@rsalveti.net]
> Sent: Friday, September 10, 2010 8:34 PM
> To: Ghorai, Sukumar
> Cc: Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org;
> tony@atomide.com
> Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> 
> On Fri, Sep 10, 2010 at 7:30 AM, Ghorai, Sukumar <s-ghorai@ti.com> wrote:
> >
> >
> >> -----Original Message-----
> > [..snip..]
> >> > >>
> >> > >> > The series is boot tested tested on 4430 SDP, Blaze with
> >> > >> > omap_4430sdp_defconfig with file over NFS and MMC.
> >> > >> >
> >> > >> > Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> >> > >> > SDPs. Same observation with Panda
> >> > >> >
> >> > >> > With omap3_defconfig, MMC while mounting the rootfs over MMC,
> the
> >> > >> > boot hangs. Same observation with Panda
> >> > >>
> >> > >> On my ES2.0 Panda, rootfs on MMC is now working with this series.
> >> > >>
> >> > > I observed the same with MMC. Ramdisk boot worked for me on PANDA.
> >> >
> >> > Note that I said "now working".  I think you read my message as "not
> >> > working."
> >> >
> >> Yes I read it otherway ... Second time today :)
> >>
> >> > IOW, rootfs on MMC *is* working for me on my es2.0 Panda.   I applied
> >> > your series to current l-o master, and it works.
> >> >
> >> Cool!!
> >
> > [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430
> ES2.0 SDP, Blaze and Panda and all booting fine.
> >
> > And omap_4430sdp_defconfig also ok omap4.
> 
> Which Panda version are you using during your tests? I tried
> omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm
> unable to detect the MMC.
> 
> Do I need any other patch to make the MMC work with Panda?
> 
You don't need any more patches for kernel. Just use latest
Panda boot-loaders and it should work.

Regards,
Santosh


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0

[Ghorai, Sukumar]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Thursday, September 09, 2010 4:53 PM
> To: linux-omap@vger.kernel.org
> Cc: tony@atomide.com; khilman@deeprootsystems.com; Shilimkar, Santosh
> Subject: [PATCH 0/7] omap4: Fixes, hacks for es2.0
> 
> This series has few fixes, hacks to get omap4 es2.0 working
> on mainline. The patches are generated against the mainline
> 2.6.36-rc3.
> 
> 
> The series is boot tested tested on 4430 SDP, Blaze with
> omap_4430sdp_defconfig with file over NFS and MMC.
> 
> Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3
> SDPs. Same observation with Panda
> 
> With omap3_defconfig, MMC while mounting the rootfs over MMC, the
> boot hangs. Same observation with Panda

[Ghorai] Santosh,
It's booing in another Panda. I think that's a board issue. 

> 
> [    5.794616] regulator_init_complete: incomplete constraints, leaving
> VUSIM on
> [    5.802764] regulator_init_complete: incomplete constraints, leaving
> VPP on
> [    5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01
> 00:53:12 UTC (9      )
> [    5.849304] mmc0: new high speed MMC card at address 0001
> [    5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB
> [    5.862091]  mmcblk0: unknown partition table
> [    6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate
> latency 0: 6
> [   18.424407] VFS: Cannot open root device "mmcblk0p2" or unknown-
> block(179,2)
> [   18.431823] Please append a correct "root=" boot option; here are the
> available      ons:
> [   18.440643] b300         7757824 mmcblk0 driver: mmcblk
> [   18.446166] Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown
> 
> All these patches are also available at:
> 	http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=summary
> 	head: omap4-for-tony
> 
> David Anders (1):
>   omap4: Panda: Add DEBUG_LL support
> 
> Eric Dumazet (1):
>   KS8851: Correct RX packet allocation
> 
> Madhusudhan Chikkature (1):
>   omap4: Workaround for CMD line reset.
> 
> Santosh Shilimkar (4):
>   omap4: Update id.c and cpu.h for es2.0
>   omap4: Temporary fix silicon version detection
>   omap4: l2x0: Fix init parameter for ES2.0
>   omap4: Fix bootup crash observed with higher CPU clocks
> 
>  arch/arm/mach-omap2/id.c                     |   39
> +++++++++++++++++++++----
>  arch/arm/mach-omap2/omap4-common.c           |    5 ++-
>  arch/arm/plat-omap/dmtimer.c                 |    2 +-
>  arch/arm/plat-omap/include/plat/cpu.h        |    5 ++-
>  arch/arm/plat-omap/include/plat/uncompress.h |    1 +
>  drivers/mmc/host/omap_hsmmc.c                |    8 +++++
>  drivers/net/ks8851.c                         |   39 ++++++++++++++-------
> -----
>  7 files changed, 71 insertions(+), 28 deletions(-)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html