August 2021 - U-Boot

[PATCH] Convert CONFIG_MX7D to Kconfig
by Tom Rini 01 Sep '21

01 Sep '21

This converts the following to Kconfig: CONFIG_MX7D Cc: Oleksandr Suvorov <oleksandr.suvorov(a)toradex.com> Signed-off-by: Tom Rini <trini(a)konsulko.com> --- arch/arm/mach-imx/mx7/Kconfig | 1 + configs/colibri_imx7_defconfig | 2 +- configs/colibri_imx7_emmc_defconfig | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-imx/mx7/Kconfig b/arch/arm/mach-imx/mx7/Kconfig index adedc011648f..059e65879c5c 100644 --- a/arch/arm/mach-imx/mx7/Kconfig +++ b/arch/arm/mach-imx/mx7/Kconfig @@ -91,6 +91,7 @@ config TARGET_COLIBRI_IMX7 select DM select DM_SERIAL select DM_THERMAL + select MX7D imply CMD_DM endchoice diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index 39149167e000..e31e663acd14 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -12,7 +12,7 @@ CONFIG_IMX_RDC=y CONFIG_IMX_BOOTAUX=y CONFIG_IMX_HAB=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D" +CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg" CONFIG_BOOTDELAY=1 # CONFIG_USE_BOOTCOMMAND is not set CONFIG_USE_PREBOOT=y diff --git a/configs/colibri_imx7_emmc_defconfig b/configs/colibri_imx7_emmc_defconfig index 87527671fef1..35f5c32dd293 100644 --- a/configs/colibri_imx7_emmc_defconfig +++ b/configs/colibri_imx7_emmc_defconfig @@ -14,7 +14,7 @@ CONFIG_IMX_BOOTAUX=y CONFIG_IMX_HAB=y CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y -CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D" +CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg" CONFIG_BOOTDELAY=1 # CONFIG_USE_BOOTCOMMAND is not set CONFIG_USE_PREBOOT=y -- 2.17.1

1 1

[PATCH 1/3] qfw: Switch to CONFIG_SYS_LOAD_ADDR from CONFIG_LOADADDR
by Tom Rini 01 Sep '21

01 Sep '21

