August 2017 - U-Boot

[U-Boot] [PATCH] ARM: uniphier: fix DSPLL init code for LD20 SoC
by Masahiro Yamada 29 Aug '17

29 Aug '17

From: Dai Okamura <okamura.dai(a)socionext.com> Signed-off-by: Dai Okamura <okamura.dai(a)socionext.com> Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> --- arch/arm/mach-uniphier/clk/pll-base-ld20.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-uniphier/clk/pll-base-ld20.c b/arch/arm/mach-uniphier/clk/pll-base-ld20.c index 697eb7aabf01..3aa42f8bfdcd 100644 --- a/arch/arm/mach-uniphier/clk/pll-base-ld20.c +++ b/arch/arm/mach-uniphier/clk/pll-base-ld20.c @@ -88,7 +88,7 @@ int uniphier_ld20_sscpll_set_regi(unsigned long reg_base, unsigned regi) if (!base) return -ENOMEM; - tmp = readl(base + 8); /* SSCPLLCTRL */ + tmp = readl(base + 8); /* SSCPLLCTRL3 */ tmp &= ~SC_PLLCTRL3_REGI_MASK; tmp |= regi << SC_PLLCTRL3_REGI_SHIFT; writel(tmp, base + 8); @@ -133,9 +133,9 @@ int uniphier_ld20_dspll_init(unsigned long reg_base) if (!base) return -ENOMEM; - tmp = readl(base + 8); /* DSPLLCTRL2 */ + tmp = readl(base + 4); /* DSPLLCTRL2 */ tmp |= SC_DSPLLCTRL2_K_LD; - writel(tmp, base + 8); + writel(tmp, base + 4); iounmap(base); -- 2.7.4

1 1

[U-Boot] [PATCH 1/1] efi_loader: bootefi hello should use loadaddr
by Heinrich Schuchardt 29 Aug '17

29 Aug '17

Command 'bootefi hello' currently uses CONFIG_SYS_LOAD_ADDR as loading address. qemu machines have by default 128 MiB RAM. CONFIG_SYS_LOAD_ADDR for x86 is 0x20000000 (512 MiB). This causes 'bootefi hello' to fail. We should use the environment variable loadaddr if available. It defaults to 0x1000000 (16 MiB) on qemu_x86. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- cmd/bootefi.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 47771f87cc..a3768158a2 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -300,7 +300,11 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (!strcmp(argv[1], "hello")) { ulong size = __efi_hello_world_end - __efi_hello_world_begin; - addr = CONFIG_SYS_LOAD_ADDR; + saddr = env_get("loadaddr"); + if (saddr) + addr = simple_strtoul(saddr, NULL, 16); + else + addr = CONFIG_SYS_LOAD_ADDR; memcpy((char *)addr, __efi_hello_world_begin, size); } else #endif -- 2.11.0

2 3

[U-Boot] [RFC] ARM: davinci: da850: Enable Caches for DA850-EVM
by Adam Ford 29 Aug '17

29 Aug '17

What starting up the DA850-EVM, U-Boot generates a warning: WARNING: Caches not enabled Looking at other arm926 processors, this is an attempt to enable the caches and remove the warning. I am notsure who the proper TI or ARM people are to review this. Signed-off-by: Adam Ford <aford173(a)gmail.com> --- board/davinci/da8xxevm/da850evm.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/board/davinci/da8xxevm/da850evm.c b/board/davinci/da8xxevm/da850evm.c index c2d2e8e..33a923c 100644 --- a/board/davinci/da8xxevm/da850evm.c +++ b/board/davinci/da8xxevm/da850evm.c @@ -491,3 +491,29 @@ int board_eth_init(bd_t *bis) return 0; } #endif /* CONFIG_DRIVER_TI_EMAC */ + +#ifndef CONFIG_SYS_ICACHE_OFF +/* Invalidate entire I-cache and branch predictor array */ +void invalidate_icache_all(void) +{ + unsigned long i = 0; + + asm ("mcr p15, 0, %0, c7, c5, 0" : : "r" (i)); +} +#else +void invalidate_icache_all(void) +{ +} +#endif + +#ifndef CONFIG_SYS_DCACHE_OFF +void enable_caches(void) +{ + /* Enable D-cache. I-cache is already enabled in start.S */ + dcache_enable(); +} +#else +void enable_caches(void) +{ +} +#endif /* CONFIG_SYS_DCACHE_OFF */ -- 2.7.4

3 4

[U-Boot] ACPI tables for Edison: advice needed
by Andy Shevchenko 29 Aug '17

29 Aug '17

