July 2018 - U-Boot

[U-Boot] [PATCH][v2] armv8: ls1088a: change dpl load command from apply to lazyapply
by Jagdish Gediya 27 Jul '18

27 Jul '18

use "fsl_mc lazyapply dpl addr" instead of "fsl_mc apply dpl addr" change dpl load addr to 0x80001000 from 0x80200000 because dpl gets corrupted at 0x80200000 during bootm command excecution. Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com> --- Changes for v2: - Change dpl load address from 0x80000000 to 0x80001000 as boot.scr is loaded at 0x80000000. include/configs/ls1088a_common.h | 10 +++++----- include/configs/ls1088ardb.h | 12 ++++++------ 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h index ea48421..68da0b8 100644 --- a/include/configs/ls1088a_common.h +++ b/include/configs/ls1088a_common.h @@ -196,17 +196,17 @@ unsigned long long get_qixis_addr(void); #if defined(CONFIG_QSPI_BOOT) #define CONFIG_BOOTCOMMAND "sf probe 0:0;" \ - "sf read 0x80200000 0xd00000 0x100000;"\ - " fsl_mc apply dpl 0x80200000 &&" \ + "sf read 0x80001000 0xd00000 0x100000;"\ + " fsl_mc lazyapply dpl 0x80001000 &&" \ " sf read $kernel_load $kernel_start" \ " $kernel_size && bootm $kernel_load" #elif defined(CONFIG_SD_BOOT) -#define CONFIG_BOOTCOMMAND "mmcinfo;mmc read 0x80200000 0x6800 0x800;"\ - " fsl_mc apply dpl 0x80200000 &&" \ +#define CONFIG_BOOTCOMMAND "mmcinfo;mmc read 0x80001000 0x6800 0x800;"\ + " fsl_mc lazyapply dpl 0x80001000 &&" \ " mmc read $kernel_load $kernel_start" \ " $kernel_size && bootm $kernel_load" #else /* NOR BOOT*/ -#define CONFIG_BOOTCOMMAND "fsl_mc apply dpl 0x580d00000 &&" \ +#define CONFIG_BOOTCOMMAND "fsl_mc lazyapply dpl 0x580d00000 &&" \ " cp.b $kernel_start $kernel_load" \ " $kernel_size && bootm $kernel_load" #endif diff --git a/include/configs/ls1088ardb.h b/include/configs/ls1088ardb.h index 4459994..d0ab2fa 100644 --- a/include/configs/ls1088ardb.h +++ b/include/configs/ls1088ardb.h @@ -381,8 +381,8 @@ "installer=load mmc 0:2 $load_addr " \ "/flex_installer_arm64.itb; " \ "env exists mcinitcmd && run mcinitcmd && " \ - "mmc read 0x80200000 0x6800 0x800;" \ - "fsl_mc apply dpl 0x80200000;" \ + "mmc read 0x80001000 0x6800 0x800;" \ + "fsl_mc lazyapply dpl 0x80001000;" \ "bootm $load_addr#ls1088ardb\0" \ "qspi_bootcmd=echo Trying load from qspi..;" \ "sf probe && sf read $load_addr " \ @@ -402,11 +402,11 @@ #if defined(CONFIG_QSPI_BOOT) /* Try to boot an on-QSPI kernel first, then do normal distro boot */ #define CONFIG_BOOTCOMMAND \ - "sf read 0x80200000 0xd00000 0x100000;" \ + "sf read 0x80001000 0xd00000 0x100000;" \ "env exists mcinitcmd && env exists secureboot " \ " && sf read 0x80780000 0x780000 0x100000 " \ "&& esbc_validate 0x80780000;env exists mcinitcmd " \ - "&& fsl_mc apply dpl 0x80200000;" \ + "&& fsl_mc lazyapply dpl 0x80001000;" \ "run distro_bootcmd;run qspi_bootcmd;" \ "env exists secureboot && esbc_halt;" @@ -414,11 +414,11 @@ #elif defined(CONFIG_SD_BOOT) #define CONFIG_BOOTCOMMAND \ "env exists mcinitcmd && mmcinfo; " \ - "mmc read 0x80200000 0x6800 0x800; " \ + "mmc read 0x80001000 0x6800 0x800; " \ "env exists mcinitcmd && env exists secureboot " \ " && mmc read 0x80780000 0x3800 0x10 " \ "&& esbc_validate 0x80780000;env exists mcinitcmd " \ - "&& fsl_mc apply dpl 0x80200000;" \ + "&& fsl_mc lazyapply dpl 0x80001000;" \ "run distro_bootcmd;run sd_bootcmd;" \ "env exists secureboot && esbc_halt;" #endif -- 2.7.4

