January 2012 - U-Boot

[U-Boot] [PATCH 0/2] SPI flash enhancements: allow default bus and chip-selects
by Eric Nelson 31 Jan '12

31 Jan '12

Patch 1 modifies the 'sf' command to allow a default bus and chip-select to be specified by board headers. This allows a bare 'sf' probe command: U-Boot> sf probe instead of the more cumbersome usage when a GPIO is tacked onto the chip-select. Otherwise, this command-line would be needed to specify GP3:19 on SabreLite: U-Boot> sf probe 0x5300 Patch 2 provides a description of usage and configuration of CONFIG_CMD_SF. Signed-off-by: Eric Nelson <eric.nelson(a)boundarydevices.com>

4 7

[U-Boot] [PATCH 1/2] sf: eeprom_m95xxx: fix up style
by Mike Frysinger 31 Jan '12

31 Jan '12

Signed-off-by: Mike Frysinger <vapier(a)gentoo.org> --- drivers/mtd/spi/eeprom_m95xxx.c | 24 ++++++++++++------------ 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/mtd/spi/eeprom_m95xxx.c b/drivers/mtd/spi/eeprom_m95xxx.c index ef8ed6f..bae9445 100644 --- a/drivers/mtd/spi/eeprom_m95xxx.c +++ b/drivers/mtd/spi/eeprom_m95xxx.c @@ -37,33 +37,33 @@ #define CONFIG_DEFAULT_SPI_MODE SPI_MODE_0 #endif -ssize_t spi_read (uchar *addr, int alen, uchar *buffer, int len) +ssize_t spi_read(uchar *addr, int alen, uchar *buffer, int len) { struct spi_slave *slave; u8 cmd = SPI_EEPROM_READ; slave = spi_setup_slave(CONFIG_DEFAULT_SPI_BUS, 1, 1000000, CONFIG_DEFAULT_SPI_MODE); - if(!slave) + if (!slave) return 0; spi_claim_bus(slave); /* command */ - if(spi_xfer(slave, 8, &cmd, NULL, SPI_XFER_BEGIN)) + if (spi_xfer(slave, 8, &cmd, NULL, SPI_XFER_BEGIN)) return -1; /* - * if alen == 3, addr[0] is the block number, we never use it here. All we - * need are the lower 16 bits + * if alen == 3, addr[0] is the block number, we never use it here. + * All we need are the lower 16 bits. */ if (alen == 3) addr++; /* address, and data */ - if(spi_xfer(slave, 16, addr, NULL, 0)) + if (spi_xfer(slave, 16, addr, NULL, 0)) return -1; - if(spi_xfer(slave, 8 * len, NULL, buffer, SPI_XFER_END)) + if (spi_xfer(slave, 8 * len, NULL, buffer, SPI_XFER_END)) return -1; spi_release_bus(slave); @@ -71,7 +71,7 @@ ssize_t spi_read (uchar *addr, int alen, uchar *buffer, int len) return len; } -ssize_t spi_write (uchar *addr, int alen, uchar *buffer, int len) +ssize_t spi_write(uchar *addr, int alen, uchar *buffer, int len) { struct spi_slave *slave; char buf[3]; @@ -85,7 +85,7 @@ ssize_t spi_write (uchar *addr, int alen, uchar *buffer, int len) spi_claim_bus(slave); buf[0] = SPI_EEPROM_WREN; - if(spi_xfer(slave, 8, buf, NULL, SPI_XFER_BEGIN | SPI_XFER_END)) + if (spi_xfer(slave, 8, buf, NULL, SPI_XFER_BEGIN | SPI_XFER_END)) return -1; buf[0] = SPI_EEPROM_WRITE; @@ -98,9 +98,9 @@ ssize_t spi_write (uchar *addr, int alen, uchar *buffer, int len) memcpy(buf + 1, addr, alen); /* command + addr, then data */ - if(spi_xfer(slave, 24, buf, NULL, SPI_XFER_BEGIN)) + if (spi_xfer(slave, 24, buf, NULL, SPI_XFER_BEGIN)) return -1; - if(spi_xfer(slave, len * 8, buffer, NULL, SPI_XFER_END)) + if (spi_xfer(slave, len * 8, buffer, NULL, SPI_XFER_END)) return -1; start = get_timer(0); @@ -115,7 +115,7 @@ ssize_t spi_write (uchar *addr, int alen, uchar *buffer, int len) } while (get_timer(start) < CONFIG_SYS_SPI_WRITE_TOUT); if (buf[1] & 1) - printf ("*** spi_write: Time out while writing!\n"); + printf("*** spi_write: Timeout while writing!\n"); spi_release_bus(slave); spi_free_slave(slave); -- 1.7.8.4

