September 2013 - U-Boot

[U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored
by Michael Heimpold 25 Jul '17

25 Jul '17

Closing a file descriptor does not guarantee that the data has been successfully saved to disk, as the kernel might defer the write. Signed-off-by: Michael Heimpold <mhei(a)heimpold.de> --- tools/env/fw_env.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 428e374..0420495 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -1033,7 +1033,19 @@ static int flash_io (int mode) rc = flash_write (fd_current, fd_target, dev_target); + if (fsync (fd_current)) { + fprintf (stderr, + "fsync failed on %s: %s\n", + DEVNAME (dev_current), strerror (errno)); + } + if (HaveRedundEnv) { + if (fsync (fd_target)) { + fprintf (stderr, + "fsync failed on %s: %s\n", + DEVNAME (dev_current), strerror (errno)); + } + if (close (fd_target)) { fprintf (stderr, "I/O error on %s: %s\n", -- 1.7.10.4

5 6

[U-Boot] [PATCH v2 0/7] mtd/st_smi: Add fixes for smi driver
by Vipin Kumar 14 Dec '15

14 Dec '15

Modifications in v2 (Review comments incorporation) - Use setbits_le32 and clrbits_le32 whereever applicable in patch-set - Define smi_mtd_init() routine irrespective of CONFIG_MTD_DEVICE Modifications in v1 - Add MTD support for smi driver - Write to flash in a tight loop - Alphabetically sort the list of devices - Avoid issuing multiple write enable commands Armando Visconti (1): mtd/st_smi: Add support for Micron N25Q128 Flash Vipin Kumar (6): mtd/st_smi: Clear error flags while initiating a fresh write mtd/st_smi: Rearrange the supported devices in alphabetical order mtd/st_smi: Avoid issuing multiple WE commands mtd/st_smi: Write to flash in a tight loop mtd/st_smi: Use page sizes respective to flash mtd/st_smi: Add mtd support for smi drivers/mtd/st_smi.c | 260 ++++++++++++++++++++++++++++++++++++++------- include/linux/mtd/st_smi.h | 1 - 2 files changed, 223 insertions(+), 38 deletions(-) -- 1.8.0

3 14

[U-Boot] [PATCH] FSL SPI read fix.
by Dale Smith 14 Dec '15

14 Dec '15

The fsl spi engine is non functional when reading from a device. This patch fixes it. Note that none of the other spi interfaces parse through the datastream looking for 0x0b bytes. -Dale diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c index a1ebd33..737719b 100644 --- a/drivers/spi/fsl_espi.c +++ b/drivers/spi/fsl_espi.c @@ -291,17 +291,10 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *data_out, debug("***spi_xfer:...%08x readed\n", tmpdin); } } - if (data_in) { - memcpy(data_in, buffer + 2 * cmd_len, tran_len); - if (*buffer == 0x0b) { - data_in += tran_len; - data_len -= tran_len; - *(int *)buffer += tran_len; - } - } spi_cs_deactivate(slave); } - + if (data_in) + memcpy(data_in, buffer + rx_offset, len); free(buffer); return 0; }

6 8

[U-Boot] fatwrite problem
by Ruud Commandeur 12 Oct '15

12 Oct '15

Hi Everyone, Sinced a few days I noticed some problems writing the uimage to a FAT partition on my SD-card. At first I was afraid of some (physical) SD-card problems, but it appears to be related to he size of the uImage. With some further testing (and adding some debug printing), I could easily reproduce the problem: //4K file, result OK fatwrite mmc 0:1 42000000 testfile 1000 writing testfile set_cluster; clustnum: 5, startsect: 176, size 2048 set_cluster; clustnum: 6, startsect: 180, size 2048 set_cluster; clustnum: -6, startsect: 132, size 2048 4096 bytes written //512 bytes file, timeout error, file not written fatwrite mmc 0:1 42000000 testfile 200 writing testfile set_cluster; clustnum: 5, startsect: 176, size 0 MMC0: Bus busy timeout! MMC0: Bus busy timeout! MMC0: Bus busy timeout! MMC0: Bus busy timeout! MMC0: Bus busy timeout! MMC0: Bus busy timeout! set_cluster; clustnum: 5, startsect: 176, size 512 MMC0: Bus busy timeout! MMC0: Bus busy timeout! MMC0: Bus busy timeout! set_cluster; clustnum: -6, startsect: 132, size 2048 MMC0: Bus busy timeout! 512 bytes written It seems to be related to he problem reported here: http://www.mail-archive.com/u-boot@lists.denx.de/msg107212.html Once the size of the set_cluster call equals 0, the mmc command is incomplete and times out. In the earlier reported problem, a patch is mentioned, but not available for dowload here. Also in the latest versions of the git repository I could not find a patch for this problem. Can anyone tell me if there is a fix for this problem? Regards, Ruud

