July 2023 - U-Boot

[PATCH 1/1] tools/fdt_add_pubkey: error handling in add_pubkey
by Heinrich Schuchardt 31 Jul '23

31 Jul '23

* If info is NULL, do not dereference it. * If mmap fails, print an error message. Fixes: 30238e99619c ("tools: add fdt_add_pubkey") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- tools/fdt_add_pubkey.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/fdt_add_pubkey.c b/tools/fdt_add_pubkey.c index 5582d7a8ef..7843a006f0 100644 --- a/tools/fdt_add_pubkey.c +++ b/tools/fdt_add_pubkey.c @@ -89,8 +89,10 @@ static int add_pubkey(struct image_sign_info *info) struct stat dest_sbuf; size_t size_inc = 0; - if (!info) + if (!info) { fprintf(stderr, "Error: info is NULL in %s\n", __func__); + return -EINVAL; + } do { if (destfd >= 0) { @@ -104,7 +106,7 @@ static int add_pubkey(struct image_sign_info *info) destfd = mmap_fdt(cmdname, keydest, size_inc, &dest_blob, &dest_sbuf, false, false); if (destfd < 0) - exit(EXIT_FAILURE); + return -ENOSPC; ret = info->crypto->add_verify_data(info, dest_blob); if (ret == -ENOSPC) -- 2.40.1

3 2

[PATCH] dm: Correct DM_FLAG_ comment
by Bin Meng 31 Jul '23

31 Jul '23

The macros are prefixed with DM_FLAG_, not DM_FLAGS_. Signed-off-by: Bin Meng <bmeng(a)tinylab.org> --- include/dm/device.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/dm/device.h b/include/dm/device.h index b86bf90609..e54cb6bca4 100644 --- a/include/dm/device.h +++ b/include/dm/device.h @@ -367,7 +367,7 @@ struct udevice_id { * @ops: Driver-specific operations. This is typically a list of function * pointers defined by the driver, to implement driver functions required by * the uclass. - * @flags: driver flags - see `DM_FLAGS_...` + * @flags: driver flags - see `DM_FLAG_...` * @acpi_ops: Advanced Configuration and Power Interface (ACPI) operations, * allowing the device to add things to the ACPI tables passed to Linux */ -- 2.25.1

2 1

[PATCH v2 1/1] efi_loader: overflow in efi_allocate_pages
by Heinrich Schuchardt 31 Jul '23

31 Jul '23

On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which does not occur in 64bit arithmetics. An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated as an error. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- v2: %s/size/sizeof/ lib/efi_loader/efi_memory.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c index e2ca78d935..9de6cf6010 100644 --- a/lib/efi_loader/efi_memory.c +++ b/lib/efi_loader/efi_memory.c @@ -487,7 +487,7 @@ efi_status_t efi_allocate_pages(enum efi_allocate_type type, enum efi_memory_type memory_type, efi_uintn_t pages, uint64_t *memory) { - u64 len = pages << EFI_PAGE_SHIFT; + u64 len; efi_status_t ret; uint64_t addr; @@ -497,6 +497,11 @@ efi_status_t efi_allocate_pages(enum efi_allocate_type type, return EFI_INVALID_PARAMETER; if (!memory) return EFI_INVALID_PARAMETER; + len = (u64)pages << EFI_PAGE_SHIFT; + /* Catch possible overflow on 64bit systems */ + if (sizeof(efi_uintn_t) == sizeof(u64) && + (len >> EFI_PAGE_SHIFT) != (u64)pages) + return EFI_OUT_OF_RESOURCES; switch (type) { case EFI_ALLOCATE_ANY_PAGES: -- 2.40.1

2 2

Pull request for spl-2023-10-rc2
by Heinrich Schuchardt 31 Jul '23

31 Jul '23

Dear Tom, The following changes since commit a36d59ba99a19c777d896d4c70e75975654e2831: Merge tag 'efi-2023-10-rc2' of https://source.denx.de/u-boot/custodians/u-boot-efi (2023-07-28 12:48:00 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/spl-2023-10-rc2 for you to fetch changes up to 7d4c8cfe2547596d07c51b2f38cde8d4c75f17fc: spl: initialize PCI before booting (2023-07-30 18:53:08 +0200) Gitlab CI showed not issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/17127 ---------------------------------------------------------------- Pull request for spl-2023-10-rc2 SPL: * use CONFIG_SPL_FS_LOAD_PAYLOAD_NAME when booting from NVMe * initialize PCI before booting ---------------------------------------------------------------- Heinrich Schuchardt (5): spl: blk: use CONFIG_SPL_FS_LOAD_PAYLOAD_NAME part: check CONFIG_IS_ENABLED(ENV_SUPPORT) spl: blk: partition numbers are hexadecimal spl: CONFIG_SPL_PCI_PNP should depend on CONFIG_SPL_PCI spl: initialize PCI before booting common/spl/spl.c | 7 +++++++ common/spl/spl_blk_fs.c | 4 ++-- common/spl/spl_nvme.c | 5 ----- disk/part.c | 8 +++++--- drivers/pci/Kconfig | 3 ++- 5 files changed, 16 insertions(+), 11 deletions(-)

2 1

[PATCH 0/6] Add SGMII support for MAIN CPSW on TI's J7200 SoC
by Siddharth Vadapalli 31 Jul '23

31 Jul '23

Hello, This series adds support for SGMII mode to the CPSW driver to enable the functionality on TI's J7200 SoC. Supporting SGMII mode also requires changes to the WIZ driver which acts as a wrapper for the SerDes used by the CPSW MAC to transmit data to the Ethernet PHY daughtercard mounted on the I2C GPIO Expander 2 connector on the J7200 EVM. Powering on and resetting the Ethernet PHY requires MDIO support which is added to the CPSW driver. For supporting DMA transactions from the MAIN CPSW instance to the A72 Host on J7200 SoC, the corresponding PSI-L endpoint information is added for the J721E SoC, which is applicable to J7200 SoC as well. The SGMII daughtercard used for testing SGMII mode has TI's DP83869 PHY. Thus, enable the config for DP83869 driver functionality. Also, enable GPIO HOG config. **NOTE**: This series is based on top of commit: 0beb649053 MAINTAINERS: correct at91 tree link and depends on the following patch being merged as well: Link: https://patchwork.ozlabs.org/project/uboot/patch/20230614222853.574427-1-da… Regards, Siddharth. Siddharth Vadapalli (4): net: ti: am65-cpsw-nuss: Add support for SGMII mode phy: ti: phy-j721e-wiz: Add SGMII support in wiz driver for J7200 phy: ti: j721e-wiz: Add SGMII support in WIZ driver for J721E configs: j7200_evm_a72: Enable configs for SGMII support with MAIN CPSW0 Suman Anna (2): dma: ti: Update J21E PSIL endpoint information for MAIN CPSW0 net: ti: am65-cpsw-nuss: Add logic to support MDIO reset configs/j7200_evm_a72_defconfig | 2 ++ drivers/dma/ti/k3-psil-j721e.c | 17 ++++++++-- drivers/net/ti/am65-cpsw-nuss.c | 57 ++++++++++++++++++++++++++++++++- drivers/phy/ti/phy-j721e-wiz.c | 21 ++++++++---- 4 files changed, 87 insertions(+), 10 deletions(-) -- 2.34.1

2 10

[PATCH 1/5] x86: fsp: Use mtrr_set_next_var() for graphics memory
by Bin Meng 31 Jul '23

31 Jul '23

At present this uses mtrr_add_request() & mtrr_commit() combination to program the MTRR for graphics memory. This usage has two major issues as below: - mtrr_commit() will re-initialize all MTRR registers from index 0, using the settings previously added by mtrr_add_request() and saved in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary - The way such combination works is based on the assumption that U-Boot has full control with MTRR programming (e.g.: U-Boot without any blob that does all low-level initialization on its own, or using FSP2 which does not touch MTRR), but this is not the case with FSP. FSP programs some MTRRs during its execution but U-Boot does not have the settings saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will corrupt what was already programmed previously. Correct this to use mtrr_set_next_var() instead. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- arch/x86/lib/fsp/fsp_graphics.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c index 2bcc49f605..09d5da8c84 100644 --- a/arch/x86/lib/fsp/fsp_graphics.c +++ b/arch/x86/lib/fsp/fsp_graphics.c @@ -110,8 +110,7 @@ static int fsp_video_probe(struct udevice *dev) if (ret) goto err; - mtrr_add_request(MTRR_TYPE_WRCOMB, vesa->phys_base_ptr, 256 << 20); - mtrr_commit(true); + mtrr_set_next_var(MTRR_TYPE_WRCOMB, vesa->phys_base_ptr, 256 << 20); printf("%dx%dx%d @ %x\n", uc_priv->xsize, uc_priv->ysize, vesa->bits_per_pixel, vesa->phys_base_ptr); -- 2.34.1

2 16

[PATCH v2 1/1] efi_loader: error handling in tcg2_hash_pe_image()
by Heinrich Schuchardt 31 Jul '23

31 Jul '23

If the hard coded array hash_algo_list[] contains an entry for an unsupported algorithm, we should not leak resources new_efi and regs. We should still extend the log with the digests for the supported algorithms and not write any message. The same holds true of tcg2_create_digest(): just continue in case hash_algo_list[] contains an unsupported entry. Fixes: 163a0d7e2cbd ("efi_loader: add PE/COFF image measurement") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- v2: drop the error message fix tcg2_create_digest() too --- lib/efi_loader/efi_tcg2.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c index 49f8a5e77c..7b7926a0d4 100644 --- a/lib/efi_loader/efi_tcg2.c +++ b/lib/efi_loader/efi_tcg2.c @@ -706,8 +706,7 @@ static efi_status_t tcg2_create_digest(const u8 *input, u32 length, sha512_finish(&ctx_512, final); break; default: - EFI_PRINT("Unsupported algorithm %x\n", hash_alg); - return EFI_INVALID_PARAMETER; + continue; } digest_list->digests[digest_list->count].hash_alg = hash_alg; memcpy(&digest_list->digests[digest_list->count].digest, final, @@ -930,8 +929,7 @@ static efi_status_t tcg2_hash_pe_image(void *efi, u64 efi_size, hash_calculate("sha512", regs->reg, regs->num, hash); break; default: - EFI_PRINT("Unsupported algorithm %x\n", hash_alg); - return EFI_INVALID_PARAMETER; + continue; } digest_list->digests[digest_list->count].hash_alg = hash_alg; memcpy(&digest_list->digests[digest_list->count].digest, hash, -- 2.40.1

2 1

[PATCH] efi_loader: capsule: enforce guid check in api and capsule_on_disk
by AKASHI Takahiro 31 Jul '23

31 Jul '23

While UPDATE_CAPSULE api is not fully implemented, this interface and capsule-on-disk feature should behave in the same way, especially in handling an empty capsule for fwu multibank, for future enhancement. So move the guid check into efi_capsule_update_firmware(). Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() for capsule on disk") Reported-by: Michal Simek <michal.simek(a)amd.com> Signed-off-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org> --- lib/efi_loader/efi_capsule.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c index 7a6f195cbc02..ddf8153e0982 100644 --- a/lib/efi_loader/efi_capsule.c +++ b/lib/efi_loader/efi_capsule.c @@ -581,6 +581,13 @@ static efi_status_t efi_capsule_update_firmware( fw_accept_os = capsule_data->flags & FW_ACCEPT_OS ? 0x1 : 0x0; } + if (guidcmp(&capsule_data->capsule_guid, + &efi_guid_firmware_management_capsule_id)) { + log_err("Unsupported capsule type: %pUs\n", + &capsule_data->capsule_guid); + return EFI_UNSUPPORTED; + } + /* sanity check */ if (capsule_data->header_size < sizeof(*capsule) || capsule_data->header_size >= capsule_data->capsule_image_size) @@ -751,15 +758,7 @@ efi_status_t EFIAPI efi_update_capsule( log_debug("Capsule[%d] (guid:%pUs)\n", i, &capsule->capsule_guid); - if (!guidcmp(&capsule->capsule_guid, - &efi_guid_firmware_management_capsule_id)) { - ret = efi_capsule_update_firmware(capsule); - } else { - log_err("Unsupported capsule type: %pUs\n", - &capsule->capsule_guid); - ret = EFI_UNSUPPORTED; - } - + ret = efi_capsule_update_firmware(capsule); if (ret != EFI_SUCCESS) goto out; } -- 2.41.0

3 5

Re: R: Pull request: u-boot-rockchip-20230728
by Kever Yang 31 Jul '23

31 Jul '23

Hi Pegorer, On 2023/7/28 23:55, Pegorer Massimo wrote: > Hi Kever, > >> Da: U-Boot <u-boot-bounces(a)lists.denx.de> Per conto di Jagan Teki >> Inviato: venerdì 28 luglio 2023 14:07 >> A: Kever Yang <kever.yang(a)rock-chips.com> >> Cc: trini(a)konsulko.com; u-boot(a)lists.denx.de >> Oggetto: Re: Pull request: u-boot-rockchip-20230728 >> >> Hi Kever, >> > Also the patches [1] that you already reviewed: is it due to the mailing list issue [2] reported by Tom, or did you find anything that needs revision? > > I can send a v2, or to re-send them, if you need. Thanks. I have send the review tag for these patches, but the patchwork does not able to get my review mail, and not able to update the patch status to reviewed, and that's why I missing this patch set. I will apply these patch manually in next PR. Thanks, - Kever > > Massimo > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=&submitter=85278&st… > > [2] https://lore.kernel.org/u-boot/20230727010637.GB3630934@bill-the-cat/ >

2 2

[PATCH 1/1] efi_loader: error handling in tcg2_hash_pe_image()
by Heinrich Schuchardt 31 Jul '23

31 Jul '23

If the hard coded array hash_algo_list[] contains an entry for an unsupported algorithm, we should not leak resources new_efi and regs. We should still extend the log with the digests for the supported algorithms. Fixes: 163a0d7e2cbd ("efi_loader: add PE/COFF image measurement") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- lib/efi_loader/efi_tcg2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c index 49f8a5e77c..18abe91bce 100644 --- a/lib/efi_loader/efi_tcg2.c +++ b/lib/efi_loader/efi_tcg2.c @@ -931,7 +931,7 @@ static efi_status_t tcg2_hash_pe_image(void *efi, u64 efi_size, break; default: EFI_PRINT("Unsupported algorithm %x\n", hash_alg); - return EFI_INVALID_PARAMETER; + continue; } digest_list->digests[digest_list->count].hash_alg = hash_alg; memcpy(&digest_list->digests[digest_list->count].digest, hash, -- 2.40.1

2 1