1 1

[U-Boot] Changes in uEnv.txt does not work
by manishdkanchan 31 Jan '12

31 Jan '12

Hi, I am Manish and i have recently started working on beagleboard xm. I am facing certain issues. Need guidance to solve it. Background: I am using beagleboard xm, uboot version 9 of 2011 Intention: Current version of uboot has the environment variable loaduimage set for ext3 partition.Now i want the uboot to pick the uimage from fat partition. I can do it by modifying the uboot code and use the rebuilt uboot but i want to remove dependency on building uboot for future version. So i was trying to play around with uEnv.txt Exercise: Initially i tried to update loaduimage to fatload mmc ${mmcdev} ${loadaddr} uImage and tried booting but was unsuccessful. I tried to uncover the problem by echo statements to track the code flow. I observed that the 1.Same command works when i change the omap3_beagle.h and rebuild the uboot but it does not work if i change it using uEnv.txt. 2.Also that the error is returned from mmcboot->bootm command saying the image is in wrong format. But i am using the same image as in case 1. Can some on guide me how do i achive this. I want to use uEnv.txt for better maintanibilty -- View this message in context: http://old.nabble.com/Changes-in-uEnv.txt-does-not-work-tp33215335p33215335… Sent from the Uboot - Users mailing list archive at Nabble.com.

2 1

Re: [U-Boot] Memory testing of flash
by Wolfgang Denk 31 Jan '12

31 Jan '12

Dear Vaibhav Kothari, please keep the ML on Cc: In message <CAHD55i3Odt_e9PdEAoyE=JhRwb5jaKem=xp7PRB-Oe1rqN9EJg(a)mail.gmail.com> you wrote: > > Thank you very much....your answer is really very helpful.. > > > Though if i wanted to test flash all sectors but not one which contains > uboot code ...is it possible to do so??how? Sure. Try for example: => erase all Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de What is research but a blind date with knowledge? -- Will Harvey

1 0

[U-Boot] Memory testing of flash
by vk 31 Jan '12

31 Jan '12

Is it safer to test flash during bootup...what if power gets off half a way while writing data on address at which uboot source code is located?Then uboot will never get started??

2 1

[U-Boot] [PATCH] omap_hsmmc: Wait for CMDI to be clear
by Tom Rini 31 Jan '12

31 Jan '12

