September 2019 - U-Boot

Re: [U-Boot] [PATCH v3] dm: core: device: switch off power domain after device removal
by Anatolij Gustschin 27 Sep '19

27 Sep '19

Hi Lokesh, On Thu, 1 Aug 2019 09:43:39 +0530 Lokesh Vutla lokeshvutla(a)ti.com wrote: >On 01/08/19 2:55 AM, Anatolij Gustschin wrote: >> The power domain associated with a device is enabled when probing, >> but currently the domain remains enabled when the device is removed. >> Some boards started to disable power domains for selected devices >> via custom board_quiesce_devices(), but it doesn't work in many >> cases, i. e. because devices still can be accessed later in >> .remove() callback on behalf of dm_remove_devices_flags(). >> >> Utilize the DM core to power off the device power domain, but add a >> device flag to be able to selectively let the power domain enabled >> after device removal. This might be required for devices that must >> remain enabled when booting OS, i. e. serial console for debug >> output, etc. >> >> Signed-off-by: Anatolij Gustschin <agust(a)denx.de> >> --- >> Changes in v3: >> - remove 'power-domain' device to fix dm power-domain test (make qcheck) >> - don't switch off the power domain for current console device >> >> Changes in v2: >> - use CONFIG_IS_ENABLED(POWER_DOMAIN) to reduce code size >> >> drivers/core/device-remove.c | 18 ++++++++++++++++++ >> include/dm/device.h | 6 ++++++ >> 2 files changed, 24 insertions(+) >> >> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c >> index 586fadee0a..5a0e48e182 100644 >> --- a/drivers/core/device-remove.c >> +++ b/drivers/core/device-remove.c >> @@ -16,6 +16,7 @@ >> #include <dm/uclass.h> >> #include <dm/uclass-internal.h> >> #include <dm/util.h> >> +#include <power-domain.h> >> >> int device_chld_unbind(struct udevice *dev, struct driver *drv) >> { >> @@ -155,6 +156,7 @@ static bool flags_remove(uint flags, uint drv_flags) >> int device_remove(struct udevice *dev, uint flags) >> { >> const struct driver *drv; >> + struct power_domain pd; >> int ret; >> >> if (!dev) >> @@ -192,6 +194,22 @@ int device_remove(struct udevice *dev, uint flags) >> } >> } >> >> + if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent && >> + device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN && >> + dev != gd->cur_serial_dev && >> + !(dev->flags & DM_FLAG_REMOVE_WITH_PD_ON)) { > >I did not realize before but this statement is too hard to read :). Can we drop >the following two conditions: > dev->parent && device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN > >power_domain_get() will indirectly take care of above two cases. I'll test it. >> + if (!power_domain_get(dev, &pd)) { >> + power_domain_off(&pd); >> + /* >> + * power_domain_get() bound the device, thus >> + * we must remove it again to prevent unbinding >> + * active devices (which would result in unbind >> + * error). >> + */ >> + device_remove(pd.dev, DM_REMOVE_NORMAL); > >Unless I am mistaken, this looks like this is an extra work. Why can't we store >a PD in struct device, something like below: > >diff --git a/drivers/core/device.c b/drivers/core/device.c >index cded457e2b..efa780a02f 100644 >--- a/drivers/core/device.c >+++ b/drivers/core/device.c >@@ -307,7 +307,6 @@ static void *alloc_priv(int size, uint flags) > > int device_probe(struct udevice *dev) > { >- struct power_domain pd; > const struct driver *drv; > int size = 0; > int ret; >@@ -388,10 +387,11 @@ int device_probe(struct udevice *dev) > if (dev->parent && device_get_uclass_id(dev) != UCLASS_PINCTRL) > pinctrl_select_state(dev, "default"); > >+ dev->pd.dev = NULL; > if (dev->parent && device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN && > !(drv->flags & DM_FLAG_DEFAULT_PD_EN_OFF)) { >- if (!power_domain_get(dev, &pd)) >- power_domain_on(&pd); >+ if (!power_domain_get(dev, &dev->pd)) >+ power_domain_on(&dev->pd); > } > > ret = uclass_pre_probe_device(dev); >diff --git a/include/dm/device.h b/include/dm/device.h >index b892386dc4..26699ca5cc 100644 >--- a/include/dm/device.h >+++ b/include/dm/device.h >@@ -12,12 +12,14 @@ > > #include <dm/ofnode.h> > #include <dm/uclass-id.h> >+#include <errno.h> > #include <fdtdec.h> > #include <linker_lists.h> > #include <linux/compat.h> > #include <linux/kernel.h> > #include <linux/list.h> > #include <linux/printk.h> >+#include <power-domain.h> > > struct driver_info; > >@@ -126,6 +128,7 @@ enum { > * When CONFIG_DEVRES is enabled, devm_kmalloc() and friends will > * add to this list. Memory so-allocated will be freed > * automatically when the device is removed / unbound >+ * @pd: Pointer to power_domain controlling this device. > */ > struct udevice { > const struct driver *driver; >@@ -149,6 +152,7 @@ struct udevice { > #ifdef CONFIG_DEVRES > struct list_head devres_head; > #endif >+ struct power_domain pd; > }; > > /* Maximum sequence number supported */ I tried similar change, this didn't work yet. When booting Linux I see infinite recursion in device_remove() for 'lsio_gpio0' on i.mx8qxp. -- Anatolij

