August 2022 - U-Boot

[PATCH v10 00/10] enable menu-driven UEFI variable maintenance
by Masahisa Kojima 17 Aug '22

17 Aug '22

This series adds the menu-driven UEFI boot variable maintenance through the "eficonfig" new command. This series also adds the removable media support in bootmenu. Initrd file selection and python based unit test are added in v10. Source code can be cloned with: $ git clone https://git.linaro.org/people/masahisa.kojima/u-boot.git -b eficonfig_upstream_v10 [Major Changes] - rebased v2022.07 - add initrd file selection - add python based unit test - there is detailed changelog in each commit Masahisa Kojima (10): efi_loader: move udevice pointer into struct efi_object eficonfig: menu-driven addition of UEFI boot option eficonfig: add "Edit Boot Option" menu entry menu: add KEY_PLUS and KEY_MINUS handling eficonfig: add "Change Boot Order" menu entry eficonfig: add "Delete Boot Option" menu entry bootmenu: add removable media entries doc:bootmenu: add description for UEFI boot support doc:eficonfig: add documentation for eficonfig command test: unit test for eficonfig cmd/Kconfig | 7 + cmd/Makefile | 1 + cmd/bootmenu.c | 106 +- cmd/eficonfig.c | 2103 +++++++++++++++++ common/menu.c | 6 + configs/sandbox_defconfig | 1 + doc/usage/cmd/bootmenu.rst | 74 + doc/usage/cmd/eficonfig.rst | 63 + doc/usage/index.rst | 1 + include/efi_config.h | 91 + include/efi_loader.h | 67 + include/menu.h | 2 + lib/efi_driver/efi_block_device.c | 3 +- lib/efi_loader/efi_bootmgr.c | 7 + lib/efi_loader/efi_boottime.c | 52 +- lib/efi_loader/efi_console.c | 70 + lib/efi_loader/efi_disk.c | 65 +- lib/efi_loader/efi_file.c | 75 +- lib/efi_loader/efi_helper.c | 13 + test/py/tests/test_eficonfig/conftest.py | 40 + .../py/tests/test_eficonfig/test_eficonfig.py | 325 +++ 21 files changed, 3109 insertions(+), 63 deletions(-) create mode 100644 cmd/eficonfig.c create mode 100644 doc/usage/cmd/eficonfig.rst create mode 100644 include/efi_config.h create mode 100644 test/py/tests/test_eficonfig/conftest.py create mode 100644 test/py/tests/test_eficonfig/test_eficonfig.py -- 2.17.1

4 19

[PATCH V4 1/2] mtd: allow getting MTD device associated with a specific DT node
by Rafał Miłecki 17 Aug '22

17 Aug '22

From: Rafał Miłecki <rafal(a)milecki.pl> MTD subsystem API allows interacting with MTD devices (e.g. reading, writing, handling bad blocks). So far a random driver could get MTD device only by its name (get_mtd_device_nm()). This change allows getting them also by a DT node. This API is required for drivers handling DT defined MTD partitions in a specific way (e.g. U-Boot (sub)partition with environment variables). Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> Acked-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- V3: First introduction of of_get_mtd_device_by_node() V4: Use EPROBE_DEFER Srinivas: in V3 Miquel said it's OK to push this patch through NVMEM --- drivers/mtd/mtdcore.c | 28 ++++++++++++++++++++++++++++ include/linux/mtd/mtd.h | 1 + 2 files changed, 29 insertions(+) diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c index 9eb0680db312..3613cc142f25 100644 --- a/drivers/mtd/mtdcore.c +++ b/drivers/mtd/mtdcore.c @@ -1154,6 +1154,34 @@ int __get_mtd_device(struct mtd_info *mtd) } EXPORT_SYMBOL_GPL(__get_mtd_device); +/** + * of_get_mtd_device_by_node - obtain an MTD device associated with a given node + * + * @np: device tree node + */ +struct mtd_info *of_get_mtd_device_by_node(struct device_node *np) +{ + struct mtd_info *mtd = NULL; + struct mtd_info *tmp; + int err; + + mutex_lock(&mtd_table_mutex); + + err = -EPROBE_DEFER; + mtd_for_each_device(tmp) { + if (mtd_get_of_node(tmp) == np) { + mtd = tmp; + err = __get_mtd_device(mtd); + break; + } + } + + mutex_unlock(&mtd_table_mutex); + + return err ? ERR_PTR(err) : mtd; +} +EXPORT_SYMBOL_GPL(of_get_mtd_device_by_node); + /** * get_mtd_device_nm - obtain a validated handle for an MTD device by * device name diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h index 955aee14b0f7..6fc841ceef31 100644 --- a/include/linux/mtd/mtd.h +++ b/include/linux/mtd/mtd.h @@ -677,6 +677,7 @@ extern int mtd_device_unregister(struct mtd_info *master); extern struct mtd_info *get_mtd_device(struct mtd_info *mtd, int num); extern int __get_mtd_device(struct mtd_info *mtd); extern void __put_mtd_device(struct mtd_info *mtd); +extern struct mtd_info *of_get_mtd_device_by_node(struct device_node *np); extern struct mtd_info *get_mtd_device_nm(const char *name); extern void put_mtd_device(struct mtd_info *mtd); -- 2.34.1

