December 2022 - U-Boot

[PATCH 3/3] efi_loader: adjust sorting of capsules
by Heinrich Schuchardt 29 Dec '22

29 Dec '22

The UEFI specification requires to apply capsules in alphabetical order. The current implementation only sorted by the first letter due to using strcmp() which will stop at the first zero byte. * Provide function u16_strcasecmp() for case insensitive comparision of UTF-16 strings * Provide a unit test for u16_strcasecmp() * Use the function to sort capsules. We do not implement the special handling of the rightmost period of capsule names yet. Heinrich Schuchardt (3): lib: add function u16_strcasecmp() test: unit test for u16_strcasecmp() efi_loader: adjust sorting of capsules include/charset.h | 13 +++++++++++++ lib/charset.c | 27 +++++++++++++++++++++++++++ lib/efi_loader/efi_capsule.c | 9 ++++++--- test/unicode_ut.c | 25 +++++++++++++++++++++++++ 4 files changed, 71 insertions(+), 3 deletions(-) -- 2.37.2

1 3

[PATCH 1/1] efi_loader: use u16_strlen() in efi_var_mem_ins()
by Heinrich Schuchardt 29 Dec '22

29 Dec '22

Don't duplicate library functionality. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- lib/efi_loader/efi_var_mem.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c index 0bac594e00..d71ccb31df 100644 --- a/lib/efi_loader/efi_var_mem.c +++ b/lib/efi_loader/efi_var_mem.c @@ -142,14 +142,10 @@ efi_status_t __efi_runtime efi_var_mem_ins( { u16 *data; struct efi_var_entry *var; - u32 var_name_len; var = (struct efi_var_entry *) ((uintptr_t)efi_var_buf + efi_var_buf->length); - for (var_name_len = 0; variable_name[var_name_len]; ++var_name_len) - ; - ++var_name_len; - data = var->name + var_name_len; + data = var->name + u16_strlen(var->name) + 1; if ((uintptr_t)data - (uintptr_t)efi_var_buf + size1 + size2 > EFI_VAR_BUF_SIZE) -- 2.37.2

1 0

[PATCH 1/1] efi_loader: typo non-volatile in efi_var_restore
by Heinrich Schuchardt 29 Dec '22

29 Dec '22