3 2

[U-Boot] am335x_evm SPL no longer fits
by Jonathan Gray 27 Sep '19

27 Sep '19

As of v2019.10-rc3 am335x_evm builds fail here as SPL doesn't fit. v2019.10-rc2 builds. v2019.10-rc4 still fails: LD spl/u-boot-spl arm-none-eabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' arm-none-eabi-ld.bfd: region `.sram' overflowed by 100 bytes I bisected this to the below commit but reverting it only slightly helps arm-none-eabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' arm-none-eabi-ld.bfd: region `.sram' overflowed by 72 bytes Building with gcc-linaro-6.3.2017.02 and binutils-2.27 b83edfbde9a845d47a2766f4677deb336abfa42a is the first bad commit commit b83edfbde9a845d47a2766f4677deb336abfa42a Author: Lukas Auer <lukas.auer(a)aisec.fraunhofer.de> Date: Wed Aug 21 21:14:42 2019 +0200 spl: fit: use U-Boot device tree when FIT image has no device tree As part of the SPL FIT boot flow, the device tree is appended to U-Boot proper. The device tree is used to record information on the loadables to make them available to the SPL framework and U-Boot proper. Depending on the U-Boot device tree provider, the FIT image might not include a device tree. Information on the loadables is missing in this case. When booting via firmware bundled with the FIT image, U-Boot SPL loads the firmware binary and U-Boot proper before starting the firmware. The firmware, in turn, is responsible for starting U-Boot proper. Information on the memory location of the U-Boot proper loadable must be available to the SPL framework so that it can be passed to the firmware binary. To support this use case when no device tree is found in the FIT image, fall back to the U-Boot device tree in this situation. At the same time, update the comment to remove the note that the destination address must be aligned to ARCH_DMA_MINALIGN. Alignment is only required as an intermediate step when reading external data. This is automatically handled by spl_fit_append_fdt(). After reading the external data, it is copied to the specified address, which does not have to be aligned to ARCH_DMA_MINALIGN. Signed-off-by: Lukas Auer <lukas.auer(a)aisec.fraunhofer.de> Reviewed-by: Bin Meng <bmeng.cn(a)gmail.com> Tested-by: Bin Meng <bmeng.cn(a)gmail.com> Reviewed-by: Anup Patel <anup.patel(a)wdc.com> common/spl/spl_fit.c | 37 ++++++++++++++++++++++++------------- 1 file changed, 24 insertions(+), 13 deletions(-)

1 1

[U-Boot] [PATCH V2 1/2] power: domain: add dev_power_domain_on
by Peng Fan 27 Sep '19

27 Sep '19

Add this new API to power on multiple domains attached to a device. Signed-off-by: Peng Fan <peng.fan(a)nxp.com> --- V2: New patch drivers/power/domain/power-domain-uclass.c | 19 +++++++++++++++++++ include/power-domain.h | 17 +++++++++++++++++ 2 files changed, 36 insertions(+) diff --git a/drivers/power/domain/power-domain-uclass.c b/drivers/power/domain/power-domain-uclass.c index 2ea0ff24c7..95aa9b30ef 100644 --- a/drivers/power/domain/power-domain-uclass.c +++ b/drivers/power/domain/power-domain-uclass.c @@ -107,6 +107,25 @@ int power_domain_off(struct power_domain *power_domain) return ops->off(power_domain); } +int dev_power_domain_on(struct udevice *dev) +{ + struct power_domain pd; + int i, count, ret; + + count = dev_count_phandle_with_args(dev, "power-domains", + "#power-domain-cells"); + for (i = 0; i < count; i++) { + ret = power_domain_get_by_index(dev, &pd, i); + if (ret) + return ret; + ret = power_domain_on(&pd); + if (ret) + return ret; + } + + return 0; +} + UCLASS_DRIVER(power_domain) = { .id = UCLASS_POWER_DOMAIN, .name = "power_domain", diff --git a/include/power-domain.h b/include/power-domain.h index ef15dc9f60..23a63f3b18 100644 --- a/include/power-domain.h +++ b/include/power-domain.h @@ -155,4 +155,21 @@ static inline int power_domain_off(struct power_domain *power_domain) } #endif +/** + * dev_power_domain_on - Enable power domains for a device . + * + * @dev: The client device. + * + * @return 0 if OK, or a negative error code. + */ +#if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)) && \ + CONFIG_IS_ENABLED(POWER_DOMAIN) +int dev_power_domain_on(struct udevice *dev); +#else +int dev_power_domain_on(struct udevice *dev) +{ + return 0; +} +#endif + #endif -- 2.16.4