3 3

[PATCH v5 0/8] Add support for cyclic function execution infrastruture
by Stefan Roese 17 Aug '22

17 Aug '22

This patchset adds the basic infrastructure to periodically execute code, e.g. all 100ms. Examples for such functions might be LED blinking etc. The functions that are hooked into this cyclic list should be small timewise as otherwise the execution of the other code that relies on a high frequent polling (e.g. UART rx char ready check) might be delayed too much. This patch also adds the Kconfig option CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time for such a cyclic function. If it's execution time exceeds this time, this cyclic function will get removed from the cyclic list. How is this cyclic functionality executed? This patchset integrates the main function responsible for calling all registered cyclic functions cyclic_run() into the common WATCHDOG_RESET macro. This guarantees that cyclic_run() is executed very often, which is necessary for the cyclic functions to get scheduled and executed at their configured periods. This cyclic infrastructure will be used by a board specific function on the NIC23 MIPS Octeon board, which needs to check periodically, if a PCIe FLR has occurred. Ideas how to continue: One idea is to rename WATCHDOG_RESET to something like SCHEDULE and move the watchdog_reset call into this cyclic infrastructure as well. Or to perhaps move the shell UART RX ready polling to a cyclic function. It's also possible to extend the "cyclic" command, to support the creation of periodically executed shell commands (for testing etc). Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=229&view=results Aaron Williams (1): mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure Stefan Roese (7): time: Import time_after64() and friends from Linux cyclic: Add basic support for cyclic function execution infrastruture cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET cyclic: Integrate cyclic functionality at bootup in board_r/f cyclic: Add 'cyclic list' and 'cyclic demo' commands cyclic: Add documentation cyclic: Add a simple test MAINTAINERS | 7 + board/Marvell/octeon_nic23/board.c | 197 +++++++++++++++++++++++++++++ cmd/Kconfig | 16 +++ cmd/Makefile | 1 + cmd/cyclic.c | 85 +++++++++++++ common/Kconfig | 20 +++ common/Makefile | 1 + common/board_f.c | 2 + common/board_r.c | 2 + common/cyclic.c | 113 +++++++++++++++++ configs/octeon_nic23_defconfig | 3 + doc/develop/cyclic.rst | 50 ++++++++ doc/develop/index.rst | 1 + doc/usage/cmd/cyclic.rst | 45 +++++++ doc/usage/index.rst | 1 + fs/cramfs/uncompress.c | 2 +- include/cyclic.h | 110 ++++++++++++++++ include/time.h | 19 +++ include/watchdog.h | 23 +++- test/common/Makefile | 1 + test/common/cyclic.c | 34 +++++ test/test-main.c | 3 + 22 files changed, 732 insertions(+), 4 deletions(-) create mode 100644 cmd/cyclic.c create mode 100644 common/cyclic.c create mode 100644 doc/develop/cyclic.rst create mode 100644 doc/usage/cmd/cyclic.rst create mode 100644 include/cyclic.h create mode 100644 test/common/cyclic.c -- 2.37.2

1 8

[PATCH 0/3] sam9x60_curiosity PDA detection support
by Durai Manickam KR 17 Aug '22

17 Aug '22

This patch series adds the PDA detection support for sam9x60_curiosity rev4 boards. In rev4, the raspberry-pi display is replaced by PDA display. Durai Manickam KR (3): configs: sama9x60_curiosity: add onewire and eeprom drivers board: sam9x60_curiosity: add pda detect call at init time ARM: dts: at91: sam9x60_curiosity: add onewire support arch/arm/dts/at91-sam9x60_curiosity.dts | 17 +++++++++++++++++ .../atmel/sam9x60_curiosity/sam9x60_curiosity.c | 4 ++++ configs/sam9x60_curiosity_mmc_defconfig | 4 ++++ 3 files changed, 25 insertions(+) -- 2.25.1

