June 2024 - U-Boot

[PATCH] cmd: sound: fix help text
by Quentin Schulz 13 Jun '24

13 Jun '24

From: Quentin Schulz <quentin.schulz(a)cherry.de> There's never been a -q or -s argument handled in the command, so let's remove it. This was highlighted during review[1] but somehow still got through. While at it, slightly "reword" in the help text how the len + freq arguments are defined. Indeed, len and freq work in pair, it is possible to define none of either, n of both, or n - 1 of freq if there are n len, in which case the freq that goes with the last len would be the n - 1 (and not the default of 400Hz if neither len nor freq is passed). I assume this isn't what's expected but leaving it for another patch if need be to fix what happens in that very odd scenario. [1] https://lore.kernel.org/u-boot/CAPnjgZ0QWNqVFZfEWHxRcFOA3E3gRAZCYs77nGUXKL0… Fixes: ea58b9a404d4 ("cmd: allow sound command to play multiple sounds") Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- cmd/sound.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/sound.c b/cmd/sound.c index 08bf74112f1..8f67cbd96e1 100644 --- a/cmd/sound.c +++ b/cmd/sound.c @@ -98,7 +98,7 @@ U_BOOT_CMD( sound, INT_MAX, 1, do_sound, "sound sub-system", "init - initialise the sound driver\n" - "sound play [[[-q|-s] len [freq]] ...] - play sounds\n" + "sound play [len [freq [len [freq ...]]]] - play sounds\n" " len - duration in ms\n" " freq - frequency in Hz\n" ); --- base-commit: 4f836fb324ba500ecabdba4146c3ca9e1600cdf5 change-id: 20240610-cmd-sound-help-cfef07dcc95a Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

3 2

[PATCH 1/1] dm: typo prbing
by Heinrich Schuchardt 13 Jun '24

13 Jun '24

%s/prbing/probing/ Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- drivers/core/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig index 1081d61fcf0..754649f091e 100644 --- a/drivers/core/Kconfig +++ b/drivers/core/Kconfig @@ -113,7 +113,7 @@ config DM_EVENT select EVENT help This enables support for generating events related to driver model - operations, such as prbing or removing a device. Subsystems can + operations, such as probing or removing a device. Subsystems can register a 'spy' function that is called when the event occurs. Such subsystems must select this option. -- 2.43.0

4 3

[u-boot-test-hooks PATCH v2 0/2] Add support for Labgrid
by Simon Glass 13 Jun '24

13 Jun '24

This adds hooks for use with Labgrid. The only existing hook that really does anything now is the 'console' one. There is also a new 'getrole' hook which looks up a role to find various things about it, such as the U-Boot board name. Changes in v2: - Make use of the common script (only) to set bin_dir - Make use of the common script (only) to set bin_dir Simon Glass (2): Create a common file for test scripts Provide some basic scripts for Labgrid integration README.md | 33 ++++++++++++++++++++++++++++ bin/console.labgrid | 42 ++++++++++++++++++++++++++++++++++++ bin/ellesmere/common-labgrid | 31 ++++++++++++++++++++++++++ bin/ellesmere/conf.all | 24 +++++++++++++++++++++ bin/getrole.labgrid | 25 +++++++++++++++++++++ bin/release.labgrid | 22 +++++++++++++++++++ bin/release.none | 22 +++++++++++++++++++ bin/u-boot-test-common | 35 ++++++++++++++++++++++++++++++ bin/u-boot-test-console | 8 +------ bin/u-boot-test-flash | 8 +------ bin/u-boot-test-getrole | 38 ++++++++++++++++++++++++++++++++ bin/u-boot-test-power-off | 8 +------ bin/u-boot-test-power-on | 8 +------ bin/u-boot-test-release | 26 ++++++++++++++++++++++ bin/u-boot-test-reset | 8 +------ 15 files changed, 303 insertions(+), 35 deletions(-) create mode 100644 bin/console.labgrid create mode 100755 bin/ellesmere/common-labgrid create mode 100644 bin/ellesmere/conf.all create mode 100644 bin/getrole.labgrid create mode 100644 bin/release.labgrid create mode 100644 bin/release.none create mode 100755 bin/u-boot-test-common create mode 100755 bin/u-boot-test-getrole create mode 100755 bin/u-boot-test-release -- 2.34.1

2 3

Pull request efi-2024-07-rc5 for branch master
by Heinrich Schuchardt 13 Jun '24

13 Jun '24

Dear Tom, The following changes since commit 1ebd659cf020843fd8e8ef90d85a66941cbab6ec: Merge tag 'u-boot-dfu-20240606' of https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-06-06 08:24:15 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2024-07-rc5 for you to fetch changes up to f3b6228ef4ee6918a9e1ec1db399ede057308a13: doc/sphinx, test/py: Update requests module to 2.32.2 (2024-06-10 15:05:30 +0200) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/21060 ---------------------------------------------------------------- Pull request efi-2024-07-rc5 Documentation: * update build dependency Python request module to version 2.32.2 * fix typos UEFI: * Correct signature check when appending to EFI variables. ---------------------------------------------------------------- Mattijs Korpershoek (1): doc: cmd: bootmeth: Fix extlinunx -> extlinux typo Michal Simek (1): efi_loader: Fix capsule_esl.dtsi.in comment style Tom Rini (1): doc/sphinx, test/py: Update requests module to 2.32.2 Weizhao Ouyang (1): efi_loader: Fix EFI_VARIABLE_APPEND_WRITE hash check doc/sphinx/requirements.txt | 2 +- doc/usage/cmd/bootmeth.rst | 2 +- lib/efi_loader/capsule_esl.dtsi.in | 4 ++-- lib/efi_loader/efi_variable.c | 6 +++--- test/py/requirements.txt | 2 +- test/py/tests/test_efi_secboot/conftest.py | 10 ++++++++++ test/py/tests/test_efi_secboot/test_authvar.py | 4 ++-- test/py/tests/test_efi_secboot/test_signed.py | 10 +++++----- 8 files changed, 25 insertions(+), 15 deletions(-)

2 1

[PATCH v2 0/7] Add AVS support for J721S2
by Manorit Chawdhry 13 Jun '24

13 Jun '24

This series adds support for AVS on J721S2. AVS Test for J721S2: https://gist.github.com/manorit2001/d7690ded6ef685aa8ffa5b16746cc529 Boot Test results: https://gist.github.com/manorit2001/6775d721b3df5a690497d94d012b93c4 Signed-off-by: Manorit Chawdhry <m-chawdhry(a)ti.com> --- Changes in v2: - Move AVS Initialization point to after do_dt_magic ( Otherwise AM68 unknowingly ends up probing AVS and fails ) - Rebase on top of OF_UPSTREAM Support - Link to v1: https://lore.kernel.org/r/20240206-b4-upstream-j721s2-avs-v1-0-b75043c59969… --- Manorit Chawdhry (7): power: pmic: tps65941: Add DM_PMIC dependency drivers: misc: k3_avs: Use soc_match_device instead of compatible. drivers: misc: k3_avs: Check return code while programming AVS drivers: misc: k3_avs: Add AVS Support for J721S2. arm: mach-k3: j721s2_init: Initialize AVS Class 0 arm: dts: j721s2: Add VTM node in R5 configs: j721s2_evm_r5_defconfig: Add AVS Configs arch/arm/dts/k3-j721s2-r5-common-proc-board.dts | 9 + arch/arm/mach-k3/j721s2/j721s2_init.c | 10 ++ configs/am68_sk_r5_defconfig | 4 + configs/j721s2_evm_r5_defconfig | 6 + drivers/misc/k3_avs.c | 216 ++++++++++++++---------- drivers/power/pmic/Kconfig | 1 + 6 files changed, 159 insertions(+), 87 deletions(-) --- base-commit: 377e91c162ab09ec20f96f966f380cb55c590edd change-id: 20240130-b4-upstream-j721s2-avs-8c187d3fe26a Best regards, -- Manorit Chawdhry <m-chawdhry(a)ti.com>

4 12

[PATCH v2 00/14] mediatek: cumulative trivial fix for OF_UPSTREAM support
by Christian Marangi 13 Jun '24

13 Jun '24

This is an initial series that have all the initial trivial fixes required for usage of OF_UPSTREAM for the mediatek SoC This also contains the pcie-gen3 driver and the required tphy support driver to make it work. Subsequent series will follow with conversion of the mtk-clk to permit usage of OF_UPSTREAM and upstream clk ID. MT7981, MT7986 and MT7988 migration to upstream clock ID is complete and working on MT7623. Changes v2: - Add mt7986 and mt7988 apmixed trivial PATCH - Make phy for pcie optional (it is for mt7988) - Fix broken mmc patch Christian Marangi (13): phy: phy-mtk-tphy: add support for phy type switch spi: mtk_spim: add support for upstream mediatek,spi-ipm compatible net: mediatek: handle alternative name for pn_swap property i2c: mediatek: add support for optional arb and pmic clock serial: mediatek: add support for bus clock and enable it serial: mediatek: add special handling for highspeed and linux compat mmc: mediatek: add support for upstream linux clock and property clk: mediatek: mt7981: support alternative compatible for fixed-plls pinctrl: mediatek: add support for gpio-controller property in root node pinctrl: mediatek: mt7981: init device before relocation pci: mediatek: make pcie-phy optional for gen3 clk: mediatek: mt7988: support alternative compatible for fixed-plls clk: mediatek: mt7986: support alternative compatible for fixed-plls John Crispin (1): pci: mediatek: add PCIe controller support for filogic silicon drivers/clk/mediatek/clk-mt7981.c | 1 + drivers/clk/mediatek/clk-mt7986.c | 1 + drivers/clk/mediatek/clk-mt7988.c | 1 + drivers/i2c/mtk_i2c.c | 30 ++ drivers/mmc/mtk-sd.c | 35 +- drivers/net/mtk_eth.c | 4 +- drivers/pci/Kconfig | 7 + drivers/pci/Makefile | 1 + drivers/pci/pcie_mediatek_gen3.c | 384 ++++++++++++++++++ drivers/phy/phy-mtk-tphy.c | 80 ++++ drivers/pinctrl/mediatek/pinctrl-mt7981.c | 1 + drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 10 + drivers/serial/serial_mtk.c | 27 +- drivers/spi/mtk_spim.c | 45 +- 14 files changed, 613 insertions(+), 14 deletions(-) create mode 100644 drivers/pci/pcie_mediatek_gen3.c -- 2.43.0

1 14

[PATCH 1/3] doc: board: phytec: phycore-am62x: Fix Link to Documentation
by Daniel Schultz 13 Jun '24

13 Jun '24

We moved our documentation to another hoster and therefore the URL changed. Point to the latest documentation instead of release versions to not link out-dated documentation. Signed-off-by: Daniel Schultz <d.schultz(a)phytec.de> --- doc/board/phytec/phycore-am62x.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/board/phytec/phycore-am62x.rst b/doc/board/phytec/phycore-am62x.rst index bc6d5246694..681ac536125 100644 --- a/doc/board/phytec/phycore-am62x.rst +++ b/doc/board/phytec/phycore-am62x.rst @@ -155,4 +155,4 @@ Further Information ------------------- Please see :doc:`../ti/am62x_sk` chapter for further AM62 SoC related documentation -and https://docs.phytec.com/phycore-am62x for vendor documentation. +and https://docs.phytec.com/projects/yocto-phycore-am62x/en/latest/ for vendor documentation. -- 2.25.1

2 3

Where to put DTB file for UEFI support on ARM
by Leith Bade 13 Jun '24

13 Jun '24

Hi all, I have a BananaPi BPI-R3 board that I am setting up to boot Ubuntu or Debian. After figuring out the required config options I have managed to get Uboot to boot the Ubuntu USB installer, and also boot off an SD card once I installed Ubuntu there. I set up the bootmeth/bootdev/bootflow stuff so that the auto boot menu works nicely with SD card. For USB I have to drop to console and do manual "usb start" etc, but good enough for running the installer. It was a bit difficult as there seems to be a lot of older documentation or Google results related to using UEFI before the bootflow stuff was added. Also it took me a while to figure out that a board/mediatek/mt7986.env file is now needed as some of the config options set #define values that are not included in /include/configs/mt7986.h board headers - due to .env files replacing those #defines. It would be nice to have a default .env file for this board that sets sensible defaults for the various memory loading addresses as it took a bit of effort to come up with all the hex values. However I am struggling to work out where to place the device tree DTB file for the Linux kernel. For this board I need a different DTB for U-boot (which is included in the u-boot.bin and fip.bin) and the kernel as U-boot's drivers do not like the Linux upstream device tree. I can see in the UEFI bootmeth code that it searches a location /dtb/ for a file named in the $fdtfile environment variable. I tried putting the .dtb file at /dtb/mt7986a-bananapi-bpi-r3.dtb on the SD card's FAT32 partition that Ubuntu created, however it doesn't seem to load this and the U-boot boots with the u-boot.bin DTB which means kernel doesn't start If I manually load the correct .dtb file to $fdt_addr_r then the correct DTB is used and the kernel starts. What is the correct location for the .dtb file when using UEFI? Is there a recommended way of putting the kernel DTB into the NAND or NOR chip when using UEFI? That way if the SD card gets wiped U-boot can still boot the USB drive. I don't fully understand how the MTD partitions, FIT files, UBI files all fit into the picture to have U-boot load the kernel DTB from flash. Thanks, Leith Bade leith(a)bade.nz

2 2

[u-boot-test-hooks PATCH 0/2] Add support for Labgrid
by Simon Glass 12 Jun '24

12 Jun '24

This adds hooks for use with Labgrid. The only existing hook that really does anything now is the 'console' one. There is also a new 'getrole' hook which looks up a role to find various things about it, such as the U-Boot board name. Simon Glass (2): Create a common file for test scripts Provide some basic scripts for Labgrid integration README.md | 33 ++++++++++++++++++++++++++++ bin/console.labgrid | 42 ++++++++++++++++++++++++++++++++++++ bin/ellesmere/common-labgrid | 31 ++++++++++++++++++++++++++ bin/ellesmere/conf.all | 24 +++++++++++++++++++++ bin/getrole.labgrid | 25 +++++++++++++++++++++ bin/release.labgrid | 22 +++++++++++++++++++ bin/release.none | 22 +++++++++++++++++++ bin/u-boot-test-common | 35 ++++++++++++++++++++++++++++++ bin/u-boot-test-console | 7 +----- bin/u-boot-test-flash | 7 +----- bin/u-boot-test-getrole | 39 +++++++++++++++++++++++++++++++++ bin/u-boot-test-power-off | 7 +----- bin/u-boot-test-power-on | 7 +----- bin/u-boot-test-release | 27 +++++++++++++++++++++++ bin/u-boot-test-reset | 7 +----- 15 files changed, 305 insertions(+), 30 deletions(-) create mode 100644 bin/console.labgrid create mode 100755 bin/ellesmere/common-labgrid create mode 100644 bin/ellesmere/conf.all create mode 100644 bin/getrole.labgrid create mode 100644 bin/release.labgrid create mode 100644 bin/release.none create mode 100755 bin/u-boot-test-common create mode 100755 bin/u-boot-test-getrole create mode 100755 bin/u-boot-test-release -- 2.34.1

2 7

[PATCH 0/6] bootstd: Add Android support
by Mattijs Korpershoek 12 Jun '24

12 Jun '24

Android boot flow is a bit different than a regular Linux distro. Android relies on multiple partitions in order to boot. A typical boot flow would be: 1. Parse the Bootloader Control Block (BCB, misc partition) 2. If BCB requested bootonce-bootloader, start fastboot and wait. 3. If BCB requested recovery or normal android, run the following: a. Get slot (A/B) from BCB b. Run AVB (Android Verified Boot) on boot partitions c. Load boot and vendor_boot partitions d. Load device-tree, ramdisk and boot The AOSP documentation has more details at [1], [2], [3] This has been implemented via complex boot scripts such as [4]. However, these boot script are neither very maintainable nor generic. Moreover, DISTRO_DEFAULTS is being deprecated [5]. Add a generic Android bootflow implementation for bootstd. For this initial version, only boot image v4 is supported. This has been tested on sandbox using: $ ./test/py/test.py --bd sandbox --build -k test_ut This has also been tested on the AM62X SK EVM using TI's Android SDK[6] To test on TI board, the following (WIP) patch is needed as well: https://gitlab.baylibre.com/baylibre/ti/ti-u-boot/-/commit/84cceb912bccd7cd… [1] https://source.android.com/docs/core/architecture/bootloader [2] https://source.android.com/docs/core/architecture/partitions [3] https://source.android.com/docs/core/architecture/partitions/generic-boot [4] https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_… [5] https://lore.kernel.org/r/all/20230914165615.1058529-17-sjg@chromium.org/ [6] https://software-dl.ti.com/processor-sdk-android/esd/AM62X/09_02_00/docs/an… Signed-off-by: Mattijs Korpershoek <mkorpershoek(a)baylibre.com> --- Mattijs Korpershoek (6): boot: android: Provide vendor_bootimg_addr in boot_get_fdt() boot: android: Add image_android_get_version() bootstd: Add bootflow_iter_check_mmc() helper android: boot: Add set_abootimg_addr() and set_avendor_bootimg_addr() bootstd: Add a bootmeth for Android bootstd: Add test for bootmeth_android MAINTAINERS | 7 + arch/sandbox/dts/test.dts | 8 + boot/Kconfig | 14 ++ boot/Makefile | 2 + boot/bootflow.c | 12 ++ boot/bootmeth_android.c | 522 ++++++++++++++++++++++++++++++++++++++++++++++ boot/bootmeth_android.h | 27 +++ boot/image-android.c | 7 +- boot/image-fdt.c | 2 +- cmd/abootimg.c | 10 + configs/sandbox_defconfig | 2 +- doc/develop/bootstd.rst | 6 + include/bootflow.h | 9 + include/image.h | 21 ++ test/boot/bootflow.c | 65 +++++- test/py/tests/test_ut.py | 76 +++++++ 16 files changed, 784 insertions(+), 6 deletions(-) --- base-commit: 227be29df37545f74243a98c12a4a33c4160e3cd change-id: 20240605-bootmeth-android-bfc8596e9367 Best regards, -- Mattijs Korpershoek <mkorpershoek(a)baylibre.com>