It is volatile variables that we do not allow to be restored from file. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- lib/efi_loader/efi_var_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c index 3d58caa13d..de9ba8de99 100644 --- a/lib/efi_loader/efi_var_file.c +++ b/lib/efi_loader/efi_var_file.c @@ -176,7 +176,7 @@ efi_status_t efi_var_restore(struct efi_var_file *buf, bool safe) data = var->name + u16_strlen(var->name) + 1; /* - * Secure boot related and non-volatile variables shall only be + * Secure boot related and volatile variables shall only be * restored from U-Boot's preseed. */ if (!safe && -- 2.37.2

2 1

[PATCH] efi_loader: avoid adding variables twice
by Ilias Apalodimas 29 Dec '22

29 Dec '22

When the efi subsystem starts we restore variables that are both in a file or stored into the .efi_runtime section of U-Boot. However once a variable gets created or changed the preseeded entries will end up in the file. As a consequence on the next boot we will end up adding identical variable entries twice. Fix this by checking if the to be inserted variable already exists. Also swap the restoration order and start with the file instead of the builtin variables, so a user can replace the preseeded ones if needed. Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> --- lib/efi_loader/efi_var_mem.c | 3 +++ lib/efi_loader/efi_variable.c | 6 +++--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c index 0bac594e004d..17a2ad2e4951 100644 --- a/lib/efi_loader/efi_var_mem.c +++ b/lib/efi_loader/efi_var_mem.c @@ -144,6 +144,9 @@ efi_status_t __efi_runtime efi_var_mem_ins( struct efi_var_entry *var; u32 var_name_len; + if (efi_var_mem_find(vendor, variable_name, NULL)) + return EFI_SUCCESS; + var = (struct efi_var_entry *) ((uintptr_t)efi_var_buf + efi_var_buf->length); for (var_name_len = 0; variable_name[var_name_len]; ++var_name_len) diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c index 8ca2d85694c8..503a33ed65c5 100644 --- a/lib/efi_loader/efi_variable.c +++ b/lib/efi_loader/efi_variable.c @@ -425,6 +425,9 @@ efi_status_t efi_init_variables(void) if (ret != EFI_SUCCESS) return ret; + ret = efi_var_from_file(); + if (ret != EFI_SUCCESS) + return ret; if (IS_ENABLED(CONFIG_EFI_VARIABLES_PRESEED)) { ret = efi_var_restore((struct efi_var_file *) __efi_var_file_begin, true); @@ -432,9 +435,6 @@ efi_status_t efi_init_variables(void) log_err("Invalid EFI variable seed\n"); } - ret = efi_var_from_file(); - if (ret != EFI_SUCCESS) - return ret; return efi_init_secure_state(); } -- 2.38.1

2 1

[PATCH v2] efi_loader: avoid adding variables twice
by Ilias Apalodimas 29 Dec '22

29 Dec '22

When the efi subsystem starts we restore variables that are both in a file or stored into the .efi_runtime section of U-Boot. However once a variable gets created or changed the preseeded entries will end up in the file. As a consequence on the next boot we will end up adding identical variable entries twice. Fix this by checking if the to be inserted variable already exists. Also swap the restoration order and start with the file instead of the builtin variables, so a user can replace the preseeded ones if needed. Tested-by: Leo Yan <leo.yan(a)linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> --- changes since v1: - Move the check in efi_var_restore(), since it would break updating variables in efi_var_mem_ins() lib/efi_loader/efi_var_file.c | 2 ++ lib/efi_loader/efi_variable.c | 6 +++--- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c index 3d58caa13da2..d70a72d12684 100644 --- a/lib/efi_loader/efi_var_file.c +++ b/lib/efi_loader/efi_var_file.c @@ -187,6 +187,8 @@ efi_status_t efi_var_restore(struct efi_var_file *buf, bool safe) continue; if (!var->length) continue; + if (efi_var_mem_find(&var->guid, var->name, NULL)) + continue; ret = efi_var_mem_ins(var->name, &var->guid, var->attr, var->length, data, 0, NULL, var->time); diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c index 8ca2d85694c8..503a33ed65c5 100644 --- a/lib/efi_loader/efi_variable.c +++ b/lib/efi_loader/efi_variable.c @@ -425,6 +425,9 @@ efi_status_t efi_init_variables(void) if (ret != EFI_SUCCESS) return ret; + ret = efi_var_from_file(); + if (ret != EFI_SUCCESS) + return ret; if (IS_ENABLED(CONFIG_EFI_VARIABLES_PRESEED)) { ret = efi_var_restore((struct efi_var_file *) __efi_var_file_begin, true); @@ -432,9 +435,6 @@ efi_status_t efi_init_variables(void) log_err("Invalid EFI variable seed\n"); } - ret = efi_var_from_file(); - if (ret != EFI_SUCCESS) - return ret; return efi_init_secure_state(); } -- 2.38.1

1 0

Re: Bug#1012269: u-boot-exynos on Odroid XU4 searches for exynos5422-smdk5420xu4.dtb instead of exynos5422-odroidxu4.dtb
by Vagrant Cascadian 29 Dec '22

29 Dec '22

