[U-Boot] [PATCH 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms

[U-Boot] [PATCH 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms

[Stefan Roese]

Commit a0a37183 (ARM: omap: merge GPMC initialization code for all
platform) broke NAND on OMAP3 based platforms. I noticed this while
testing the latest 2014.07-rc version on the TAO3530 board. NAND
detection did not work with this error message:

NAND:  nand: error: Unable to find NAND settings in GPMC Configuration - quitting

As OMAP3 configs don't set CONFIG_NAND but CONFIG_NAND_CMD. the GPMC
was not initialized for NAND at all. This patch now fixes this issue.

Tested on TAO3530 board.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Pekon Gupta <pekon@ti.com>
Cc: Tom Rini <trini@ti.com>
---
 arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap-common/mem-common.c b/arch/arm/cpu/armv7/omap-common/mem-common.c
index 5bc7e1f..ba26cd1 100644
--- a/arch/arm/cpu/armv7/omap-common/mem-common.c
+++ b/arch/arm/cpu/armv7/omap-common/mem-common.c
@@ -89,7 +89,7 @@ void gpmc_init(void)
 						};
 	u32 size = GPMC_SIZE_16M;
 	u32 base = CONFIG_SYS_FLASH_BASE;
-#elif defined(CONFIG_NAND)
+#elif defined(CONFIG_NAND) || defined(CONFIG_CMD_NAND)
 /* configure GPMC for NAND */
 	const u32  gpmc_regs[GPMC_MAX_REG] = {	M_NAND_GPMC_CONFIG1,
 						M_NAND_GPMC_CONFIG2,
-- 
2.0.1

[U-Boot] [PATCH 2/3] ARM: omap: Remove unused arch/arm/cpu/armv7/omap3/mem.c

[Stefan Roese]

These functions have been merged into the common GPMC init code
with this commit a0a37183 (ARM: omap: merge GPMC initialization code
for all platform). The file is not compiled any more. So remove it
as well.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Pekon Gupta <pekon@ti.com>
Cc: Tom Rini <trini@ti.com>
---
 arch/arm/cpu/armv7/omap3/mem.c | 139 -----------------------------------------
 1 file changed, 139 deletions(-)
 delete mode 100644 arch/arm/cpu/armv7/omap3/mem.c

diff --git a/arch/arm/cpu/armv7/omap3/mem.c b/arch/arm/cpu/armv7/omap3/mem.c
deleted file mode 100644
index 1832aff..0000000
--- a/arch/arm/cpu/armv7/omap3/mem.c
+++ /dev/null
@@ -1,139 +0,0 @@
-/*
- * (C) Copyright 2008
- * Texas Instruments, <www.ti.com>
- *
- * Author :
- *     Manikandan Pillai <mani.pillai@ti.com>
- *
- * Initial Code from:
- *     Richard Woodruff <r-woodruff2@ti.com>
- *     Syed Mohammed Khasim <khasim@ti.com>
- *
- * SPDX-License-Identifier:	GPL-2.0+
- */
-
-#include <common.h>
-#include <asm/io.h>
-#include <asm/arch/mem.h>
-#include <asm/arch/sys_proto.h>
-#include <command.h>
-
-struct gpmc *gpmc_cfg;
-
-#if defined(CONFIG_CMD_NAND)
-static const u32 gpmc_m_nand[GPMC_MAX_REG] = {
-	M_NAND_GPMC_CONFIG1,
-	M_NAND_GPMC_CONFIG2,
-	M_NAND_GPMC_CONFIG3,
-	M_NAND_GPMC_CONFIG4,
-	M_NAND_GPMC_CONFIG5,
-	M_NAND_GPMC_CONFIG6, 0
-};
-#endif /* CONFIG_CMD_NAND */
-
-#if defined(CONFIG_CMD_ONENAND)
-static const u32 gpmc_onenand[GPMC_MAX_REG] = {
-	ONENAND_GPMC_CONFIG1,
-	ONENAND_GPMC_CONFIG2,
-	ONENAND_GPMC_CONFIG3,
-	ONENAND_GPMC_CONFIG4,
-	ONENAND_GPMC_CONFIG5,
-	ONENAND_GPMC_CONFIG6, 0
-};
-#endif /* CONFIG_CMD_ONENAND */
-
-/********************************************************
- *  mem_ok() - test used to see if timings are correct
- *             for a part. Helps in guessing which part
- *             we are currently using.
- *******************************************************/
-u32 mem_ok(u32 cs)
-{
-	u32 val1, val2, addr;
-	u32 pattern = 0x12345678;
-
-	addr = OMAP34XX_SDRC_CS0 + get_sdr_cs_offset(cs);
-
-	writel(0x0, addr + 0x400);	/* clear pos A */
-	writel(pattern, addr);		/* pattern to pos B */
-	writel(0x0, addr + 4);		/* remove pattern off the bus */
-	val1 = readl(addr + 0x400);	/* get pos A value */
-	val2 = readl(addr);		/* get val2 */
-	writel(0x0, addr + 0x400);	/* clear pos A */
-
-	if ((val1 != 0) || (val2 != pattern))	/* see if pos A val changed */
-		return 0;
-	else
-		return 1;
-}
-
-void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base,
-			u32 size)
-{
-	writel(0, &cs->config7);
-	sdelay(1000);
-	/* Delay for settling */
-	writel(gpmc_config[0], &cs->config1);
-	writel(gpmc_config[1], &cs->config2);
-	writel(gpmc_config[2], &cs->config3);
-	writel(gpmc_config[3], &cs->config4);
-	writel(gpmc_config[4], &cs->config5);
-	writel(gpmc_config[5], &cs->config6);
-
-	/*
-	 * Enable the config.  size is the CS size and goes in
-	 * bits 11:8.  We set bit 6 to enable this CS and the base
-	 * address goes into bits 5:0.
-	 */
-	 writel((size << 8) | (GPMC_CS_ENABLE << 6) |
-				 ((base >> 24) & GPMC_BASEADDR_MASK),
-				 &cs->config7);
-	sdelay(2000);
-}
-
-/*****************************************************
- * gpmc_init(): init gpmc bus
- * Init GPMC for x16, MuxMode (SDRAM in x32).
- * This code can only be executed from SRAM or SDRAM.
- *****************************************************/
-void gpmc_init(void)
-{
-	/* putting a blanket check on GPMC based on ZeBu for now */
-	gpmc_cfg = (struct gpmc *)GPMC_BASE;
-#if defined(CONFIG_CMD_NAND) || defined(CONFIG_CMD_ONENAND)
-	const u32 *gpmc_config = NULL;
-	u32 base = 0;
-	u32 size = 0;
-#endif
-	u32 config = 0;
-
-	/* global settings */
-	writel(0, &gpmc_cfg->irqenable); /* isr's sources masked */
-	writel(0, &gpmc_cfg->timeout_control);/* timeout disable */
-
-	config = readl(&gpmc_cfg->config);
-	config &= (~0xf00);
-	writel(config, &gpmc_cfg->config);
-
-	/*
-	 * Disable the GPMC0 config set by ROM code
-	 * It conflicts with our MPDB (both at 0x08000000)
-	 */
-	writel(0, &gpmc_cfg->cs[0].config7);
-	sdelay(1000);
-
-#if defined(CONFIG_CMD_NAND)	/* CS 0 */
-	gpmc_config = gpmc_m_nand;
-
-	base = PISMO1_NAND_BASE;
-	size = PISMO1_NAND_SIZE;
-	enable_gpmc_cs_config(gpmc_config, &gpmc_cfg->cs[0], base, size);
-#endif
-
-#if defined(CONFIG_CMD_ONENAND)
-	gpmc_config = gpmc_onenand;
-	base = PISMO1_ONEN_BASE;
-	size = PISMO1_ONEN_SIZE;
-	enable_gpmc_cs_config(gpmc_config, &gpmc_cfg->cs[0], base, size);
-#endif
-}
-- 
2.0.1

[U-Boot] [PATCH 2/3] ARM: omap: Remove unused arch/arm/cpu/armv7/omap3/mem.c

[Gupta, Pekon]

>From: Stefan Roese [mailto:sr at denx.de]
>These functions have been merged into the common GPMC init code
>with this commit a0a37183 (ARM: omap: merge GPMC initialization code
>for all platform). The file is not compiled any more. So remove it
>as well.
>
>Signed-off-by: Stefan Roese <sr@denx.de>
>Cc: Pekon Gupta <pekon@ti.com>
>Cc: Tom Rini <trini@ti.com>
>---
> arch/arm/cpu/armv7/omap3/mem.c | 139 -----------------------------------------
> 1 file changed, 139 deletions(-)
> delete mode 100644 arch/arm/cpu/armv7/omap3/mem.c
>
Acked-by: Pekon Gupta <pekon@ti.com>

This file was removed in original patch, but probably was missed out
because Tom Rini had to manually rebase the patch before applying.

with regards, pekon

[U-Boot] [U-Boot, 2/3] ARM: omap: Remove unused arch/arm/cpu/armv7/omap3/mem.c

[Tom Rini]

On Wed, Jul 09, 2014 at 05:18:10PM +0200, Stefan Roese wrote:

> These functions have been merged into the common GPMC init code
> with this commit a0a37183 (ARM: omap: merge GPMC initialization code
> for all platform). The file is not compiled any more. So remove it
> as well.
> 
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Pekon Gupta <pekon@ti.com>
> Cc: Tom Rini <trini@ti.com>
> Acked-by: Pekon Gupta <pekon@ti.com>

Applied to u-boot-ti/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140725/6db256c4/attachment.pgp>

[U-Boot] [PATCH 3/3] ARM: omap: tao3530: Convert to generic board

[Stefan Roese]

Use generic board setup functions by defining
CONFIG_SYS_GENERIC_BOARD.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@ti.com>
---
 include/configs/tao3530.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/tao3530.h b/include/configs/tao3530.h
index 1b0fee9..62613e1 100644
--- a/include/configs/tao3530.h
+++ b/include/configs/tao3530.h
@@ -22,6 +22,7 @@
 
 #define CONFIG_OMAP_GPIO
 #define CONFIG_OMAP_COMMON
+#define CONFIG_SYS_GENERIC_BOARD
 
 #define MACH_TYPE_OMAP3_TAO3530		2836
 
-- 
2.0.1

[U-Boot] [U-Boot, 3/3] ARM: omap: tao3530: Convert to generic board

[Tom Rini]

On Wed, Jul 09, 2014 at 05:18:11PM +0200, Stefan Roese wrote:

> Use generic board setup functions by defining
> CONFIG_SYS_GENERIC_BOARD.
> 
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Tom Rini <trini@ti.com>

Applied to u-boot-ti/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140725/4c7bdf36/attachment.pgp>

[U-Boot] [PATCH 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms

[Gupta, Pekon]

Hi Stefan,

>From: Stefan Roese [mailto:sr at denx.de]
>
>Commit a0a37183 (ARM: omap: merge GPMC initialization code for all
>platform) broke NAND on OMAP3 based platforms. I noticed this while
>testing the latest 2014.07-rc version on the TAO3530 board. NAND
>detection did not work with this error message:
>
>NAND:  nand: error: Unable to find NAND settings in GPMC Configuration - quitting
>
>As OMAP3 configs don't set CONFIG_NAND but CONFIG_NAND_CMD. the GPMC
>was not initialized for NAND at all. This patch now fixes this issue.
>
Sorry couldn't understand this, why have users enabled CONFIG_NAND_CMD,
if CONFIG_NAND itself is not enabled ?
Otherwise, if TAO3530 board uses the on-die NAND, then it should enable
NAND in its board profile via boards.cfg

>Tested on TAO3530 board.


with regards, pekon

[U-Boot] [PATCH 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms

[Stefan Roese]

Hi Pekon,

On 09.07.2014 20:22, Gupta, Pekon wrote:
>> Commit a0a37183 (ARM: omap: merge GPMC initialization code for all
>> platform) broke NAND on OMAP3 based platforms. I noticed this while
>> testing the latest 2014.07-rc version on the TAO3530 board. NAND
>> detection did not work with this error message:
>>
>> NAND:  nand: error: Unable to find NAND settings in GPMC Configuration - quitting
>>
>> As OMAP3 configs don't set CONFIG_NAND but CONFIG_NAND_CMD. the GPMC
>> was not initialized for NAND at all. This patch now fixes this issue.
>>
> Sorry couldn't understand this, why have users enabled CONFIG_NAND_CMD,
> if CONFIG_NAND itself is not enabled ?

CONFIG_NAND doesn't seem to be a mandatory define if NAND is used. Many 
OMAP3 based boards don't enable this define but still use NAND. The 
"old" mem.c also did only check for CONFIG_CMD_NAND to configure the 
GPMC accordingly. Thats why I chose to change mem-common.c to accept 
this kind of configuration instead of changing all those config headers 
to enable CONFIG_NAND.

> Otherwise, if TAO3530 board uses the on-die NAND, then it should enable
> NAND in its board profile via boards.cfg

Sorry, I don't understand what this has to do with on-die NAND. This 
patch is a clear fix to restore the original behavior with the "old" mem.c.

Thanks,
Stefan

[U-Boot] [PATCH 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms

[Tom Rini]

On Thu, Jul 10, 2014 at 07:28:00AM +0200, Stefan Roese wrote:
> Hi Pekon,
> 
> On 09.07.2014 20:22, Gupta, Pekon wrote:
> >>Commit a0a37183 (ARM: omap: merge GPMC initialization code for all
> >>platform) broke NAND on OMAP3 based platforms. I noticed this while
> >>testing the latest 2014.07-rc version on the TAO3530 board. NAND
> >>detection did not work with this error message:
> >>
> >>NAND:  nand: error: Unable to find NAND settings in GPMC Configuration - quitting
> >>
> >>As OMAP3 configs don't set CONFIG_NAND but CONFIG_NAND_CMD. the GPMC
> >>was not initialized for NAND at all. This patch now fixes this issue.
> >>
> >Sorry couldn't understand this, why have users enabled CONFIG_NAND_CMD,
> >if CONFIG_NAND itself is not enabled ?
> 
> CONFIG_NAND doesn't seem to be a mandatory define if NAND is used.

Exactly.  Adding in CONFIG_NAND is something that am335x started doing
because of the cases where we do, or do not, want to assume NAND exists.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140711/b2e8f25b/attachment.pgp>

[U-Boot] [PATCH 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms

[Gupta, Pekon]

>From: Tom Rini [mailto:tom.rini at gmail.com] On Behalf Of Rini, Tom
>>On Thu, Jul 10, 2014 at 07:28:00AM +0200, Stefan Roese wrote:
>> Hi Pekon,
>>
>>> On 09.07.2014 20:22, Gupta, Pekon wrote:
>> >>Commit a0a37183 (ARM: omap: merge GPMC initialization code for all
>> >>platform) broke NAND on OMAP3 based platforms. I noticed this while
>> >>testing the latest 2014.07-rc version on the TAO3530 board. NAND
>> >>detection did not work with this error message:
>> >>
>> >>NAND:  nand: error: Unable to find NAND settings in GPMC Configuration - quitting
>> >>
>> >>As OMAP3 configs don't set CONFIG_NAND but CONFIG_NAND_CMD. the GPMC
>> >>was not initialized for NAND at all. This patch now fixes this issue.
>> >>
>> >Sorry couldn't understand this, why have users enabled CONFIG_NAND_CMD,
>> >if CONFIG_NAND itself is not enabled ?
>>
>> CONFIG_NAND doesn't seem to be a mandatory define if NAND is used.
>
>Exactly.  Adding in CONFIG_NAND is something that am335x started doing
>because of the cases where we do, or do not, want to assume NAND exists.
>
That is bad. We shouldn't have added any CONFIG just for sake of making
one platform work, that to with very generic nomenclature. Anyways, given
the fact we have two similar configs, Let's kill one of them completely.
I think killing CONFIG_NAND would be easier, as it's used only in few
TI specific am33xx boards. Agree ?


with regards, pekon

[U-Boot] [PATCH 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms

[Stefan Roese]

On 12.07.2014 15:30, Gupta, Pekon wrote:
>> From: Tom Rini [mailto:tom.rini at gmail.com] On Behalf Of Rini, Tom
>>> On Thu, Jul 10, 2014 at 07:28:00AM +0200, Stefan Roese wrote:
>>> Hi Pekon,
>>>
>>>> On 09.07.2014 20:22, Gupta, Pekon wrote:
>>>>> Commit a0a37183 (ARM: omap: merge GPMC initialization code for all
>>>>> platform) broke NAND on OMAP3 based platforms. I noticed this while
>>>>> testing the latest 2014.07-rc version on the TAO3530 board. NAND
>>>>> detection did not work with this error message:
>>>>>
>>>>> NAND:  nand: error: Unable to find NAND settings in GPMC Configuration - quitting
>>>>>
>>>>> As OMAP3 configs don't set CONFIG_NAND but CONFIG_NAND_CMD. the GPMC
>>>>> was not initialized for NAND at all. This patch now fixes this issue.
>>>>>
>>>> Sorry couldn't understand this, why have users enabled CONFIG_NAND_CMD,
>>>> if CONFIG_NAND itself is not enabled ?
>>>
>>> CONFIG_NAND doesn't seem to be a mandatory define if NAND is used.
>>
>> Exactly.  Adding in CONFIG_NAND is something that am335x started doing
>> because of the cases where we do, or do not, want to assume NAND exists.
>>
> That is bad. We shouldn't have added any CONFIG just for sake of making
> one platform work, that to with very generic nomenclature. Anyways, given
> the fact we have two similar configs, Let's kill one of them completely.
> I think killing CONFIG_NAND would be easier, as it's used only in few
> TI specific am33xx boards. Agree ?

Yes. It would be great if you send an patch for this to be applied after 
this release. And we should take my patch for this release to fix this 
problem quickly.

Thanks,
Stefan

[U-Boot] [PATCH 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms

[Gupta, Pekon]

>From: Stefan Roese [mailto:sr at denx.de]
>>On 12.07.2014 15:30, Gupta, Pekon wrote:
>>> From: Tom Rini [mailto:tom.rini at gmail.com] On Behalf Of Rini, Tom
>>>> On Thu, Jul 10, 2014 at 07:28:00AM +0200, Stefan Roese wrote:
>>>> Hi Pekon,
>>>>
>>>>> On 09.07.2014 20:22, Gupta, Pekon wrote:
>>>>>> Commit a0a37183 (ARM: omap: merge GPMC initialization code for all
>>>>>> platform) broke NAND on OMAP3 based platforms. I noticed this while
>>>>>> testing the latest 2014.07-rc version on the TAO3530 board. NAND
>>>>>> detection did not work with this error message:
>>>>>>
>>>>>> NAND:  nand: error: Unable to find NAND settings in GPMC Configuration - quitting
>>>>>>
>>>>>> As OMAP3 configs don't set CONFIG_NAND but CONFIG_NAND_CMD. the GPMC
>>>>>> was not initialized for NAND at all. This patch now fixes this issue.
>>>>>>
>>>>> Sorry couldn't understand this, why have users enabled CONFIG_NAND_CMD,
>>>>> if CONFIG_NAND itself is not enabled ?
>>>>
>>>> CONFIG_NAND doesn't seem to be a mandatory define if NAND is used.
>>>
>>> Exactly.  Adding in CONFIG_NAND is something that am335x started doing
>>> because of the cases where we do, or do not, want to assume NAND exists.
>>>
>> That is bad. We shouldn't have added any CONFIG just for sake of making
>> one platform work, that to with very generic nomenclature. Anyways, given
>> the fact we have two similar configs, Let's kill one of them completely.
>> I think killing CONFIG_NAND would be easier, as it's used only in few
>> TI specific am33xx boards. Agree ?
>
>Yes. It would be great if you send an patch for this to be applied after
>this release. And we should take my patch for this release to fix this
>problem quickly.
>
Yes, absolutely, I don't want to stall your work.
Acked-by: Pekon Gupta <pekon@ti.com>

with regards, pekon

[U-Boot] [U-Boot, 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms

[Tom Rini]

On Wed, Jul 09, 2014 at 05:18:09PM +0200, Stefan Roese wrote:

> Commit a0a37183 (ARM: omap: merge GPMC initialization code for all
> platform) broke NAND on OMAP3 based platforms. I noticed this while
> testing the latest 2014.07-rc version on the TAO3530 board. NAND
> detection did not work with this error message:
> 
> NAND:  nand: error: Unable to find NAND settings in GPMC Configuration - quitting
> 
> As OMAP3 configs don't set CONFIG_NAND but CONFIG_NAND_CMD. the GPMC
> was not initialized for NAND at all. This patch now fixes this issue.
> 
> Tested on TAO3530 board.
> 
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Pekon Gupta <pekon@ti.com>
> Cc: Tom Rini <trini@ti.com>
> Acked-by: Pekon Gupta <pekon@ti.com>

Please note that this introduces build failure on the tricorder
platforms but is a bugfix.  Thomas, tricorder is currently broken in
that NAND doesn't work without this patch.  With this patch we're now
too big in SPL to fit in SRAM.  I suspect, but this needs run-time
testing that we can bump max size / say 6KB for stack, or better yet
confirm that like am335x / am43xx / omap4+ we init DDR prior to putting
CONFIG_SPL_STACK into sp and can use the whole of SRAM for SPL and have
stack be an address in DDR (see
http://patchwork.ozlabs.org/patch/371636/).

Applied to u-boot-ti/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140725/5f3b0c5e/attachment.pgp>