3 17

[PATCH] arm: mvebu: Enable bootstd and other modernization for Synology DS414 (Armada XP) board
by Tony Dinh 12 Jun '24

12 Jun '24

- Switch to standard boot (in include/configs/ds414.h and configs/ds414_defconfig) - Implement board_late_init() to ensure successful enumeration of USB3 devices - Remove unnecessary misc_init_r(), since NET_RANDOM_ETHADDR is now configured in - Remove unnecessary checkboard() - Updated IDENT_STRING to indicate this u-boot supports both Synology DS414 and DS214+ boards - Add SYS_THUMB_BUILD to reduce binary size - Add NET_RANDOM_ETHADDR - Add CONFIG_LBA48 and CONFIG_SYS_64BIT_LBA to support >2TB HDD/SDD Signed-off-by: Tony Dinh <mibodhi(a)gmail.com> --- board/Synology/ds414/ds414.c | 15 +++-------- configs/ds414_defconfig | 20 ++++++-------- include/configs/ds414.h | 51 ++++++++++++++++++++++-------------- 3 files changed, 42 insertions(+), 44 deletions(-) diff --git a/board/Synology/ds414/ds414.c b/board/Synology/ds414/ds414.c index abe6f9eb5e..f0b55fa095 100644 --- a/board/Synology/ds414/ds414.c +++ b/board/Synology/ds414/ds414.c @@ -181,18 +181,9 @@ int board_init(void) return 0; } -int misc_init_r(void) +int board_late_init(void) { - if (!env_get("ethaddr")) { - puts("Incomplete environment, populating from SPI flash\n"); - do_syno_populate(0, NULL); - } - return 0; -} - -int checkboard(void) -{ - puts("Board: DS414\n"); - + /* Do late init to ensure successful enumeration of XHCI devices */ + pci_init(); return 0; } diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig index ecf9501ba5..501ed51129 100644 --- a/configs/ds414_defconfig +++ b/configs/ds414_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_CPU_INIT=y +CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_MVEBU=y CONFIG_SUPPORT_PASSING_ATAGS=y CONFIG_CMDLINE_TAG=y @@ -25,44 +26,40 @@ CONFIG_SPL_BSS_MAX_SIZE=0x4000 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xf1012000 CONFIG_DEBUG_UART_CLOCK=250000000 +CONFIG_IDENT_STRING="\nSynology DS214+/DS414 2/4-Bay Diskstation" CONFIG_SYS_LOAD_ADDR=0x800000 CONFIG_PCI=y CONFIG_DEBUG_UART=y +CONFIG_BOOTSTD_FULL=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyS0,115200 ip=off initrd=0x8000040,8M root=/dev/md0 rw syno_hw_version=DS414r1 ihd_num=4 netif_num=2 flash_size=8 SataLedSpecial=1 HddHotplug=1" -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="sf probe; sf read ${loadaddr} 0xd0000 0x2d0000; sf read ${ramdisk_addr_r} 0x3a0000 0x430000; bootm ${loadaddr} ${ramdisk_addr_r}" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_MISC_INIT_R=y +CONFIG_BOARD_LATE_INIT=y CONFIG_SPL_MAX_SIZE=0x1bfd0 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set CONFIG_SPL_I2C=y +CONFIG_SYS_PROMPT="DS414> " CONFIG_SYS_MAXARGS=32 CONFIG_CMD_I2C=y CONFIG_CMD_PCI=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y -# CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y CONFIG_CMD_TFTPPUT=y -CONFIG_CMD_MII=y -CONFIG_CMD_PING=y CONFIG_CMD_TIME=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_FAT=y CONFIG_CMD_JFFS2=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_UBI=y -CONFIG_ISO_PARTITION=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_SPI_MAX_HZ=50000000 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ARP_TIMEOUT=200 CONFIG_NET_RETRY_COUNT=50 +CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_OF_TRANSLATE=y +CONFIG_LBA48=y +CONFIG_SYS_64BIT_LBA=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y # CONFIG_MMC is not set @@ -83,4 +80,3 @@ CONFIG_USB_XHCI_HCD=y # CONFIG_USB_XHCI_MVEBU is not set CONFIG_USB_XHCI_PCI=y CONFIG_USB_EHCI_HCD=y -CONFIG_USB_STORAGE=y diff --git a/include/configs/ds414.h b/include/configs/ds414.h index 9446acba79..bbefe632e0 100644 --- a/include/configs/ds414.h +++ b/include/configs/ds414.h @@ -1,5 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* + * Copyright (C) 2024 Tony Dinh <mibodhi(a)gmail.com> * Copyright (C) 2014 Stefan Roese <sr(a)denx.de> */ @@ -16,14 +17,9 @@ * U-Boot into it. */ -/* I2C */ #define CFG_I2C_MVTWSI_BASE0 MVEBU_TWSI_BASE -/* - * mv-common.h should be defined after CMD configs since it used them - * to enable certain macros - */ -#include "mv-common.h" +#define PHY_ANEG_TIMEOUT 16000 /* PHY needs a longer aneg time */ /* * Memory layout while starting into the bin_hdr via the @@ -38,23 +34,38 @@ * L2 cache thus cannot be used. */ -/* SPL */ -/* Defines for SPL */ +/* Keep device tree and initrd in lower memory so the kernel can access them */ +#define RELOCATION_LIMITS_ENV_SETTINGS \ + "fdt_high=0x10000000\0" \ + "initrd_high=0x10000000\0" + +/* + * mv-common.h should be defined after CMD configs since it used them + * to enable certain macros + */ +#include "mv-common.h" + +#ifndef CONFIG_SPL_BUILD -/* Default Environment */ +#define KERNEL_ADDR_R __stringify(0x1000000) +#define FDT_ADDR_R __stringify(0x2000000) +#define RAMDISK_ADDR_R __stringify(0x2200000) +#define SCRIPT_ADDR_R __stringify(0x1800000) +#define PXEFILE_ADDR_R __stringify(0x1900000) -#define CFG_EXTRA_ENV_SETTINGS \ - "initrd_high=0xffffffff\0" \ - "ramdisk_addr_r=0x8000000\0" \ - "usb0Mode=host\0usb1Mode=host\0usb2Mode=device\0" \ - "ethmtu=1500\0eth1mtu=1500\0" \ - "update_uboot=sf probe; dhcp; " \ - "mw.b ${loadaddr} 0x0 0xd0000; " \ - "tftpboot ${loadaddr} u-boot-with-spl.kwb; " \ - "sf update ${loadaddr} 0x0 0xd0000\0" +#define LOAD_ADDRESS_ENV_SETTINGS \ + "kernel_addr_r=" KERNEL_ADDR_R "\0" \ + "fdt_addr_r=" FDT_ADDR_R "\0" \ + "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \ + "scriptaddr=" SCRIPT_ADDR_R "\0" \ + "pxefile_addr_r=" PXEFILE_ADDR_R "\0" +#define CFG_EXTRA_ENV_SETTINGS \ + RELOCATION_LIMITS_ENV_SETTINGS \ + LOAD_ADDRESS_ENV_SETTINGS \ + "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \ + "console=ttyS0,115200\0" -/* increase autoneg timeout, my NIC sucks */ -#define PHY_ANEG_TIMEOUT 16000 +#endif /* CONFIG_SPL_BUILD */ #endif /* _CONFIG_SYNOLOGY_DS414_H */ -- 2.39.2

2 5

[PATCH v2 0/1]: drivers: bootcount: Add support for FAT filesystem
by Vasileios Amoiridis 11 Jun '24

11 Jun '24

Changes in v2: - Use generic code by utilizing FS_TYPE_ANY - Change filename from bootcount_ext.c to bootcount_fs.c v1: https://lore.kernel.org/u-boot/20240605181041.68317-1-vassilisamir@gmail.co… This patch adds support to save the bootcount variable in a file located in FAT filesystem. Up to now, there was support only for EXT filesystem. The reason I put this as RFC is because the file "bootcount_ext.c" will no longer represent the implementation for the EXT filesystem, but also for the FAT filesystem. Should it be renamed? If not, wouldn't it be inconsistent? Cheers, Vasilis P.S: Documentation has not been modified yet, I will submit in the v2 (if any). Vasileios Amoiridis (1): drivers: bootcount: Add support for FAT filesystem doc/README.bootcount | 12 ++--- drivers/bootcount/Kconfig | 53 +++++++++++++------ drivers/bootcount/Makefile | 2 +- .../{bootcount_ext.c => bootcount_fs.c} | 12 ++--- 4 files changed, 50 insertions(+), 29 deletions(-) rename drivers/bootcount/{bootcount_ext.c => bootcount_fs.c} (81%) -- 2.25.1

4 13

[PATCH] doc: Fix link reference to general verified boot docs
by Alexander Dahl 11 Jun '24

11 Jun '24

Fixes: ad29e08b79fd ("doc: Bring in FIT signature files") Signed-off-by: Alexander Dahl <ada(a)thorsis.com> --- doc/usage/fit/signature.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst index 03a71b5192d..b868dcbf9fd 100644 --- a/doc/usage/fit/signature.rst +++ b/doc/usage/fit/signature.rst @@ -15,7 +15,7 @@ that it can be verified using a public key later. Provided that the private key is kept secret and the public key is stored in a non-volatile place, any image can be verified in this way. -See verified-boot.txt for more general information on verified boot. +See :doc:`verified-boot` for more general information on verified boot. Concepts base-commit: 1ebd659cf020843fd8e8ef90d85a66941cbab6ec -- 2.39.2

2 1

[PATCH v2 0/4] Generate capsules from config files
by Sughosh Ganu 11 Jun '24

11 Jun '24

Add support for generating capsules through a config file. Multiple capsules can be generated through a single invocation of the mkeficapsule tool, where the capsule parameters are fetched from the config file. The format of the config file pretty similar to the one used by the capsule generation tool in EDKII. The functionality is enabled on the sandbox variant and the EFI capsule update test is now configured to generate the capsules through a config file. The sandbox_flattree variant generates capsules through binman, thus covering both the paths. This is a rebased version of the earlier patch series that was sent to the mailing list [1]. That series was not getting merged as Simon had asked for generation of capsules as part of the sandbox platform build. Those patches have since been merged. Moreover, there has been adoption of the capsule generation logic by TI platforms as well, so that should address the concern which Tom had about it's usage. These patches are more of a step in the direction of adding support for generation of a multi-payload capsule. There has been a request for it's support for a platform [2]. [1] - https://lists.denx.de/pipermail/u-boot/2023-November/538223.html [2] - https://lists.denx.de/pipermail/u-boot/2024-March/548126.html Sughosh Ganu (4): tools: mkeficapsule: Add support for parsing capsule params from config file doc: Document capsule generation through a config file sandbox: capsule: Add a config file for generating capsules test: capsule: Generate capsules through config file configs/sandbox_defconfig | 2 + doc/develop/uefi/uefi.rst | 70 ++++ .../test_efi_capsule/capsule_gen_binman.dts | 2 + test/py/tests/test_efi_capsule/conftest.py | 7 + .../test_efi_capsule/sandbox_capsule_cfg.txt | 73 ++++ tools/Kconfig | 15 + tools/Makefile | 1 + tools/eficapsule.h | 114 ++++++ tools/mkeficapsule.c | 87 +++-- tools/mkeficapsule_parse.c | 352 ++++++++++++++++++ 10 files changed, 692 insertions(+), 31 deletions(-) create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt create mode 100644 tools/mkeficapsule_parse.c -- 2.34.1

3 9

Proposal: U-Boot memory management
by Simon Glass 11 Jun '24

11 Jun '24