All platforms define CONFIG_SYS_LOAD_ADDR, but only some define CONFIG_LOADADDR. Very very rarely are these not the same address, and qemu-ppce500 is one such case. However, based on reading the history of the code, this mismatched value was simply a copy-paste from other PowerPC platforms where it is this unused currently. Switch the code to use CONFIG_SYS_LOAD_ADDR and update the documentation. Cc: Bin Meng <bmeng.cn(a)gmail.com> Signed-off-by: Tom Rini <trini(a)konsulko.com> --- cmd/qfw.c | 6 +----- doc/usage/qfw.rst | 2 +- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/cmd/qfw.c b/cmd/qfw.c index eb6a552f6fad..d58615040c64 100644 --- a/cmd/qfw.c +++ b/cmd/qfw.c @@ -121,11 +121,7 @@ static int qemu_fwcfg_do_load(struct cmd_tbl *cmdtp, int flag, env = env_get("loadaddr"); load_addr = env ? (void *)hextoul(env, NULL) : -#ifdef CONFIG_LOADADDR - (void *)CONFIG_LOADADDR; -#else - NULL; -#endif + (void *)CONFIG_SYS_LOAD_ADDR; env = env_get("ramdiskaddr"); initrd_addr = env ? diff --git a/doc/usage/qfw.rst b/doc/usage/qfw.rst index 87463e1e5bb8..b3704b92d6d9 100644 --- a/doc/usage/qfw.rst +++ b/doc/usage/qfw.rst @@ -26,7 +26,7 @@ The *qfw load* command is used to load a kernel and an initial RAM disk. kernel_addr address to which the file specified by the -kernel parameter of QEMU shall be loaded. Defaults to environment variable *loadaddr* and further to - the value of *CONFIG_LOADADDR*. + the value of *CONFIG_SYS_LOAD_ADDR*. initrd_addr address to which the file specified by the -initrd parameter of QEMU shall -- 2.17.1

2 6

incompatible device trees between u-boot and linux
by Michael Walle 31 Aug '21

31 Aug '21

Hi, I noticed that there is a fallback to the u-boot device tree for linux (esp. EFI boot) if no other device tree was found, see [1]. It seems this is working fine for imx devices, for example, where you can just boot a stock installer iso via EFI. It will just work and it is quite a nice feature as a fallback. Now for the layerscape architecture, the ls1028a in my case, things are more difficult because the bindings differ between u-boot and linux - one which comes to mind is DSA and ethernet. Which begs the general question, is it encouraged to have both bindings diverge? To me it seems, that most bindings in u-boot are ad-hoc and there is no real review or alignment but just added as needed, which is ok if they are local to u-boot. But since they are nowadays passed to linux (by default!) I'm not so sure anymore. OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like they should (could?) be shared between linux and u-boot. -michael [1] https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471

6 17

Re: Re: [PATCH 2/2] drivers: mmc: Add wait_dat0 support for sdhci driver
by Stephen Carlson 31 Aug '21

31 Aug '21

Jaehoon, readx_poll_timeout expands to read_poll_timeout which accepts the signature: read_poll_timeout(op, addr, val, cond, sleep_us, timeout_us) sdhci_readl requires two arguments, host and SHCI_PRESENT_STATE, which cannot both be provided to that macro in the addr parameter. One potential workaround would be to declare a static helper function to call sdhci_readl with a constant second parameter, but this proposal would increase function call overhead and stack usage. Is it worth changing for the readability improvement? Thanks, Stephen Carlson -----Original Message----- From: Jaehoon Chung <jh80.chung(a)samsung.com> Sent: Friday, August 27, 2021 10:14 PM To: stcarlso(a)linux.microsoft.com; u-boot(a)lists.denx.de Cc: Peng Fan <peng.fan(a)nxp.com> Subject: Re: [PATCH 2/2] drivers: mmc: Add wait_dat0 support for sdhci driver On 8/18/21 4:46 AM, stcarlso(a)linux.microsoft.com wrote: > From: Stephen Carlson <stcarlso(a)linux.microsoft.com> > > Adds an implementation of the wait_dat0 MMC operation for the DM SDHCI > driver, allowing the driver to continue when the card is ready rather > than waiting for the worst case time on each MMC switch operation. > > Signed-off-by: Stephen Carlson <stcarlso(a)linux.microsoft.com> > --- > drivers/mmc/sdhci.c | 20 ++++++++++++++++++++ > include/sdhci.h | 2 ++ > 2 files changed, 22 insertions(+) > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index > eea4701d8a..bb55e00ef5 100644 > --- a/drivers/mmc/sdhci.c > +++ b/drivers/mmc/sdhci.c > @@ -775,6 +775,25 @@ static int sdhci_get_cd(struct udevice *dev) > return value; > } > > +static int sdhci_wait_dat0(struct udevice *dev, int state, > + int timeout_us) > +{ > + int tmp; > + struct mmc *mmc = mmc_get_mmc_dev(dev); > + struct sdhci_host *host = mmc->priv; > + unsigned long timeout = timer_get_us() + timeout_us; > + > + // readx_poll_timeout is unsuitable because sdhci_readl accepts > + // two arguments Removed the comment or use "/* */" instead of "//" And i didn't understand what's unsuitable? Best Regards, Jaehoon Chung > + do { > + tmp = sdhci_readl(host, SDHCI_PRESENT_STATE); > + if (!!(tmp & SDHCI_DATA_0_LVL_MASK) == !!state) > + return 0; > + } while (!timeout_us || !time_after(timer_get_us(), timeout)); > + > + return -ETIMEDOUT; > +} > + > const struct dm_mmc_ops sdhci_ops = { > .send_cmd = sdhci_send_command, > .set_ios = sdhci_set_ios, > @@ -783,6 +802,7 @@ const struct dm_mmc_ops sdhci_ops = { #ifdef > MMC_SUPPORTS_TUNING > .execute_tuning = sdhci_execute_tuning, > #endif > + .wait_dat0 = sdhci_wait_dat0, > }; > #else > static const struct mmc_ops sdhci_ops = { diff --git > a/include/sdhci.h b/include/sdhci.h index 0ae9471ad7..dd4eb41442 > 100644 > --- a/include/sdhci.h > +++ b/include/sdhci.h > @@ -65,6 +65,8 @@ > #define SDHCI_CARD_STATE_STABLE BIT(17) > #define SDHCI_CARD_DETECT_PIN_LEVEL BIT(18) > #define SDHCI_WRITE_PROTECT BIT(19) > +#define SDHCI_DATA_LVL_MASK 0x00F00000 > +#define SDHCI_DATA_0_LVL_MASK BIT(20) > > #define SDHCI_HOST_CONTROL 0x28 > #define SDHCI_CTRL_LED BIT(0) >

1 0

[PATCH 1/2] mmc: fsl_esdhc_imx: initialize data for imx7ulp
by Oleksandr Suvorov 31 Aug '21

31 Aug '21

From: Jorge Ramirez-Ortiz <jorge(a)foundries.io> Import data for eSDHC driver for SoC iMX7ULP from the Linux kernel. Set supported by u-boot flags only. Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> Signed-off-by: Ricardo Salveti <ricardo(a)foundries.io> Co-developed-by: Oleksandr Suvorov <oleksandr.suvorov(a)foundries.io> Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov(a)foundries.io> --- drivers/mmc/fsl_esdhc_imx.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c index aabf39535f..6c8f77f9ee 100644 --- a/drivers/mmc/fsl_esdhc_imx.c +++ b/drivers/mmc/fsl_esdhc_imx.c @@ -1706,6 +1706,11 @@ static struct esdhc_soc_data usdhc_imx7d_data = { | ESDHC_FLAG_HS400, }; +static struct esdhc_soc_data usdhc_imx7ulp_data = { + .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING + | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200, +}; + static struct esdhc_soc_data usdhc_imx8qm_data = { .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200 | @@ -1720,7 +1725,7 @@ static const struct udevice_id fsl_esdhc_ids[] = { { .compatible = "fsl,imx6sl-usdhc", }, { .compatible = "fsl,imx6q-usdhc", }, { .compatible = "fsl,imx7d-usdhc", .data = (ulong)&usdhc_imx7d_data,}, - { .compatible = "fsl,imx7ulp-usdhc", }, + { .compatible = "fsl,imx7ulp-usdhc", .data = (ulong)&usdhc_imx7ulp_data,}, { .compatible = "fsl,imx8qm-usdhc", .data = (ulong)&usdhc_imx8qm_data,}, { .compatible = "fsl,imx8mm-usdhc", .data = (ulong)&usdhc_imx8qm_data,}, { .compatible = "fsl,imx8mn-usdhc", .data = (ulong)&usdhc_imx8qm_data,}, -- 2.31.1

3 4

nand/am335x_spl_bch - SPL NAND loading hang on power on only
by Kevin Baker 31 Aug '21

31 Aug '21

Hi all, I am working on updating our version of u-boot, and came across something weird - the SPL hangs after "Trying to load NAND" on the first power-on boot, but after a watchdog reset or power-on reset, the NAND works fine. U-Boot SPL 2021.01-00010-g8c91cf967b-dirty (Aug 30 2021 - 19:03:45 -0500) Trying to boot from NAND <<<< hangs here until watchdog reset After checking more common issues - pinmux/config/timing/NAND connections, etc. and printf-tracing it, it is actually hanging after board_nand_init and at this call to select_chip before getting to NAND_CMD_RESET: drivers/mtd/nand/raw/am335x_spl_bch.c: nand_init() ... board_nand_init(&nand_chip); if (nand_chip.select_chip) nand_chip.select_chip(mtd, 0); <<<< stuck here ??? <<<< /* NAND chip may require reset after power-on */ nand_command(0, 0, 0, NAND_CMD_RESET); ... Somehow, the first power up, nand_chip.select_chip is 0xFFFFFFFF, so it hangs at that point. Whereas future power-on resets have the location cleared to 0, so it works fine... Explicitly setting select_chip to NULL in the call to board_nand_init for omap_gpmc makes everything work fine: drivers/mtd/nand/raw/omap_gpmc.c: board_nand_init() ... writel(gpmc_config, &gpmc_cfg->config) + nand->select_chip = NULL; + nand->IO_ADDR_R = (void __iomem *)&gpmc_cfg->cs[cs].nand_dat; ... But now I am worried about other things not being cleared out properly at reset... The am335x SPL NAND driver is pretty old and presumably well-tested code, so I was kinda surprised at this fix working. Would anyone know if a configuration setting, compiler setting or similar contributes to this? Or is it some artifact of the power-up state of the board? Is there a better way of 'clearing' the static nand_chip struct in am335x_spl_bch.c, or is there really a missing setup of this function pointer somewhere for am335x_spl_bch/omap_gpmc? This is against TI's u-boot @ d77252021a85c72d7ff9a4e151b81c4b4b9e1205 , with a Variscite VAR-SOM-AM33 module. Just wanted to check with the list to see if I am missing something... Thanks, Kevin

1 0

[PATCH] x86: Change SYS_LOAD_ADDR to 0x01000000
by Tom Rini 31 Aug '21

31 Aug '21

At least on qemu, and likely other platforms, a load address of 0x02000000 ends up without our protected range currently. Move this down to 0x01000000. Cc: Bin Meng <bmeng.cn(a)gmail.com> Signed-off-by: Tom Rini <trini(a)konsulko.com> --- Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Kconfig b/Kconfig index 931a22806e4e..eaf48b80196f 100644 --- a/Kconfig +++ b/Kconfig @@ -389,8 +389,8 @@ config SYS_LDSCRIPT config SYS_LOAD_ADDR hex "Address in memory to use by default" - default 0x01000000 if ARCH_SOCFPGA - default 0x02000000 if PPC || X86 + default 0x01000000 if ARCH_SOCFPGA || X86 + default 0x02000000 if PPC default 0x22000000 if MACH_SUN9I default 0x42000000 if ARCH_SUNXI && !MACH_SUN9I default 0x82000000 if ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3 -- 2.17.1

2 2

[PATCH v6 00/12] handling all DM watchdogs in watchdog_reset()
by Rasmus Villemoes 31 Aug '21

31 Aug '21

This series is an attempt at expanding the wdt-uclass provided watchdog_reset() to handle all DM watchdogs, not just the first one. Some of the ad hoc work done for the first DM watchdog in initr_watchdog() is now moved to a .pre_probe hook so it is automatically done for all devices. It also includes a patch adding a driver for a gpio-petted watchdog device (and a sandbox test of that) - it is included here because that also gives a relatively easy way to have more than one (kind of) watchdog device in the sandbox, which is then used at the end to test that watchdog_reset() behaves as expected. v2: https://lore.kernel.org/u-boot/20210527220017.1266765-1-rasmus.villemoes@pr… v3: https://lore.kernel.org/u-boot/20210702124510.124401-1-rasmus.villemoes@pre… v4: https://lore.kernel.org/u-boot/20210802150016.588750-1-rasmus.villemoes@pre… v5: https://lore.kernel.org/u-boot/20210811124800.2593226-1-rasmus.villemoes@pr… Changes in v6: Make wdt_stop_all() return the first error encountered (if any), yet still visit all watchdog devices. Rasmus Villemoes (12): watchdog: wdt-uclass.c: use wdt_start() in wdt_expire_now() watchdog: wdt-uclass.c: introduce struct wdt_priv watchdog: wdt-uclass.c: neaten UCLASS_DRIVER definition watchdog: wdt-uclass.c: refactor initr_watchdog() watchdog: wdt-uclass.c: keep track of each device's running state sandbox: disable CONFIG_WATCHDOG_AUTOSTART watchdog: wdt-uclass.c: add wdt_stop_all() helper board: x530: switch to wdt_stop_all() watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset() watchdog: add gpio watchdog driver sandbox: add test of wdt_gpio driver sandbox: add test of wdt-uclass' watchdog_reset() arch/sandbox/dts/test.dts | 8 + board/alliedtelesis/x530/x530.c | 5 +- configs/sandbox64_defconfig | 2 + configs/sandbox_defconfig | 2 + .../watchdog/gpio-wdt.txt | 19 ++ drivers/watchdog/Kconfig | 9 + drivers/watchdog/Makefile | 1 + drivers/watchdog/gpio_wdt.c | 68 +++++++ drivers/watchdog/wdt-uclass.c | 192 +++++++++++++----- include/asm-generic/global_data.h | 6 - include/wdt.h | 8 + test/dm/wdt.c | 90 +++++++- 12 files changed, 349 insertions(+), 61 deletions(-) create mode 100644 doc/device-tree-bindings/watchdog/gpio-wdt.txt create mode 100644 drivers/watchdog/gpio_wdt.c -- 2.31.1

5 33

[PATCH] mx7ulp: add getting a board serial number
by Oleksandr Suvorov 31 Aug '21

31 Aug '21

From: Ricardo Salveti <ricardo(a)foundries.io> Get Unique ID of SoC iMX7ULP, using the logic described in Fusemap (IMX7ULPRMB2_Rev0_Fusemap) attached in the i.MX 7ULP APRM [1]. [1] https://www.nxp.com/docs/en/reference-manual/IMX7ULPRMB2.pdf Signed-off-by: Ricardo Salveti <ricardo(a)foundries.io> Co-developed-by: Oleksandr Suvorov <oleksandr.suvorov(a)foundries.io> Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov(a)foundries.io> --- arch/arm/mach-imx/mx7ulp/soc.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c index 320f24dd29..d088ee093d 100644 --- a/arch/arm/mach-imx/mx7ulp/soc.c +++ b/arch/arm/mach-imx/mx7ulp/soc.c @@ -13,6 +13,7 @@ #include <asm/arch/sys_proto.h> #include <asm/mach-imx/boot_mode.h> #include <asm/mach-imx/hab.h> +#include <asm/setup.h> #include <linux/bitops.h> #define PMC0_BASE_ADDR 0x410a1000 @@ -363,3 +364,25 @@ enum boot_device get_boot_device(void) return boot_dev; } + +#ifdef CONFIG_SERIAL_TAG +/* + * OCOTP_CFG (SJC CHALLENGE, Unique ID) + * i.MX 7ULP Applications Processor Reference Manual, Rev. 0, 09/2020 + * + * OCOTP_CFG0 offset 0x4B0: 15:0 -> 15:0 bits of Unique ID + * OCOTP_CFG1 offset 0x4C0: 15:0 -> 31:16 bits of Unique ID + * OCOTP_CFG2 offset 0x4D0: 15:0 -> 47:32 bits of Unique ID + * OCOTP_CFG3 offset 0x4E0: 15:0 -> 63:48 bits of Unique ID + */ +void get_board_serial(struct tag_serialnr *serialnr) +{ + struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR; + struct fuse_bank *bank = &ocotp->bank[1]; + struct fuse_bank1_regs *fuse = + (struct fuse_bank1_regs *)bank->fuse_regs; + + serialnr->low = (fuse->cfg0 & 0xFFFF) + ((fuse->cfg1 & 0xFFFF) << 16); + serialnr->high = (fuse->cfg2 & 0xFFFF) + ((fuse->cfg3 & 0xFFFF) << 16); +} +#endif -- 2.31.1

2 2

How should we deal with actual hush odd behavior?
by Francis Laniel 31 Aug '21

31 Aug '21

Hi. I hope you are fine and the same for your family and friends. In July, a proposal to add a new shell for U-Boot was posted on the mailing list [1]. The community discussed a lot about this changes, some people did not agree with it because the new shell is not compatible with the actual one (hush) [2]. So, a proposal to update U-Boot actual hush to follow what they currently have in Busybox was made [3]. Porting 2021 Busybox hush to U-Boot seems, for me, to be a good idea as we would benefit from Busybox bug fixes as well as being compatible with actual hush (in theory). We could also add new features to U-Boot hush, like functions, as they were added to Busybox. Nonetheless, the idea of this port is to be compatible. In practice, I noted some cases when this is actually not the case. The first one can be related to how && and || operators were handled in hush. So, the following: false && false || true Returns 0 on Busybox 2021 hush and 1 on U-Boot. The behavior of 2021 is coherent with the definition of these operators [4]: > The return status of AND and OR lists is the exit > status of the last command executed in the list. An other example concerns variable expansion, where foo='bar "quux" is expanded to bar quux in U-Boot and bar "quux in Busybox. I do not have a real opinion on the second one, as I think local variable set in U-Boot scripts are quite simple as people do not try to do: foo="bar \"quux 'quuz' \"\"\"corge". The first one is maybe more problematic. Grepping "if test" shows me that the more complex if condition seems to be under the form: if first_test_ AND/OR second_test Here also, people seems to no try to write complex expression like: foo || bar; echo quux && quuz. So, porting Busybox 2021 hush can solve bugs we have currently in U-Boot, but what if fixing these bugs lead to a board script failing and so a device not booting... I would like to have the opinion of the community on this question. Best regards. --- [1] https://lists.denx.de/pipermail/u-boot/2021-July/453347.html [2] https://lists.denx.de/pipermail/u-boot/2021-July/453790.html [3] https://lists.denx.de/pipermail/u-boot/2021-July/453848.html [4] https://linux.die.net/man/1/bash

4 4