2 4

[PATCH] mmc: atmel_sdhci: re-enable sdhci after SD Card re-insertion
by Sergiu Moga 17 Aug '22

17 Aug '22

Whenever the SD Card would be removed and then re-inserted while in the U-Boot command line, the `SDBPWR` bit of the `SDMMC_PCR` register would remain unset afterwards. In order for the bit to be set again after re-insertion, register an additional `deferred_probe` method that the DM would then transparently call. This method will call the generic `sdhci_probe` which will, during its execution flow, set this bit to 1. Signed-off-by: Sergiu Moga <sergiu.moga(a)microchip.com> Reported-by: Mihai Sain <mihai.sain(a)microchip.com> Reviewed-by: Eugen Hristev <eugen.hristev(a)microchip.com> --- drivers/mmc/atmel_sdhci.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c index 2b5ceeab94..37b0beeed4 100644 --- a/drivers/mmc/atmel_sdhci.c +++ b/drivers/mmc/atmel_sdhci.c @@ -52,6 +52,17 @@ struct atmel_sdhci_plat { struct mmc mmc; }; +static int atmel_sdhci_deferred_probe(struct sdhci_host *host) +{ + struct udevice *dev = host->mmc->dev; + + return sdhci_probe(dev); +} + +static const struct sdhci_ops atmel_sdhci_ops = { + .deferred_probe = atmel_sdhci_deferred_probe, +}; + static int atmel_sdhci_probe(struct udevice *dev) { struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev); @@ -104,6 +115,7 @@ static int atmel_sdhci_probe(struct udevice *dev) return ret; host->mmc->priv = host; + host->ops = &atmel_sdhci_ops; upriv->mmc = host->mmc; clk_free(&clk); -- 2.25.1

2 2

[PATCH v2 0/6] cmd/fru: move FRU handling support to common region
by Jae Hyun Yoo 16 Aug '22

16 Aug '22

Hello, The FRU handling was added as a Xilinx board dependent support but it is also useful for other boards, so this commit moves the FRU handling support to the common region so that it can be enabled by CONFIG_CMD_FRU. To provide manufacturer specific custom info fields and multi-records parsing, it refactors the FRU handling logic using linked list so that each board support can utilize them in their own custom way. This series adds 'Product Info' parsing support, usage document and py test script too. Please review! Thanks, Jae Graeme Gregory (1): cmd: fru: move FRU handling support to common region Jae Hyun Yoo (5): xilinx: common: refactor FRU handling support cmd: fru: fix a sandbox segfault issue cmd: fru: add product info area parsing support doc: fru: add documentation for the fru command test: py: fru: add a test for the fru command board/xilinx/Kconfig | 8 - board/xilinx/common/Makefile | 3 - board/xilinx/common/board.c | 68 ++- board/xilinx/common/fru.h | 108 ----- board/xilinx/common/fru_ops.c | 415 ----------------- cmd/Kconfig | 8 + cmd/Makefile | 1 + {board/xilinx/common => cmd}/fru.c | 54 ++- configs/sandbox64_defconfig | 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_noinst_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + configs/sandbox_vpl_defconfig | 1 + doc/usage/cmd/fru.rst | 144 ++++++ doc/usage/index.rst | 1 + include/fru.h | 146 ++++++ lib/Makefile | 1 + lib/fru_ops.c | 725 +++++++++++++++++++++++++++++ test/py/tests/test_fru.py | 47 ++ 20 files changed, 1178 insertions(+), 557 deletions(-) delete mode 100644 board/xilinx/common/fru.h delete mode 100644 board/xilinx/common/fru_ops.c rename {board/xilinx/common => cmd}/fru.c (50%) create mode 100644 doc/usage/cmd/fru.rst create mode 100644 include/fru.h create mode 100644 lib/fru_ops.c create mode 100644 test/py/tests/test_fru.py -- 2.25.1

2 10

[PATCH] [RFC] cmd: i2c: fix default address len for DM_I2C
by Tim Harvey 16 Aug '22

16 Aug '22

