August 2014 - U-Boot

[U-Boot] Recommended SH toolchain
by Vasili Galka 08 May '15

08 May '15

Hi Nobuhiro, I'm trying to verify the correct build of all SH boards in U-Boot. What is the recommended toolchain to use? I tried the one from kernel.org [1], but it does not work for all the boards, I get build errors like this one: Building rsk7203 board... sh4-linux-gcc: error: command line option '-m3e' is not supported by this configuration sh4-linux-gcc: error: command line option '-m3e' is not supported by this configuration make[3]: *** [include/autoconf.mk] Error 1 make[3]: *** [include/autoconf.mk.dep] Error 1 make[2]: *** [silentoldconfig] Error 1 make: *** [sub-make] Error 2 sh4-linux-size: '/home/lab/dev/u-boot/out/all_sh/u-boot': No such file sh4-linux-gcc: error: command line option '-m3e' is not supported by this configuration sh4-linux-gcc: error: command line option '-m3e' is not supported by this configuration make[3]: *** [include/autoconf.mk] Error 1 make[3]: *** Waiting for unfinished jobs.... make[3]: *** [include/autoconf.mk.dep] Error 1 'make -f /home/lab/dev/u-boot/scripts/Makefile.autoconf obj=include include/autoconf.mk include/autoconf.mk.dep' Failed make[2]: *** [silentoldconfig] Error 1 make[1]: *** No rule to make target `include/config/auto.conf', needed by `include/config/uboot.release'. Stop. make: *** [sub-make] Error 2 I'll appreciate your help. [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/ Regards, Vasili

4 5

[U-Boot] fatload from eMMC general purpose partition
by Andreas Naumann 24 Apr '15

24 Apr '15

Hi, using an eMMC I want to load uImage and dtb from a general purpose partition (since these can be configured as pSLC independent of the user data area). From the kernel I can format and access the GP-partition, in my case mkfs.vfat. However, U-Boots fatload/extload on the GP-partition do not work or maybe I just give the wrong parameters. Is this implemented at all, any hints? Regards Andreas

3 3

[U-Boot] [PATCH 1/3] sf: ops: Add spi_flash_copy_mmap function
by Tom Rini 22 Apr '15

22 Apr '15

When doing a memory mapped copy we may have DMA available and thus need to have this copy abstracted so that the driver can do it, rather than a simple memcpy. Cc: Jagannadha Sutradharudu Teki <jaganna(a)xilinx.com> Signed-off-by: Tom Rini <trini(a)ti.com> --- drivers/mtd/spi/sf_ops.c | 8 +++++++- include/spi.h | 3 +++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c index ef91b92..2c7b890 100644 --- a/drivers/mtd/spi/sf_ops.c +++ b/drivers/mtd/spi/sf_ops.c @@ -14,6 +14,7 @@ #include <spi.h> #include <spi_flash.h> #include <watchdog.h> +#include <linux/compiler.h> #include "sf_internal.h" @@ -359,6 +360,11 @@ int spi_flash_read_common(struct spi_flash *flash, const u8 *cmd, return ret; } +void __weak spi_flash_copy_mmap(void *data, void *offset, size_t len) +{ + memcpy(data, offset, len); +} + int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset, size_t len, void *data) { @@ -375,7 +381,7 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset, return ret; } spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MMAP); - memcpy(data, flash->memory_map + offset, len); + spi_flash_copy_mmap(data, flash->memory_map + offset, len); spi_xfer(flash->spi, 0, NULL, NULL, SPI_XFER_MMAP_END); spi_release_bus(flash->spi); return 0; diff --git a/include/spi.h b/include/spi.h index ffd6647..eecb9ad 100644 --- a/include/spi.h +++ b/include/spi.h @@ -220,6 +220,9 @@ int spi_set_wordlen(struct spi_slave *slave, unsigned int wordlen); int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout, void *din, unsigned long flags); +/* Copy memory mapped data */ +void spi_flash_copy_mmap(void *data, void *offset, size_t len); + /** * Determine if a SPI chipselect is valid. * This function is provided by the board if the low-level SPI driver -- 1.7.9.5

3 7

[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

[U-Boot] [PATCH] net: phy: micrel: add support for KSZ8895 switch in SMI mode
by Philippe De Muyter 30 Jan '15

30 Jan '15

This patch adds a phy driver for the Micrel KSZ8895 switch. As the SoC MAC is directly connected to the switch MAC the link to the switch is always up. But the KSZ8895 switch can be hardwired in three configuration modes : - not configurable with eventually an eeprom-stored configuration - configurable by the mdio/mdc connection (SMI protocol) - configurable by a SPI connection. In not configurable mode, the switch starts automatically, but in the other modes, it must be started programmatically, by writing 1 in configuration register 1. We only support the not configurable and mdio/mdc (aka SMI) modes here. Signed-off-by: Philippe De Muyter <phdm(a)macqel.be> Cc: Christian Gmeiner <christian.gmeiner(a)gmail.com> --- drivers/net/phy/micrel.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 58 insertions(+), 0 deletions(-) diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c index 5d7e3be..8fbd7d5 100644 --- a/drivers/net/phy/micrel.c +++ b/drivers/net/phy/micrel.c @@ -22,6 +22,63 @@ static struct phy_driver KSZ804_driver = { .shutdown = &genphy_shutdown, }; +/** + * KSZ8895 + */ + +static unsigned short smireg_to_phy(unsigned short reg) +{ + return ((reg & 0xc0) >> 3) + 0x06 + ((reg & 0x20) >> 5); +} + +static unsigned short smireg_to_reg(unsigned short reg) +{ + return reg & 0x1F; +} + +static void ksz8895_write_smireg(struct phy_device *phydev, int smireg, int val) +{ + phydev->bus->write(phydev->bus, smireg_to_phy(smireg), MDIO_DEVAD_NONE, + smireg_to_reg(smireg), val); +} + +#if 0 +static int ksz8895_read_smireg(struct phy_device *phydev, int smireg) +{ + return phydev->bus->read(phydev->bus, smireg_to_phy(smireg), + MDIO_DEVAD_NONE, smireg_to_reg(smireg)); +} +#endif + +int ksz8895_config(struct phy_device *phydev) +{ + /* we are connected directly to the switch without + * dedicated PHY. SCONF1 == 001 */ + phydev->link = 1; + phydev->duplex = DUPLEX_FULL; + phydev->speed = SPEED_100; + + /* Force the switch to start */ + ksz8895_write_smireg(phydev, 1, 1); + + return 0; +} + +static int ksz8895_startup(struct phy_device *phydev) +{ + return 0; +} + +static struct phy_driver ksz8895_driver = { + .name = "Micrel KSZ8895/KSZ8864", + .uid = 0x221450, + .mask = 0xffffe1, + .features = PHY_BASIC_FEATURES, + .config = &ksz8895_config, + .startup = &ksz8895_startup, + .shutdown = &genphy_shutdown, +}; + #ifndef CONFIG_PHY_MICREL_KSZ9021 /* * I can't believe Micrel used the exact same part number @@ -222,5 +279,6 @@ int phy_micrel_init(void) phy_register(&KS8721_driver); #endif phy_register(&ksz9031_driver); + phy_register(&ksz8895_driver); return 0; } -- 1.7.5.3

2 1

[U-Boot] [PATCH v2 0/6] Add target board MS7206SE
by Yoshinori Sato 30 Jan '15

30 Jan '15

Hi. I updated MS7206SE support. Please review and comment Changes v2 cleanup for checkpatch.pl Yoshinori Sato (6): Add MS7206SE support Add MS7206SE ethernet support Add SH7206 support SH2A cache support Module enabler cleanup Various update arch/sh/config.mk | 3 + arch/sh/cpu/sh2/Makefile | 6 ++ arch/sh/cpu/sh2/cache-sh2a.c | 145 +++++++++++++++++++++++++++++++++ arch/sh/cpu/sh2/config.mk | 4 +- arch/sh/cpu/sh2/cpu.c | 58 +++---------- arch/sh/cpu/sh2/nocache.c | 36 ++++++++ arch/sh/cpu/sh2/start.S | 2 +- arch/sh/include/asm/cpu_sh2.h | 15 ++-- arch/sh/include/asm/cpu_sh2a.h | 16 ++++ arch/sh/include/asm/cpu_sh7206.h | 75 +++++++++++++++++ board/renesas/ms7206se/Makefile | 10 +++ board/renesas/ms7206se/lowlevel_init.S | 124 ++++++++++++++++++++++++++++ board/renesas/ms7206se/ms7206se.c | 43 ++++++++++ boards.cfg | 1 + drivers/net/smc91111.h | 31 ++++++- include/configs/ms7206se.h | 95 +++++++++++++++++++++ 16 files changed, 605 insertions(+), 59 deletions(-) create mode 100644 arch/sh/cpu/sh2/cache-sh2a.c create mode 100644 arch/sh/cpu/sh2/nocache.c create mode 100644 arch/sh/include/asm/cpu_sh2a.h create mode 100644 arch/sh/include/asm/cpu_sh7206.h create mode 100644 board/renesas/ms7206se/Makefile create mode 100644 board/renesas/ms7206se/lowlevel_init.S create mode 100644 board/renesas/ms7206se/ms7206se.c create mode 100644 include/configs/ms7206se.h -- 1.8.5.3

2 7

[U-Boot] [PATCH 1/2] net: tsec: Fix NULL access in case init_phy() fails
by Claudiu Manoil 30 Jan '15

30 Jan '15

If the PHY is not recognized don't access phydev (NULL) and return 0 to signal failure. Signed-off-by: Claudiu Manoil <claudiu.manoil(a)freescale.com> --- drivers/net/tsec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index e9138f0..65fb2b0 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -590,6 +590,8 @@ static int init_phy(struct eth_device *dev) tsec_configure_serdes(priv); phydev = phy_connect(priv->bus, priv->phyaddr, dev, priv->interface); + if (!phydev) + return 0; phydev->supported &= supported; phydev->advertising = phydev->supported; -- 1.7.11.7

2 2

[U-Boot] net: tsec: Pending patches
by Claudiu Manoil 30 Jan '15

30 Jan '15

Hello, Would you please consider applying these two "net" tree patches? http://patchwork.ozlabs.org/patch/299620/ (net: Merge asm/fsl_enet.h into fsl_mdio.h) http://patchwork.ozlabs.org/patch/299447/ (net: tsec: Fix NULL access in case init_phy() fails) Thanks, Claudiu

2 1