On 2022-12-25, Jochen Sprickerhof wrote: > * Vagrant Cascadian <vagrant(a)debian.org> [2022-11-04 14:22]: >>On 2022-06-02, Jochen Sprickerhof wrote: >>> with the latest u-boot-exynos in unstable it tries to load >>> exynos5422-smdk5420xu4.dtb whereas linux-image-5.17.0-3-armmp only >>> contains exynos5422-odroidxu4.dtb. This was not the case with 2022.01+dfsg-2: >>> >>> U-Boot 2022.04+dfsg-2+b1 (May 14 2022 - 21:25:25 +0000) for ODROID-XU3/XU4/HC1/HC2 >>> [..] >>> Retrieving file: /usr/lib/linux-image-5.17.0-3-armmp/exynos5422-smdk5420xu4.dtb >>> ** File not found /usr/lib/linux-image-5.17.0-3-armmp/exynos5422-smdk5420xu4.dtb ** >>> >>> U-Boot 2022.01+dfsg-2 (Jan 26 2022 - 19:58:27 +0000) for ODROID-XU3/XU4/HC1/HC2 >>> [..] >>> Retrieving file: /usr/lib/linux-image-5.17.0-3-armmp/exynos5422-odroidxu4.dtb ... >>My guess is this was broken in 2022.04, and fixed in 2022.07-rc5 with >>this commit: ... >>Could you test 2022.10 from unstable and/or pull 2022.07 from >>snapshots.debian.org and test it? > > I finally found time to test, sorry for the delay. Still the same > problem: > > U-Boot 2022.10+dfsg-2 (Dec 23 2022 - 23:18:44 +0000) for ODROID-XU3/XU4/HC1/HC2 > > CPU: Exynos5422 @ 800 MHz > DRAM: 2 GiB > Core: 73 devices, 12 uclasses, devicetree: separate > MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 2 > Loading Environment from MMC... *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > Model: Odroid XU3/XU4/HC1/HC2 based on Exynos5422 > Type: xu4 > Boot device: MMC(0) ... > Retrieving file: /usr/lib/linux-image-6.0.0-6-armmp/exynos5422-smdk5420xu4.dtb > ** File not found /usr/lib/linux-image-6.0.0-6-armmp/exynos5422-smdk5420xu4.dtb ** ... > The workaround with: > > ln -s exynos5422-odroidxu4.dtb exynos5422-smdk5420xu4.dtb Hrm. This suggests the fix might not have been effective, which should have been included in 2022.07... CCing upstream... commit e744bf3a4ba442a0e9ee1c509c70e1452e3a15d0 Author: Tom Rini <trini(a)konsulko.com> Date: Wed Jun 8 14:30:14 2022 -0400 odroid_xu3: Fix board environment variable When migrating CONFIG_CONS_INDEX to Kconfig, on this platform we changed what "board" evaluated to in the environment. This in turn meant that we would no longer try and find the correct fdtfile via the normal distro boot logic. Fix this by overriding board in the default environment, as done on other platforms where CONFIG_SYS_BOARD is not what we want to be in the board environment variable. Fixes: f76750d11133 ("Convert CONFIG_CONS_INDEX et al to Kconfig") Reported-by: Gabriel Hojda <ghojda(a)yo2urs.ro> Tested-by: Gabriel Hojda <ghojda(a)yo2urs.ro> Signed-off-by: Tom Rini <trini(a)konsulko.com> Alternately... did you at any point run saveenv? This might have stored the incorrect value... and then it might not probe for the correct value. live well, vagrant

2 1

[PATCH] riscv: bypass malloc when spl fit boots from ram
by Rick Chen 28 Dec '22

28 Dec '22

When fit image boots from ram, the payload will be prepared in the address of SPL_LOAD_FIT_ADDRESS. In spl fit generic flow, it will malloc another memory address and copy whole fit image to this malloc address. But it is un-necessary for booting from RAM. This patch improves this flow by declare the board_spl_fit_buffer_addr() to replace the original one. The larger image size (eq: Kernel Image 10~20MB), it can save more booting time. Also enhance memcpy function by checking source and destination address. If they are the same address, just return and don't copy data anymore. Signed-off-by: Rick Chen <rick(a)andestech.com> --- arch/riscv/lib/memcpy.S | 2 ++ arch/riscv/lib/spl.c | 16 ++++++++++++++++ 2 files changed, 18 insertions(+) diff --git a/arch/riscv/lib/memcpy.S b/arch/riscv/lib/memcpy.S index 00672c19ad..9884077c93 100644 --- a/arch/riscv/lib/memcpy.S +++ b/arch/riscv/lib/memcpy.S @@ -9,6 +9,7 @@ /* void *memcpy(void *, const void *, size_t) */ ENTRY(__memcpy) WEAK(memcpy) + beq a0, a1, .copy_end /* Save for return value */ mv t6, a0 @@ -121,6 +122,7 @@ WEAK(memcpy) 2: mv a0, t6 +.copy_end: ret .Lmisaligned_word_copy: diff --git a/arch/riscv/lib/spl.c b/arch/riscv/lib/spl.c index f4d3b67e5d..18f86ee207 100644 --- a/arch/riscv/lib/spl.c +++ b/arch/riscv/lib/spl.c @@ -61,3 +61,19 @@ void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image) #endif image_entry(gd->arch.boot_hart, fdt_blob); } + +#ifdef CONFIG_SPL_RAM_SUPPORT +struct legacy_img_hdr *spl_get_load_buffer(ssize_t offset, size_t size) +{ + return (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + offset); +} + +void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len) +{ + void *buf; + + buf = spl_get_load_buffer(0, sectors * bl_len); + + return buf; +} +#endif -- 2.17.1