According to the comment block "The default {addr} parameter is one byte (.1) which works well for memories and registers with 8 bits of address space." While this is true for legacy I2C a default length of -1 is being passed for DM_I2C which results in a usage error. Restore the documented behavior by always using a default alen of 1. Signed-off-by: Tim Harvey <tharvey(a)gateworks.com> This is an RFC as I'm unclear if we want to restore the legacy usage or enforce a new usage (in which case the comment block should be updated) and I'm not clear if this is documented in other places. If the decision is to enforce a new usage then it is unclear to me how to specifiy the default alen as there is no command for that (i2c alen [len]?). --- cmd/i2c.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/cmd/i2c.c b/cmd/i2c.c index bd04b14024be..c57271479e81 100644 --- a/cmd/i2c.c +++ b/cmd/i2c.c @@ -118,17 +118,7 @@ static uchar i2c_no_probes[] = CONFIG_SYS_I2C_NOPROBES; #endif #define DISP_LINE_LEN 16 - -/* - * Default for driver model is to use the chip's existing address length. - * For legacy code, this is not stored, so we need to use a suitable - * default. - */ -#if CONFIG_IS_ENABLED(DM_I2C) -#define DEFAULT_ADDR_LEN (-1) -#else #define DEFAULT_ADDR_LEN 1 -#endif #if CONFIG_IS_ENABLED(DM_I2C) static struct udevice *i2c_cur_bus; -- 2.25.1

2 5

[RESEND PATCH v2 0/6] net: fm: Verify Fman microcode
by Sean Anderson 16 Aug '22

16 Aug '22

Surprisingly, Fman microcode does not seem to be verified. This series aims to rectify this by introducing an optional FIT wrapper. This wrapper is made mandatory if FIT_SIGNATURE is enabled. NXP boards do not use this config, so the microcode will remain unverified for them. This is OK, since we do not want to break existing systems. This series depends on [1]. There is no logical dependency, but they modify adjacent #includes, so the past patch will not apply cleanly unless that series is applied. [1] https://lore.kernel.org/u-boot/20220422173032.2259019-1-sean.anderson@seco.… Changes in v2: - Document helpers - Split off Fman microcode verification patches into their own series - Split helper refactoring into a patch adding the helpers and one patch per subsystem. Sean Anderson (6): ARMv8/sec_firmware: Remove SEC_FIRMWARE_FIT_CNF_NAME image: fit: Add some helpers for getting data ARMv8/sec_firmware: Convert to use fit_get_data_conf_prop cmd: fpga: Convert to use fit_get_data_node net: Convert fit verification to use fit_get_data_* net: fm: Add support for FIT firmware arch/arm/cpu/armv8/sec_firmware.c | 52 ++-------------------- boot/image-fit.c | 37 ++++++++++++++++ cmd/fpga.c | 24 +++------- drivers/net/fm/fm.c | 18 ++++++++ drivers/net/fsl-mc/mc.c | 30 ++----------- drivers/net/pfe_eth/pfe_firmware.c | 40 +---------------- include/image.h | 70 ++++++++++++++++++++++++++++++ 7 files changed, 139 insertions(+), 132 deletions(-) -- 2.35.1.1320.gc452695387.dirty

2 10

[PATCH 0/5] arm: mvebu: Automatically detect CONFIG_SYS_TCLK
by Pali Rohár 16 Aug '22

16 Aug '22

This patch series automatically detects CONFIG_SYS_TCLK value, set it in global mach/soc.h file and remove manual CONFIG_SYS_TCLK value from all mvebu/kirkwood board config files. So it just a cleanup to avoid defining custom macros in board config files which can be automatically detected. Could you test these patches on a38x and a37x platforms that nothing is broken? I tested them on a38x Turris Omnia. Pali Rohár (5): arm: mvebu: a38x: Detect CONFIG_SYS_TCLK from SAR register arm: mvebu: a37x: Detect CONFIG_SYS_TCLK from SAR register arm: mvebu: msys: Set CONFIG_SYS_TCLK globally arm: mvebu: axp: Set CONFIG_SYS_TCLK globally arm: kirkwood: Do not overwrite CONFIG_SYS_TCLK arch/arm/mach-kirkwood/include/mach/kw88f6281.h | 2 -- arch/arm/mach-mvebu/include/mach/soc.h | 15 ++++++++++----- include/configs/clearfog.h | 1 - include/configs/controlcenterdc.h | 2 -- include/configs/crs3xx-98dx3236.h | 1 - include/configs/db-88f6720.h | 1 - include/configs/db-88f6820-amc.h | 2 -- include/configs/db-88f6820-gp.h | 2 -- include/configs/db-mv784mp-gp.h | 1 - include/configs/db-xc3-24g4xg.h | 1 - include/configs/ds414.h | 1 - include/configs/helios4.h | 1 - include/configs/lacie_kw.h | 5 ----- include/configs/lsxl.h | 2 -- include/configs/maxbcm.h | 1 - include/configs/theadorable.h | 1 - include/configs/turris_omnia.h | 1 - include/configs/x530.h | 2 -- 18 files changed, 10 insertions(+), 32 deletions(-) -- 2.20.1