Hi, This records my thoughts after a discussion with Ilias & Heinrich re memory allocation in U-Boot. 1. malloc() malloc() is used for programmatic memory allocation. It allows memory to be freed. It is not designed for very large allocations (e.g. a 10MB kernel or 100MB ramdisk). 2. lmb lmb is used for large blocks of memory, such as those needed for a kernel or ramdisk. Allocation is only transitory, for the purposes of loading some images and booting. If the boot fails, then all lmb allocations go away. lmb is set up by getting all available memory and then removing what is used by U-Boot (code, data, malloc() space, etc.) lmb reservations have a few flags so that areas of memory can be provided with attributes There are some corner cases...e.g. loading a file does an lmb allocation but only for the purpose of avoiding a file being loaded over U-Boot code/data. The allocation is dropped immediately after the file is loaded. Within the bootm command, or when using standard boot, this would be fairly easy to solve. Linux has renamed lmb to memblock. We should consider doing the same. 3. EFI EFI has its own memory-allocation tables. Like lmb, EFI is able to deal with large allocations. But via a 'pool' function it can also do smaller allocations similar to malloc(), although each one uses at least 4KB at present. EFI allocations do not go away when a boot fails. With EFI it is possible to add allocations post facto, in which case they are added to the allocation table just as if the memory was allocated with EFI to begin with. The EFI allocations and the lmb allocations use the same memory, so in principle could conflict. EFI allocations are sometimes used to allocate internal U-Boot data as well, if needed by the EFI app. For example, while efi_image_parse() uses malloc(), efi_var_mem.c uses EFI allocations since the code runs in the app context and may need to access the memory after U-Boot has exited. Also efi_smbios.c uses allocate_pages() and then adds a new mapping as well. EFI memory has attributes, including what the memory is used for (to some degree of granularity). See enum efi_memory_type and struct efi_mem_desc. In the latter there are also attribute flags - whether memory is cacheable, etc. EFI also has the x86 idea of 'conventional' memory, meaning (I believe) that below 4GB that isn't reserved for the hardware/system. This is meaningless, or at least confusing, on ARM systems. 4. reservations It is perhaps worth mentioning a fourth method of memory management, where U-Boot reserves chunks of memory before relocation (in board_init_f.c), e.g. for the framebuffer, U-Boot code, the malloc() region, etc. Problems —------- There are no urgent problems, but here are some things that could be improved: 1. EFI should attach most of its data structures to driver model. This work has started, with the partition support, but more effort would help. This would make it easier to see which memory is related to devices and which is separate. 2. Some drivers do EFI reservations today, whether EFI is used for booting or not (e.g. rockchip video rk_vop_probe()). 3. U-Boot doesn't really map arch-specific memory attributes (e.g. armv8's struct mm_region) to EFI ones. 4. EFI duplicates some code from bootm, some of which relates to memory allocation (e.g. FDT fixup). 5. EFI code is used even if EFI is never used to boot 6. EFI allocations can result in the same memory being used as has already been allocated by lmb. Users may load files which overwrite memory allocated by EFI. Lifetime -------- We have three different memory allocators with different purposes. Can we unify them a little? Within U-Boot: - malloc() space lives forever - lmb lives while setting out images for booting - EFI (mostly) lives while booting an EFI app In practice, EFI is set up early in U-Boot. Some of this is necessary, some not. EFI allocations stay around forever. This works OK since large allocations are normally not done in EFI, so memory isn't really consumed to any great degree by the boot process. What happens to EFI allocations if the app returns? They are still present, in case another app is run. This seems fine. API –-- Can we unify some APIs? It should be possible to use lmb for large EFI memory allocations, so long as they are only needed for booting. We effectively do this today, since EFI does not manage the arrangement of loaded images in memory. for the most part. It would not make sense to use EFI allocation to replace lmb and malloc(), of course. Could we use a common (lower-level) API for allocation, used by both lmb and EFI? They do have some similarities. However they have different lifetime constraints (EFI allocations are never dropped, unlikely lmb). ** Overall, it seems that the existence of memory allocation in boot-time services has created confusion. Memory allocation is muddled, with both U-Boot code and boot-time services calling the same memory allocator. This just has not been clearly thought out. Proposal —------- Here are some ideas: 1. For video, use the driver model API to locate the video regions, or block off the entire framebuffer memory, for all devices as a whole. Use efi_add_memory_map() 2. Add memory attributes to UCLASS_RAM and use them in EFI, mapping to the EFI_MEMORY_... attributes in struct efi_mem_desc. 3. Add all EFI reservations just before booting the app, as we do with devicetree fixup. With this model, malloc() and lmb are used for all allocation. Then efi_add_memory_map() is called for each region in turn just before booting. Memory attributes are dealt with above. The type (enum efi_memory_type) can be determined simply by the data structure stored in it, as is done today. For example, SMBIOS tables can use EFI_ACPI_RECLAIM_MEMORY. Very few types are used and EFI code understands the meaning of each. 4. Avoid setting up EFI memory at the start of U-Boot. Do it only when booting. This looks to require very little effort. 5. Avoid calling efi_allocate_pages() and efi_allocate_pool() outside boot-time services. This solves the problem 6. If memory is needed by an app, allocate it with malloc() and see 3. There are only two efi_allocate_pages() (smbios and efi_runtime). There are more calls of efi_allocate_pool(), but most of these seem easy to fix up. For example, efi_init_event_log() allocates a buffer, but this can be allocated in normal malloc() space or in a bloblist. 6. Don't worry too much about whether EFI will be used for booting. The cost is likely not that great: use bootstage to measure it as is done for driver model. Try to minmise the cost of its tables, particularly for execution time, but otherwise just rely on the ability to disable EFI_LOADER. – Regards, Simon

6 51

[PATCH 0/4] alist: Implement a pointer list / array of structs
by Simon Glass 11 Jun '24

11 Jun '24

This data structure provides a list of pointers / array of structures. I was planning to use it for the lmb restructure, to allow it to support any number of entries, but then I gave up on it. There are quite a few places in U-Boot where such a list would be useful, since it supports growing the array. The series includes a patch to convert an existing function to use this. It adds a little under 300 bytes of code with Thumb2. Example: struct my_struct obj; struct my_struct *ptr = alist_add(&lst, &obj, struct my_struct); // now ptr is in the list [1] https://patchwork.ozlabs.org/project/uboot/list/?series=371258&state=* Simon Glass (4): malloc: Support testing with realloc() lib: Handle a special case with str_to_list() alist: Add support for an allocated pointer list lib: Convert str_to_list() to use alist common/dlmalloc.c | 4 + include/alist.h | 205 ++++++++++++++++++++++++++++++++++++++++++++++ lib/Makefile | 1 + lib/alist.c | 154 ++++++++++++++++++++++++++++++++++ lib/strto.c | 33 ++++---- test/lib/Makefile | 1 + test/lib/alist.c | 197 ++++++++++++++++++++++++++++++++++++++++++++ test/str_ut.c | 4 +- 8 files changed, 582 insertions(+), 17 deletions(-) create mode 100644 include/alist.h create mode 100644 lib/alist.c create mode 100644 test/lib/alist.c -- 2.34.1

1 4

[NEXT] Pull request efi-next-20240611
by Heinrich Schuchardt 11 Jun '24

11 Jun '24

Dear Tom, This pull request is for the next branch. The following changes since commit 4f836fb324ba500ecabdba4146c3ca9e1600cdf5: memory: ti-gpmc: use printf to dump settings/timings (2024-06-07 14:07:23 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-next-20240611 for you to fetch changes up to 535321c2ea76de44896330040d2e43aa4645d026: efi_loader: rename struct efi_initrd_dp to efi_lo_dp_prefix (2024-06-10 11:43:37 +0200) Gitlab CI reported no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/21059 ---------------------------------------------------------------- Pull request efi-next-20240611 UEFI: * Allow specifying a device-tree in an EFI load option using the efidebug or eficonfig command. * Let the EFI boot manager fall back to an OS provided device-tree if no device-tree is specified. ---------------------------------------------------------------- Heinrich Schuchardt (9): efi_loader: allow concatenation with contained end node cmd: eficonfig: add support for setting fdt cmd: efidebug: add support for setting fdt efi_loader: load device-tree specified in boot option efi_loader: move distro_efi_get_fdt_name() efi_loader: return binary from efi_dp_from_lo() efi_loader: export efi_load_image_from_path efi_loader: load distro dtb in bootmgr efi_loader: rename struct efi_initrd_dp to efi_lo_dp_prefix boot/bootmeth_efi.c | 60 +------------- cmd/eficonfig.c | 83 ++++++++++++++----- cmd/efidebug.c | 129 ++++++++++++++++++++--------- include/efi_load_initrd.h | 12 ++- include/efi_loader.h | 24 +++++- lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_bootbin.c | 2 +- lib/efi_loader/efi_bootmgr.c | 81 +++++++++++++++++- lib/efi_loader/efi_boottime.c | 3 +- lib/efi_loader/efi_device_path.c | 40 +++++---- lib/efi_loader/efi_device_path_utilities.c | 2 +- lib/efi_loader/efi_fdt.c | 117 ++++++++++++++++++++++++++ lib/efi_loader/efi_helper.c | 44 ++++++++++ lib/efi_loader/efi_load_initrd.c | 2 +- lib/efi_loader/initrddump.c | 2 +- 15 files changed, 463 insertions(+), 139 deletions(-) create mode 100644 lib/efi_loader/efi_fdt.c

2 1

Debugging gpio-hogs which don't get probed
by Chris Webb 11 Jun '24

11 Jun '24

I'm building u-boot for a mt7981a board, very similar to the in-tree mt7981-emmc-rfb. For reference, my device tree and output of make savedefconfig are here: https://gist.github.com/arachsys/98048980728c652bea641b42cfd41a40 Everything boots fine, but I have a handful of gpios which need to be set to fixed values before booting the kernel to enable a 5g modem. I can do this with gpio clear 10; gpio set 5; gpio set 9; gpio 11 which works fine, but I think the 'official' solution for this might be using u-boot's gpio-hog support? With that in mind, I added &gpio { hub_power { gpio-hog; gpios = <5 GPIO_ACTIVE_HIGH>; output-high; }; modem_control { gpio-hog; gpios = <9 GPIO_ACTIVE_HIGH>; output-high; }; modem_reset { gpio-hog; gpios = <10 GPIO_ACTIVE_HIGH>; output-low; }; modem_power { gpio-hog; gpios = <11 GPIO_ACTIVE_HIGH>; output-high; }; }; with CONFIG_GPIO_HOG=y, but this doesn't seem to work on either u-boot.git HEAD or 2024.07-rc. To try to see what was going on better, I added some debug printfs: --- a/u-boot/drivers/gpio/gpio-uclass.c +++ b/u-boot/drivers/gpio/gpio-uclass.c @@ -328,6 +330,8 @@ static int gpio_hog_of_to_plat(struct udevice *dev) static int gpio_hog_probe(struct udevice *dev) { + printf("gpio_hog_probe called\n"); + struct gpio_hog_data *plat = dev_get_plat(dev); struct gpio_hog_priv *priv = dev_get_priv(dev); int ret; @@ -1518,6 +1523,8 @@ void devm_gpiod_put(struct udevice *dev, struct gpio_desc *desc) static int gpio_post_bind(struct udevice *dev) { + printf("gpio_post_bind called\n"); + if (CONFIG_IS_ENABLED(GPIO_HOG) && dev_has_ofnode(dev)) { struct udevice *child; ofnode node; @@ -1539,6 +1546,7 @@ static int gpio_post_bind(struct udevice *dev) * since hogs can be essential to the hardware * system. */ + printf("found a gpio-hog\n"); dev_or_flags(child, DM_FLAG_PROBE_AFTER_BIND); } } This shows gpio_post_bind being called, then the four gpio-hogs found and set to probe after bind, but the gpio_hog_probe function is never actually called. Presumably this is the problem - if they're not probed then they'll never take effect? I enabled CONFIG_DM_WARN and CONFIG_DM_DEBUG, which confirm that nothing ever seems to be probing the gpio-hog children, but there aren't obviously any errors or warnings related to them either. Nothing relevant happens after gpio_post_bind is called. Is this a bug or is there some basic config/dts mistake on my part here? Is there some other debug info I can get that might shed light on what's going on, or some config prerequisite for DM_FLAG_PROBE_AFTER_BIND to work that I'm likely to be missing? Best wishes, Chris.

1 1

[PATCH 0/7] MIPS: Enable EFI support
by Jiaxun Yang 11 Jun '24

11 Jun '24

Hi all, This series enabled EFI support to MIPS platform. Although MIPS is not defined by UEFI specification, there are quite a few firmware implementations available, including MIPS-EFI[1] for Loongson-2F, Lemote's proprietary EDK2 implementation on Loongson-3[2], Kunlun firmware for Loongson-3[3], efiffy[4] for MIPS Creator CI20 and another mystery EDK implementation shipped with some Creator CI20 board. Available applications including gnu-efi, Loongson's GRUB fork[5], Ventoy[6]. My implementation in U-Boot is aiming to follow conventions made by other implementations for architecture stuff and remain compliance with spec for general aspects. bootefi hello and selftest passed on both 32 and 64 bit system, gnu-efi, grub and ventoy are tested on mips64el with my pending platform works. mips32el efi executable from efiffy is tested as well. Please review. Thanks [1]: https://github.com/kontais/EFI-MIPS [2]: https://github.com/loongson-community/firmware-nonfree [3]: http://www.kunluntech.com.cn/klbiosxl [4]: https://sourceforge.net/projects/efify/ [5]: https://github.com/loongson-community/grub [6]: https://www.ventoy.net/en/index.html Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Jiaxun Yang (7): MIPS: Implement setjmp efi: Allow runtime relocate to be disabled Makefile.lib: Preserve .rodata section for EFI file Makefile.lib: Enforce EFI CFLAGS/AFLAGS MIPS: Add smbios_start to arch_global_data MIPS: Define MIPS EFI related bits everywhere MIPS: Implement EFI supporting stuff Makefile | 3 + arch/mips/config.mk | 9 + arch/mips/include/asm/global_data.h | 3 + arch/mips/include/asm/setjmp.h | 36 ++++ arch/mips/lib/Makefile | 15 ++ arch/mips/lib/crt0_mips_efi.S | 239 ++++++++++++++++++++++ arch/mips/lib/elf_mips_efi.lds | 113 ++++++++++ arch/mips/lib/reloc_mips_efi.c | 99 +++++++++ arch/mips/lib/setjmp32.S | 51 +++++ arch/mips/lib/setjmp64.S | 56 +++++ include/asm-generic/pe.h | 5 + include/config_distro_bootcmd.h | 6 + include/efi_default_filename.h | 8 + include/efi_loader.h | 26 ++- include/elf.h | 8 + lib/efi_loader/Kconfig | 12 +- lib/efi_loader/efi_image_loader.c | 18 ++ lib/efi_loader/efi_memory.c | 14 +- lib/efi_loader/efi_runtime.c | 11 +- lib/efi_loader/efi_var_mem.c | 6 +- lib/efi_selftest/Makefile | 2 +- lib/efi_selftest/efi_selftest_miniapp_exception.c | 2 + scripts/Makefile.lib | 10 +- 23 files changed, 734 insertions(+), 18 deletions(-) --- base-commit: ad7dce5abd49ef3b5c93da5303e15449c8c162b4 change-id: 20240517-mips-efi-c9a1ad819c2d Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

4 27

[PATCH 00/13] Arm64 big endian enablement
by Jiaxun Yang 11 Jun '24

11 Jun '24

Hi all, This series enabled big endian support for arm64, enabled qemu-arm board for arm64be and slightly adjusted our Kconfig handling on endianness. In practical I think most Arm SoCs do support little endian only, for those SoCs with big endian support they are usually bi-endian and expected bootloader in little endian. The only big-endian only Arm SoC I know is a network processor from ZTE ZXIC, I doubt if upstream U-Boot will ever support it. However enabling arm64be can enable us to take more care on big endian targets, given that arm64 is the most feature rich arch in U-Boot, we can run more test on big endian systems. Boot tested on qemu. Please review. Thanks Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Jiaxun Yang (13): tools/relocate-rela: Fix Big Endian elf64 handling arm: Don't select ARM_ASM_UNIFIED on arm64 arm: Fix assembler.h for arm64 arm: Introduce CPU_LE/CPU_BE macros arm: Define endian related bits in system.h armv8: Big Endian enablement for compiler and linker arm: Perform byte swap for read and write in io.h armv8: Allow endianness to be setted at reset entry armv8: spin_table: Perform byte swap for jump address lib/crc32: Don't perform byte swap for arm64 crc32b Kconfig: Unify endian support option config: Use CONFIG_SYS_BIG_ENDIAN in code whenever possible qemu-arm: Big endian enablement for arm64 Makefile | 2 +- arch/Kconfig | 34 ++++++++--- arch/arc/include/asm/arc-bcr.h | 10 +-- arch/arm/Kconfig | 3 +- arch/arm/config.mk | 14 +++++ arch/arm/cpu/armv8/Kconfig | 9 +++ .../arm/cpu/armv8/linux-kernel-image-header-vars.h | 4 +- arch/arm/cpu/armv8/spin_table_v8.S | 2 + arch/arm/cpu/armv8/start.S | 26 ++++++++ arch/arm/cpu/armv8/u-boot-spl.lds | 6 ++ arch/arm/cpu/armv8/u-boot.lds | 4 ++ arch/arm/include/asm/assembler.h | 25 ++++++++ arch/arm/include/asm/io.h | 12 ++-- arch/arm/include/asm/system.h | 3 + arch/arm/lib/elf_aarch64_efi.lds | 7 +++ arch/mips/Kconfig | 20 +++--- arch/mips/mach-ath79/Kconfig | 8 +-- arch/mips/mach-bmips/Kconfig | 20 +++--- arch/mips/mach-jz47xx/Kconfig | 2 +- arch/mips/mach-mscc/Kconfig | 4 +- arch/mips/mach-pic32/Kconfig | 2 +- board/emulation/qemu-arm/Kconfig | 2 + board/emulation/qemu-arm/MAINTAINERS | 1 + configs/qemu_arm64be_defconfig | 71 ++++++++++++++++++++++ doc/board/emulation/qemu-arm.rst | 7 ++- drivers/mtd/nand/raw/brcmnand/brcmnand.c | 2 +- lib/crc32.c | 3 +- scripts/Makefile.build | 2 +- scripts/Makefile.lib | 3 +- tools/relocate-rela.c | 40 +++++++----- 30 files changed, 271 insertions(+), 77 deletions(-) --- base-commit: 3be9f399e911cfc437a37ac826441f1d96da1c9b change-id: 20240518-aarch64-be-1ec99cf7f28b Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

2 14

[PATCH v3 0/1] Enable reset_cpu() in SPL for ZynqMP
by lukas.funke-oss＠weidmueller.com 11 Jun '24

11 Jun '24

From: Lukas Funke <lukas.funke(a)weidmueller.com> This series enables the CPU reset in the SPL for ZynqMP based platforms. This only works if CONFIG_SYSRESET is disabled. This is usually the case since the the regular sysreset requires bl31 firmware to be loaded in order to hand the sysreset over to PMU firmware. In SPL we can talk to the PMU firmware directly and request a CPU reset. Changes in v3: - Use 'ZYNQMP_PM_RESET_SOFT' directly - Add comment on what happens if CONFIG_ZYNQMP_FIRMWARE is not enabled Changes in v2: - Drop 2/2 since reworking ZYNQMP_FIRMWARE dependency is out-of-scope Lukas Funke (1): xilinx: zynqmp: Enable reset_cpu() in SPL board/xilinx/zynqmp/zynqmp.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) -- 2.30.2

2 2

[PATCH v3 1/1] arm64: zynqmp: Enable usb3 for k24 som
by Neal Frager 11 Jun '24

11 Jun '24

This patch corrects the mio and pll configuration registers for using usb3 on the kd240 starter kit. Without this patch, the usb3 to sd card bridge does not initialize correctly and u-boot is unable to find the OS located on the kd240 starter kit sd card. In addition, this patch correctly configures mio76 and mio77 as gpio pins which are used as reset gpio pins on the kd240 starter kit. Signed-off-by: Neal Frager <neal.frager(a)amd.com> --- V1->V2: - rebased patch to latest u-boot master branch - improved git commit message V2->V3: - removed unnecessary serdes initialization from patch --- .../zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c | 23 ++++++++----------- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c b/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c index 166e61431b..274203ffaa 100644 --- a/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c +++ b/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c @@ -528,8 +528,8 @@ static unsigned long psu_mio_init_data(void) psu_mask_write(0xFF180124, 0x000000FEU, 0x00000002U); psu_mask_write(0xFF180128, 0x000000FEU, 0x00000002U); psu_mask_write(0xFF18012C, 0x000000FEU, 0x00000002U); - psu_mask_write(0xFF180130, 0x000000FEU, 0x000000C0U); - psu_mask_write(0xFF180134, 0x000000FEU, 0x000000C0U); + psu_mask_write(0xFF180130, 0x000000FEU, 0x00000000U); + psu_mask_write(0xFF180134, 0x000000FEU, 0x00000000U); psu_mask_write(0xFF180204, 0xFFFFFFFFU, 0x50000000U); psu_mask_write(0xFF180208, 0xFFFFFFFFU, 0x00B02020U); psu_mask_write(0xFF18020C, 0x00003FFFU, 0x00000FC0U); @@ -569,21 +569,16 @@ static unsigned long psu_peripherals_init_data(void) psu_mask_write(0xFD1A0100, 0x0001807CU, 0x00000000U); psu_mask_write(0xFF5E0238, 0x001A0000U, 0x00000000U); psu_mask_write(0xFF5E023C, 0x0093C018U, 0x00000000U); - psu_mask_write(0xFF5E0230, 0x00000008U, 0x00000000U); + psu_mask_write(0xFF5E0230, 0x00000002U, 0x00000000U); psu_mask_write(0xFF5E0238, 0x00000001U, 0x00000000U); psu_mask_write(0xFF180390, 0x00000004U, 0x00000004U); psu_mask_write(0xFF5E023C, 0x00000400U, 0x00000000U); - psu_mask_write(0xFF5E0238, 0x00000040U, 0x00000000U); - psu_mask_write(0xFF180310, 0x00008000U, 0x00000000U); - psu_mask_write(0xFF180320, 0x33840000U, 0x02840000U); - psu_mask_write(0xFF18031C, 0x7FFE0000U, 0x64500000U); - psu_mask_write(0xFF180358, 0x00000008U, 0x00000008U); - psu_mask_write(0xFF180324, 0x03C00000U, 0x00000000U); + psu_mask_write(0xFF5E0238, 0x00000080U, 0x00000000U); psu_mask_write(0xFF5E0238, 0x00000400U, 0x00000000U); psu_mask_write(0xFF5E0238, 0x00008000U, 0x00000000U); psu_mask_write(0xFF5E0238, 0x00000010U, 0x00000000U); psu_mask_write(0xFF5E0238, 0x00007800U, 0x00000000U); - psu_mask_write(0xFF5E0238, 0x00000004U, 0x00000000U); + psu_mask_write(0xFF5E0238, 0x00000006U, 0x00000000U); psu_mask_write(0xFF5E0238, 0x00040000U, 0x00000000U); psu_mask_write(0xFF4B0024, 0x000000FFU, 0x000000FFU); psu_mask_write(0xFFCA5000, 0x00001FFFU, 0x00000000U); @@ -591,13 +586,15 @@ static unsigned long psu_peripherals_init_data(void) psu_mask_write(0xFFA60040, 0x80000000U, 0x80000000U); psu_mask_write(0xFF260020, 0xFFFFFFFFU, 0x05F5DD18U); psu_mask_write(0xFF260000, 0x00000001U, 0x00000001U); - psu_mask_write(0xFF5E0250, 0x00000F0FU, 0x00000202U); + psu_mask_write(0xFF0A0284, 0x03FFFFFFU, 0x01000000U); + psu_mask_write(0xFF0A0288, 0x03FFFFFFU, 0x01000000U); + psu_mask_write(0xFF0A0014, 0x03FF03FFU, 0x02FF0100U); mask_delay(1); - psu_mask_write(0xFF5E0250, 0x00000F0FU, 0x00000002U); + psu_mask_write(0xFF0A0014, 0x03FF03FFU, 0x02FF0000U); mask_delay(5); - psu_mask_write(0xFF5E0250, 0x00000F0FU, 0x00000202U); + psu_mask_write(0xFF0A0014, 0x03FF03FFU, 0x02FF0100U); return 1; } -- 2.25.1

