March 2014 - 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] [RFC PATCH 1/2] common: Add new clk command
by Michal Simek 05 Jan '16

05 Jan '16

Command provides just dump subcommand for showing clock frequencies in a soc. Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- README | 1 + common/Makefile | 1 + common/cmd_clk.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++ include/clk.h | 6 ++++++ include/config_cmd_all.h | 1 + 5 files changed, 60 insertions(+) create mode 100644 common/cmd_clk.c create mode 100644 include/clk.h diff --git a/README b/README index aea82be..0087649 100644 --- a/README +++ b/README @@ -887,6 +887,7 @@ The following options need to be configured: CONFIG_CMD_BSP * Board specific commands CONFIG_CMD_BOOTD bootd CONFIG_CMD_CACHE * icache, dcache + CONFIG_CMD_CLK * clock command support CONFIG_CMD_CONSOLE coninfo CONFIG_CMD_CRC32 * crc32 CONFIG_CMD_DATE * support for RTC, date/time... diff --git a/common/Makefile b/common/Makefile index d12cba5..a000e7d 100644 --- a/common/Makefile +++ b/common/Makefile @@ -59,6 +59,7 @@ obj-$(CONFIG_CMD_BOOTLDR) += cmd_bootldr.o obj-$(CONFIG_CMD_BOOTSTAGE) += cmd_bootstage.o obj-$(CONFIG_CMD_CACHE) += cmd_cache.o obj-$(CONFIG_CMD_CBFS) += cmd_cbfs.o +obj-$(CONFIG_CMD_CLK) += cmd_clk.o obj-$(CONFIG_CMD_CONSOLE) += cmd_console.o obj-$(CONFIG_CMD_CPLBINFO) += cmd_cplbinfo.o obj-$(CONFIG_DATAFLASH_MMC_SELECT) += cmd_dataflash_mmc_mux.o diff --git a/common/cmd_clk.c b/common/cmd_clk.c new file mode 100644 index 0000000..6d3d46a --- /dev/null +++ b/common/cmd_clk.c @@ -0,0 +1,51 @@ +/* + * Copyright (C) 2013 Xilinx, Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ +#include <common.h> +#include <command.h> +#include <clk.h> + +int __weak soc_clk_dump(void) +{ + puts("Not implemented\n"); + return 1; +} + +static int do_clk_dump(cmd_tbl_t *cmdtp, int flag, int argc, + char *const argv[]) +{ + return soc_clk_dump(); +} + +static cmd_tbl_t cmd_clk_sub[] = { + U_BOOT_CMD_MKENT(dump, 1, 1, do_clk_dump, "", ""), +}; + +static int do_clk(cmd_tbl_t *cmdtp, int flag, int argc, + char *const argv[]) +{ + cmd_tbl_t *c; + + if (argc < 2) + return CMD_RET_USAGE; + + /* Strip off leading 'clk' command argument */ + argc--; + argv++; + + c = find_cmd_tbl(argv[0], &cmd_clk_sub[0], ARRAY_SIZE(cmd_clk_sub)); + + if (c) + return c->cmd(cmdtp, flag, argc, argv); + else + return CMD_RET_USAGE; +} + +#ifdef CONFIG_SYS_LONGHELP +static char clk_help_text[] = + "dump - Print clock frequencies"; +#endif + +U_BOOT_CMD(clk, 2, 1, do_clk, "CLK sub-system", clk_help_text); diff --git a/include/clk.h b/include/clk.h new file mode 100644 index 0000000..df4570c --- /dev/null +++ b/include/clk.h @@ -0,0 +1,6 @@ +#ifndef _CLK_H_ +#define _CLK_H_ + +int soc_clk_dump(void); + +#endif /* _CLK_H_ */ diff --git a/include/config_cmd_all.h b/include/config_cmd_all.h index d847069..3e8983f 100644 --- a/include/config_cmd_all.h +++ b/include/config_cmd_all.h @@ -23,6 +23,7 @@ #define CONFIG_CMD_BSP /* Board Specific functions */ #define CONFIG_CMD_CACHE /* icache, dcache */ #define CONFIG_CMD_CDP /* Cisco Discovery Protocol */ +#define CONFIG_CMD_CLK /* Clock support */ #define CONFIG_CMD_CONSOLE /* coninfo */ #define CONFIG_CMD_DATE /* support for RTC, date/time...*/ #define CONFIG_CMD_DHCP /* DHCP Support */ -- 1.8.2.3