3 4

[GIT PULL] Please pull u-boot-pmic master
by Jaehoon Chung 27 Dec '22

27 Dec '22

Dear Tom, Please pull u-boot-pmic master into u-boot master branch. If there is a problem, let me know, plz Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-pmic/-/pipelines/14522 The following changes since commit e1befc8512fe4f67056a6e4b5cd2ab936abc35c6: Merge tag 'tpm-23122022' of https://source.denx.de/u-boot/custodians/u-boot-tpm (2022-12-23 07:46:41 -0500) are available in the Git repository at: git@source.denx.de:u-boot/custodians/u-boot-pmic.git master for you to fetch changes up to dbedf4a56b49544b0f9174856a14bd6be2d9e641: power: regulator: Add support for NPCM8xx (2022-12-26 15:44:00 +0900) ---------------------------------------------------------------- Jim Liu (1): power: regulator: Add support for NPCM8xx drivers/power/regulator/Kconfig | 8 ++++++++ drivers/power/regulator/Makefile | 1 + drivers/power/regulator/npcm8xx_regulator.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 141 insertions(+) create mode 100644 drivers/power/regulator/npcm8xx_regulator.c

2 1

[ANN] U-Boot v2023.01-rc4 released
by Tom Rini 26 Dec '22

26 Dec '22

Hey all, Here's -rc4, on schedule. I believe this should resolve the case Fedora showed where some binaries are allowed to be missing, IF a flag is also passed to make. We've got one more patch to make external optional binaries be more clearly supported, to pull in still. In terms of a changelog, git log --merges v2023.01-rc3..v2023.01-rc4 contains what I've pulled but as always, better PR messages and tags will provide better results here. Looking forward, the schedule is for now rcs every other Monday, and with final release on January 9th, 2023. Thanks all! -- Tom

3 9

[PATCH v2] power: regulator: Add support for NPCM8xx
by Jim Liu 26 Dec '22

26 Dec '22