3 9

[U-Boot] FDT: alignment of 64-bits integers
by Jean-Jacques Hiblot 27 Sep '19

27 Sep '19

Hi Simon, while working with the FDT in the SPL, I came across an alignment issue. I have seen 64-bits integers not aligned on a 64-bit boundary, although is doesn't happen very often. According to the FDT spec, the requirement is to be aligned on 32-bits, so it is OK. However on ARM64, until the cache is enabled, it is not possible to access 64-bits integers not aligned on a 64-bits boundary. This issue has been discussed here : http://u-boot.10912.n7.nabble.com/memcpy-memset-on-arm64-platforms-td353928… I have a patch for this but I am not sure, this is the right approach: diff --git a/include/linux/libfdt_env.h b/include/linux/libfdt_env.h index e2bf79c7ee..b6b7176a8a 100644 --- a/include/linux/libfdt_env.h +++ b/include/linux/libfdt_env.h @@ -15,7 +15,7 @@ typedef __be16 fdt16_t; typedef __be32 fdt32_t; -typedef __be64 fdt64_t; +typedef __be64 fdt64_t __aligned(4); The trouble with this patch is that for every fdt64_t the access will be aligned on 32-bits, inducing an overall performance penalty. The other approach will be to fix the problem where it happens. So far I had the issue only ofnode_read_u64() because that is what the driver I worked with is using. What do you think? Thanks, JJ

2 1

[U-Boot] [PATCH v2] env: Add CONFIG_ENV_SUPPORT
by Patrick Delaunay 27 Sep '19

27 Sep '19