6 12

[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] usb start crashing on arndale
by armdev 19 Oct '15

19 Oct '15

Hi, We have recently started working on arndale and running u-boot head on it. Seems like it is crashing on our setup with a data abort on usb start. Can anyone please confirm and suggest a fix / solution U-Boot 2014.04-rc1-00486-geeb72e6 (Mar 11 2014 - 11:44:32) for ARNDALE CPU: Exynos5250@1000MHz Board: Arndale I2C: i2c_init: failed to init bus 0 for speed = 100000 ready DRAM: 2 GiB trace: copying 00084f98 bytes of early data from 50000000 to beff0000 trace: enabled WARNING: Caches not enabled MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 i2c_init: failed to init bus 0 for speed = 100000 In: serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 ARNDALE # usb start (Re)start USB... USB0: data abort pc : [<bef8524c>] lr : [<bef85298>] sp : beb5f9c0 ip : 00000003 fp : 00000000 r10: 00000000 r9 : beb62ecc r8 : befbcc80 r7 : befbcc84 r6 : 0000ffff r5 : 000000ff r4 : 00000001 r3 : 00000000 r2 : 00000001 r1 : 000000ff r0 : 0000ffff Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... Thanks and Regards Armdev@FTM Team

3 5

[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 v3 00/13] ARMv7: add PSCI support to u-boot
by Marc Zyngier 19 Feb '15

19 Feb '15

PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to turn some of the existing u-boot code into a separate section that can live in secure RAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. This patch series contains 4 parts: - the first four patches are just bug fixes - the next two refactor the HYP/non-secure code to allow relocation in secure memory - the next four contain the generic PSCI code and DT infrastructure - the last three implement the CPU_ON method of the Allwinner A20 (aka sun7i). I realize the A20 u-boot code is not upstream yet (BTW is anyone actively working on that?), but hopefully that should give a good idea of how things are structured so far. The patches are against the mainline u-boot tree as of today, merged with the sunxi u-boot tree of the day and the first 10 patches will directly apply to mainline u-boot. As for using this code, it goes like this: sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x60000000 sun7i-a20-cubietruck.dtb 2270120 bytes read in 117 ms (18.5 MiB/s) 9138 bytes read in 3 ms (2.9 MiB/s) sun7i# fdt addr 0x60000000 ; fdt resize ; fdt set ethernet0 mac-address "[5a fe b0 07 b0 07]" sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/backup/a20_root,tcp sun7i# bootz 0x40008000 - 0x60000000 The kernel now boots in HYP mode, finds its secondary CPU without any SMP code present in the kernel, and runs KVM out of the box. I've been told the Xen/ARM guys managed to do the same fairly easily. This code has also been tested on a VExpress TC2, running KVM with all 5 CPUs, in order to make sure there was no obvious regression. I'm wildly cross-posting this patch series, including to lists I'm not subscribed to. Please keep me on Cc for any comment you may have. The code is also available at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci Cheers, M. Ma Haijun (1): ARM: convert arch_fixup_memory_node to a generic FDT fixup function Marc Zyngier (12): ARM: HYP/non-sec: move switch to non-sec to the last boot phase ARM: HYP/non-sec: add a barrier after setting SCR.NS==1 ARM: non-sec: reset CNTVOFF to zero ARM: add missing HYP mode constant ARM: HYP/non-sec: add separate section for secure code ARM: HYP/non-sec: allow relocation to secure RAM ARM: HYP/non-sec: add generic ARMv7 PSCI code ARM: HYP/non-sec: add the option for a second-stage monitor ARM: HYP/non-sec/PSCI: emit DT nodes sunxi: fix SRAM_B/SRAM_D memory map sunxi: HYP/non-sec: add sun7i PSCI backend sunxi: HYP/non-sec: configure CNTFRQ on all CPUs arch/arm/config.mk | 2 +- arch/arm/cpu/armv7/Makefile | 5 + arch/arm/cpu/armv7/nonsec_virt.S | 168 +++++++++++++++++--------------- arch/arm/cpu/armv7/psci.S | 105 ++++++++++++++++++++ arch/arm/cpu/armv7/sunxi/Makefile | 3 + arch/arm/cpu/armv7/sunxi/psci.S | 162 ++++++++++++++++++++++++++++++ arch/arm/cpu/armv7/virt-dt.c | 100 +++++++++++++++++++ arch/arm/cpu/armv7/virt-v7.c | 59 ++++------- arch/arm/cpu/u-boot.lds | 30 ++++++ arch/arm/include/asm/arch-sunxi/cpu.h | 4 +- arch/arm/include/asm/armv7.h | 11 ++- arch/arm/include/asm/proc-armv/ptrace.h | 2 + arch/arm/include/asm/psci.h | 35 +++++++ arch/arm/include/asm/secure.h | 26 +++++ arch/arm/lib/bootm-fdt.c | 13 ++- arch/arm/lib/bootm.c | 27 +++-- arch/arm/lib/interrupts.c | 2 +- arch/arm/lib/sections.c | 2 + common/image-fdt.c | 7 +- include/common.h | 6 +- include/configs/sun7i.h | 7 ++ 21 files changed, 627 insertions(+), 149 deletions(-) create mode 100644 arch/arm/cpu/armv7/psci.S create mode 100644 arch/arm/cpu/armv7/sunxi/psci.S create mode 100644 arch/arm/cpu/armv7/virt-dt.c create mode 100644 arch/arm/include/asm/psci.h create mode 100644 arch/arm/include/asm/secure.h -- 1.8.5.1