2 1

[U-Boot] [PATCH 1/3] dm: pci: Assign correct driver data when binding a driver
by Bin Meng 27 Jul '18

27 Jul '18

The correct driver data comes from the matching 'id' instead of 'find_id' in pci_find_and_bind_driver(). Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- drivers/pci/pci-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c index 46e9c71..7e16ad1 100644 --- a/drivers/pci/pci-uclass.c +++ b/drivers/pci/pci-uclass.c @@ -690,7 +690,7 @@ static int pci_find_and_bind_driver(struct udevice *parent, if (ret) goto error; debug("%s: Match found: %s\n", __func__, drv->name); - dev->driver_data = find_id->driver_data; + dev->driver_data = id->driver_data; *devp = dev; return 0; } -- 2.7.4

2 7

[U-Boot] [PATCH v3 0/5] dm: led: remove auto probe in binding function
by Patrick Delaunay 27 Jul '18

27 Jul '18

Hi, The commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7 introduce auto probe of LED in binding function but that cause issue on my board. This first patch of this patchset activateis the LED on my board to explain the issue, the second patch revert this commit and the third one propose an other solution. For me, this commit is a error because in README of doc/driver-model/ it is indicated: The device's bind() method is permitted to perform simple actions, but should not scan the device tree node, not initialise hardware, nor set up structures or allocate memory. All of these tasks should be left for the probe() method. And in the patch the LED driver is probed during the binding scan. When I activated the LED in my ARM target with the patch "stm32mp1: add gpio led support", I have the sequence: dm_init_and_scan() : 1/ dm_scan_fdt_node() => loop on all the node 2/ scan for LED node => probe of LED driver is forced by "default-state" detection LED1 - "red" => probe of father of "red" node A - led B - soc C - root => probe of node needed by GPIO 1 - pin-controller 2 - gpio@50002000 3 - rcc-clk@50000000 4 - rcc@50000000 => probe forced by default state for other led LED2 - green LED3 - orange => probe of node needed by GPIO (other bank) 5 - gpio@50009000 3/ dm_extended_scan_fdt scan continue... scan node "fixed-clock" under "/clocks" clk-hse clk-hsi clk-lse clk-lsi clk-csi 4/ probe of all the used devices.... after dm_extended_scan_fdt() So many driver are probed before the end of the scan binding loop ! And that cause issue in my board (boot failed) because the rcc-clk clock driver found the input frequency with these fixed-clock, which are binded only after the stm32mp1 clock driver probe. For me probe in forbidden in binding function and thus uclass_get_device_tail() is not allowed in the commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7 which need to be reverted. In the third patch I proposed an other solution based on the existing solution in u-class regulator used to enable regulator with "boot on" property (see regulators_enable_boot_on function). I think that adding a function is the better solution in the driver model to force probe for some node according binding information (after dm_init_and_scan call). This new function should be called in board_init function for each board but it could be also added in init_sequence_r[] in future. Changes in v3: - add motivation in revert commit - minor update after Simon review - include led.h to avoid compilation warning on stm32mp1 board Changes in v2: - add sandbox impact and test update Patrick Delaunay (5): stm32mp1: add gpio led support Revert "dm: led: auto probe() LEDs with "default-state"" dm: led: move default state support in led uclass stm32mp1: use new function led default state sandbox: led: use new function to configure default state arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 24 ++++++++++++++ board/sandbox/sandbox.c | 9 ++++++ board/st/stm32mp1/stm32mp1.c | 4 +++ common/board_r.c | 3 +- configs/stm32mp15_basic_defconfig | 2 ++ drivers/led/led-uclass.c | 54 ++++++++++++++++++++++++++++++++ drivers/led/led_gpio.c | 17 ---------- include/led.h | 23 ++++++++++++++ test/dm/led.c | 3 ++ 9 files changed, 121 insertions(+), 18 deletions(-) -- 2.7.4