7 23

[U-Boot] Can't start Linux if U-Boot built with CONFIG_WATCHDOG
by Matthew Lear 26 Aug '15

26 Aug '15

Hello all, I've added watchdog support based on U-Boot (git) for the m68k coldfire mcf54455evb platform. I've fed the patch to the maintainer to help in development. However, I am unable to start my m68k w/MMU coldfire Linux kernel from U-Boot if U-Boot is built with CONFIG_WATCHDOG regardless if the watchdog_enable(), watchdog_reset() and watchdog_disable() functions touch hardware or not. I initially thought this was a problem with enabling the watchdog somehow (ie when Linux started, some hw configuration in the device was getting upset or corrupted etc resulting in the failure), but when I commented out the code from the above functions that actually accesses the hw (ie to enable, kick and disable the watchdog timer hw block), Linux is still unable to start. In fact, I don't think Linux actually gets started! That's the problem. If I rebuild the same U-Boot code base with CONFIG_WATCHDOG undefined, Linux can start just fine. As far as I can tell, there are no functional differences in building U-Boot with or without CONFIG_WATCHDOG enabled when the functions above are stubs and do absolutely nothing at all. If I build U-Boot with debug, what I see is as follows: ## Transferring control to Linux (at address 40020000) ... BIV ...and then the board is dead. I occasionally see something like the following from U-Boot: *** Unexpected exception *** Vector Number: 4 Format: 04 Fault Status: 0 PC: 4fdbfdc8 SR: 00002700 SP: 4fd72a64 D0: 00000004 D1: 000003f9 D2: 4fdb4202 D3: 004fa3da D4: 00000000 D5: 4fdc7c8c D6: 122c0034 D7: 4fd82f76 A0: 4033cb98 A1: 4025aa39 A2: 40020000 A3: 4fdbfdc8 A4: 00000000 A5: 4fdc5800 A6: 4fd72afb *** Please Reset Board! *** The 'BIV' is relevant because in my 2.6.29 kernel src arch/m68k/include/asm/bootinfo_mm.h, BOOTINFOV_MAGIC is defined to be 0x4249561A which is BIV^Z. This ascii text is located in the kernel image header info: >From arch/m68k/coldfire/head.S: .section ".text.head","ax" ENTRY(_stext) bras 1f /* Jump over bootinfo version numbers */ .long BOOTINFOV_MAGIC .long 0 And from U-Boot itself: -> md ${loadaddr} 40010000: 27051956 97342d7d 4a54afd5 00300000 '..V.4-}JT...0.. 40010010: 40020000 40020000 8a006fc1 050c0200 @...@.....o..... 40010020: 4c696e75 78204b65 726e656c 20496d61 Linux Kernel Ima 40010030: 67650000 00000000 00000000 00000000 ge.............. 40010040: 60084249 561a0000 00004ef9 40304000 `.BIV.....N.@0@. I suspect that the failure of starting Linux is caused by some mismatch in data structures (or versions there of) shared/copied between Linux and U-Boot and that this data has somehow changed when U-Boot is built with CONFIG_WATCHDOG #defined. However, I can't find any evidence of this in the U-Boot code base. The bras instruction above must be key and I suspect that this is the area causing the problem. Can anybody offer any advice / explanation of what exactly could be going on and why? I wouldn't have expected that defining CONFIG_WATCHDOG would change anything as fundamental as this. Apologies for the cross-post (U-Boot and m68k kernel dev) but I hope to get opinions/feedback/help from both communities. Any assistance very much appreciated indeed. Many thanks, -- Matt

2 1

[U-Boot] How do I use AM335x eth1 rather than eth0 ?
by Mark Jackson 17 Mar '15

17 Mar '15

We have a dual Ethernet board (based on the BeagelBone) but with both Ethernet ports connected. I'm wanting to use eth1 (rather than eth0), so in my board.c file, I changed:- static struct cpsw_slave_data cpsw_slaves[] = { { .slave_reg_ofs = 0x208, .sliver_reg_ofs = 0xd80, .phy_id = 0, }, { .slave_reg_ofs = 0x308, .sliver_reg_ofs = 0xdc0, .phy_id = 1, }, }; ... to ... static struct cpsw_slave_data cpsw_slaves[] = { { .slave_reg_ofs = 0x308, .sliver_reg_ofs = 0xdc0, .phy_id = 1, }, { .slave_reg_ofs = 0x208, .sliver_reg_ofs = 0xd80, .phy_id = 0, }, }; ... assuming that eth0 would now be ignored (as only 1 slave is configured). But (eg) dhcp still only responds on eth0 !?! What else do I have to change ? Cheers Mark J.

4 5

[U-Boot] [PATCH 1/3] sf: stmicro: Add support for N25Q32
by Michal Simek 02 Dec '14

02 Dec '14