2 1

[PATCH] arm64: zynqmp: Setup multiboot register to 0
by Michal Simek 11 Jun '24

11 Jun '24

On Kria when board starts from Image A or Image B partition multiboot register is already setup to that location. When reset command is called board is issuing soft reset which start SW at already used location (offset of multiboot * 32k). But board should continue to run from multiboot offset 0 (start of QSPI) and call early bootloader every reboot that's why clear multiboot register to 0 by default to go that route all the time. Signed-off-by: Michal Simek <michal.simek(a)amd.com> --- board/xilinx/zynqmp/zynqmp_kria.env | 1 + 1 file changed, 1 insertion(+) diff --git a/board/xilinx/zynqmp/zynqmp_kria.env b/board/xilinx/zynqmp/zynqmp_kria.env index 846eceb0118d..69e333c53887 100644 --- a/board/xilinx/zynqmp/zynqmp_kria.env +++ b/board/xilinx/zynqmp/zynqmp_kria.env @@ -65,6 +65,7 @@ kd240_setup=i2c dev 1 && run usb_hub_init;zynqmp pmufw node 33; zynqmp pmufw nod tpm_setup=tpm autostart; board_setup=\ +zynqmp mmio_write 0xFFCA0010 0xfff 0; \ if test ${card1_name} = SCK-KV-G; then run kv260_setup; fi;\ if test ${card1_name} = SCK-KR-G; then run kr260_setup; fi;\ if test ${card1_name} = SCK-KD-G; then run kd240_setup; fi;\ -- 2.40.1

1 1

[PATCH 0/4] arm64: versal2: Add support for new AMD Versal Gen 2 SoC
by Michal Simek 11 Jun '24

11 Jun '24

Hi, I am sending patches for adding initial support for new AMD Versal Gen 2 SoC. If you want to find out more information please take a look at this page: https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal.html Thanks, Michal Michal Simek (4): arm64: versal2: Add support for AMD Versal Gen 2 soc: versal2: Add SoC driver for AMD Versal Gen 2 mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2 spi: versal2: Enable spi drivers for Versal Gen 2 arch/arm/Kconfig | 14 + arch/arm/Makefile | 1 + arch/arm/dts/Makefile | 2 + arch/arm/dts/amd-versal2-virt.dts | 11 + arch/arm/mach-versal2/Kconfig | 55 +++ arch/arm/mach-versal2/Makefile | 10 + arch/arm/mach-versal2/clk.c | 34 ++ arch/arm/mach-versal2/cpu.c | 93 +++++ arch/arm/mach-versal2/include/mach/hardware.h | 97 +++++ .../arm/mach-versal2/include/mach/sys_proto.h | 9 + board/amd/common | 1 + board/amd/versal2/Kconfig | 16 + board/amd/versal2/MAINTAINERS | 7 + board/amd/versal2/Makefile | 11 + board/amd/versal2/board.c | 343 ++++++++++++++++++ board/amd/versal2/cmds.c | 81 +++++ board/xilinx/Kconfig | 6 +- configs/amd_versal2_virt_defconfig | 150 ++++++++ drivers/gpio/Kconfig | 2 +- drivers/mailbox/Kconfig | 2 +- drivers/mmc/zynq_sdhci.c | 22 +- drivers/soc/Kconfig | 8 + drivers/soc/Makefile | 1 + drivers/soc/soc_amd_versal2.c | 77 ++++ drivers/spi/Kconfig | 2 +- drivers/spi/cadence_qspi.c | 3 +- drivers/spi/zynqmp_gqspi.c | 6 +- env/Kconfig | 6 +- include/configs/amd_versal2.h | 143 ++++++++ 29 files changed, 1193 insertions(+), 20 deletions(-) create mode 100644 arch/arm/dts/amd-versal2-virt.dts create mode 100644 arch/arm/mach-versal2/Kconfig create mode 100644 arch/arm/mach-versal2/Makefile create mode 100644 arch/arm/mach-versal2/clk.c create mode 100644 arch/arm/mach-versal2/cpu.c create mode 100644 arch/arm/mach-versal2/include/mach/hardware.h create mode 100644 arch/arm/mach-versal2/include/mach/sys_proto.h create mode 120000 board/amd/common create mode 100644 board/amd/versal2/Kconfig create mode 100644 board/amd/versal2/MAINTAINERS create mode 100644 board/amd/versal2/Makefile create mode 100644 board/amd/versal2/board.c create mode 100644 board/amd/versal2/cmds.c create mode 100644 configs/amd_versal2_virt_defconfig create mode 100644 drivers/soc/soc_amd_versal2.c create mode 100644 include/configs/amd_versal2.h -- 2.40.1

2 9

[PATCH] doc: board: sophgo: milkv_duo: Update Milk-V Duo documentation
by Kongyang Liu 11 Jun '24

11 Jun '24