4 19

[PATCHv3] drivers: tee: i2c: support the NXP SE05x probe errata
by Jorge Ramirez-Ortiz 16 Aug '22

16 Aug '22

Early instantiation of this I2C device would lock up when being probed. https://www.nxp.com/docs/en/errata/SE050_Erratasheet.pdf 3.2.2 In scenarios of detecting I2C ICs on the bus using an empty I2C frame containing only the address the SE050 will block the I2C bus. Tested on STM32MP1 Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> Acked-by: Oleksandr Suvorov <oleksandr.suvorov(a)foundries.io> --- drivers/tee/optee/Kconfig | 14 +++++++++++++ drivers/tee/optee/i2c.c | 44 +++++++++++++++++++++++++++++++++++---- 2 files changed, 54 insertions(+), 4 deletions(-) diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index d03028070b..a80ddaed2c 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -37,6 +37,20 @@ config OPTEE_TA_SCP03 help Enables support for controlling (enabling, provisioning) the Secure Channel Protocol 03 operation in the OP-TEE SCP03 TA. + +config TEE_I2C_NXP_SE05X_ERRATA + bool "Enable NXP SE05X Errata" + select TEE_I2C_NXP_SE05X_ERRATA_IN_BUS + default n + help + This config prevents the I2C trampoline driver from probing + on every transfer. + +config TEE_I2C_NXP_SE05X_ERRATA_IN_BUS + int "I2C bus where to apply the NXP SE05X errata" + depends on TEE_I2C_NXP_SE05X_ERRATA + default 0 + endmenu endif diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c index ef4e10f991..a3ea34d4a2 100644 --- a/drivers/tee/optee/i2c.c +++ b/drivers/tee/optee/i2c.c @@ -3,13 +3,18 @@ * Copyright (c) 2020 Foundries.io Ltd */ +#define LOG_CATEGORY UCLASS_I2C + #include <common.h> #include <dm.h> #include <i2c.h> +#include <stdlib.h> #include <tee.h> #include "optee_msg.h" #include "optee_private.h" +#define NXP_SE05X_ADDR 0x48 + static int check_xfer_flags(struct udevice *chip, uint tee_flags) { uint flags; @@ -30,6 +35,30 @@ static int check_xfer_flags(struct udevice *chip, uint tee_flags) return 0; } +static struct udevice *get_chip_dev(int bnum, int addr) +{ + struct udevice *chip; + struct udevice *bus; + + if (IS_ENABLED(CONFIG_TEE_I2C_NXP_SE05X_ERRATA)) { + if (bnum == CONFIG_TEE_I2C_NXP_SE05X_ERRATA_IN_BUS && + addr == NXP_SE05X_ADDR) { + if (uclass_get_device_by_seq(UCLASS_I2C, bnum, &bus)) + return NULL; + + if (i2c_get_chip(bus, addr, 0, &chip)) + return NULL; + + return chip; + } + } + + if (i2c_get_chip_for_busnum(bnum, addr, 0, &chip)) + return NULL; + + return chip; +} + void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg) { const u8 attr[] = { @@ -38,7 +67,8 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg) OPTEE_MSG_ATTR_TYPE_RMEM_INOUT, OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT, }; - struct udevice *chip_dev; + struct udevice *chip_dev = NULL; + struct tee_shm *shm; u8 *buf; int ret; @@ -56,9 +86,9 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg) if (!buf) goto bad; - if (i2c_get_chip_for_busnum((int)arg->params[0].u.value.b, - (int)arg->params[0].u.value.c, - 0, &chip_dev)) + chip_dev = get_chip_dev((int)arg->params[0].u.value.b, + (int)arg->params[0].u.value.c); + if (!chip_dev) goto bad; if (check_xfer_flags(chip_dev, arg->params[1].u.value.a)) @@ -66,10 +96,16 @@ void optee_suppl_cmd_i2c_transfer(struct optee_msg_arg *arg) switch (arg->params[0].u.value.a) { case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD: + log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD %d\n", + (size_t)arg->params[2].u.rmem.size); + ret = dm_i2c_read(chip_dev, 0, buf, (size_t)arg->params[2].u.rmem.size); break; case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR: + log_debug("OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR %d\n", + (size_t)arg->params[2].u.rmem.size); + ret = dm_i2c_write(chip_dev, 0, buf, (size_t)arg->params[2].u.rmem.size); break; -- 2.34.1

1 0