Hi! I have a preliminary working ACPI tables for Intel Edison (to replace ugly SFI provided by firmware). What I would like to ask is how better from your point of view to proceed. I have apparently not all devices covered in the tables, though I have almost stable code which brings ACPI support to Edison. I see few options here: 0. Do nothing :-) 1. Apply ACPI code, but leave no tables applied yet. 2. Apply both and amend whenever problem occurs. 3. Postpone until kernel will be ready for that (*) 4. ...other option...? *) LInux kernel (vanilla) is not ready for this change. It means in all above cases there will be neither new config file (like edison_acpi_defconfig) nor modification to the existing one (of course!). The stuff is highly experimental now. -- With Best Regards, Andy Shevchenko

3 5

[U-Boot] [PATCH] board/ls2080ardb: Update board env based on SoC
by Priyanka Jain 29 Aug '17

29 Aug '17

As per current implemenetation, default value of board env is based on board filename i.e ls2080ardb. With distro support changes, this env is used to decide upon kernel dtb which is different for other SoCs (ls2088a, ls2081a) combination supported with this board. Add support to modify board env based on SoC type Signed-off-by: Priyanka Jain <priyanka.jain(a)nxp.com> --- board/freescale/ls2080ardb/ls2080ardb.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/board/freescale/ls2080ardb/ls2080ardb.c b/board/freescale/ls2080ardb/ls2080ardb.c index d7122b3..ca9c047 100644 --- a/board/freescale/ls2080ardb/ls2080ardb.c +++ b/board/freescale/ls2080ardb/ls2080ardb.c @@ -247,6 +247,8 @@ int misc_init_r(void) char *env_hwconfig; u32 __iomem *dcfg_ccsr = (u32 __iomem *)DCFG_BASE; u32 val; + struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR); + u32 svr = gur_in32(&gur->svr); val = in_le32(dcfg_ccsr + DCFG_RCWSR13 / 4); @@ -274,6 +276,16 @@ int misc_init_r(void) if (adjust_vdd(0)) printf("Warning: Adjusting core voltage failed.\n"); + /* + * Default value of board env is based on filename which is + * ls2080ardb. Modify board env for other supported SoCs + */ + if ((SVR_SOC_VER(svr) == SVR_LS2088A) || + (SVR_SOC_VER(svr) == SVR_LS2048A)) + setenv("board", "ls2088ardb"); + else if ((SVR_SOC_VER(svr) == SVR_LS2081A) || + (SVR_SOC_VER(svr) == SVR_LS2041A)) + setenv("board", "ls2081ardb"); return 0; } -- 1.7.4.1

2 4

[U-Boot] usb-otg mode
by michael＠siptele.com 29 Aug '17

29 Aug '17

Hello u-booters! I have bought a TV box (with Android). I want to install Linux on this box. Inserting sd card with Linux image did nothing. As I did not want to break the box, I spend several days compiling u-boot with usbtty to get some insight to the TV box. Starting the TV box with my compiled spl.bin "sunxi-fel uboot u-boot-sunxi-with-spl.bin" did not show me any usbtty on my host device and I couldn't see a thing. Then, I discovered that I can open the TV box without breaking it. I welded USB UART to the console pins and bingo! I get console messages and can intercut with the u-boot console. Apparently, booting the box with "sunxi-fel uboot u-boot-sunxi-with-spl.bin" Starts the box in normal usb mode. (not otg). So, the usb detach from the host machine And the console over usbtty does not reach it. Can we program the u-boot to start the USB in usb-otg mode? Thank you, Michael

1 0

[U-Boot] [PATCH v1 1/2] imx: fix USB boot mode detection for i.MX 6UL and 6ULL
by Stefan Agner 29 Aug '17

29 Aug '17

