February 2024 - U-Boot

How to load raw disk image in u-boot?
by Sourabh Hegde 15 Feb '24

15 Feb '24

Hello, I am working on the secure boot for raspberry pi topic as described here https://github.com/raspberrypi/usbboot/tree/master?tab=readme-ov-file#secur… The boot.img file contains u-boot.bin, config.txt, boot.scr, Image, DTB and other raspberry pi necessary files. But when I try to integrate this with u-boot, the boot.img is not being parsed and I see below errors libfdt fdt_check_header(): FDT_ERR_BADMAGIC No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image I tried to manually load it using: fatload mmc 0:1 ${kernel_addr_r} boot.img this works but, booty is not able to run it booti ${kernel_addr_r} - ${fdt_addr} Bad Linux ARM64 Image magic! I believe first we need to uncompress the raw disk image and then load it. However with unzip it is not possible to do it. unzip ${kernel_addr_r} 0x83000000 Error: Bad gzipped data So, how can we load the raw disk image in U-boot?

1 0

Double free error with ubi_volume_desc/ubi_close_volume
by Nieuwenhuizen Felix (ETAS-DAP/XPC-Fe8) 15 Feb '24

15 Feb '24

Hi all, I seem to be running into a double free error with ubi_volume_desc/ubi_close_volume during a ubifsmount/ubifsload/ubifsumount sequence. This is the sequence that I'm seeing: ubifsmount - do_ubifs_mount - cmd_ubifs_mount - uboot_ubifs_mount - ubifs_mount - open_ubi - ubi_open_volume -> returns ubi_volume_desc #1 - open_ubi returns ubi_volume_desc #1 - ubi_volume_desc #1 stored in local ubi variable - ubifs_fill_super - ubi_open_volume returns ubi_volume_desc #2 - ubi_volume_desc #2 stored in sb->s_fs_info->ubi - ubi_close_volume(ubi) i.e. ubi_close_volume(ubi_volume_desc #1) - kfree(ubi_volume_desc #1) - sb stored in global ubifs_sb (including ubi_volume_desc #2) ubifsload - do_ubifs_load - ubifs_load - ubifs_read - ubi_open_volume -> returns ubi_volume_desc #3 - ubi_volume_desc #3 stored in ubifs_sb->s_fs_info->ubi (this overwrites ubi_volume_desc #2!) - ubi_close_volume(ubifs_sb->s_fs_info->ubi) i.e. ubi_close_volume(ubi_volume_desc #3) - kfree(ubi_volume_desc #3) ubifsumount - do_ubifs_umount - cmd_ubifs_umount - uboot_ubifs_umount - ubifs_umount(ubifs_sb->s_fs_info) - ubi_close_volume(ubifs_sb->s_fs_info->ubi) i.e. ubi_close_volume(ubi_volume_desc #3) - kfree(ubi_volume_desc #3) - this is a double free error, ubi_volume_desc #2 should be closed instead (but the reference has been lost)! The issue seems to be that ubifs_read overwrites the ubi_volume_desc that's stored in the superblock, and thus ubi_volume_desc #2 is never freed, while ubi_volume_desc #3 is freed twice. I'm not sure what the correct behaviour should be: - should the volume be closed at the end of ubifs_mount, or stay open until ubifs_umount? - should ubifs_read not open the volume if it is already open? Thanks in advance! Regards, Felix

1 1

TI LCD Driver and splash screen.
by Steven Hill 15 Feb '24

15 Feb '24

Hello. I am bringing up a new am335x platform and need splash screen support. I already wrote new backlight and LCD panel Linux drivers for the platform. The kernel side is solid. I brought the device tree and backlight driver from the kernel and put it into v2023.04 U-Boot. Currently getting a "cannot allocate frame buffer memory error" and have tried a bunch of different things. I have attached my current defconfig. The panel/graphics portion in the device tree I copied from arch/arm/dts/am335x-brxre1.dts to start. Was hoping people had some pointers or ideas. Cheers, Steve