Add detailed steps for compiling U-Boot and OpenSBI, generating the firmware package with fiptool, and booting the board. Signed-off-by: Kongyang Liu <seashell11234455(a)gmail.com> --- doc/board/sophgo/milkv_duo.rst | 41 +++++++++++++++++++++++++--------- 1 file changed, 30 insertions(+), 11 deletions(-) diff --git a/doc/board/sophgo/milkv_duo.rst b/doc/board/sophgo/milkv_duo.rst index cb2ed1ad98..a88db5b903 100644 --- a/doc/board/sophgo/milkv_duo.rst +++ b/doc/board/sophgo/milkv_duo.rst @@ -20,31 +20,50 @@ Building .. code-block:: console export CROSS_COMPILE=<riscv64 toolchain prefix> + +3. Compile U-Boot + +.. code-block:: console + cd <U-Boot-dir> make milkv_duo_defconfig make -This will generate u-boot-dtb.bin +This will generate u-boot.bin and u-boot.dtb -Booting -~~~~~~~ -Currently, we rely on vendor FSBL(First Stage Boot Loader) to initialize the -clock and load the u-boot image, then bootup from it. +4. Compile OpenSBI + +.. code-block:: console -Alternatively, to run u-boot-dtb.bin on top of FSBL, follow these steps: + cd <OpenSBI-dir> + make PLATFORM=generic FW_FDT_PATH=<Your U-Boot Path>/u-boot.dtb -1. Use the vendor-provided tool to create a unified fip.bin file containing - FSBL, OpenSBI, and U-Boot. +This will generate fw_dynamic.bin -2. Place the generated fip.bin file into the FAT partition of the SD card. +4. Generate firmware image package -3. Insert the SD card into the board and power it on. +Fiptool(https://github.com/sophgo/fiptool) is used to generate fip file. + +.. code-block:: console + + git clone https://github.com/sophgo/fiptool + cd fiptool + ./fiptool \ + --fsbl data/fsbl/cv180x.bin \ + --opensbi <OpenSBI-dir>/fw_dynamic.bin \ + --uboot <U-Boot-dir>/u-boot.bin \ + +This will generate fip.bin + +Booting +~~~~~~~ +1. Place the generated fip.bin file into the FAT partition of the SD card. +2. Insert the SD card into the board and power it on. The board will automatically execute the FSBL from the fip.bin file. Subsequently, it will transition to OpenSBI, and finally, OpenSBI will invoke U-Boot. - Sample boot log from Milk-V Duo board ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. code-block:: none -- 2.41.0

2 2

[PATCH 1/1] Added arm64 assembly for examples/api crt0
by Brunham, Kalen 10 Jun '24

10 Jun '24

I've encountered a problem when compiling the 'examples/api' directory for ARM64 in U-boot. The problem lies in the assembly code in 'examples/api/crt0.S' where the current CONFIG_ARM code is only 32-bit. When targeting ARM64, a 64-bit version is necessary. I have proposed a fix by including a 'CONFIG_ARM64' section in the assembly code as shown below. These changes have been check via https://github.com/u-boot/u-boot/pull/538. Feedback is welcome. --- examples/api/crt0.S | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/examples/api/crt0.S b/examples/api/crt0.S index 57bba9d851..4c23a54b21 100644 --- a/examples/api/crt0.S +++ b/examples/api/crt0.S @@ -24,6 +24,21 @@ syscall: mtctr %r11 bctr +#elif defined(CONFIG_ARM64) + + .text + .globl _start +_start: + ldr ip0, =search_hint + str sp_el2, [ip0] + b main + + + .globl syscall +syscall: + ldr ip0, =syscall_ptr + ldr pc_el2, [ip0] + #elif defined(CONFIG_ARM) .text -- Signed-off-by: Kalen Brunham <kalen.brunham(a)intel.com>

5 26

[PATCH v3] abootimg: Add init_boot image support
by Roman Stratiienko 10 Jun '24

10 Jun '24

Quote from [1]: "For devices launching with Android 13, the generic ramdisk is removed from the boot image and placed in a separate init_boot image. This change leaves the boot image with only the GKI kernel." While at it, update wrong error handling message when vendor_boot cannot be loaded. [1]: https://source.android.com/docs/core/architecture/partitions/generic-boot Signed-off-by: Roman Stratiienko <r.stratiienko(a)gmail.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek(a)baylibre.com> --- Changes in v2: - Addressed review comments v1 Changes in v3: - Rebased on top of latest u-boot/next boot/image-board.c | 13 ++++++++++--- cmd/abootimg.c | 26 +++++++++++++++++++++----- include/image.h | 7 +++++++ 3 files changed, 38 insertions(+), 8 deletions(-) diff --git a/boot/image-board.c b/boot/image-board.c index b7884b8c5d..f212401304 100644 --- a/boot/image-board.c +++ b/boot/image-board.c @@ -406,13 +406,20 @@ static int select_ramdisk(struct bootm_headers *images, const char *select, u8 a if (IS_ENABLED(CONFIG_ANDROID_BOOT_IMAGE)) { int ret; if (IS_ENABLED(CONFIG_CMD_ABOOTIMG)) { - void *boot_img = map_sysmem(get_abootimg_addr(), 0); + ulong boot_img = get_abootimg_addr(); + ulong init_boot_img = get_ainit_bootimg_addr(); void *vendor_boot_img = map_sysmem(get_avendor_bootimg_addr(), 0); + void *ramdisk_img; - ret = android_image_get_ramdisk(boot_img, vendor_boot_img, + if (init_boot_img == -1) + ramdisk_img = map_sysmem(boot_img, 0); + else + ramdisk_img = map_sysmem(init_boot_img, 0); + + ret = android_image_get_ramdisk(ramdisk_img, vendor_boot_img, rd_datap, rd_lenp); unmap_sysmem(vendor_boot_img); - unmap_sysmem(boot_img); + unmap_sysmem(ramdisk_img); } else { void *ptr = map_sysmem(images->os.start, 0); diff --git a/cmd/abootimg.c b/cmd/abootimg.c index 88c77d9992..327712a536 100644 --- a/cmd/abootimg.c +++ b/cmd/abootimg.c @@ -14,6 +14,7 @@ /* Please use abootimg_addr() macro to obtain the boot image address */ static ulong _abootimg_addr = -1; +static ulong _ainit_bootimg_addr = -1; static ulong _avendor_bootimg_addr = -1; ulong get_abootimg_addr(void) @@ -21,6 +22,11 @@ ulong get_abootimg_addr(void) return (_abootimg_addr == -1 ? image_load_addr : _abootimg_addr); } +ulong get_ainit_bootimg_addr(void) +{ + return _ainit_bootimg_addr; +} + ulong get_avendor_bootimg_addr(void) { return _avendor_bootimg_addr; @@ -179,7 +185,7 @@ static int do_abootimg_addr(struct cmd_tbl *cmdtp, int flag, int argc, char *endp; ulong img_addr; - if (argc < 2 || argc > 3) + if (argc < 2 || argc > 4) return CMD_RET_USAGE; img_addr = hextoul(argv[1], &endp); @@ -190,16 +196,26 @@ static int do_abootimg_addr(struct cmd_tbl *cmdtp, int flag, int argc, _abootimg_addr = img_addr; - if (argc == 3) { + if (argc > 2) { img_addr = simple_strtoul(argv[2], &endp, 16); if (*endp != '\0') { - printf("Error: Wrong vendor image address\n"); + printf("Error: Wrong vendor_boot image address\n"); return CMD_RET_FAILURE; } _avendor_bootimg_addr = img_addr; } + if (argc == 4) { + img_addr = simple_strtoul(argv[3], &endp, 16); + if (*endp != '\0') { + printf("Error: Wrong init_boot image address\n"); + return CMD_RET_FAILURE; + } + + _ainit_bootimg_addr = img_addr; + } + return CMD_RET_SUCCESS; } @@ -243,7 +259,7 @@ static int do_abootimg_dump(struct cmd_tbl *cmdtp, int flag, int argc, } static struct cmd_tbl cmd_abootimg_sub[] = { - U_BOOT_CMD_MKENT(addr, 3, 1, do_abootimg_addr, "", ""), + U_BOOT_CMD_MKENT(addr, 4, 1, do_abootimg_addr, "", ""), U_BOOT_CMD_MKENT(dump, 2, 1, do_abootimg_dump, "", ""), U_BOOT_CMD_MKENT(get, 5, 1, do_abootimg_get, "", ""), }; @@ -271,7 +287,7 @@ static int do_abootimg(struct cmd_tbl *cmdtp, int flag, int argc, U_BOOT_CMD( abootimg, CONFIG_SYS_MAXARGS, 0, do_abootimg, "manipulate Android Boot Image", - "addr <boot_img_addr> [<vendor_boot_img_addr>]>\n" + "addr <boot_img_addr> [<vendor_boot_img_addr> [<init_boot_img_addr>]]\n" " - set the address in RAM where boot image is located\n" " ($loadaddr is used by default)\n" "abootimg dump dtb\n" diff --git a/include/image.h b/include/image.h index acffd17e0d..c5b288f62b 100644 --- a/include/image.h +++ b/include/image.h @@ -1970,6 +1970,13 @@ bool is_android_vendor_boot_image_header(const void *vendor_boot_img); */ ulong get_abootimg_addr(void); +/** + * get_ainit_bootimg_addr() - Get Android init boot image address + * + * Return: Android init boot image address + */ +ulong get_ainit_bootimg_addr(void); + /** * get_avendor_bootimg_addr() - Get Android vendor boot image address * -- 2.40.1

3 2

[PATCH] android: Fix ramdisk loading for bootimage v3+
by Roman Stratiienko 10 Jun '24

10 Jun '24

The boot_ramdisk and vendor_ramdisk must be both concatenated together. Without this change, Android root is missing some of the necessary tools to complete virtual AB OTA. Signed-off-by: Roman Stratiienko <r.stratiienko(a)gmail.com> --- boot/image-android.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/boot/image-android.c b/boot/image-android.c index 04f2a8015e..499eae9bcd 100644 --- a/boot/image-android.c +++ b/boot/image-android.c @@ -64,7 +64,6 @@ static void android_boot_image_v3_v4_parse_hdr(const struct andr_boot_img_hdr_v3 data->kcmdline = hdr->cmdline; data->header_version = hdr->header_version; - data->ramdisk_ptr = env_get_ulong("ramdisk_addr_r", 16, 0); /* * The header takes a full page, the remaining components are aligned @@ -75,6 +74,7 @@ static void android_boot_image_v3_v4_parse_hdr(const struct andr_boot_img_hdr_v3 data->kernel_ptr = end; data->kernel_size = hdr->kernel_size; end += ALIGN(hdr->kernel_size, ANDR_GKI_PAGE_SIZE); + data->ramdisk_ptr = end; data->ramdisk_size = hdr->ramdisk_size; data->boot_ramdisk_size = hdr->ramdisk_size; end += ALIGN(hdr->ramdisk_size, ANDR_GKI_PAGE_SIZE); @@ -462,25 +462,24 @@ int android_image_get_ramdisk(const void *hdr, const void *vendor_boot_img, return -1; } if (img_data.header_version > 2) { - ramdisk_ptr = img_data.ramdisk_ptr; + ramdisk_ptr = img_data.ramdisk_addr; memcpy((void *)(ramdisk_ptr), (void *)img_data.vendor_ramdisk_ptr, img_data.vendor_ramdisk_size); - memcpy((void *)(ramdisk_ptr + img_data.vendor_ramdisk_size), - (void *)img_data.ramdisk_ptr, + ramdisk_ptr += img_data.vendor_ramdisk_size; + memcpy((void *)(ramdisk_ptr), (void *)img_data.ramdisk_ptr, img_data.boot_ramdisk_size); + ramdisk_ptr += img_data.boot_ramdisk_size; if (img_data.bootconfig_size) { memcpy((void *) - (ramdisk_ptr + img_data.vendor_ramdisk_size + - img_data.boot_ramdisk_size), - (void *)img_data.bootconfig_addr, + (ramdisk_ptr), (void *)img_data.bootconfig_addr, img_data.bootconfig_size); } } printf("RAM disk load addr 0x%08lx size %u KiB\n", - img_data.ramdisk_ptr, DIV_ROUND_UP(img_data.ramdisk_size, 1024)); + img_data.ramdisk_addr, DIV_ROUND_UP(img_data.ramdisk_size, 1024)); - *rd_data = img_data.ramdisk_ptr; + *rd_data = img_data.ramdisk_addr; *rd_len = img_data.ramdisk_size; return 0; -- 2.40.1

4 3

[PATCH] arm: move _end to linker symbols
by Ilias Apalodimas 10 Jun '24

10 Jun '24

commit 6e2228fb052b ("Merge patch series "Clean up arm linker scripts") was cleaning up linker scripts for armv7 and v8 but was leaving _end and __secure_stack_start/end. commit d0b5d9da5de2 ("arm: make _end compiler-generated") was moving _end to be compiler generated. _end is defined as c variable in its own section to force the compiler emit relative a reference. However, defining those in the linker script will do the same thing since [0]. So let's remove the special sections from the linker scripts, the variable definitions from sections.c and define them as a symbols. It's worth noting that _image_binary_end symbol is now redundant and can be removed in the future. - SPL The .end section has been removed from the new binary [ 5] .end PROGBITS 00000000fffdf488 000000000002f488 0 0000000000000000 0000000000000000 0 1 [0000000000000003]: WRITE, ALLOC $~ bloat-o-meter kria_old/spl/u-boot-spl krina_new/spl/u-boot-spl add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) Function old new delta Total: Before=115980, After=115980, chg +0.00% $~ readelf -sW kria_old/u-boot kria_new/u-boot | grep -w _end 12047: 000000000813a0f0 0 OBJECT GLOBAL DEFAULT 11 _end 12047: 000000000813a118 0 NOTYPE GLOBAL DEFAULT 11 _end $~ readelf -sW kria_old/spl/u-boot-spl kria_new/spl/u-boot-spl | grep -w _end 1605: 00000000fffdf488 0 OBJECT GLOBAL DEFAULT 5 _end 1603: 00000000fffdf498 0 NOTYPE GLOBAL DEFAULT 4 _end $~ readelf -sW old/u-boot new/u-boot | grep -w _end 8847: 0000000000103710 0 OBJECT GLOBAL DEFAULT 11 _end 8847: 0000000000103738 0 NOTYPE GLOBAL DEFAULT 11 _end $~ readelf -sW old_v7/u-boot new_v7/u-boot | grep -w _end 10638: 000da824 0 OBJECT GLOBAL DEFAULT 10 _end 10637: 000da84c 0 NOTYPE GLOBAL DEFAULT 10 _end - For both QEMU instances $~ bloat-o-meter old/u-boot new/u-boot add/remove: 0/0 grow/shrink: 1/0 up/down: 20/0 (20) Function old new delta version_string 50 70 +20 Total: Before=656915, After=656935, chg +0.00% [0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object") Signed-off-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> --- arch/arm/cpu/arm1136/u-boot-spl.lds | 6 +----- arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds | 6 +----- arch/arm/cpu/armv8/u-boot-spl.lds | 7 +------ arch/arm/cpu/u-boot-spl.lds | 6 +----- arch/arm/cpu/u-boot.lds | 6 +----- arch/arm/lib/sections.c | 1 - arch/arm/mach-aspeed/ast2600/u-boot-spl.lds | 6 +----- arch/arm/mach-at91/arm926ejs/u-boot-spl.lds | 7 +------ arch/arm/mach-at91/armv7/u-boot-spl.lds | 7 +------ arch/arm/mach-omap2/u-boot-spl.lds | 7 +------ arch/arm/mach-rockchip/u-boot-tpl-v8.lds | 7 +------ arch/arm/mach-zynq/u-boot.lds | 6 +----- board/davinci/da8xxevm/u-boot-spl-da850evm.lds | 7 +------ board/samsung/common/exynos-uboot-spl.lds | 6 +----- 14 files changed, 13 insertions(+), 72 deletions(-) diff --git a/arch/arm/cpu/arm1136/u-boot-spl.lds b/arch/arm/cpu/arm1136/u-boot-spl.lds index f83988fd7e6a..b7af29183a97 100644 --- a/arch/arm/cpu/arm1136/u-boot-spl.lds +++ b/arch/arm/cpu/arm1136/u-boot-spl.lds @@ -33,11 +33,7 @@ SECTIONS .data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram . = ALIGN(4); __image_copy_end = .; - - .end : - { - *(.__end) - } + _end = .; .bss : { diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds index 7e20448f8108..7c6309246f8b 100644 --- a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds +++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds @@ -49,11 +49,7 @@ SECTIONS __bss_end = .; } - .end : - { - *(.__end) - } - + _end = .; _image_binary_end = .; .dynsym _image_binary_end : { *(.dynsym) } diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-spl.lds index ef8af67e11c3..215cedd69a8c 100644 --- a/arch/arm/cpu/armv8/u-boot-spl.lds +++ b/arch/arm/cpu/armv8/u-boot-spl.lds @@ -53,12 +53,7 @@ SECTIONS . = ALIGN(8); __image_copy_end = .; - - .end : { - . = ALIGN(8); - *(.__end) - } >.sram - + _end = .; _image_binary_end = .; .bss : { diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds index 9ed62395a9c5..eee463a1b1c6 100644 --- a/arch/arm/cpu/u-boot-spl.lds +++ b/arch/arm/cpu/u-boot-spl.lds @@ -53,12 +53,8 @@ SECTIONS __rel_dyn_end = .; } - .end : - { - *(.__end) - } - _image_binary_end = .; + _end = .; .bss __rel_dyn_start (OVERLAY) : { __bss_start = .; diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds index 707b19795f08..2f50087f57a9 100644 --- a/arch/arm/cpu/u-boot.lds +++ b/arch/arm/cpu/u-boot.lds @@ -166,11 +166,7 @@ SECTIONS __rel_dyn_end = .; } - .end : - { - *(.__end) - } - + _end = .; _image_binary_end = .; /* diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c index db5463b2bbbc..07efabaa7dc8 100644 --- a/arch/arm/lib/sections.c +++ b/arch/arm/lib/sections.c @@ -23,4 +23,3 @@ char __secure_start[0] __section(".__secure_start"); char __secure_end[0] __section(".__secure_end"); char __secure_stack_start[0] __section(".__secure_stack_start"); char __secure_stack_end[0] __section(".__secure_stack_end"); -char _end[0] __section(".__end"); diff --git a/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds b/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds index ada6570d9712..9502a7384b53 100644 --- a/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds +++ b/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds @@ -61,11 +61,7 @@ SECTIONS __rel_dyn_end = .; } > .nor - .end : - { - *(.__end) - } > .nor - + _end = .; _image_binary_end = .; .bss : { diff --git a/arch/arm/mach-at91/arm926ejs/u-boot-spl.lds b/arch/arm/mach-at91/arm926ejs/u-boot-spl.lds index 1a8bf94dee0c..09cf838cf96e 100644 --- a/arch/arm/mach-at91/arm926ejs/u-boot-spl.lds +++ b/arch/arm/mach-at91/arm926ejs/u-boot-spl.lds @@ -33,12 +33,7 @@ SECTIONS . = ALIGN(4); __image_copy_end = .; - - .end : - { - *(.__end) - } >.sram - + _end = .; _image_binary_end = .; .bss : diff --git a/arch/arm/mach-at91/armv7/u-boot-spl.lds b/arch/arm/mach-at91/armv7/u-boot-spl.lds index 6ca725fc4ce0..460a91d93ec4 100644 --- a/arch/arm/mach-at91/armv7/u-boot-spl.lds +++ b/arch/arm/mach-at91/armv7/u-boot-spl.lds @@ -40,12 +40,7 @@ SECTIONS . = ALIGN(4); __image_copy_end = .; - - .end : - { - *(.__end) - } >.sram - + _end = .; _image_binary_end = .; .bss : diff --git a/arch/arm/mach-omap2/u-boot-spl.lds b/arch/arm/mach-omap2/u-boot-spl.lds index 1d6e5d45b468..3bb759d8a1c8 100644 --- a/arch/arm/mach-omap2/u-boot-spl.lds +++ b/arch/arm/mach-omap2/u-boot-spl.lds @@ -39,12 +39,7 @@ SECTIONS . = ALIGN(4); __image_copy_end = .; - - .end : - { - *(.__end) - } - + _end = .; _image_binary_end = .; .bss : diff --git a/arch/arm/mach-rockchip/u-boot-tpl-v8.lds b/arch/arm/mach-rockchip/u-boot-tpl-v8.lds index ad32654085b3..958a1b70aefe 100644 --- a/arch/arm/mach-rockchip/u-boot-tpl-v8.lds +++ b/arch/arm/mach-rockchip/u-boot-tpl-v8.lds @@ -46,12 +46,7 @@ SECTIONS . = ALIGN(8); __image_copy_end = .; - - .end : { - . = ALIGN(8); - *(.__end) - } - + _end = .; _image_binary_end = .; .bss ALIGN(8) : { diff --git a/arch/arm/mach-zynq/u-boot.lds b/arch/arm/mach-zynq/u-boot.lds index 3e0c96c50556..f52523edf490 100644 --- a/arch/arm/mach-zynq/u-boot.lds +++ b/arch/arm/mach-zynq/u-boot.lds @@ -68,11 +68,7 @@ SECTIONS __rel_dyn_end = .; } - .end : - { - *(.__end) - } - + _end = .; _image_binary_end = .; /* diff --git a/board/davinci/da8xxevm/u-boot-spl-da850evm.lds b/board/davinci/da8xxevm/u-boot-spl-da850evm.lds index 7e0f09f3b5b1..56d6f4f114b9 100644 --- a/board/davinci/da8xxevm/u-boot-spl-da850evm.lds +++ b/board/davinci/da8xxevm/u-boot-spl-da850evm.lds @@ -46,12 +46,7 @@ SECTIONS } >.sram __image_copy_end = .; - - .end : - { - *(.__end) - } - + _end = .; _image_binary_end = .; .bss : diff --git a/board/samsung/common/exynos-uboot-spl.lds b/board/samsung/common/exynos-uboot-spl.lds index 73cd97a1b1de..9d3b57e98dbb 100644 --- a/board/samsung/common/exynos-uboot-spl.lds +++ b/board/samsung/common/exynos-uboot-spl.lds @@ -41,11 +41,7 @@ SECTIONS . = ALIGN(4); __image_copy_end = .; - - .end : - { - *(.__end) - } >.sram + _end = .; .bss : { -- 2.40.1

3 4

[PATCH] image: Set load_end on partial loads
by Mattijs Korpershoek 10 Jun '24

10 Jun '24

When decompressing, it's possible that the algorithm only performs a partial decompression. This usually happens when CONFIG_SYS_BOOTM_LEN is too small for the uncompressed image. When that happens, image_decomp() returns an error and *load_end == load. The error is then handled by handle_decomp_error(). handle_decomp_error() expects the number of uncompressed bytes in uncomp_size but receives *load_end - load == load - load == 0. Because of this, handle_decomp_error does not report the expected "Image too large: increase CONFIG_SYS_BOOTM_LEN" error message. Modify the image_decomp() logic to always report the decompressed size, even when a partial decompression happened. Signed-off-by: Mattijs Korpershoek <mkorpershoek(a)baylibre.com> --- This has been tested on an AM62X SK EVM board with a big lz4 image and the default CONFIG_SYS_BOOTM_LEN of 0x800000. This has also been tested on sandbox using: => ut compression --- boot/image.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/boot/image.c b/boot/image.c index 073931cd7a3f..4f48e6eb563d 100644 --- a/boot/image.c +++ b/boot/image.c @@ -531,10 +531,10 @@ int image_decomp(int comp, ulong load, ulong image_start, int type, printf("Unimplemented compression type %d\n", comp); return ret; } - if (ret) - return ret; *load_end = load + image_len; + if (ret) + return ret; return 0; } --- base-commit: a7f0154c412859323396111dd0c09dbafbc153cb change-id: 20240523-image-partial-decomp-d6604e998e3a Best regards, -- Mattijs Korpershoek <mkorpershoek(a)baylibre.com>

3 2

[PATCH] fs: relax ext4_write_file() dependency
by Baruch Siach 10 Jun '24

10 Jun '24

ext4_write_file() depends on CONFIG_EXT4_WRITE. Allow build without CONFIG_CMD_EXT4_WRITE. Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> --- fs/fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fs.c b/fs/fs.c index bed1f7242f41..0c47943f3339 100644 --- a/fs/fs.c +++ b/fs/fs.c @@ -224,7 +224,7 @@ static struct fstype_info fstypes[] = { .exists = ext4fs_exists, .size = ext4fs_size, .read = ext4_read_file, -#ifdef CONFIG_CMD_EXT4_WRITE +#ifdef CONFIG_EXT4_WRITE .write = ext4_write_file, .ln = ext4fs_create_link, #else -- 2.43.0

2 1

[PATCH] dm: use newly added linux/compat alloc functions
by Maxim Moskalets 10 Jun '24

10 Jun '24

Signed-off-by: Maxim Moskalets <maximmosk4(a)gmail.com> --- include/dm/devres.h | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/include/dm/devres.h b/include/dm/devres.h index 697534aa5b..27761deb6d 100644 --- a/include/dm/devres.h +++ b/include/dm/devres.h @@ -266,17 +266,13 @@ static inline void *devm_kzalloc(struct udevice *dev, size_t size, gfp_t gfp) static inline void *devm_kmalloc_array(struct udevice *dev, size_t n, size_t size, gfp_t flags) { - /* TODO: add kmalloc_array() to linux/compat.h */ - if (size != 0 && n > SIZE_MAX / size) - return NULL; - return kmalloc(n * size, flags); + return kmalloc_array(n, size, flags); } static inline void *devm_kcalloc(struct udevice *dev, size_t n, size_t size, gfp_t flags) { - /* TODO: add kcalloc() to linux/compat.h */ - return kmalloc(n * size, flags | __GFP_ZERO); + return kcalloc(n, size, flags); } static inline void devm_kfree(struct udevice *dev, void *ptr) -- 2.39.2

2 1

[PATCH v3 0/9] efi_loader: improve device-tree loading
by Heinrich Schuchardt 10 Jun '24

10 Jun '24

In U-Boot EFI boot options can already specify both an EFI binary and an initrd. With this series we can additionally define the matching device-tree to be loaded in the boot option. With the last patch the boot manager will fall back the device-tree specified by $fdtfile in directories '/dtb/', '/', or '/dtb/current/' on the boot device if no device-tree is specified in the boot option or via a bootefi command parameter. v3: Add missing '@' in EFI_LP_DP_PART_FDT description. Use calloc() instead of malloc() in load_fdt_from_load_option(). Add missing '@' in load_fdt_from_load_option function description Rename struct efi_initrd_dp to efi_lo_dp_prefix. v2: Update efi_dp_concat() instead of new function efi_dp_merge(). Carve out a function efi_load_option_dp_join() which we can use both for the eficonfig and the efidebug command. Rename variables id_dp, final_dp_size. Rename create_initrd_dp() to create_lo_dp_part(). Use enum as parameter for create_lo_dp_part(). Put all related changes into one patch. Heinrich Schuchardt (8): efi_loader: allow concatenation with contained end node cmd: eficonfig: add support for setting fdt cmd: efidebug: add support for setting fdt efi_loader: load device-tree specified in boot option efi_loader: move distro_efi_get_fdt_name() efi_loader: return binary from efi_dp_from_lo() efi_loader: export efi_load_image_from_path efi_loader: load distro dtb in bootmgr boot/bootmeth_efi.c | 60 +--------- cmd/eficonfig.c | 83 +++++++++---- cmd/efidebug.c | 130 +++++++++++++++------ include/efi_loader.h | 24 +++- lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_bootbin.c | 2 +- lib/efi_loader/efi_bootmgr.c | 75 +++++++++++- lib/efi_loader/efi_boottime.c | 3 +- lib/efi_loader/efi_device_path.c | 40 ++++--- lib/efi_loader/efi_device_path_utilities.c | 2 +- lib/efi_loader/efi_fdt.c | 117 +++++++++++++++++++ lib/efi_loader/efi_helper.c | 44 +++++++ 12 files changed, 445 insertions(+), 136 deletions(-) create mode 100644 lib/efi_loader/efi_fdt.c -- 2.43.0

4 15

[PATCH 0/3] Android partition load optimization
by Roman Stratiienko 10 Jun '24

10 Jun '24

This series offers an optimization of the Android image loading procedure. The first patch introduces a new 'abootimg load' command, which loads partitions from storage into memory. It uses malloc() to find a free memory region, whereas previously, the developer had to find a free memory region by himself. The remaining patches reduce boot time by avoiding extra disk activity. The second patch implements get_preloaded_partition(), which picks a partition from memory previously loaded by the 'abootimg load' command. The third patch optimizes the 'abootimg load' command by skipping zeros loading at the partition's end. Roman Stratiienko (3): abootcmd: Add load subcommand avb: Implement get_preloaded_partition callback abootimg: Implement smart image load feature boot/image-android.c | 70 ++++++++++++++++++++++++++ cmd/abootimg.c | 116 ++++++++++++++++++++++++++++++++++++++++++- common/avb_verify.c | 53 ++++++++++++++++++++ include/image.h | 12 +++++ 4 files changed, 250 insertions(+), 1 deletion(-) -- 2.40.1

3 8

[PATCH 0/4] dm: core: fix several debug messages and migrate debug() to dm_warn
by Quentin Schulz 10 Jun '24

10 Jun '24

Fix a few misleading or incorrect debug messages and prompt text for a Kconfig symbol. Migrate debug() messages to use dm_warn() instead so that we can print them without selecting DM_DEBUG which does too much (e.g. makes assert() reset U-boot if it fails). Tested on top of next branch but it applies without complaints on top of master as well, so up to you to which branch to merge it. Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- Quentin Schulz (4): dm: core: fix misleading debug message when matching compatible dm: core: fix signedness in debug messages dm: core: migrate debug() messages to use dm_warn dm: core: fix typo in SPL_DM_WARN prompt text drivers/core/Kconfig | 2 +- drivers/core/device.c | 2 +- drivers/core/fdtaddr.c | 6 ++-- drivers/core/lists.c | 7 ++--- drivers/core/of_access.c | 50 +++++++++++++++--------------- drivers/core/of_addr.c | 40 ++++++++++++------------ drivers/core/of_extra.c | 32 +++++++++---------- drivers/core/ofnode.c | 80 ++++++++++++++++++++++++------------------------ drivers/core/regmap.c | 56 ++++++++++++++++----------------- drivers/core/root.c | 14 ++++----- drivers/core/uclass.c | 4 +-- 11 files changed, 146 insertions(+), 147 deletions(-) --- base-commit: 4f836fb324ba500ecabdba4146c3ca9e1600cdf5 change-id: 20240610-misc-20240610-f9dce050186b Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

1 4

[PATCH v6 00/14] firmware: scmi: add SCMI base protocol support
by AKASHI Takahiro 10 Jun '24

10 Jun '24

This patch series allows users to access SCMI base protocol provided by SCMI server (platform). See SCMI specification document v3.2 beta[1] for more details about SCMI base protocol. What is currently not implemented is - SCMI_BASE_NOTIFY_ERRORS command and notification callback mechanism This feature won't be very useful in the current U-Boot environment. [1] https://developer.arm.com/documentation/den0056/e/?lang=en Test ==== The patch series was tested on the following platforms: * sandbox * qemu-arm64 with OPTEE as SCMI server * confirmed CI check (pull request #439) Prerequisite: ============= * This patch series is based on v2023.10. Patches: ======== Patch#1-#6: refactoring & bug fix Patch#7-#9,#11: Add SCMI base protocol driver Patch#10,#12-#13: Add SCMI base protocol device unit test Patch#14: add a protocol sanity check Change history: =============== v6 (Oct 11, 2023) * shuffle the order of patches to fix a bisect error (No change on the code) * drop scmi command which was intended to be used for debugging * add patch#8 (version check) v5 (sep 26, 2023) * fix a per_child_auto size (patch#1) * fix an existing bug (not using a protocol's channel) (patch#2-#4) v4 (Sep 12, 2023) * shuffle the patch order (patch#5,6 prior to patch#7) * several improvements/cleanup thanks to Etienne (Each commit message has more details.) v3 (Sep 8, 2023) * import patch#6 (protocol availability check) from my followup patch * fix an issue on ST board (reported by Etienne) (patch#1) * minor code improvements * fix various typos pointed out by Etienne * revise function descriptions/comments (Each commit message has more details.) v2 (Jul, 26, 2023) * refactor devm_scmi_of_get_channel()/process_msg(), removing uses of ops (patch#1) * use helper functions, removing uses of ops (patch#2,#9,#10) * add more descriptions in scmi command doc (patch#11) * remove 'scmi base' sub-command (patch#10,#12) v1 (Jun, 28, 2023) * initial release AKASHI Takahiro (14): scmi: refactor the code to hide a channel from devices firmware: scmi: use a protocol's own channel if assigned firmware: scmi: support dummy channels for sandbox agent firmware: scmi: move scmi_bind_protocols() backward firmware: scmi: framework for installing additional protocols test: dm: add protocol-specific channel test firmware: scmi: implement SCMI base protocol firmware: scmi: add a version check against base protocol firmware: scmi: fake base protocol commands on sandbox test: dm: simplify SCMI unit test on sandbox firmware: scmi: install base protocol to SCMI agent sandbox: remove SCMI base node definition from test.dts test: dm: add SCMI base protocol test firmware: scmi: add a check against availability of protocols arch/sandbox/dts/test.dts | 5 +- arch/sandbox/include/asm/scmi_test.h | 19 +- drivers/clk/clk_scmi.c | 27 +- drivers/firmware/scmi/Makefile | 1 + drivers/firmware/scmi/base.c | 664 +++++++++++++++++++++ drivers/firmware/scmi/mailbox_agent.c | 5 +- drivers/firmware/scmi/optee_agent.c | 5 +- drivers/firmware/scmi/sandbox-scmi_agent.c | 469 ++++++++++++++- drivers/firmware/scmi/scmi_agent-uclass.c | 412 +++++++++++-- drivers/firmware/scmi/smccc_agent.c | 5 +- drivers/power/regulator/scmi_regulator.c | 26 +- drivers/reset/reset-scmi.c | 19 +- include/dm/uclass-id.h | 1 + include/scmi_agent-uclass.h | 89 ++- include/scmi_agent.h | 29 +- include/scmi_protocols.h | 495 +++++++++++++++ test/dm/scmi.c | 195 ++++-- 17 files changed, 2262 insertions(+), 204 deletions(-) create mode 100644 drivers/firmware/scmi/base.c -- 2.34.1

5 19

[PATCH v4 0/6] Introduce UBI block device
by Alexey Romanov 10 Jun '24

10 Jun '24

Hello! This series adds support for the UBI block device, which allows to read/write data block by block. For example, it can now be used for BCB or Android AB command: $ bcb load ubi 0 part_name Tested only on SPI NAND, so bind is made only for SPI NAND drivers. Can be used with mtdblock device [1]. --- Changes V1 -> V2 [2]: - Rebased over mtdblock v2 patchset [3]. - Compile UBI partitions support only if CONFIG_BLK option is enabled. Changes V2 -> V3 [4]: - Fix build warnings: use LBAF printf format string for lbaint_t types. Changes V3 -> V4 [5]: - Rebased over u-boot/master. - Fix build errors and warnings if CONFIG_BLK isn't enabled. - Fix failed tests in cases is ubiblock device isn't binded. Links: [1] https://lore.kernel.org/all/20240227100441.1811047-1-avromanov@salutedevice… [2] https://lore.kernel.org/all/20240306134906.1179285-1-avromanov@salutedevice… [3] https://lore.kernel.org/all/20240307130726.1582487-1-avromanov@salutedevice… [4] https://lore.kernel.org/all/20240325144148.3738195-1-avromanov@salutedevice… [5] https://lore.kernel.org/all/20240524111319.3512009-1-avromanov@salutedevice… Alexey Romanov (6): ubi: allow to read from volume with offset ubi: allow to write to volume with offset drivers: introduce UBI block abstraction disk: don't try search for partition type if already set disk: support UBI partitions spinand: bind UBI block cmd/ubi.c | 77 +++++++++++++++++++-- disk/part.c | 7 ++ drivers/block/blk-uclass.c | 1 + drivers/mtd/nand/spi/core.c | 8 ++- drivers/mtd/ubi/Makefile | 1 + drivers/mtd/ubi/block.c | 130 ++++++++++++++++++++++++++++++++++++ drivers/mtd/ubi/part.c | 99 +++++++++++++++++++++++++++ env/ubi.c | 16 ++--- include/part.h | 2 + include/ubi_uboot.h | 8 ++- 10 files changed, 332 insertions(+), 17 deletions(-) create mode 100644 drivers/mtd/ubi/block.c create mode 100644 drivers/mtd/ubi/part.c -- 2.34.1

2 7

[PATCH 00/42] mmc: dw_mmc: Enable eMMC on E850-96 board
by Sam Protsenko 10 Jun '24

10 Jun '24

Bring 64-bit support to dw_mmc core and Exynos dw_mmc drivers, and enable it on E850-96 board. Additionally do some related cleanups and device tree updates. 64-bit version of DesignWare MMC can be often found on modern ARM64 chips. It's different from its older 32-bit version (which is already implemented in U-Boot): some new registers were added, existing register addresses are changed, DMA descriptor table is different, etc. Exynos DW MMC driver was updated too: ARM64 Exynos chips implement their clock drivers using CCF framework, pinmux configuration is done at startup in DM capable pinctrl drivers, device tree properties were changed w.r.t. their upstream (Linux kernel) counterparts. CLKSEL register address is also different on 64-bit Exynos platforms. The patch series was tested on E850-96 board by running mainline Linux kernel with Debian rootfs from eMMC ("boot" partition) with these commands: 8<-------------------------------------------------------------------->8 env set fdtaddr 0x8a000000 env set bootaddr 0x94000000 env set boot_kerneladdr 0x94000800 part start mmc 0 boot boot_start part size mmc 0 boot boot_size mmc read $bootaddr $boot_start $boot_size abootimg addr $bootaddr abootimg get dtb --index=0 dtb_start dtb_size cp.b $dtb_start $fdtaddr $dtb_size fdt addr $fdtaddr 0x100000 cp.b $boot_kerneladdr $loadaddr 2aaaa00 env set bootargs console=ttySAC0,115200n8 printk.devkmsg=on \ root=/dev/mmcblk0p12 rootwait rw booti $loadaddr - $fdtaddr 8<-------------------------------------------------------------------->8 For E850-96 eMMC to function properly in DDR mode, the pending patch [1] has to be applied. Otherwise it won't be possible for exynos_dw_mmc driver to change CIU clock rate from 200 MHz up to 400 MHz, and MMC will fall back to SDR mode, which makes eMMC throughput twice as slower. With patch [1] applied, 'mmc info' reports this: Bus Speed: 52000000 Mode: MMC DDR52 (52MHz) and 'clk dump' shows CIU clock rate to be ~400 MHz (after first mmc operation, e.g. 'part start' or 'mmc read'): 399750000 gout_mmc_embd_sdclkin Which makes sense, because dw_mmc requests to set CCLKIN = 52 MHz (with DDR/8-bit mode), and exynos_dw_mmc tries to set CIU clock rate to: SDCLKIN = 2 * ciu_div * CCLKIN = 2 * 4 * 52 MHz = 416 MHz, and the closest possible value the clock driver can set is 399.75 MHz, which works just fine. For Exynos4 and Exynos5 (ARM32) boards, this patch series was only build tested (manually and with buildman). The build is clean (no errors or warnings), but I don't have any Exynos4/Exynos5 boards at my disposal, so I can't actually verify MMC operation there. [1] https://lists.denx.de/pipermail/u-boot/2024-March/547719.html Sam Protsenko (42): mmc: dw_mmc: Remove common.h mmc: dw_mmc: Remove unused version field from struct dwmci_host mmc: dw_mmc: Move struct idmac to dw_mmc.c mmc: dw_mmc: Extract waiting for data busy into a separate routine mmc: dw_mmc: Extract FIFO init into a separate routine mmc: dw_mmc: Extract clock on/off code into a separate routine mmc: dw_mmc: Extract FIFO data transfer into a separate routine mmc: dw_mmc: Extract DMA transfer handling code into a separate routine mmc: dw_mmc: Extract setting the DMA descriptor into a separate routine mmc: dw_mmc: Improve 32-bit IDMAC descriptor namings mmc: dw_mmc: Add support for 64-bit IDMAC mmc: dw_mmc: Replace fifoth_val property with fifo-depth mmc: dw_mmc: Fix kernel-doc comments in dwmmc.h mmc: dw_mmc: Use CONFIG_IS_ENABLED() to check config options mmc: dw_mmc: Improve coding style arm: dts: exynos: Add upstream DW MMC properties to all Exynos dts dt-bindings: exynos: Update bindings doc for DW MMC controller arm: exynos: Add header guard for dwmmc.h mmc: exynos_dw_mmc: Fix obtaining the base address of controller mmc: exynos_dw_mmc: Fix getting private data in exynos_dwmci_board_init() mmc: exynos_dw_mmc: Don't call pinmux functions on ARM64 chips mmc: exynos_dw_mmc: Obtain and use CIU clock via CCF API mmc: exynos_dw_mmc: Use .of_to_plat for device tree parsing mmc: exynos_dw_mmc: Convert to use livetree API mmc: exynos_dw_mmc: Read upstream SDR timing properties mmc: exynos_dw_mmc: Abstract CLKSEL register mmc: exynos_dw_mmc: Refactor fixed CIU clock divider mmc: exynos_dw_mmc: Read common bus-width property mmc: exynos_dw_mmc: Read common clock-frequency property mmc: exynos_dw_mmc: Move quirks from struct dwmci_host to chip data mmc: exynos_dw_mmc: Read and use DDR timing when available mmc: exynos_dw_mmc: Set requested freq in get_mmc_clk() callback mmc: exynos_dw_mmc: Add support for ARM64 Exynos chips mmc: exynos_dw_mmc: Remove common.h mmc: exynos_dw_mmc: Use CONFIG_IS_ENABLED() to check config options mmc: exynos_dw_mmc: Pull all init code into probe function mmc: exynos_dw_mmc: Don't call dwmci_setup_cfg() after add_dwmci() mmc: exynos_dw_mmc: Use dev->name as driver's displayed name mmc: exynos_dw_mmc: Improve coding style arm: dts: exynos: Remove outdated DW MMC properties in all Exynos dts configs: e850-96: Enable MMC doc: samsung: Mention enabled eMMC in E850-96 board doc arch/arm/dts/exynos4210-origen.dts | 3 +- arch/arm/dts/exynos4210-trats.dts | 6 +- arch/arm/dts/exynos4210-universal_c210.dts | 6 +- arch/arm/dts/exynos4412-odroid.dts | 14 +- arch/arm/dts/exynos4412-trats2.dts | 20 +- arch/arm/dts/exynos5250-arndale.dts | 10 +- arch/arm/dts/exynos5250-smdk5250.dts | 13 +- arch/arm/dts/exynos5250-snow.dts | 13 +- arch/arm/dts/exynos5250-spring.dts | 7 +- arch/arm/dts/exynos5420-smdk5420.dts | 13 +- arch/arm/dts/exynos5422-odroidxu3.dts | 4 +- arch/arm/dts/exynos54xx.dtsi | 13 +- arch/arm/mach-exynos/include/mach/dwmmc.h | 40 +- configs/e850-96_defconfig | 10 +- doc/board/samsung/e850-96.rst | 5 +- doc/device-tree-bindings/exynos/dwmmc.txt | 46 +- drivers/mmc/ca_dw_mmc.c | 2 +- drivers/mmc/dw_mmc.c | 535 +++++++++++++-------- drivers/mmc/exynos_dw_mmc.c | 362 +++++++++----- drivers/mmc/ftsdc010_mci.h | 1 - drivers/mmc/hi6220_dw_mmc.c | 7 +- drivers/mmc/nexell_dw_mmc.c | 5 +- drivers/mmc/rockchip_dw_mmc.c | 5 +- drivers/mmc/s5p_sdhci.c | 2 +- drivers/mmc/snps_dw_mmc.c | 6 +- drivers/mmc/socfpga_dw_mmc.c | 4 +- include/dwmmc.h | 246 +++++----- 27 files changed, 858 insertions(+), 540 deletions(-) -- 2.39.2

2 56

[PATCH] doc: Add UEFI supplement document
by Jiaxun Yang 08 Jun '24

08 Jun '24

Add UEFI supplement document to define some behaviours on architectures not covered by the original specification. Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Hi all, This document is in response to discussion at [1]. It is produced based on my attempt to port U-Boot UEFI to MIPS and Xtensa. I also plan to try m68k. Please review Thanks [1]: https://lore.kernel.org/u-boot/CAC_iWjLbY6+FaUYQw2Zv5y5byCnXRHxfzvrFf1dMyJX… --- doc/develop/uefi/index.rst | 1 + doc/develop/uefi/uefi_supplement.rst | 73 ++++++++++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+) diff --git a/doc/develop/uefi/index.rst b/doc/develop/uefi/index.rst index e26b1fbe05c5..a274fff88754 100644 --- a/doc/develop/uefi/index.rst +++ b/doc/develop/uefi/index.rst @@ -11,6 +11,7 @@ can be run an UEFI payload. :maxdepth: 2 uefi.rst + uefi_supplement.rst u-boot_on_efi.rst iscsi.rst fwu_updates.rst diff --git a/doc/develop/uefi/uefi_supplement.rst b/doc/develop/uefi/uefi_supplement.rst new file mode 100644 index 000000000000..cb20cd290912 --- /dev/null +++ b/doc/develop/uefi/uefi_supplement.rst @@ -0,0 +1,73 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (c) 2024 Jiaxun Yang <jiaxun.yang(a)flygoat.com> + +U-Boot Supplement to UEFI Specifications +======================================== + +Motivation +---------- + +The UEFI specifications are designed to be platform-independent, enabling the +implementation of UEFI-like API support across various architectures. However, +some platform-dependent aspects and constraints remain. This document provides +a supplement to the UEFI specifications for U-Boot, clarifying these platform +dependent details for architectures not covered by the original specifications. + +Architectural Conventions +------------------------- + +The UEFI specifications cover IA32, X64, ARM, AARCH64, RISC-V, LoongArch, and +Itanium architectures. This document extends the UEFI specifications to include +all architectures supported by U-Boot. + +The following conventions are used for these architectures: + +- For architectures with multiple ABIs, we adhere to the calling conventions + used by the Linux kernel for the same architecture. + +- Optional CPU registers (floating-point, SIMD) are excluded from calling + conventions. However, the UEFI payload should be able to utilize them if + available. + +- Control is handed over to the UEFI payload at the privilege level used + by the Linux kernel for the same architecture. + +- Identity mapping (i.e., VA == PA mapping) is preferred for UEFI. However, + this may not be possible for some architectures. In such cases, if the + processor supports a default linear translation, it should be used. + +- Endianness: UEFI specifications enforce little-endian architectures. + However, U-Boot supports both little-endian and big-endian architectures. + For big-endian architectures, UEFI data structures should be stored in + native endianness, with exceptions explicitly specified. + +UEFI Images +----------- + +The UEFI specifications define the PE/COFF image format for UEFI applications. +U-Boot extends this format as follows: + +- **PE32+ Machine Type**: UEFI specifications define machine types for supported + architectures. For machines not covered by UEFI specifications, we use the + machine type defined by the Microsoft PE/COFF specification if possible. + Otherwise, we use the ``IMAGE_FILE_MACHINE_UNKNOWN`` (0) machine type. + U-Boot should always accept ``IMAGE_FILE_MACHINE_UNKNOWN`` as a valid + machine type. + +- **Header Endianness**: PE/COFF header data fields are always stored as + little-endian, regardless of the target architecture's endianness. + +- **DOS Stub**: To accommodate various boot image formats, we relax the requirement + for a DOS stub in the UEFI image. U-Boot should accept UEFI images without a DOS + stub and MZ signature. However, U-Boot still expects the PE/COFF header at the + file offset specified at offset 0x3C. + +I/O Device Access +----------------- + +UEFI specifications define the EFI_DEVICE_IO_PROTOCOL and EFI_PCI_IO_PROTOCOL +for accessing I/O devices. U-Boot extends these specifications as follows: + +- All I/O access is performed using the CPU's native endianness. + For big-endian architectures, U-Boot should convert data to/from little-endian + before/after accessing I/O devices. --- base-commit: 46ff00bea5dd2dd247d5e2fdadbf5dcf8653cd9a change-id: 20240529-efi-spec-0ea657985272 Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

2 2

[PATCH next v2 0/6] rockchip: display PMIC variant properly + misc fixes for Theobroma boards
by Quentin Schulz 08 Jun '24

08 Jun '24

This fixes how the Rockchip PMIC variant is shown for all but RK808 by stripping the LSB. Also fix the size of the environment on Jaguar to match the default (smaller) size. Fix SPL_PAD_TO on Ringneck. Remove duplicated default value of ENV_OFFSET in puma defconfig. Remove unnecessary override of the fit offset in u-boot dtsi for Puma and Ringneck. Fix TPL_MAX_SIZE for Ringneck to match the (valid) default value for PX30 boards. Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- Changes in v2: - add patch for fixing TPL_MAX_SIZE on PX30 Ringneck - print show_variant when PMIC variant not found - use bitfield_extract_by_mask instead of using hardcoded shift operator - Link to v1: https://lore.kernel.org/r/20240524-misc-tsd-v1-0-b7bde1344b9e@cherry.de --- Quentin Schulz (6): rockchip: jaguar-rk3588: use default env size for Rockchip on MMC rockchip: rk3399-puma: remove default value from defconfig rockchip: rk3399-puma: remove unnecessary simple-bin:fit:offset override rockchip: px30-ringneck: Update SPL_PAD_TO Kconfig option power: rk8xx: properly print all supported PMICs name rockchip: ringneck-px30: fix TPL_MAX_SIZE arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi | 8 -------- arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 6 ------ configs/jaguar-rk3588_defconfig | 1 - configs/puma-rk3399_defconfig | 1 - configs/ringneck-px30_defconfig | 3 +-- drivers/power/pmic/rk8xx.c | 5 ++--- 6 files changed, 3 insertions(+), 21 deletions(-) --- base-commit: 8887ffb625f65475fd6619f8b05fb7a5a12b016b change-id: 20240524-misc-tsd-e08551c01c8a Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

3 13

[PATCH] configs: k3: Enable capsule authentication
by Jonathan Humphreys 08 Jun '24

08 Jun '24

Enable EFI capsule authentication and set the capsule public key certificate file in the base TI K3 EFI Capsule config. This will enable EFI capsule authentication on all boards that include the base TI K3 EFI Capsule config file. This patch is built upon the series enabling EFI capsule TI boards [0] as well as using capsule certificates directly [1]. [0] https://lore.kernel.org/r/20240607223858.1971290-1-j-humphreys@ti.com [1] https://lore.kernel.org/r/20240607225915.1985514-1-j-humphreys@ti.com Signed-off-by: Jonathan Humphreys <j-humphreys(a)ti.com> --- configs/k3_efi_capsule.config | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/k3_efi_capsule.config b/configs/k3_efi_capsule.config index e31cea37269..8f8f63f672e 100644 --- a/configs/k3_efi_capsule.config +++ b/configs/k3_efi_capsule.config @@ -1,2 +1,4 @@ CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y +CONFIG_EFI_CAPSULE_AUTHENTICATE=y +CONFIG_EFI_CAPSULE_CRT_FILE="arch/arm/mach-k3/keys/custMpk.crt" -- 2.34.1

1 0

[PATCH] scripts/Makefile.lib: EFI: Use capsule CRT instead of ESL file
by Jonathan Humphreys 08 Jun '24

08 Jun '24

The EFI Capsule ESL file (EFI Signature List File) used for authentication is a binary generated from the EFI Capsule public key certificate. Instead of including it in the source repo, automatically generate it from the certificate file during the build process. Currently, sandbox is the only device using this, so removed its ESL file and set the (new) CONFIG_EFI_CAPSULE_CRT_FILE config to point to its public key certificate. Signed-off-by: Jonathan Humphreys <j-humphreys(a)ti.com> --- board/sandbox/capsule_pub_esl_good.esl | Bin 831 -> 0 bytes configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- doc/develop/uefi/uefi.rst | 8 ++++---- lib/efi_loader/Kconfig | 12 +++++++----- scripts/Makefile.lib | 17 +++++++++-------- 6 files changed, 22 insertions(+), 19 deletions(-) delete mode 100644 board/sandbox/capsule_pub_esl_good.esl diff --git a/board/sandbox/capsule_pub_esl_good.esl b/board/sandbox/capsule_pub_esl_good.esl deleted file mode 100644 index f8cc272309b2f80113c29e22bc9fdd5c767b4667..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 831 zcmZ1&d0^?2Da*aux2_hA(f&|m&&&V@%1|1@gOCPI%=`vTjNcb9GchtTi3D3+YdNud z!N;6d=3f<&F-6ONS4$i4vT<s)d9;1!Wn|=LWiSvk6fqEDV-96u=HU);4GxJ9_H_4i z4Kh#==QT1murM$&v@kF?F^ZDlH#RUZHZ(9Wg9_l(*~F-XYzZSP19KB2KLgNRTue=j zj0_uCzfHaHH`(1}*Y#3U|97H!k3}~NhPN}GOrG;oTyFi(qmA`NTh~3>_x7NA^t?#f z>a)U0PLquF6_u8?^dHul+F@6qxB0YdssF`W?=n<3b^P4dmiKI#^@p}E)#B;%RW0;Z z-#n?@Et9eDfUQTgV&QR*{b|~VRC6NVv@WS%&0hbnAnbMH)s>m<ruWw!o9KU&t7IaN z^ws?)fy!Y!PA6wHM9oeqJuYyoIO0;duj#}3>jlOWk4kw?f2&||$2#il@?9KqESXN5 zbz2wTe>RVi?d~3_cT1K9oDaUDRd@aM1GkLbi{)<QcW%>Ma(#i_ui5G`j(PuTIhpoN z73DslYiZhJ`RkA&6Eh<N<Kke0Km%D|xXbdfh_Q&secT;;BI`VRLX*$F#X3)yTwnIl z%Rn9^t;`}}Al86g0Y6BAFeBrC7FGjhAcY+4z_<klJ0n9-ZF-^Byx1)aGPkZ;M8@iK z@4h6QYApWke51U4vh|)B+RHfwcQh8f`Fd8-Ad#bU?mv#SCl^~!ojUbKMpn)-Kd>zH z-bULy5-~dZsg>zZPS-w(zNM;c<#N4ar|5@t2FY2AoF7{4IWYI(=HR-Vl;VtSQGM$z zG&LhNEwesN5|ez&@#Le<mt%k4Ngp{`oU3!I!!G(r+O78=mGAf;yBNLt_LaVmLHB2w zF3Vp(*($;GmPMkjzjWQf=x-~Qozl?NwEilS|Lo7%xGP$f^Riek&1Q@!w>qJ9NJDsL xX})Fc$L0Fj-&QP|CD!3Bu=aCF<a-t|<@nrhQ$HQy*tL7JV9T^r#)tp!0|2#rO&9<G diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 93b52f2de5c..d6c7d7a4ad3 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -352,7 +352,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y CONFIG_EFI_CAPSULE_AUTHENTICATE=y -CONFIG_EFI_CAPSULE_ESL_FILE="board/sandbox/capsule_pub_esl_good.esl" +CONFIG_EFI_CAPSULE_CRT_FILE="board/sandbox/capsule_pub_key_good.crt" CONFIG_EFI_SECURE_BOOT=y CONFIG_TEST_FDTDEC=y CONFIG_UNIT_TEST=y diff --git a/configs/sandbox_flattree_defconfig b/configs/sandbox_flattree_defconfig index 6bf8874e722..049a606613e 100644 --- a/configs/sandbox_flattree_defconfig +++ b/configs/sandbox_flattree_defconfig @@ -227,7 +227,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y CONFIG_EFI_CAPSULE_AUTHENTICATE=y -CONFIG_EFI_CAPSULE_ESL_FILE="board/sandbox/capsule_pub_esl_good.esl" +CONFIG_EFI_CAPSULE_CRT_FILE="board/sandbox/capsule_pub_key_good.crt" CONFIG_UNIT_TEST=y CONFIG_UT_TIME=y CONFIG_UT_DM=y diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index 36ac75278fa..985956ab85c 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -580,10 +580,10 @@ and used by the steps highlighted below. } You can perform step-4 through the Kconfig symbol -CONFIG_EFI_CAPSULE_ESL_FILE. This symbol points to the esl file -generated in step-2. Once the symbol has been populated with the path -to the esl file, it will automatically get embedded into the -platform's dtb as part of U-Boot build. +CONFIG_EFI_CAPSULE_CRT_FILE. This symbol points to the signing key +generated in step-2. As part of U-Boot build, the ESL certificate file will +be generated from the signing key and automatically get embedded into the +platform's dtb. Anti-rollback Protection ************************ diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 430bb7f0f7d..23079a5709d 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -298,13 +298,15 @@ config EFI_CAPSULE_MAX Select the max capsule index value used for capsule report variables. This value is used to create CapsuleMax variable. -config EFI_CAPSULE_ESL_FILE - string "Path to the EFI Signature List File" +config EFI_CAPSULE_CRT_FILE + string "Path to the EFI capsule public key certificate" depends on EFI_CAPSULE_AUTHENTICATE help - Provides the path to the EFI Signature List file which will - be embedded in the platform's device tree and used for - capsule authentication at the time of capsule update. + Provides the path to the EFI capsule public key certificate that + corresponds to the capsule signing key. This certificate will be used + to generate the EFI capsule ESL (signature list file) that gets + embedded in the platform's device tree and used for capsule + authentication at the time of capsule update. config EFI_DEVICE_PATH_TO_TEXT bool "Device path to text protocol" diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 62f87517c09..7e2c0b145df 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -342,22 +342,23 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ ; \ sed "s:$(pre-tmp):$(<):" $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile) +capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in +capsule_crt_file=$(subst $(quote),,$(CONFIG_EFI_CAPSULE_CRT_FILE)) +capsule_esl_dtsi=.capsule_esl.dtsi + quiet_cmd_capsule_esl_gen = CAPSULE_ESL_GEN $@ cmd_capsule_esl_gen = \ - $(shell sed "s:ESL_BIN_FILE:$(capsule_esl_path):" $(capsule_esl_input_file) > $@) + cert-to-efi-sig-list $< $(obj)/capsule_esl_file \ + $(shell sed "s:ESL_BIN_FILE:$(abspath $(obj)/capsule_esl_file):" $(capsule_esl_input_file) > $@) -$(obj)/.capsule_esl.dtsi: FORCE -ifeq ($(CONFIG_EFI_CAPSULE_ESL_FILE),"") - $(error "CONFIG_EFI_CAPSULE_ESL_FILE is empty, EFI capsule authentication \ +$(obj)/$(capsule_esl_dtsi): $(capsule_crt_file) FORCE +ifeq ($(CONFIG_EFI_CAPSULE_CRT_FILE),"") + $(error "CONFIG_EFI_CAPSULE_CRT_FILE is empty, EFI capsule authentication \ public key must be specified when CONFIG_EFI_CAPSULE_AUTHENTICATE is enabled") else $(call cmd_capsule_esl_gen) endif -capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in -capsule_esl_dtsi = .capsule_esl.dtsi -capsule_esl_path=$(abspath $(srctree)/$(subst $(quote),,$(CONFIG_EFI_CAPSULE_ESL_FILE))) - dtsi_include_list_deps := $(addprefix $(u_boot_dtsi_loc),$(subst $(quote),,$(dtsi_include_list))) ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE -- 2.34.1

1 0

[PATCH] memory: ti-gpmc: use printf to dump settings/timings
by Roger Quadros 08 Jun '24

08 Jun '24

pr_info() depends on CONFIG_LOGLEVEL > 6. If user has enabled CONFIG_TI_GPMC_DEBUG then we should print the GPMC settings/timings regardless of CONFIG_LOGLEVEL. So use printf() instead of pr_info(). Signed-off-by: Roger Quadros <rogerq(a)kernel.org> --- drivers/memory/ti-gpmc.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/memory/ti-gpmc.c b/drivers/memory/ti-gpmc.c index 8af48e199a7..e979c431e33 100644 --- a/drivers/memory/ti-gpmc.c +++ b/drivers/memory/ti-gpmc.c @@ -242,20 +242,20 @@ static int get_gpmc_timing_reg(/* timing specifiers */ if (l) time_ns_min = gpmc_clk_ticks_to_ns(l - 1, cs, cd) + 1; time_ns = gpmc_clk_ticks_to_ns(l, cs, cd); - pr_info("gpmc,%s = <%u>; /* %u ns - %u ns; %i ticks%s*/\n", - name, time_ns, time_ns_min, time_ns, l, - invalid ? "; invalid " : " "); + printf("gpmc,%s = <%u>; /* %u ns - %u ns; %i ticks%s*/\n", + name, time_ns, time_ns_min, time_ns, l, + invalid ? "; invalid " : " "); } else { /* raw format */ - pr_info("gpmc,%s = <%u>;%s\n", name, l, - invalid ? " /* invalid */" : ""); + printf("gpmc,%s = <%u>;%s\n", name, l, + invalid ? " /* invalid */" : ""); } return l; } #define GPMC_PRINT_CONFIG(cs, config) \ - pr_info("CS%i %s: 0x%08x\n", cs, #config, \ + printf("CS%i %s: 0x%08x\n", cs, #config, \ gpmc_cs_read_reg(cs, config)) #define GPMC_GET_RAW(reg, st, end, field) \ get_gpmc_timing_reg(cs, (reg), (st), (end), 0, field, GPMC_CD_FCLK, 0, 1, 0) @@ -274,7 +274,7 @@ static int get_gpmc_timing_reg(/* timing specifiers */ static void gpmc_show_regs(int cs, const char *desc) { - pr_info("gpmc cs%i %s:\n", cs, desc); + printf("gpmc cs%i %s:\n", cs, desc); GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG1); GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG2); GPMC_PRINT_CONFIG(cs, GPMC_CS_CONFIG3); @@ -291,7 +291,7 @@ static void gpmc_cs_show_timings(int cs, const char *desc) { gpmc_show_regs(cs, desc); - pr_info("gpmc cs%i access configuration:\n", cs); + printf("gpmc cs%i access configuration:\n", cs); GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG1, 4, 4, "time-para-granularity"); GPMC_GET_RAW(GPMC_CS_CONFIG1, 8, 9, "mux-add-data"); GPMC_GET_RAW_SHIFT_MAX(GPMC_CS_CONFIG1, 12, 13, 1, @@ -318,7 +318,7 @@ static void gpmc_cs_show_timings(int cs, const char *desc) GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG6, 7, 7, "cycle2cycle-samecsen"); GPMC_GET_RAW_BOOL(GPMC_CS_CONFIG6, 6, 6, "cycle2cycle-diffcsen"); - pr_info("gpmc cs%i timings configuration:\n", cs); + printf("gpmc cs%i timings configuration:\n", cs); GPMC_GET_TICKS(GPMC_CS_CONFIG2, 0, 3, "cs-on-ns"); GPMC_GET_TICKS(GPMC_CS_CONFIG2, 8, 12, "cs-rd-off-ns"); GPMC_GET_TICKS(GPMC_CS_CONFIG2, 16, 20, "cs-wr-off-ns"); @@ -409,9 +409,9 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit, int max l = gpmc_cs_read_reg(cs, reg); if (IS_ENABLED(CONFIG_TI_GPMC_DEBUG)) { - pr_info("GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n", - cs, name, ticks, gpmc_get_clk_period(cs, cd) * ticks / 1000, - (l >> st_bit) & mask, time); + printf("GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n", + cs, name, ticks, gpmc_get_clk_period(cs, cd) * ticks / 1000, + (l >> st_bit) & mask, time); } l &= ~(mask << st_bit); @@ -618,8 +618,8 @@ static int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t, return -ENXIO; if (IS_ENABLED(CONFIG_TI_GPMC_DEBUG)) { - pr_info("GPMC CS%d CLK period is %lu ns (div %d)\n", - cs, (div * gpmc_get_fclk_period()) / 1000, div); + printf("GPMC CS%d CLK period is %lu ns (div %d)\n", + cs, (div * gpmc_get_fclk_period()) / 1000, div); } gpmc_cs_bool_timings(cs, &t->bool_timings); --- base-commit: e7992828adcd5fad75bce9e6c41dfa9277ab93b0 change-id: 20240515-for-2024-10-gpmc-printf-dcd5f446d951 Best regards, -- Roger Quadros <rogerq(a)kernel.org>

2 1

[PATCH] include: extension_board: Increase overlay file name size
by Daniel Schultz 08 Jun '24

08 Jun '24

Upstream overlays like the ARM64 TI k3-am625-beagleplay-csi2-tevi-ov5640.dtso can easily have more then 32 characters. Increase the overlay length to 64 characters to apply overlays with longer names. Signed-off-by: Daniel Schultz <d.schultz(a)phytec.de> --- include/extension_board.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/extension_board.h b/include/extension_board.h index 87d404c0074..22e4104bc54 100644 --- a/include/extension_board.h +++ b/include/extension_board.h @@ -14,7 +14,7 @@ struct extension { char name[32]; char owner[32]; char version[32]; - char overlay[32]; + char overlay[64]; char other[32]; }; -- 2.25.1

3 2

[PATCH v2 0/5] *** phyCORE-AM62x: DDR detection / Inject DDR timing deltas ***
by Wadim Egorov 08 Jun '24

08 Jun '24

Changes in v2: - Reabse to current next - Add Tested-by: John Ma <jma(a)phytec.com> - Add Kconfig option to select RAM size statically - Make board/phytec/common/k3 always compile for CONFIG_ARCH_K3 v1: https://lists.denx.de/pipermail/u-boot/2024-May/553057.html Wadim Egorov (5): board: phytec: Make AM6 SoM detection depend on I2C board: phytec: Fix function definitions in AM6x SOM detection arm: mach-k3: am625: Call do_board_detect() before DDR probing board: phytec: common: Introduce a method to inject DDR timings deltas board: phytec: am62x: Add support for 1 & 4 GB RAM variants arch/arm/mach-k3/am62x/am625_init.c | 2 + board/phytec/common/Kconfig | 2 + board/phytec/common/Makefile | 4 +- board/phytec/common/am6_som_detection.c | 18 +- board/phytec/common/am6_som_detection.h | 8 + board/phytec/common/k3/Makefile | 1 + board/phytec/common/k3/k3_ddrss_patch.c | 68 ++++++ board/phytec/common/k3/k3_ddrss_patch.h | 28 +++ board/phytec/phycore_am62x/Kconfig | 30 +++ board/phytec/phycore_am62x/MAINTAINERS | 1 + board/phytec/phycore_am62x/phycore-am62x.c | 152 ++++++++++++- board/phytec/phycore_am62x/phycore-ddr-data.h | 206 ++++++++++++++++++ configs/phycore_am62x_a53_defconfig | 4 + configs/phycore_am62x_r5_defconfig | 4 + 14 files changed, 514 insertions(+), 14 deletions(-) create mode 100644 board/phytec/common/k3/k3_ddrss_patch.c create mode 100644 board/phytec/common/k3/k3_ddrss_patch.h create mode 100644 board/phytec/phycore_am62x/phycore-ddr-data.h -- 2.34.1

3 8

[PATCH 0/6] PHYTEC SOM Detection API v3
by Daniel Schultz 08 Jun '24

08 Jun '24

This patch series adds support for the EEPROM v3 API. V3 is backwards compatible to V2 and therefore, the V2 image still exists at the beginning. Only the API version changed from 2 to 3. V3 is a block-based memory layout organized as singled-linked list with different types of blocks. This is a more flexible approach and allows us to extend it by more block types in the future. The V3 data starts with a 8-byte large header which defines the block count (u8), V3 subversion (u8) and data payload length (u16). Additionally the header contains a CRC8 checksum a 3 reserved bytes. Each block starts with a 4-byte large header which defined the block type (u8), the absolute address of the next block (u16) and a CRC8 checksum. The content itself is defined via the block type and we currently have 2 different types: 1) MAC: Contains the Ethernet interface number (u8), MAC address (6 x u8) and a CRC8 checksum. Daniel Schultz (6): board: phytec: common: Move eeprom read to new function board: phytec: common: Define PHYTEC_API2_DATA_LEN board: phytec: common: Move API v2 init to new function board: phytec: common: Add API v3 board: phytec: common: k3: Set MAC configs: phycore_am62x_a53_defconfig: Enable CONFIG_ENV_OVERWRITE board/phytec/common/Kconfig | 9 + board/phytec/common/Makefile | 2 +- board/phytec/common/k3/board.c | 23 ++ board/phytec/common/phytec_som_detection.c | 228 +++++++++++++++--- board/phytec/common/phytec_som_detection.h | 9 + .../common/phytec_som_detection_blocks.c | 105 ++++++++ .../common/phytec_som_detection_blocks.h | 61 +++++ configs/phycore_am62x_a53_defconfig | 1 + 8 files changed, 408 insertions(+), 30 deletions(-) create mode 100644 board/phytec/common/phytec_som_detection_blocks.c create mode 100644 board/phytec/common/phytec_som_detection_blocks.h -- 2.25.1

