[U-Boot] [PATCH 1/3] ARM: omap: Fix GPMC init for OMAP3 platforms
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,
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 -}
From: Stefan Roese [mailto:sr@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
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!
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
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!
Hi Stefan,
From: Stefan Roese [mailto:sr@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
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
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.
From: Tom Rini [mailto:tom.rini@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
On 12.07.2014 15:30, Gupta, Pekon wrote:
From: Tom Rini [mailto:tom.rini@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
From: Stefan Roese [mailto:sr@denx.de]
On 12.07.2014 15:30, Gupta, Pekon wrote:
From: Tom Rini [mailto:tom.rini@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
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!
participants (3)
-
Gupta, Pekon -
Stefan Roese -
Tom Rini