From: Jagannadha Sutradharudu Teki <jagannadha.sutradharudu-teki(a)xilinx.com> Add support for Numonyx N25Q32 SPI flash. Signed-off-by: Jagannadha Sutradharudu Teki <jaganna(a)xilinx.com> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- drivers/mtd/spi/stmicro.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c index 32df827..09a3d68 100644 --- a/drivers/mtd/spi/stmicro.c +++ b/drivers/mtd/spi/stmicro.c @@ -93,6 +93,12 @@ static const struct stmicro_spi_flash_params stmicro_spi_flash_table[] = { .name = "M25P128", }, { + .id = 0xba16, + .pages_per_sector = 256, + .nr_sectors = 64, + .name = "N25Q32", + }, + { .id = 0xba17, .pages_per_sector = 256, .nr_sectors = 128, -- 1.7.0.4

3 4

[U-Boot] [PATCH 0/3] Serial Flash: call spi_flash_free more coherently
by Valentin Longchamp 15 Oct '14

15 Oct '14

Some board require spi_flash_free to be called after all the accesses, in order, for instance, to restore the pin multiplexing configuration in the case where the SPI pins are multiplexed. This patch series tries to enhance this. Patch 1 adds spi_flash_free calls to env_sf so that the SPI interface is always "cleaned up" after the env read/writes. Patch 2 adds a 'sf release' command that implicitly calls spi_flash_free and is thus the pendant of 'sf probe'. Patch 3 uses the 'sf command' for the km_arm board scripts. Valentin Longchamp (3): env_sf: generalize call to spi_flash_free after accesses cmd_sf: add 'release' command km_arm: call 'sf release' in the newenv and update scripts common/cmd_sf.c | 13 ++++++++++++- common/env_sf.c | 34 ++++++++++++++++------------------ include/configs/km/km_arm.h | 6 ++++-- 3 files changed, 32 insertions(+), 21 deletions(-) -- 1.8.0.1

2 6

[U-Boot] newbie questions regarding some config options.
by Christopher Harvey 22 Aug '14

22 Aug '14

As per the README file: Subscribe to u-boot mailing list; if (clueless) email("Hi, I am new to U-Boot, how do I get started?"); I'm messing around with uboot and QEMU (qemu-system-arm -M realview-pbx-a9 -kernel u-boot.bin), things are going pretty well in the sense that I'm not having too much trouble reading most of the code and creating a new board. I have some questions that I can't figure out by reading the code. What is the CONFIG_SYS_TEXT_BASE variable and how can I figure out what it should be? I randomly set it to 0x0...then tried to debug u-boot under qemu, but when stepping in the start.S file it was instantly clear that it wasn't really working because gdb said the code ran right though the _start: b reset instruction and qemu eventually crashed with the following output: qemu: fatal: Trying to execute code outside RAM or ROM at 0xfeb70cdc R00=00000000 R01=ffff0000 R02=00000000 R03=000108ac R04=ffff0000 R05=ffbedf70 R06=ffff0000 R07=00000010 R08=00001000 R09=ffff0000 R10=000108ac R11=00000000 R12=00001078 R13=ffbedf60 R14=00000960 R15=feb70cdc PSR=600001d3 -ZC- A svc32 Aborted Apart from that everything is pretty clear to me, but I want to make sure I'm getting this points right: Is the environment the set of variables that can be modified with setenv? How can I determine the "size of the environment"? Is it the number of characters including variable names? Also, is there anything special I need to do with gdb to get it to follow relocating code? thanks, -Chris

5 8

[U-Boot] [PATCH] OpenRD: relocate environment to 640kB
by Sascha Silbe 14 Aug '14

14 Aug '14

U-Boot has become slightly larger than where the environment sector was previously located. Saving the environment would brick the device. Relocate the environment to where it is with the stock (i.e. Marvell USP) U-Boot version. That should give plenty of room for U-Boot to grow, including local customisations. This obviously breaks compatibility with previous mainline versions of U-Boot. Users will need to back up the environment before an update and restore it afterwards, or manually copy it to the new address before the update. Signed-off-by: Sascha Silbe <t-uboot(a)infra-silbe.de> --- include/configs/openrd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/openrd.h b/include/configs/openrd.h index 53bafe1..ea7f9aa 100644 --- a/include/configs/openrd.h +++ b/include/configs/openrd.h @@ -90,8 +90,8 @@ * it has to be rounded to sector size */ #define CONFIG_ENV_SIZE 0x20000 /* 128k */ -#define CONFIG_ENV_ADDR 0x60000 -#define CONFIG_ENV_OFFSET 0x60000 /* env starts here */ +#define CONFIG_ENV_ADDR 0xa0000 +#define CONFIG_ENV_OFFSET 0xa0000 /* env starts here */ /* * Default environment variables -- 1.8.2.1

4 20