| Message ID | 1399565627-27770-4-git-send-email-pekon@ti.com |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
On Thu, May 08, 2014 at 09:43:47PM +0530, pekon gupta wrote: > GPMC controller on TI's OMAP SoC is general purpose controller to interface > with different types of external devices like; > - parallel NOR flash > - parallel NAND flash > - OneNand flash > - SDR RAM > - Ethernet Devices like LAN9220 > > Though GPMC configurations may be different for each platform depending on > clock-frequency and external device interfacing with controller. But > initialization sequence remains common across all platfoms. > > Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c > files into single omap-common/mem-common.c > > However, actual platforms specific register config values are still sourced > from corresponding platform specific headers like; > AM33xx: arch/arm/include/asm/arch-am33xx/mem.h > OMAP3: arch/arm/include/asm/arch-omap3/mem.h > OMAP4: arch/arm/include/asm/arch-omap4/mem.h > OMAP4: arch/arm/include/asm/arch-omap5/mem.h > > Also, CONFIG_xx passed by board-profile decide config for which set of macros > need to be used for initialization > CONFIG_NAND: initialize GPMC for NAND device > CONFIG_NOR: initialize GPMC for NOR device > CONFIG_ONENAND: initialize GPMC for ONENAND device > > Signed-off-by: Pekon Gupta <pekon@ti.com> After adding GPMC_SIZE_256M to omap3/mem.h, applied to u-boot-ti/master, thanks! And note that git detect renames got a bit too agressive here so I had to apply it kinda by hand, but I think I did everything right.
>From: Tom Rini [mailto:tom.rini@gmail.com] On Behalf Of Rini, Tom >On Thu, May 08, 2014 at 09:43:47PM +0530, pekon gupta wrote: > >> GPMC controller on TI's OMAP SoC is general purpose controller to interface >> with different types of external devices like; >> - parallel NOR flash >> - parallel NAND flash >> - OneNand flash >> - SDR RAM >> - Ethernet Devices like LAN9220 >> >> Though GPMC configurations may be different for each platform depending on >> clock-frequency and external device interfacing with controller. But >> initialization sequence remains common across all platfoms. >> >> Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c >> files into single omap-common/mem-common.c >> >> However, actual platforms specific register config values are still sourced >> from corresponding platform specific headers like; >> AM33xx: arch/arm/include/asm/arch-am33xx/mem.h >> OMAP3: arch/arm/include/asm/arch-omap3/mem.h >> OMAP4: arch/arm/include/asm/arch-omap4/mem.h >> OMAP4: arch/arm/include/asm/arch-omap5/mem.h >> >> Also, CONFIG_xx passed by board-profile decide config for which set of macros >> need to be used for initialization >> CONFIG_NAND: initialize GPMC for NAND device >> CONFIG_NOR: initialize GPMC for NOR device >> CONFIG_ONENAND: initialize GPMC for ONENAND device >> >> Signed-off-by: Pekon Gupta <pekon@ti.com> > >After adding GPMC_SIZE_256M to omap3/mem.h, applied to u-boot-ti/master, >thanks! > >And note that git detect renames got a bit too agressive here so I had >to apply it kinda by hand, but I think I did everything right. > Thanks much .. I'll review the changes. with regards, pekon
Hi,
I'm actually seeing some breakage from this commit
(a0a37183bd75e74608bc78c8d0e2a34454f95a91). When booting the DuoVero
board (no NAND/NOR/ONENAND but a network card on GPMC), it hangs as it
enters the kernel.
These lines in gpmc_init() in arch/arm/cpu/armv7/omap-common/mem-common.c
...
writel(0, &gpmc_cfg->cs[0].config7);
sdelay(1000);
/* enable chip-select specific configurations */
enable_gpmc_cs_config(gpmc_regs, &gpmc_cfg->cs[0], base, size);
...
seem to be the source of the issue. Even though we have nothing
connected on CS0, the last line of enable_gpmc_cs_config() enables the
interface despite it being disabled right before in writel(0,
&gpmc_cfg->cs[0].config7);
--Ash
On Mon, May 26, 2014 at 9:47 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>From: Tom Rini [mailto:tom.rini@gmail.com] On Behalf Of Rini, Tom
>>On Thu, May 08, 2014 at 09:43:47PM +0530, pekon gupta wrote:
>>
>>> GPMC controller on TI's OMAP SoC is general purpose controller to interface
>>> with different types of external devices like;
>>> - parallel NOR flash
>>> - parallel NAND flash
>>> - OneNand flash
>>> - SDR RAM
>>> - Ethernet Devices like LAN9220
>>>
>>> Though GPMC configurations may be different for each platform depending on
>>> clock-frequency and external device interfacing with controller. But
>>> initialization sequence remains common across all platfoms.
>>>
>>> Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c
>>> files into single omap-common/mem-common.c
>>>
>>> However, actual platforms specific register config values are still sourced
>>> from corresponding platform specific headers like;
>>> AM33xx: arch/arm/include/asm/arch-am33xx/mem.h
>>> OMAP3: arch/arm/include/asm/arch-omap3/mem.h
>>> OMAP4: arch/arm/include/asm/arch-omap4/mem.h
>>> OMAP4: arch/arm/include/asm/arch-omap5/mem.h
>>>
>>> Also, CONFIG_xx passed by board-profile decide config for which set of macros
>>> need to be used for initialization
>>> CONFIG_NAND: initialize GPMC for NAND device
>>> CONFIG_NOR: initialize GPMC for NOR device
>>> CONFIG_ONENAND: initialize GPMC for ONENAND device
>>>
>>> Signed-off-by: Pekon Gupta <pekon@ti.com>
>>
>>After adding GPMC_SIZE_256M to omap3/mem.h, applied to u-boot-ti/master,
>>thanks!
>>
>>And note that git detect renames got a bit too agressive here so I had
>>to apply it kinda by hand, but I think I did everything right.
>>
> Thanks much .. I'll review the changes.
>
> with regards, pekon
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Hi Ash, >From: ashcharles@gmail.com >Hi, > >I'm actually seeing some breakage from this commit >(a0a37183bd75e74608bc78c8d0e2a34454f95a91). When booting the DuoVero >board (no NAND/NOR/ONENAND but a network card on GPMC), it hangs as it >enters the kernel. > >These lines in gpmc_init() in arch/arm/cpu/armv7/omap-common/mem-common.c >... > writel(0, &gpmc_cfg->cs[0].config7); > sdelay(1000); > /* enable chip-select specific configurations */ > enable_gpmc_cs_config(gpmc_regs, &gpmc_cfg->cs[0], base, size); >... >seem to be the source of the issue. Even though we have nothing >connected on CS0, the last line of enable_gpmc_cs_config() enables the >interface despite it being disabled right before in writel(0, >&gpmc_cfg->cs[0].config7); > Sorry seeing this bit late. Were you able to root cause the issue ? All Ethernet related GPMC configurations are defined by following macros File: $U-BOOT/arch/arm/include/asm/arch-omap3/mem.h #define NET_GPMC_CONFIG1 0x00001000 #define NET_GPMC_CONFIG2 0x001e1e01 #define NET_GPMC_CONFIG3 0x00080300 #define NET_GPMC_CONFIG4 0x1c091c09 #define NET_GPMC_CONFIG5 0x04181f1f #define NET_GPMC_CONFIG6 0x00000FCF #define NET_GPMC_CONFIG7 0x00000f6c OR /* GPMC CS configuration for an SMSC LAN9221 ethernet controller */ #define NET_LAN9221_GPMC_CONFIG1 0x00001000 #define NET_LAN9221_GPMC_CONFIG2 0x00060700 #define NET_LAN9221_GPMC_CONFIG3 0x00020201 #define NET_LAN9221_GPMC_CONFIG4 0x06000700 #define NET_LAN9221_GPMC_CONFIG5 0x0006090A #define NET_LAN9221_GPMC_CONFIG6 0x87030000 #define NET_LAN9221_GPMC_CONFIG7 0x00000f6c I havn't touched these values, except for moving some of them from one header-file to other. Also, the change in u-boot, should not affect the kernel. That means kernel's GPMC driver was depending on some pre-configured value, which is wrong. There were couple of fixes for SMSC controller pushed in 3.16 kernel, Are following in your tree ? fb677ef tony@atomide.com ARM: OMAP2+: Fix GPMC remap for devices using an offset efe8072 tony@atomide.com ARM: OMAP2+: Fix oops for GPMC free with regards, pekon
Hi Pekon, On Mon, Jul 7, 2014 at 11:19 PM, Gupta, Pekon <pekon@ti.com> wrote: > Sorry seeing this bit late. Were you able to root cause the issue ? Did you see http://patchwork.ozlabs.org/patch/356984/ ? This resolves the issue for me but I'd welcome any feedback you have on this fix. ... > Also, the change in u-boot, should not affect the kernel. > That means kernel's GPMC driver was depending on some pre-configured > value, which is wrong. > There were couple of fixes for SMSC controller pushed in 3.16 kernel, > Are following in your tree ? > fb677ef tony@atomide.com ARM: OMAP2+: Fix GPMC remap for devices using an offset > efe8072 tony@atomide.com ARM: OMAP2+: Fix oops for GPMC free Okay---I'd seen the breakage on both the standard 3.5 kernel for my board (overo) as well as on the then-mainline version 3.15+ which is why I dived into u-boot to find a fix. I was likely missing these two commits though! Thanks, Ash
>From: ashcharles@gmail.com >>On Mon, Jul 7, 2014 at 11:19 PM, Gupta, Pekon <pekon@ti.com> wrote: >> Sorry seeing this bit late. Were you able to root cause the issue ? >Did you see http://patchwork.ozlabs.org/patch/356984/ ? >This resolves the issue for me but I'd welcome any feedback you have >on this fix. Thanks for the fix. Though I don't know why GPMC initialization without any device connected should cause a hang, that too on kernel side. with regards, pekon
diff --git a/arch/arm/cpu/armv7/am33xx/Makefile b/arch/arm/cpu/armv7/am33xx/Makefile index 5566310..aae3f09 100644 --- a/arch/arm/cpu/armv7/am33xx/Makefile +++ b/arch/arm/cpu/armv7/am33xx/Makefile @@ -14,7 +14,6 @@ endif obj-$(CONFIG_TI816X) += clock_ti816x.o obj-y += sys_info.o -obj-y += mem.o obj-y += ddr.o obj-y += emif4.o obj-y += board.o diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile index 59f5352..5f5132f 100644 --- a/arch/arm/cpu/armv7/omap-common/Makefile +++ b/arch/arm/cpu/armv7/omap-common/Makefile @@ -27,8 +27,4 @@ obj-y += boot-common.o obj-y += lowlevel_init.o endif -ifndef CONFIG_SPL_BUILD -ifneq ($(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX),) obj-y += mem-common.o -endif -endif diff --git a/arch/arm/cpu/armv7/am33xx/mem.c b/arch/arm/cpu/armv7/omap-common/mem-common.c similarity index 68% rename from arch/arm/cpu/armv7/am33xx/mem.c rename to arch/arm/cpu/armv7/omap-common/mem-common.c index 56c9e7d..944ef84 100644 --- a/arch/arm/cpu/armv7/am33xx/mem.c +++ b/arch/arm/cpu/armv7/omap-common/mem-common.c @@ -19,9 +19,36 @@ #include <asm/arch/mem.h> #include <asm/arch/sys_proto.h> #include <command.h> +#include <linux/mtd/omap_gpmc.h> struct gpmc *gpmc_cfg; +#if defined(CONFIG_OMAP34XX) +/******************************************************** + * 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; +} +#endif void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, u32 size) @@ -74,6 +101,17 @@ void gpmc_init(void) }; u32 size = GPMC_SIZE_256M; u32 base = CONFIG_SYS_NAND_BASE; +#elif defined(CONFIG_CMD_ONENAND) + const u32 gpmc_regs[GPMC_MAX_REG] = { ONENAND_GPMC_CONFIG1, + ONENAND_GPMC_CONFIG2, + ONENAND_GPMC_CONFIG3, + ONENAND_GPMC_CONFIG4, + ONENAND_GPMC_CONFIG5, + ONENAND_GPMC_CONFIG6, + 0 + }; + u32 base = PISMO1_ONEN_BASE; + u32 size = PISMO1_ONEN_SIZE; #else const u32 gpmc_regs[GPMC_MAX_REG] = { 0, 0, 0, 0, 0, 0, 0 }; u32 size = 0; @@ -83,6 +121,7 @@ void gpmc_init(void) writel(0x00000008, &gpmc_cfg->sysconfig); writel(0x00000000, &gpmc_cfg->irqstatus); writel(0x00000000, &gpmc_cfg->irqenable); + writel(0x00000000, &gpmc_cfg->timeout_control); #ifdef CONFIG_NOR writel(0x00000200, &gpmc_cfg->config); #else diff --git a/arch/arm/cpu/armv7/omap3/Makefile b/arch/arm/cpu/armv7/omap3/Makefile index 39ff257..cf86046 100644 --- a/arch/arm/cpu/armv7/omap3/Makefile +++ b/arch/arm/cpu/armv7/omap3/Makefile @@ -9,7 +9,6 @@ obj-y := lowlevel_init.o obj-y += board.o obj-y += clock.o -obj-y += mem.o obj-y += sys_info.o ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_OMAP3_ID_NAND) += spl_id_nand.o
GPMC controller on TI's OMAP SoC is general purpose controller to interface with different types of external devices like; - parallel NOR flash - parallel NAND flash - OneNand flash - SDR RAM - Ethernet Devices like LAN9220 Though GPMC configurations may be different for each platform depending on clock-frequency and external device interfacing with controller. But initialization sequence remains common across all platfoms. Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c files into single omap-common/mem-common.c However, actual platforms specific register config values are still sourced from corresponding platform specific headers like; AM33xx: arch/arm/include/asm/arch-am33xx/mem.h OMAP3: arch/arm/include/asm/arch-omap3/mem.h OMAP4: arch/arm/include/asm/arch-omap4/mem.h OMAP4: arch/arm/include/asm/arch-omap5/mem.h Also, CONFIG_xx passed by board-profile decide config for which set of macros need to be used for initialization CONFIG_NAND: initialize GPMC for NAND device CONFIG_NOR: initialize GPMC for NOR device CONFIG_ONENAND: initialize GPMC for ONENAND device Signed-off-by: Pekon Gupta <pekon@ti.com> --- arch/arm/cpu/armv7/am33xx/Makefile | 1 - arch/arm/cpu/armv7/omap-common/Makefile | 4 - .../{am33xx/mem.c => omap-common/mem-common.c} | 39 ++++++ arch/arm/cpu/armv7/omap3/Makefile | 1 - arch/arm/cpu/armv7/omap3/mem.c | 139 --------------------- 5 files changed, 39 insertions(+), 145 deletions(-) rename arch/arm/cpu/armv7/{am33xx/mem.c => omap-common/mem-common.c} (68%) 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