1 0

[PATCH 1/1] efi_loader: set IMAGE_DLLCHARACTERISTICS_NX_COMPAT
by Heinrich Schuchardt 14 Feb '24

14 Feb '24

The IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag marks an EFI binary where the following conditions are met [1]: * Executable and writable sections are separated. * The application does not run self-modifying code. * The application uses the EFI_MEMORY_ATTRIBUTE_PROTOCOL when loading executable code. * The application does not assume that all memory ranges are usable. * The stack is not expected to be executable. The only EFI binaries U-Boot provides that do not fulfill these requirements are the EFI app and the EFI payload. Once we have implemented separation of writable and executable memory in U-Boot we can use the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag to decide if we will load an EFI binary. [1] New UEFI CA memory mitigation requirements for signing https://techcommunity.microsoft.com/t5/hardware-dev-center/new-uefi-ca-memo… Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- The separation of executable and writable sections for armv7 EFI binaries is provided by [PATCH 1/1] arm: separate .data and .text sections of EFI binaries https://lore.kernel.org/u-boot/20240214190625.13764-1-heinrich.schuchardt@c… --- arch/arm/lib/crt0_aarch64_efi.S | 4 ++++ arch/arm/lib/crt0_arm_efi.S | 4 ++++ arch/riscv/lib/crt0_riscv_efi.S | 4 ++++ include/asm-generic/pe.h | 3 +++ 4 files changed, 15 insertions(+) diff --git a/arch/arm/lib/crt0_aarch64_efi.S b/arch/arm/lib/crt0_aarch64_efi.S index 3c2cef6ec7..fe6eca576e 100644 --- a/arch/arm/lib/crt0_aarch64_efi.S +++ b/arch/arm/lib/crt0_aarch64_efi.S @@ -66,7 +66,11 @@ extra_header_fields: .long _start - ImageBase /* SizeOfHeaders */ .long 0 /* CheckSum */ .short IMAGE_SUBSYSTEM_EFI_APPLICATION /* Subsystem */ +#if CONFIG_VENDOR_EFI .short 0 /* DllCharacteristics */ +#else + .short IMAGE_DLLCHARACTERISTICS_NX_COMPAT +#endif .quad 0 /* SizeOfStackReserve */ .quad 0 /* SizeOfStackCommit */ .quad 0 /* SizeOfHeapReserve */ diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S index ba9fada500..afeff3f3fb 100644 --- a/arch/arm/lib/crt0_arm_efi.S +++ b/arch/arm/lib/crt0_arm_efi.S @@ -65,7 +65,11 @@ extra_header_fields: .long _start - image_base /* SizeOfHeaders */ .long 0 /* CheckSum */ .short IMAGE_SUBSYSTEM_EFI_APPLICATION /* Subsystem */ +#if CONFIG_VENDOR_EFI .short 0 /* DllCharacteristics */ +#else + .short IMAGE_DLLCHARACTERISTICS_NX_COMPAT +#endif .long 0 /* SizeOfStackReserve */ .long 0 /* SizeOfStackCommit */ .long 0 /* SizeOfHeapReserve */ diff --git a/arch/riscv/lib/crt0_riscv_efi.S b/arch/riscv/lib/crt0_riscv_efi.S index 46b0855237..c7a4559eac 100644 --- a/arch/riscv/lib/crt0_riscv_efi.S +++ b/arch/riscv/lib/crt0_riscv_efi.S @@ -96,7 +96,11 @@ extra_header_fields: .long _start - ImageBase /* SizeOfHeaders */ .long 0 /* CheckSum */ .short IMAGE_SUBSYSTEM_EFI_APPLICATION /* Subsystem */ +#if CONFIG_VENDOR_EFI .short 0 /* DllCharacteristics */ +#else + .short IMAGE_DLLCHARACTERISTICS_NX_COMPAT +#endif #if __riscv_xlen == 32 .long 0 /* SizeOfStackReserve */ .long 0 /* SizeOfStackCommit */ diff --git a/include/asm-generic/pe.h b/include/asm-generic/pe.h index b9d674b6da..cd5b6ad62b 100644 --- a/include/asm-generic/pe.h +++ b/include/asm-generic/pe.h @@ -51,6 +51,9 @@ #define IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER 12 #define IMAGE_SUBSYSTEM_EFI_ROM 13 +/* DLL characteristics */ +#define IMAGE_DLLCHARACTERISTICS_NX_COMPAT 0x100 + /* Section flags */ #define IMAGE_SCN_CNT_CODE 0x00000020 #define IMAGE_SCN_CNT_INITIALIZED_DATA 0x00000040 -- 2.43.0