3 11

[PATCH 0/2] Add remoteproc support for J784S4 SoCs
by Beleswar Padhi 08 Jun '24

08 Jun '24

Hello All, This series adds remoteproc support for TI's J784S4 SoCs. The K3 J784S4 SoCs have four dual-core R5F subsystems and four C71x DSP subsystems. Enable the remoteproc drivers in defconfig and set the rproc firmware names to add remoteproc support. Note: No driver changes are required as J784S4 SoCs have the same data as J721S2 SoCs. Thus, utilize the existing compatible string for driver probe. Beleswar Padhi (2): configs: j784s4_evm_a72_defconfig: Enable remoteproc drivers board: ti: j784s4: j784s4.env: Set remoteproc firmware names board/ti/j784s4/j784s4.env | 6 ++++++ configs/j784s4_evm_a72_defconfig | 3 +++ 2 files changed, 9 insertions(+) -- 2.34.1

2 3

[PATCH 0/4] Adding support to load secure firmware for HS devices
by Udit Kumar 08 Jun '24

08 Jun '24

Some use case needs rproc firmware to be loaded at u-boot stage, using following commands at u-boot shell, firmware could be loaded => setenv dorprocboot 1 => run boot_rprocs For Secure devices, secure version of rproc firmware should be loaded, which is appended by sec keyword[0]. but currently non-secure firmware is loaded even for secure devices. So adding support for loading secure firmware on Secured devices. [0]: https://gist.github.com/uditkumarti/cd8bf6a448079b59145d17a0e8bf13b7 Bootlogs: GP : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-g… line 65 onwards HS : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-h… line 60 onwards Manorit Chawdhry (3): include: mach-k3: move k3 security functions to security.h drivers: remoteproc: ti_k3 : enable secure booting with firmware images mach-k3: common.c: add a flag for booting authenticated rproc binaries Udit Kumar (1): include: env: ti: Add support for secure firmwares arch/arm/mach-k3/common.c | 4 +++- arch/arm/mach-k3/common.h | 4 ++-- arch/arm/mach-k3/include/mach/security.h | 11 +++++++++++ drivers/remoteproc/ti_k3_dsp_rproc.c | 4 ++++ drivers/remoteproc/ti_k3_r5f_rproc.c | 4 ++++ include/env/ti/k3_rproc.env | 6 +++++- include/env/ti/ti_common.env | 1 + 7 files changed, 30 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/security.h -- 2.34.1