Add a new flag CONFIG_ENV_SUPPORT to compile all the environment features in U-Boot (attributes, callbacks and flags); it is the supplement of the 2 existing flags for SPL/TPL. To have ENV support, enable the flag: - CONFIG_ENV_SUPPORT for U-Boot proper - CONFIG_SPL_ENV_SUPPORT for SPL - CONFIG_TPL_ENV_SUPPORT for TPL This new configuration allows to use the macro CONFIG_IS_ENABLED(ENV_SUPPORT) in the code without issue and solves the regression introduced by commit 7d4776545b0f ("env: solve compilation error in SPL"); change_ok was always NULL in U-Boot. Signed-off-by: Patrick Delaunay <patrick.delaunay(a)st.com> --- Changes in v2: - Update commit message after Lukasz Majewki review cmd/Kconfig | 2 ++ env/Kconfig | 7 +++++++ env/Makefile | 11 ++++------- include/env_callback.h | 4 ++++ include/env_flags.h | 4 ++++ 5 files changed, 21 insertions(+), 7 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 05872fa0d7..f7a1b1faf5 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -465,6 +465,7 @@ config CMD_ENV_EXISTS config CMD_ENV_CALLBACK bool "env callbacks - print callbacks and their associated variables" + depends on ENV_SUPPORT help Some environment variable have callbacks defined by U_BOOT_ENV_CALLBACK. These are called when the variable changes. @@ -473,6 +474,7 @@ config CMD_ENV_CALLBACK config CMD_ENV_FLAGS bool "env flags -print variables that have non-default flags" + depends on ENV_SUPPORT help Some environment variables have special flags that control their behaviour. For example, serial# can only be written once and cannot diff --git a/env/Kconfig b/env/Kconfig index 74db2f38cc..f0c5a7a39c 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -1,5 +1,12 @@ menu "Environment" +config ENV_SUPPORT + bool "Support all environment features" + default y + help + Enable full environment support in U-Boot, + including attributes, callbacks and flags. + config ENV_IS_NOWHERE bool "Environment is not stored" default y if !ENV_IS_IN_EEPROM && !ENV_IS_IN_EXT4 && \ diff --git a/env/Makefile b/env/Makefile index 90144d6caf..2a468ac16b 100644 --- a/env/Makefile +++ b/env/Makefile @@ -5,10 +5,11 @@ obj-y += common.o env.o +obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o +obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o +obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o + ifndef CONFIG_SPL_BUILD -obj-y += attr.o -obj-y += callback.o -obj-y += flags.o obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o extra-$(CONFIG_ENV_IS_EMBEDDED) += embedded.o obj-$(CONFIG_ENV_IS_IN_EEPROM) += embedded.o @@ -19,10 +20,6 @@ obj-$(CONFIG_ENV_IS_IN_ONENAND) += onenand.o obj-$(CONFIG_ENV_IS_IN_SATA) += sata.o obj-$(CONFIG_ENV_IS_IN_REMOTE) += remote.o obj-$(CONFIG_ENV_IS_IN_UBI) += ubi.o -else -obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o -obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o -obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o endif obj-$(CONFIG_$(SPL_TPL_)ENV_IS_NOWHERE) += nowhere.o diff --git a/include/env_callback.h b/include/env_callback.h index 982c07854d..a757fe6b5f 100644 --- a/include/env_callback.h +++ b/include/env_callback.h @@ -72,6 +72,10 @@ "serial#:serialno," \ CONFIG_ENV_CALLBACK_LIST_STATIC +#if CONFIG_IS_ENABLED(ENV_SUPPORT) void env_callback_init(struct env_entry *var_entry); +#else +static inline void env_callback_init(struct env_entry *var_entry) { } +#endif #endif /* __ENV_CALLBACK_H__ */ diff --git a/include/env_flags.h b/include/env_flags.h index e5380f2948..ec480e3ed7 100644 --- a/include/env_flags.h +++ b/include/env_flags.h @@ -153,7 +153,11 @@ int env_flags_validate_env_set_params(char *name, char *const val[], int count); * When adding a variable to the environment, initialize the flags for that * variable. */ +#if CONFIG_IS_ENABLED(ENV_SUPPORT) void env_flags_init(struct env_entry *var_entry); +#else +static inline void env_flags_init(struct env_entry *var_entry) { } +#endif /* * Validate the newval for to conform with the requirements defined by its flags -- 2.17.1

2 1

[U-Boot] [PATCH] ARM: dts: pcl063: add usdhc reset pin of eMMC
by Parthiban Nallathambi 26 Sep '19

26 Sep '19

pcl063 phycore SoM with eMMC also got usdhc reset pin, add reset pin to pinmux. Signed-off-by: Parthiban Nallathambi <pn(a)denx.de> --- arch/arm/dts/pcl063-common.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/dts/pcl063-common.dtsi b/arch/arm/dts/pcl063-common.dtsi index 2b14b2dc5f..b88dde2fb0 100644 --- a/arch/arm/dts/pcl063-common.dtsi +++ b/arch/arm/dts/pcl063-common.dtsi @@ -113,7 +113,7 @@ pinctrl_enet1: enet1grp { fsl,pins = < MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0 - MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0X1b0b0 + MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0 MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 @@ -191,6 +191,7 @@ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x170f9 MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x170f9 MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x170f9 + MX6UL_PAD_NAND_ALE__USDHC2_RESET_B 0x170f9 >; }; }; -- 2.21.0

1 0

[U-Boot] [PATCH] clk: Fix error check in clk_set_default_parents()
by Jean-Jacques Hiblot 26 Sep '19

26 Sep '19