7 35

[U-Boot] [PATCH] lcd: Add support for CONFIG_LCD_NOSTDOUT
by Hannes Petermaier 04 Feb '15

04 Feb '15

- Adds support for CONFIG_LCD_NOSTDOUT, which prevents switching stdout to the LCD screen, usefull in case when only lcd_puts(...), lcd_printf(...) is used for displaying status informations. Signed-off-by: Hannes Petermaier <oe5hpm(a)oevsv.at> --- README | 7 +++++++ common/lcd.c | 9 ++++++--- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/README b/README index 216f0c7..4792068 100644 --- a/README +++ b/README @@ -1702,6 +1702,13 @@ CBFS (Coreboot Filesystem) support Normally display is black on white background; define CONFIG_SYS_WHITE_ON_BLACK to get it inverted. + CONFIG_LCD_NOSTDOUT + Normally 'stdout' is redirected to LCD-screen after + initialization. Define CONFIG_LCD_NOSTDOUT to avoid this. + Useful in case where only lcd_puts(...), lcd_printf(...) + functions of the framework are used and 'normal' u-boot + console remains e.g. on serial-line. + CONFIG_LCD_ALIGNMENT Normally the LCD is page-aligned (tyically 4KB). If this is diff --git a/common/lcd.c b/common/lcd.c index aa81522..eac1b87 100644 --- a/common/lcd.c +++ b/common/lcd.c @@ -400,12 +400,12 @@ __weak int lcd_get_size(int *line_length) int drv_lcd_init(void) { - struct stdio_dev lcddev; - int rc; - lcd_base = (void *) gd->fb_base; lcd_init(lcd_base); /* LCD initialization */ +#ifndef CONFIG_LCD_NOSTDOUT + struct stdio_dev lcddev; + int rc; /* Device initialization */ memset(&lcddev, 0, sizeof(lcddev)); @@ -419,6 +419,9 @@ int drv_lcd_init(void) rc = stdio_register(&lcddev); return (rc == 0) ? 1 : rc; +#else + return 0; +#endif } /*----------------------------------------------------------------------*/ -- 1.7.9.5

5 8