4 15

[PATCH v1 0/2] arm: dts: k3-am625-verdin: Enable LPDDR4 WDQS control
by Emanuele Ghidoli 08 Jun '24

08 Jun '24

From: Emanuele Ghidoli <emanuele.ghidoli(a)toradex.com> Manually, since SysConfig tool do not have the relevant option, set PHY_LP4_WDQS_OE_EXTEND to 1. Since WDQS control mode is required on our modules LPDDR4, this enables WDQS control mode 1. Emanuele Ghidoli (2): arm: dts: k3-am625-verdin: Update autogenerated LPDDR4 configuration arm: dts: k3-am625-verdin: Enable LPDDR4 WDQS control arch/arm/dts/k3-am625-verdin-lpddr4-1600MTs.dtsi | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) -- 2.34.1

2 3

[PATCH v2 0/3] arm64: add a software pagetable walker
by Caleb Connolly 07 Jun '24

07 Jun '24

MMU issues are some of the most frustrating to debug. To make this slightly less unbearable, introduce a software pagetable walker for ARMv8. This can be called to dump a pagetable with the default formatter, or a custom callback can be provided to implement more complicated parsing. This can also be useful to dump the pagetable used by a previous bootloader stage (by reading out the ttbr register). Here is an example of the output when walking U-Boot's own memory map on a Qualcomm RB3 board: Walking pagetable at 000000017df90000, va_bits: 36. Using 3 levels [0x17df91000] | Table | | [0x17df92000] | Table | | [0x000001000 - 0x000200000] | Pages | Device-nGnRnE | Non-shareable [0x000200000 - 0x040000000] | Block | Device-nGnRnE | Non-shareable [0x040000000 - 0x080000000] | Block | Device-nGnRnE | Non-shareable [0x080000000 - 0x140000000] | Block | Normal | Inner-shareable [0x17df93000] | Table | | [0x140000000 - 0x17de00000] | Block | Normal | Inner-shareable [0x17df94000] | Table | | [0x17de00000 - 0x17dfa0000] | Pages | Normal | Inner-shareable --- Changes in v2: - Document the MMU debugging features in doc/arch/arm64.rst - Mention that functions are stripped out when unused. - Link to v1: https://lore.kernel.org/r/20240607-caleb-upstreaming-v1-0-99094dabb3d9@lina… --- Caleb Connolly (3): arm64: mmu.h: fix PTE_TABLE_AP arm64: add software pagetable walker doc: arch: arm64: describe pagetable debugging arch/arm/cpu/armv8/cache_v8.c | 202 +++++++++++++++++++++++++++++++++++++++ arch/arm/include/asm/armv8/mmu.h | 57 ++++++++++- doc/arch/arm64.rst | 37 +++++++ 3 files changed, 295 insertions(+), 1 deletion(-) --- change-id: 20240607-caleb-upstreaming-82744a2786b3 base-commit: 22ca7e13dc02be83c29450ae4444add8e150ebdd // Caleb (they/them)

2 4