From: Stefan Agner <stefan.agner(a)toradex.com> Add the reserved boot mode used in the bmode command for i.MX 6UL and 6ULL as introduced in commit 3fd9579085fa ("imx: mx6ull: fix USB bmode for i.MX 6UL and 6ULL"). Also replace BMODE_UART with BMODE_RESERVED, which is more appropriate. Commit 96aac843b68d ("imx: Use IMX6_BMODE_* macros instead of numericals") added macros for boot modes, in the process the reserved boot mode got named BMODE_UART. We use the reserved boot mode in the bmode command to let the boot ROM enter serial downloader recovery mode. But this is only a side effect, the actual boot mode is reserved... Signed-off-by: Stefan Agner <stefan.agner(a)toradex.com> --- Afaik there is no board yet using SPL on 6UL/ULL... arch/arm/include/asm/mach-imx/sys_proto.h | 7 ++++++- arch/arm/mach-imx/spl.c | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h b/arch/arm/include/asm/mach-imx/sys_proto.h index 046df6291a..d94c095118 100644 --- a/arch/arm/include/asm/mach-imx/sys_proto.h +++ b/arch/arm/include/asm/mach-imx/sys_proto.h @@ -69,8 +69,13 @@ enum imx6_bmode_emi { enum imx6_bmode { IMX6_BMODE_EMI, - IMX6_BMODE_UART, +#if defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL) + IMX6_BMODE_QSPI, + IMX6_BMODE_RESERVED, +#else + IMX6_BMODE_RESERVED, IMX6_BMODE_SATA, +#endif IMX6_BMODE_SERIAL_ROM, IMX6_BMODE_SD, IMX6_BMODE_ESD, diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index 75698c48ea..836b334fa9 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -42,7 +42,7 @@ u32 spl_boot_device(void) break; } /* Reserved: Used to force Serial Downloader */ - case IMX6_BMODE_UART: + case IMX6_BMODE_RESERVED: return BOOT_DEVICE_UART; /* SATA: See 8.5.4, Table 8-20 */ case IMX6_BMODE_SATA: -- 2.14.1

4 11

[U-Boot] Patman avoiding bounces
by Chris Packham 29 Aug '17

29 Aug '17

Hi, I recently sent a few patches using patman and ran into two problems. The first is a set of undeliverable addresses. This isn't a big problem, more of an annoyance but it also means that anyone replying to my patches also gets the same set of bounces. Would adding a blacklist feature be a good idea? Should such a list be stored in-tree? It might also be worth integrating with git's mailmap to handle those who are still active under a new address, that's probably something that would be useful in-tree for other uses. The other issue is the number of addresses hitting the mailing list limit requiring moderator approval. I'm not sure what the exact limit is but presumably it's something in the mailman config. It would be great if patman had some (configurable) knowledge of this limit an only added Ccs up to this. I'm less certain of a heuristic for which addresses to drop, obviously the known inactive ones mentioned above are easy to drop. After that I'm not sure maybe base it on number of commits to the affected files (i think get_maintainer.pl already gathers this info). Thoughts? If i get some time I'll try and make a proof of concept for the blacklist. Thanks, Chris

4 5

[U-Boot] [PATCH] icorem6: Fix to find MMC devices
by Jagan Teki 29 Aug '17

29 Aug '17

From: Jagan Teki <jagan(a)amarulasolutions.com> U-Boot proper is using DM_MMC so, enable CONFIG_BLK otherwise find_mmc_device failed to detect MMC device. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- configs/imx6qdl_icore_mmc_defconfig | 1 - configs/imx6qdl_icore_rqs_defconfig | 1 - 2 files changed, 2 deletions(-) diff --git a/configs/imx6qdl_icore_mmc_defconfig b/configs/imx6qdl_icore_mmc_defconfig index ec39d09..9d61c48 100644 --- a/configs/imx6qdl_icore_mmc_defconfig +++ b/configs/imx6qdl_icore_mmc_defconfig @@ -36,7 +36,6 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_LIST="imx6q-icore imx6dl-icore" -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_PHYLIB=y CONFIG_PHY_SMSC=y diff --git a/configs/imx6qdl_icore_rqs_defconfig b/configs/imx6qdl_icore_rqs_defconfig index ba3ac1b..319a88d 100644 --- a/configs/imx6qdl_icore_rqs_defconfig +++ b/configs/imx6qdl_icore_rqs_defconfig @@ -34,7 +34,6 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_LIST="imx6q-icore-rqs imx6dl-icore-rqs" -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y -- 2.7.4

2 3

[U-Boot] [PATCH] imx6: don't include unneeded boot_mode array in SPL
by Anatolij Gustschin 29 Aug '17

29 Aug '17

The soc_boot_modes array is only used by bmode command and not needed in SPL. Don't include it into SPL. Signed-off-by: Anatolij Gustschin <agust(a)denx.de> --- arch/arm/mach-imx/mx6/soc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c index 9ede1f5..13ca286 100644 --- a/arch/arm/mach-imx/mx6/soc.c +++ b/arch/arm/mach-imx/mx6/soc.c @@ -551,6 +551,7 @@ void imx_get_mac_from_fuse(int dev_id, unsigned char *mac) } #endif +#ifndef CONFIG_SPL_BUILD /* * cfg_val will be used for * Boot_cfg4[7:0]:Boot_cfg3[7:0]:Boot_cfg2[7:0]:Boot_cfg1[7:0] @@ -577,6 +578,7 @@ const struct boot_mode soc_boot_modes[] = { {"esdhc4", MAKE_CFGVAL(0x40, 0x38, 0x00, 0x00)}, {NULL, 0}, }; +#endif void reset_misc(void) { -- 2.7.4

2 2