1 0

[PATCH] button: qcom-pmic: fix some error checking
by Dan Carpenter 14 Feb '24

14 Feb '24

The pmic_reg_read() function can return errors. Add a check for that. Fixes: 4e8aa0065d4b ("button: qcom-pmic: introduce Qualcomm PMIC button driver") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> --- This patch is mostly to make static checkers happy but it's obvious and harmless. drivers/button/button-qcom-pmic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/button/button-qcom-pmic.c b/drivers/button/button-qcom-pmic.c index 34a976d1e6c6..e778e51a4f36 100644 --- a/drivers/button/button-qcom-pmic.c +++ b/drivers/button/button-qcom-pmic.c @@ -86,7 +86,7 @@ static int qcom_pwrkey_probe(struct udevice *dev) } ret = pmic_reg_read(priv->pmic, priv->base + REG_SUBTYPE); - if ((ret & 0x7) == 0) { + if (ret < 0 || (ret & 0x7) == 0) { printf("%s: unexpected PMCI function subtype %d\n", dev->name, ret); return -ENXIO; } -- 2.43.0

3 3

[PATCH v2 1/9] riscv: Optimize source end address calculation in start.S
by Bin Meng 14 Feb '24

14 Feb '24

The __bss_start is the source end address hence load its address directly into register 't2' for optimization. Signed-off-by: Bin Meng <bmeng(a)tinylab.org> Reviewed-by: Rick Chen <rick(a)andestech.com> --- (no changes since v1) arch/riscv/cpu/start.S | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index 4687bca3c9..3c8344c345 100644 --- a/arch/riscv/cpu/start.S +++ b/arch/riscv/cpu/start.S @@ -283,9 +283,7 @@ stack_setup: beq t0, s4, clear_bss /* skip relocation */ mv t1, s4 /* t1 <- scratch for copy_loop */ - la t3, __bss_start - sub t3, t3, t0 /* t3 <- __bss_start_ofs */ - add t2, t0, t3 /* t2 <- source end address */ + la t2, __bss_start /* t2 <- source end address */ copy_loop: LREG t5, 0(t0) -- 2.34.1

3 13

[PATCH] arm64: versal-net: Setup correct addresses of GICR/GICD
by Michal Simek 14 Feb '24

14 Feb '24

Previous addresses where used in past in emulation environment but never gets to silicon that's why use correct addresses. Signed-off-by: Michal Simek <michal.simek(a)amd.com> --- include/configs/xilinx_versal_net.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/xilinx_versal_net.h b/include/configs/xilinx_versal_net.h index 2b441da91a10..9cb6b2bfea3e 100644 --- a/include/configs/xilinx_versal_net.h +++ b/include/configs/xilinx_versal_net.h @@ -16,8 +16,8 @@ /* #define CONFIG_ARMV8_SWITCH_TO_EL1 */ /* Generic Interrupt Controller Definitions */ -#define GICD_BASE 0xF9000000 -#define GICR_BASE 0xF9060000 +#define GICD_BASE 0xe2000000 +#define GICR_BASE 0xe2060000 /* Serial setup */ #define CFG_SYS_BAUDRATE_TABLE \ -- 2.36.1

1 1

[FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
by Shantur Rathore 14 Feb '24

14 Feb '24

USB 3.0 spec requires hub to reset device while enumeration. Some USB 2.0 hubs / devices don't handle this well and after implementation of reset some USB 2.0 disks weren't detected on Allwinner based boards. Resetting only when hub is USB 3.0 fixes it. Tested-by: Andre Przywara <andre.przywara(a)arm.com> Signed-off-by: Shantur Rathore <i(a)shantur.com> --- common/usb_hub.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/common/usb_hub.c b/common/usb_hub.c index 3fb7e14d10..2e054eb935 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -174,8 +174,10 @@ static void usb_hub_power_on(struct usb_hub_device *hub) debug("enabling power on all ports\n"); for (i = 0; i < dev->maxchild; i++) { - usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET); - debug("Reset : port %d returns %lX\n", i + 1, dev->status); + if (usb_hub_is_superspeed(dev)) { + usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET); + debug("Reset : port %d returns %lX\n", i + 1, dev->status); + } usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER); debug("PowerOn : port %d returns %lX\n", i + 1, dev->status); } -- 2.40.1

4 23

[PATCH] Added FDT PAD memory size while reserving memory for FDT to avoid some memory corruption issue
by Selvakumar Velandi 14 Feb '24

14 Feb '24

Hi, Issue: Linux kernel getting crash after loading kernel in VM system using RISCV QEMU. RootCause: Memory corruption in uboot FDT memory while launching a VM system in RISCV QEMU. Fix: In the board_f.c file the FDT memory region is reserved without FDT padding bytes. uboot will add some params like bootargs while launching linux. While relocate the FDT, if its decided as run in the Fixed memory location i.e fdy_high is set as -1, then the padding bytes not added while relocating the FDT, but the size is blindly added with padding bytes without reserving the physical memory in the FDT header in the image_fdt.c file. Please find the attached patch file to fix the issue. Please review and revert your comments. Regards, SelvakumarVelandi Krutrim SI designs -- *** This communication is confidential, may be privileged and is meant only for the intended recipient and purpose. No part of this email or any files transmitted with it can be shared, copied, forwarded or published online or offline, without prior written consent of the sender. If you are not the intended recipient, please preserve the confidentiality, delete the e-mail and attachments, if any from your system and inform the sender immediately. ***

2 4

[AVB/AB] Overhaul plans
by Igor Opaniuk 14 Feb '24

14 Feb '24

Hi everyone, I'm currently planning a big overhaul of the current implementation of AVB/AB in U-Boot during the 2024 year, which I have barely touched since 2019. I used to believe that it was stillborn, but looks like it's being actively used now by some SoC vendors and Google folks [1][2]. This is what I have in my todo list: * Backport latest libavb from AOSP upstream and add support for Verified Boot 1.3.0 version * Sync include/android_bootloader_message.h with AOSP upstream * Check and backport fixes for AVB in AOSP U-Boot fork if needed [1] * Get acquainted with a current state of A/B support in AOSP and backport all needed changes * Re-factor libavb, switch to U-Boot existing implementation of rsa/sha256/sha512 * Add SHA512 implementation that leverage ARMv8 CE (pull it from Linux) * Enable hw acceleration of SHA256/SHA512 that supports ARMv8 Crypto Extensions to speed up verification process on ARMv8-based boards. * AVB support for NAND storage If someone is already working on anything from the above list - please feel free to reach out to me, so we can avoid duplication of effort. Any comments/suggestions are welcome! Thanks! [1] https://android.googlesource.com/platform/external/u-boot [2] https://source.android.com/docs/devices/cuttlefish/bootloader-dev [3] https://android.googlesource.com/platform/bootable/recovery/+/main/bootload… -- Best regards - Atentamente - Meilleures salutations Igor Opaniuk mailto: igor.opaniuk(a)gmail.com skype: igor.opanyuk http://ua.linkedin.com/in/iopaniuk

2 3