4 9

[U-Boot] musb-new startup timeout
by Alex Kiernan 27 Jul '18

27 Jul '18

We've been chasing a problem for a while where we've got USB3 devices plugged in (on AM3352 board), this is using the musb-new driver. The symptoms are you plug in a device in and run `usb start` and get `USB0: Port not available.`, having watched the timings (and from our reading of the USB spec - though this is spec in one hand and analyser in the other...) we think that the USB device should raise the D+ line within 100ms to indicate that it is present. With a USB 2.0 hubs we see this very quickly, but with some USB3 hubs (and some USB3 memory sticks) this takes on the order of 800ms. We failed to find the right part of the USB3 spec, so not sure if this is normal. There's a timeout in musb_uboot.c of 1s: int musb_lowlevel_init(struct musb_host_data *host) { void *mbase; /* USB spec says it may take up to 1 second for a device to connect */ unsigned long timeout = get_timer(0) + 1000; int ret; ... If we bump that timeout to 1200ms then devices that were unreliable now work, but obviously the longer the delay, the more time the boot process takes when there's no USB (assuming there's a `usb start` in there). Would making that timeout configurable be a crazy thing to do, or are these devices which we're trying to use just broken and we should avoid them. Given the timeout's down in a driver, I assume other drivers have the same 1s timeout? -- Alex Kiernan

1 0

[U-Boot] [PATCH] board_f: drop 'dead code' in ram_top computation
by Philipp Tomsich 27 Jul '18

27 Jul '18

gd->ram_top is assigned to twice on consecutive lines and the compiler won't be able to tell that the first assignment is dead (including its r-value) due to the r-value containing a (side-effect free) function call. This drops the first assignment. Signed-off-by: Philipp Tomsich <philipp.tomsich(a)theobroma-systems.com> --- common/board_f.c | 1 - 1 file changed, 1 deletion(-) diff --git a/common/board_f.c b/common/board_f.c index 88d7700..1b8a003 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -283,7 +283,6 @@ static int setup_dest_addr(void) #ifdef CONFIG_SYS_SDRAM_BASE gd->ram_base = CONFIG_SYS_SDRAM_BASE; #endif - gd->ram_top = gd->ram_base + get_effective_memsize(); gd->ram_top = board_get_usable_ram_top(gd->mon_len); gd->relocaddr = gd->ram_top; debug("Ram top: %08lX\n", (ulong)gd->ram_top); -- 2.1.4

3 2

[U-Boot] [PATCH 1/2] env: Include bootdelay in environment if negative
by Alex Kiernan 27 Jul '18

27 Jul '18

The test for (CONFIG_BOOTDELAY >= 0) has been in U-Boot since the beginning, but the meaning of it has changed over time. Allow the default to be set for any value, including -ve ones. This allows (for example) CONFIG_ENV_IS_NOWHERE to have values for bootdelay in its compiled in environment. The only thing this changes is where the default for bootdelay can be fetched from; before this change you get a compiled in default, after you'll pull it from the default value in the environment, but both values will be the same. Also if there's a value set in the environment then that will take precedence (as before). Signed-off-by: Alex Kiernan <alex.kiernan(a)gmail.com> --- include/env_default.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/env_default.h b/include/env_default.h index 54d8124793..bd600cfa44 100644 --- a/include/env_default.h +++ b/include/env_default.h @@ -40,7 +40,7 @@ const uchar default_environment[] = { #ifdef CONFIG_NFSBOOTCOMMAND "nfsboot=" CONFIG_NFSBOOTCOMMAND "\0" #endif -#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) +#if defined(CONFIG_BOOTDELAY) "bootdelay=" __stringify(CONFIG_BOOTDELAY) "\0" #endif #if defined(CONFIG_BAUDRATE) && (CONFIG_BAUDRATE >= 0) -- 2.17.1

2 6

[U-Boot] [PATCH v2 0/4] arm: odroid: Convert to distro_bootcmd.
by Vagrant Cascadian 27 Jul '18

27 Jul '18

Switch odroid platform to use distro_bootcmd, adjusting to use standardized environment variable names, and use the default bootdelay. The additional environment variables from distro_bootcmd requires increasing the default environment size, which would break backwards compatibility with saved environments. At Marek's suggestion, I've bumped it well over the size needed (~4.5k vs. 16k) to give room for future growth. Variations on these patches have been in use in Debian's u-boot packages since 2016. A variation of this patch series was originally submitted to u-boot over a year ago, and resent a few times since, with little to no response. Thanks for considering! Changes in v2: - Change from 16384 to SZ_16K, as suggested by Minkyu Kang. Vagrant Cascadian (4): arm: odroid: Use standard environment variable names kernel_addr_r, ramdisk_addr_r and fdt_addr_r. arm: odroid: Increase default env size in preparation for distro_bootcmd. arm: odroid: Enable distro_bootcmd support. arm: odroid: Inherit default value for bootdelay from distro_bootcmd. include/configs/odroid.h | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) -- 2.11.0

3 7

[U-Boot] [PATCH] snow: set fdtfile
by Guillaume GARDET 27 Jul '18

27 Jul '18

Needed to boot with EFI distro boot. Signed-off-by: Guillaume GARDET <guillaume.gardet(a)free.fr> Cc: Akshay Saraswat <akshay.s(a)samsung.com> Cc: Tom Rini <trini(a)konsulko.com> --- include/configs/snow.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/snow.h b/include/configs/snow.h index 3b0db32ece..c546a5a6d0 100644 --- a/include/configs/snow.h +++ b/include/configs/snow.h @@ -8,6 +8,9 @@ #ifndef __CONFIG_SNOW_H #define __CONFIG_SNOW_H +#define EXYNOS_FDTFILE_SETTING \ + "fdtfile=exynos5250-snow.dtb\0" + #include <configs/exynos5250-common.h> #include <configs/exynos5-dt-common.h> #include <configs/exynos5-common.h> -- 2.17.1

4 5

[U-Boot] [PATCH 1/4] configs: opos6uldev: undef CONFIG_POWER_DOMAIN when SPL_BUILD
by Peng Fan 27 Jul '18

27 Jul '18

Because CONFIG_POWER_DOMAIN is enabled in defconfig, however driver/power/domain is not built for SPL, there is build failure when power_domain_on added to device_probe. Because power domain is not needed in SPL, let's undef it. Signed-off-by: Peng Fan <peng.fan(a)nxp.com> Cc: "Sébastien Szymanski" <sebastien.szymanski(a)armadeus.com> Cc: Stefano Babic <sbabic(a)denx.de> --- Need to find a way to avoid SPL build failure in future patch, but in this patchset let's undef CONFIG_POWER_DOMAIN first, because it is not needed. include/configs/opos6uldev.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/opos6uldev.h b/include/configs/opos6uldev.h index b634d9eb03..75fefec0ac 100644 --- a/include/configs/opos6uldev.h +++ b/include/configs/opos6uldev.h @@ -15,6 +15,7 @@ #ifdef CONFIG_SPL_BUILD #undef CONFIG_DM_REGULATOR +#undef CONFIG_POWER_DOMAIN #endif #endif -- 2.14.1

2 10

[U-Boot] [PATCH] fdt_support: make FDT_FIXUP_PARTITIONS depend on CMD_MTDPARTS
by Masahiro Yamada 27 Jul '18

27 Jul '18

fdt_fixup_mtdparts() calls mtdparts_init() and device_find(), which are defined in cmd/mtdparts.c The combination of FDT_FIXUP_PARTITIONS=y and CMD_MTDPARTS=n emits the following link error: common/fdt_support.c:903: undefined reference to `mtdparts_init' common/fdt_support.c:914: undefined reference to `device_find' Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> --- lib/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Kconfig b/lib/Kconfig index a77bf1c..622f3c2 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -334,7 +334,7 @@ config SPL_OF_LIBFDT config FDT_FIXUP_PARTITIONS bool "overwrite MTD partitions in DTS through defined in 'mtdparts'" depends on OF_LIBFDT - default n + depends on CMD_MTDPARTS help Allow overwriting defined partitions in the device tree blob using partition info defined in the 'mtdparts' environment -- 2.7.4

2 2