Before we can send a command we need both the DATI (command inhibit on mmc_dat line) bit and CMDI (command inhibit on mmc_cmd line) are clear. The previous behavior of only checking on DATI was insufficient on some cards and incorrect behavior in any case. This makes the code check for both bits being clear and makes the error print more clear as to what happened. DATI_CMDDIS is removed as it was unused elsewhere in the code and stood for 'DATI is set, cmds are disabled still'. Fix originally spotted by Peter Bigot. Tested-by: Peter A. Bigot <bigotp(a)acm.org> Tested-by: Robert Nelson <robertcnelson(a)gmail.com> Signed-off-by: Tom Rini <trini(a)ti.com> --- arch/arm/include/asm/arch-am33xx/mmc_host_def.h | 2 +- arch/arm/include/asm/arch-omap3/mmc_host_def.h | 2 +- arch/arm/include/asm/arch-omap4/mmc_host_def.h | 2 +- arch/arm/include/asm/arch-omap5/mmc_host_def.h | 2 +- drivers/mmc/omap_hsmmc.c | 5 +++-- 5 files changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/arch-am33xx/mmc_host_def.h b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h index 5d7dd4b..943526b 100644 --- a/arch/arm/include/asm/arch-am33xx/mmc_host_def.h +++ b/arch/arm/include/asm/arch-am33xx/mmc_host_def.h @@ -97,7 +97,7 @@ typedef struct hsmmc { #define INDEX_MASK (0x3f << 24) #define INDEX(i) (i << 24) #define DATI_MASK (0x1 << 1) -#define DATI_CMDDIS (0x1 << 1) +#define CMDI_MASK (0x1 << 0) #define DTW_1_BITMODE (0x0 << 1) #define DTW_4_BITMODE (0x1 << 1) #define DTW_8_BITMODE (0x1 << 5) /* CON[DW8]*/ diff --git a/arch/arm/include/asm/arch-omap3/mmc_host_def.h b/arch/arm/include/asm/arch-omap3/mmc_host_def.h index 2963679..f8c42c0 100644 --- a/arch/arm/include/asm/arch-omap3/mmc_host_def.h +++ b/arch/arm/include/asm/arch-omap3/mmc_host_def.h @@ -129,7 +129,7 @@ struct hsmmc { #define INDEX_MASK (0x3f << 24) #define INDEX(i) (i << 24) #define DATI_MASK (0x1 << 1) -#define DATI_CMDDIS (0x1 << 1) +#define CMDI_MASK (0x1 << 0) #define DTW_1_BITMODE (0x0 << 1) #define DTW_4_BITMODE (0x1 << 1) #define DTW_8_BITMODE (0x1 << 5) /* CON[DW8]*/ diff --git a/arch/arm/include/asm/arch-omap4/mmc_host_def.h b/arch/arm/include/asm/arch-omap4/mmc_host_def.h index 74439c9..ce1bce1 100644 --- a/arch/arm/include/asm/arch-omap4/mmc_host_def.h +++ b/arch/arm/include/asm/arch-omap4/mmc_host_def.h @@ -107,7 +107,7 @@ struct hsmmc { #define INDEX_MASK (0x3f << 24) #define INDEX(i) (i << 24) #define DATI_MASK (0x1 << 1) -#define DATI_CMDDIS (0x1 << 1) +#define CMDI_MASK (0x1 << 0) #define DTW_1_BITMODE (0x0 << 1) #define DTW_4_BITMODE (0x1 << 1) #define DTW_8_BITMODE (0x1 << 5) /* CON[DW8]*/ diff --git a/arch/arm/include/asm/arch-omap5/mmc_host_def.h b/arch/arm/include/asm/arch-omap5/mmc_host_def.h index 74439c9..ce1bce1 100644 --- a/arch/arm/include/asm/arch-omap5/mmc_host_def.h +++ b/arch/arm/include/asm/arch-omap5/mmc_host_def.h @@ -107,7 +107,7 @@ struct hsmmc { #define INDEX_MASK (0x3f << 24) #define INDEX(i) (i << 24) #define DATI_MASK (0x1 << 1) -#define DATI_CMDDIS (0x1 << 1) +#define CMDI_MASK (0x1 << 0) #define DTW_1_BITMODE (0x0 << 1) #define DTW_4_BITMODE (0x1 << 1) #define DTW_8_BITMODE (0x1 << 5) /* CON[DW8]*/ diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index ef64e37..2400db2 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -198,9 +198,10 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, ulong start; start = get_timer(0); - while ((readl(&mmc_base->pstate) & DATI_MASK) == DATI_CMDDIS) { + while ((readl(&mmc_base->pstate) & (DATI_MASK | CMDI_MASK)) != 0) { if (get_timer(0) - start > MAX_RETRY_MS) { - printf("%s: timedout waiting for cmddis!\n", __func__); + printf("%s: timedout waiting on cmd inhibit to clear\n", + __func__); return TIMEOUT; } } -- 1.7.0.4

2 1

[U-Boot] mx28 spl power cpu clock configuration
by Robert Deliën 31 Jan '12

31 Jan '12

Hi Marek/Fabio, I think there's an error in code setting up the CPU clock in the SPL for the i.MX28. When instruction stepping through mx28_power_clock2pll in spl_power_init.c, the processor drops dead right after PLL bypass has been disabled. The i.MX28 reference manual (pag 116) states that the JTAG clock is derived from the CPU clock and that the JTAG tap will stop working if CPU clock is stalled, too low or disabled. I figured that disabling PLL bypass would temporarilly cause an irregular clock, throwing off the probe, even in adaptive clocking mode. Three different probes later, I know it is not. Freescal tech support said it may be related to a non ARM specification shortcut in the clock tree, but that's not causing the problem either. I succeeded in reproducing the problem using only my JTAG probe (Abatron BDI300) on adaptive clocking. Below the transcript of the probe's command line interface: 926E>reset ... 926E>md 0x80040000 1 80040000 : 0x00000000 0 .... 926E>mm 0x80040000 0x00020000 926E>md 0x80040000 1 80040000 : 0x00020000 131072 .... 926E> 926E>md 0x800401d0 1 800401d0 : 0x000441ff 279039 .A.. 926E>mm 0x800401d0 0x000041ff 926E>md 0x800401d0 1 After the last command, both mx28evk board and JTAG probe hang. The last JTAG transaction, caused by the last 'mm'-command, is shown on attachement 'TCK-RTCK, Adaptive, No Frac0.png'. This picture shows that the transaction the probe is raising TCK, but the target is no longer following it, as it's supposed to do. When configuring the probe at a fixed clock of 1MHz, the same sequence no longer hangs up the probe, but just hangs up the target: 926E>reset ... 926E>md 0x80040000 1 80040000 : 0x00000000 0 .... 926E>mm 0x80040000 0x00020000 926E>md 0x80040000 1 80040000 : 0x00020000 131072 .... 926E> 926E>md 0x800401d0 1 800401d0 : 0x000441ff 279039 .A.. 926E>mm 0x800401d0 0x000041ff 926E>md 0x80040000 1 80040000 : 0xffffffff -1 .... The last read-back is obviously a bogus value. The last JTAG transaction, caused by the last 'mm'-command, is shown on attachement 'TCK-RTCK, 1MHz, No Frac0.png'. This picture shows that half-way the transaction the stops outputting RTCK, while the probe continues on it's fixed clock. I think the cause of this problem is that PLL bypass is disabled - using PLL0 as CPU clock source instead of it's reference xtal - while CPU clock gating on PLL0 is still enabled. Now I don't fully understand why this problem only occurs when instruction-stepping the code, and not under normal operating conditions. It may be related to delay, because some time later mx28_mem_init in spl_mem_init.c does disable CPU clock gating on PLL0. I have tested this by modifying the sequence above by inserting commands to disable CPU clock gating: 926E>reset ... 926E>md 0x80040000 1 80040000 : 0x00000000 0 .... 926E>mm 0x80040000 0x00020000 926E>md 0x80040000 1 80040000 : 0x00020000 131072 .... 926E> 926E>md 0x800401b0 1 800401b0 : 0x92929292 -1835887982 .... 926E>mm 0x800401b0 0x12525513 926E>md 0x800401b0 1 800401b0 : 0x52521513 1381111059 ..RR 926E> 926E>md 0x800401d0 1 800401d0 : 0x000441ff 279039 .A.. 926E>mm 0x800401d0 0x000041ff 926E>md 0x800401d0 1 800401d0 : 0x000041ff 16895 .A.. After this sequence, both probe and board are still fully responsive. Even the written value can be read back successfully. Attachement 'TCK-RTCK, Adaptive, Frac0.png' shows the JTAG transaction, caused by the last 'mm'-command. The zoomed section at the bottom shows how the clock frequency increases half-way the command. The sequence above changes more to the clkctrl_frac0 register than just disabling CPU clock gating, but I have repeated this sequence writing a value of 0x92929212 (over a power-up default of 0x92929292) and that works just the same. Shouldn't we configure clkctrl_frac0 - or at least disable CPU clock gating - before disabling PLL bypass? Cheers, Robert.

3 18

[U-Boot] [PATCH] mx6q: mx6qsabrelite: Conditionally define macros for environment in serial flash
by Eric Nelson 30 Jan '12

30 Jan '12

The default settings store the persistent environment on SD card and not serial flash (SPI NOR). To use SPI NOR to save the environment instead of SD card, edit include/configs/mx6qsabrelite.h and - undefine CONFIG_ENV_IS_IN_MMC - define CONFIG_ENV_IS_IN_SPI_FLASH The SPI driver can take as chip select the controller's chip selects as well as an external GPIO. The LSB byte has the value of the internal chip select, the highest (thought as 16-bit value) contains the GPIO number. The GPIO used on Sabre Lite is GP3:19 == 83. --- include/configs/mx6qsabrelite.h | 18 +++++++++++++++--- 1 files changed, 15 insertions(+), 3 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index 3bf7819..70c9d10 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -175,10 +175,22 @@ /* FLASH and environment organization */ #define CONFIG_SYS_NO_FLASH -#define CONFIG_ENV_OFFSET (6 * 64 * 1024) -#define CONFIG_ENV_SIZE (8 * 1024) +#define CONFIG_ENV_SIZE (8 * 1024) + #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_SYS_MMC_ENV_DEV 0 +/* #define CONFIG_ENV_IS_IN_SPI_FLASH */ + +#if defined(CONFIG_ENV_IS_IN_MMC) +#define CONFIG_ENV_OFFSET (6 * 64 * 1024) +#define CONFIG_SYS_MMC_ENV_DEV 0 +#elif defined(CONFIG_ENV_IS_IN_SPI_FLASH) +#define CONFIG_ENV_OFFSET (768 * 1024) +#define CONFIG_ENV_SECT_SIZE (8 * 1024) +#define CONFIG_ENV_SPI_BUS CONFIG_SF_DEFAULT_BUS +#define CONFIG_ENV_SPI_CS CONFIG_SF_DEFAULT_CS +#define CONFIG_ENV_SPI_MODE CONFIG_SF_DEFAULT_MODE +#define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED +#endif #define CONFIG_OF_LIBFDT -- 1.7.1

1 0

[U-Boot] [PATCH] mx6q: mx6qsabrelite: Provide default serial flash bus and chip-select
by Eric Nelson 30 Jan '12

30 Jan '12

Signed-off-by: Eric Nelson <eric.nelson(a)boundarydevices.com> Acked-by: Dirk Behme <dirk.behme(a)de.bosch.com> Acked-by: Stefano Babic <sbabic(a)denx.de> --- include/configs/mx6qsabrelite.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h index bcb1a42..3bf7819 100644 --- a/include/configs/mx6qsabrelite.h +++ b/include/configs/mx6qsabrelite.h @@ -46,9 +46,12 @@ #define CONFIG_CMD_SF #ifdef CONFIG_CMD_SF +#define GPIO_3_19 ((2*32)+19) #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_SST #define CONFIG_MXC_SPI +#define CONFIG_SF_DEFAULT_BUS 0 +#define CONFIG_SF_DEFAULT_CS (0|(GPIO_3_19<<8)) #define CONFIG_SF_DEFAULT_SPEED 25000000 #define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0) #endif -- 1.7.1

1 0

[U-Boot] [PATCH V4 0/7] mxc_spi refactoring (for mx6q and mx6qsabrelite)
by Eric Nelson 30 Jan '12

30 Jan '12

This patch set refactors mxc_spi as described in http://lists.denx.de/pipermail/u-boot/2010-March/068791.html and requested in http://lists.denx.de/pipermail/u-boot/2012-January/116023.html in order to add support for the MX6Q in general and the mx6qsabrelite specifically. Patch 1 simply moves the conditional parts of mxc_spi.c into the respective CPU-specific imx-regs.h files. Patch 2 adds general support for SPI to the i.MX6. Patch 3 adds support to the mx6qsabrelite board Patch 4 modifies the 'sf' command to allow a default bus and chip-select to be specified by board headers. This allows a bare 'sf' probe command: U-Boot> sf probe instead of the more cumbersome usage when a GPIO is tacked onto the chip-select. Otherwise, this command-line would be needed to specify GP3:19 on SabreLite: U-Boot> sf probe 0x5300 Patch 5 provides a description of usage and configuration of CONFIG_CMD_SF. Patch 6 adds default chip-select values for mx6qsabrelite platform. Patch 7 adds reference macros for use in storing the environment in serial flash to match the use on Freescale's U-Boot release This patch set has been compiled against the following configurations, but only tested on mx6qsabrelite: mx6qsabrelite mx51evk mx31pdk mx35pdk

4 25