According to the documentation in clk.h, clk_set_parent() return the new rate of the clock or a negative error code. Signed-off-by: Jean-Jacques Hiblot <jjhiblot(a)ti.com> --- drivers/clk/clk-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c index 64c181f4ad..bf1adc09ab 100644 --- a/drivers/clk/clk-uclass.c +++ b/drivers/clk/clk-uclass.c @@ -223,7 +223,7 @@ static int clk_set_default_parents(struct udevice *dev) if (ret == -ENOSYS) continue; - if (ret) { + if (ret < 0) { debug("%s: failed to reparent clock %d for %s\n", __func__, index, dev_read_name(dev)); return ret; -- 2.17.1

1 0

[U-Boot] 'size/ext4size/fatsize' shell commands do not dispay the filesize
by Adarsh Babu Kalepalli 26 Sep '19

26 Sep '19

Hello, Commands "size / ext4size / fatsize" do not display the file size. + u-boot version:2019.10-rc4 + H/W Board : Beaglebone Black + Command Causing Issue: size/ext4size/fatsize + Command Output: Size of the mentioned file is not displayed on serial console. Console Output from Beaglebone Black for usb and mmc devices : ---------------------------------------------------------------------------------------- => fatls usb 0:1 1024 1kB.txt 1048576 1MB.txt 2 file(s), 0 dir(s) => fatsize usb 0:1 1MB.txt => size usb 0:1 1MB.txt => size size - determine a file's size Usage: size <interface> <dev[:part]> <filename> - Find file 'filename' from 'dev' on 'interface' and determine its size. => ext4ls mmc 0:2 <DIR> 4096 . <DIR> 4096 .. <DIR> 4096 bin <DIR> 4096 boot <DIR> 4096 dev <DIR> 4096 etc <DIR> 4096 home <DIR> 4096 lib <DIR> 4096 media <DIR> 4096 mnt <DIR> 4096 proc <DIR> 4096 run <DIR> 4096 sbin <DIR> 4096 sys <SYM> 8 tmp <DIR> 4096 usr <DIR> 4096 var 1024 test_data => ext4size mmc 0:2 /test_data => size mmc 0:2 /test_data => -------------------------------------------------------------------------------------------- - Adarsh <https://www.avast.com/en-in/recommend?utm_medium=email&utm_source=link&utm_…> I’m protected online with Avast Free Antivirus. Get it here — it’s free forever. <https://www.avast.com/en-in/recommend?utm_medium=email&utm_source=link&utm_…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 1

[U-Boot] Unable to delete the hush shell local variables
by Adarsh Babu Kalepalli 26 Sep '19

26 Sep '19

Hi, + u-boot version:2019.10-rc4 + H/W Board : Beaglebone Black + Issue : Unable to delete the hush shell local variables with 'local_variable_name=' at the shell prompt (similar to 'setenv env_variable_name'),I tried to delete a Hush shell local variable after creating it. This approach did not delete (as in the below sequence of shell commands) the local variable. ----------------------------------------------------- => hushVar=3 => showvar HUSH_VERSION=0.01 hushVar=3 => hushvar= => showvar HUSH_VERSION=0.01 hushVar=3 => ------------------------------------------------------ Is there a other approach to delete hush shell local variables ?? Any pointers to detailed information regarding Hush Shell Scripts will also be helpful. -Adarsh <https://www.avast.com/en-in/recommend?utm_medium=email&utm_source=link&utm_…> I’m protected online with Avast Free Antivirus. Get it here — it’s free forever. <https://www.avast.com/en-in/recommend?utm_medium=email&utm_source=link&utm_…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0

[U-Boot] [PATCH v2 0/9] imx: mxs: Fixes and DM/DTS conversion code for several i.MX28 drivers
by Lukasz Majewski 26 Sep '19

26 Sep '19

This patch series focuses on fixing and enhancing the i.MX28 to be converted to DM/DTS. The mxs gpio, spi and eMMC drivers has been fixed and converted to DM/DTS. Changes in v2: - New patch - Correct position of struct mmc_ops mxsmmc_ops to avoid build breaks on board using legacy i.MX28 mmc driver. - New patch - New patch - New patch Lukasz Majewski (9): doc: fix: Replace SPL_OF_PLATDATA with OF_PLATDATA in examples dts: imx28: Remove #include "imx28.dtsi" from imx28-u-boot.dtsi file spl: Init proper struct driver member (platdata_auto_alloc_size) for mxs_spi spi: fix: Call mxs_reset_block() during DM/DTS probe spi: Add support for SPL_OF_PLATDATA to mxs_spi.c driver mmc: Convert mxsmmc eMMC driver for i.MX2{38} to DM/DTS mmc: Replace printf with debug call for timeouts in the i.MX28 mxs driver spl: Introduce SPL_DM_GPIO Kconfig define spi: Add support for SPL_OF_PLATDATA to mxs_gpio.c driver arch/arm/dts/imx28-u-boot.dtsi | 1 - common/spl/Kconfig | 6 + doc/driver-model/of-plat.rst | 8 +- drivers/gpio/mxs_gpio.c | 72 +++++-- drivers/mmc/mxsmmc.c | 445 ++++++++++++++++++++++++++++++++++------- drivers/spi/mxs_spi.c | 38 +++- 6 files changed, 474 insertions(+), 96 deletions(-) -- 2.11.0

5 25