Add support for setting nuvoton BMC NPCM845 voltage supply. Signed-off-by: Jim Liu <JJLIU0(a)nuvoton.com> --- Changes for v2: - modify Kconfig description - modify get_value function --- drivers/power/regulator/Kconfig | 8 ++ drivers/power/regulator/Makefile | 1 + drivers/power/regulator/npcm8xx_regulator.c | 132 ++++++++++++++++++++ 3 files changed, 141 insertions(+) create mode 100644 drivers/power/regulator/npcm8xx_regulator.c diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig index c519e066ef..c02e6377d8 100644 --- a/drivers/power/regulator/Kconfig +++ b/drivers/power/regulator/Kconfig @@ -128,6 +128,14 @@ config DM_REGULATOR_MAX77686 features for REGULATOR MAX77686. The driver implements get/set api for: value, enable and mode. +config DM_REGULATOR_NPCM8XX + bool "Enable Driver Model for NPCM8xx voltage supply" + depends on DM_REGULATOR && ARCH_NPCM8XX + help + Enable support for configuring voltage supply on NPCM8XX SoC. The + voltage supplies support two voltage levels and the driver implements + get/set api for setting the value. + config DM_REGULATOR_FAN53555 bool "Enable Driver Model for REGULATOR FAN53555" depends on DM_PMIC_FAN53555 diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile index bc736068bc..68e4c0f9dd 100644 --- a/drivers/power/regulator/Makefile +++ b/drivers/power/regulator/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o obj-$(CONFIG_REGULATOR_AS3722) += as3722_regulator.o obj-$(CONFIG_$(SPL_)DM_REGULATOR_DA9063) += da9063.o obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o +obj-$(CONFIG_DM_REGULATOR_NPCM8XX) += npcm8xx_regulator.o obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o obj-$(CONFIG_$(SPL_)DM_REGULATOR_BD71837) += bd71837.o obj-$(CONFIG_$(SPL_)DM_REGULATOR_PCA9450) += pca9450.o diff --git a/drivers/power/regulator/npcm8xx_regulator.c b/drivers/power/regulator/npcm8xx_regulator.c new file mode 100644 index 0000000000..fcd1058cdf --- /dev/null +++ b/drivers/power/regulator/npcm8xx_regulator.c @@ -0,0 +1,132 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) 2022 Nuvoton Technology Corp. + */ + +#include <common.h> +#include <dm.h> +#include <asm/io.h> +#include <dm/device_compat.h> +#include <power/regulator.h> + +#define REG_VSRCR 0xf08000e8 /* Voltage Supply Control Register */ + +/* Supported voltage levels (uV) */ +static const u32 volts_type1[] = { 3300000, 1800000 }; +static const u32 volts_type2[] = { 1000000, 1800000 }; +#define VOLT_LEV0 0 +#define VOLT_LEV1 1 + +struct volt_supply { + char *name; + const u32 *volts; + u32 reg_shift; /* Register bit offset for setting voltage */ +}; + +static const struct volt_supply npcm8xx_volt_supps[] = { + {"v1", volts_type1, 0}, + {"v2", volts_type1, 1}, + {"v3", volts_type1, 2}, + {"v4", volts_type1, 3}, + {"v5", volts_type1, 4}, + {"v6", volts_type1, 5}, + {"v7", volts_type1, 6}, + {"v8", volts_type1, 7}, + {"v9", volts_type1, 8}, + {"v10", volts_type1, 9}, + {"v11", volts_type2, 10}, + {"v12", volts_type1, 11}, + {"v13", volts_type1, 12}, + {"v14", volts_type2, 13}, + {"vsif", volts_type1, 14}, + {"vr2", volts_type1, 30}, +}; + +static const struct volt_supply *npcm8xx_volt_supply_get(const char *name) +{ + int i; + + for (i = 0; i < ARRAY_SIZE(npcm8xx_volt_supps); i++) { + if (!strcmp(npcm8xx_volt_supps[i].name, name)) + return &npcm8xx_volt_supps[i]; + } + + return NULL; +} + +static int npcm8xx_regulator_set_value(struct udevice *dev, int uV) +{ + struct dm_regulator_uclass_plat *uc_pdata; + const struct volt_supply *supp; + u32 val, level; + + uc_pdata = dev_get_uclass_plat(dev); + if (!uc_pdata) + return -ENXIO; + + dev_dbg(dev, "%s set_value: %d\n", uc_pdata->name, uV); + supp = npcm8xx_volt_supply_get(uc_pdata->name); + if (!supp) + return -ENOENT; + + if (uV == supp->volts[VOLT_LEV0]) + level = VOLT_LEV0; + else if (uV == supp->volts[VOLT_LEV1]) + level = VOLT_LEV1; + else + return -EINVAL; + + /* Set voltage level */ + val = readl(REG_VSRCR); + val &= ~BIT(supp->reg_shift); + val |= level << supp->reg_shift; + writel(val, REG_VSRCR); + + return 0; +} + +static int npcm8xx_regulator_get_value(struct udevice *dev) +{ + struct dm_regulator_uclass_plat *uc_pdata; + const struct volt_supply *supp; + u32 val; + + uc_pdata = dev_get_uclass_plat(dev); + if (!uc_pdata) + return -ENXIO; + + supp = npcm8xx_volt_supply_get(uc_pdata->name); + if (!supp) + return -ENOENT; + + val = readl(REG_VSRCR) & BIT(supp->reg_shift); + + dev_dbg(dev, "%s get_value: %d\n", uc_pdata->name, + val ? supp->volts[VOLT_LEV1] : supp->volts[VOLT_LEV0]); + + return val ? supp->volts[VOLT_LEV1] : supp->volts[VOLT_LEV0]; +} + +static int npcm8xx_regulator_set_enable(struct udevice *dev, bool enable) +{ + /* Always on */ + return 0; +} + +static const struct dm_regulator_ops npcm8xx_regulator_ops = { + .set_value = npcm8xx_regulator_set_value, + .get_value = npcm8xx_regulator_get_value, + .set_enable = npcm8xx_regulator_set_enable, +}; + +static const struct udevice_id npcm8xx_regulator_ids[] = { + { .compatible = "regulator-npcm845" }, + { }, +}; + +U_BOOT_DRIVER(regulator_npcm8xx) = { + .name = "regulator_npcm845", + .id = UCLASS_REGULATOR, + .ops = &npcm8xx_regulator_ops, + .of_match = npcm8xx_regulator_ids, +}; -- 2.17.1

2 1