January 2025 - U-Boot

Please pull u-boot-marvell/master
by Stefan Roese 29 Jan '25

29 Jan '25

Hi Tom, please pull this next batch of mostly Marvell related patches: ---------------------------------------------------------------- - kirkwood: Enable bootstd and other modernization for OpenRD boards (Tony) - board: solidrun: clearfog: enable ddr odt0 on write for both chip-select (Josua) - configs: mvebu_espressobin_ultra-88f3720_defconfig: enable full bootflow functionality (Ben) - Initial support for PXA1908 and samsung-coreprimevelte (Duje) ---------------------------------------------------------------- Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=389&view=results Thanks, Stefan The following changes since commit a517796cfa5d8f4ca2f0c11c78c24a08a102c047: Prepare v2025.04-rc1 (2025-01-27 16:38:46 -0600) are available in the Git repository at: git@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 5983f0ff6128583ee2771d39d45a3e9a15caf470: board: samsung: add initial support for coreprimevelte board (2025-01-28 09:08:44 +0100) ---------------------------------------------------------------- Ben Schneider (1): configs: mvebu_espressobin_ultra-88f3720_defconfig: enable full bootflow functionality Duje Mihanović (3): serial: ns16550: Add Intel XScale support arm: mmp: add initial support for PXA1908 SoC board: samsung: add initial support for coreprimevelte board Josua Mayer (1): board: solidrun: clearfog: enable ddr odt0 on write for both chip-select Tony Dinh (1): arm: kirkwood: Enable bootstd and other modernization for OpenRD boards MAINTAINERS | 8 ++ arch/arm/Kconfig | 11 +++ arch/arm/Makefile | 1 + arch/arm/dts/Makefile | 2 + arch/arm/dts/pxa1908-samsung-coreprimevelte.dts | 74 +++++++++++++++ arch/arm/dts/pxa1908.dtsi | 106 ++++++++++++++++++++++ arch/arm/mach-kirkwood/Kconfig | 1 + arch/arm/mach-mmp/Kconfig | 12 +++ arch/arm/mach-mmp/Makefile | 1 + arch/arm/mach-mmp/board.c | 84 +++++++++++++++++ arch/arm/mach-mmp/mmu.c | 30 ++++++ board/Marvell/openrd/openrd.env | 20 ++++ board/samsung/coreprimevelte/Kconfig | 12 +++ board/samsung/coreprimevelte/MAINTAINERS | 6 ++ board/solidrun/clearfog/clearfog.c | 2 +- configs/coreprimevelte_defconfig | 18 ++++ configs/mvebu_espressobin_ultra-88f3720_defconfig | 1 + configs/openrd_base_defconfig | 18 +--- configs/openrd_client_defconfig | 18 +--- configs/openrd_ultimate_defconfig | 18 +--- drivers/serial/ns16550.c | 1 + include/configs/openrd.h | 18 ---- include/configs/pxa1908.h | 18 ++++ 23 files changed, 422 insertions(+), 58 deletions(-) create mode 100644 arch/arm/dts/pxa1908-samsung-coreprimevelte.dts create mode 100644 arch/arm/dts/pxa1908.dtsi create mode 100644 arch/arm/mach-mmp/Kconfig create mode 100644 arch/arm/mach-mmp/Makefile create mode 100644 arch/arm/mach-mmp/board.c create mode 100644 arch/arm/mach-mmp/mmu.c create mode 100644 board/Marvell/openrd/openrd.env create mode 100644 board/samsung/coreprimevelte/Kconfig create mode 100644 board/samsung/coreprimevelte/MAINTAINERS create mode 100644 configs/coreprimevelte_defconfig create mode 100644 include/configs/pxa1908.h

2 1

[PATCH] Dockerfile: Update to gcc-14.2.0 and clang-18
by Tom Rini 29 Jan '25

29 Jan '25

Outside of changing versions here the other visible change is that we tell grub that riscv64 does not have "large model" support. Without this change the resulting mkimage is non-functional. This is known upstream already. Link: https://savannah.gnu.org/bugs/?65909 Signed-off-by: Tom Rini <trini(a)konsulko.com> --- .azure-pipelines.yml | 8 ++++---- .gitlab-ci.yml | 6 +++--- tools/docker/Dockerfile | 8 ++++---- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index ba351b9802d1..4d3a5800beb3 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -2,7 +2,7 @@ variables: windows_vm: windows-2022 ubuntu_vm: ubuntu-24.04 macos_vm: macOS-14 - ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20240911.1-08Dec2024 + ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20240911.1-28Jan2025 # Add '-u 0' options for Azure pipelines, otherwise we get "permission # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer", # since our $(ci_runner_image) user is not root. @@ -324,16 +324,16 @@ stages: TEST_PY_TEST_SPEC: "version" sandbox_clang: TEST_PY_BD: "sandbox" - OVERRIDE: "-O clang-17" + OVERRIDE: "-O clang-18" sandbox_clang_asan: TEST_PY_BD: "sandbox" - OVERRIDE: "-O clang-17 -a ASAN" + OVERRIDE: "-O clang-18 -a ASAN" TEST_PY_TEST_SPEC: "version" sandbox64: TEST_PY_BD: "sandbox64" sandbox64_clang: TEST_PY_BD: "sandbox64" - OVERRIDE: "-O clang-17" + OVERRIDE: "-O clang-18" sandbox_spl: TEST_PY_BD: "sandbox_spl" TEST_PY_TEST_SPEC: "test_ofplatdata or test_handoff or test_spl" diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 74dc05d58a70..c3c38e24fd1d 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -20,7 +20,7 @@ workflow: # Grab our configured image. The source for this is found # in the u-boot tree at tools/docker/Dockerfile -image: ${MIRROR_DOCKER}/trini/u-boot-gitlab-ci-runner:jammy-20240911.1-08Dec2024 +image: ${MIRROR_DOCKER}/trini/u-boot-gitlab-ci-runner:jammy-20240911.1-28Jan2025 # We run some tests in different order, to catch some failures quicker. stages: @@ -241,7 +241,7 @@ sandbox with clang test.py: - ${DEFAULT_AMD64_TAG} variables: TEST_PY_BD: "sandbox" - OVERRIDE: "-O clang-17" + OVERRIDE: "-O clang-18" <<: *buildman_and_testpy_dfn sandbox64 test.py: @@ -256,7 +256,7 @@ sandbox64 with clang test.py: - ${DEFAULT_AMD64_TAG} variables: TEST_PY_BD: "sandbox64" - OVERRIDE: "-O clang-17" + OVERRIDE: "-O clang-18" <<: *buildman_and_testpy_dfn sandbox_spl test.py: diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index d2848ab85f35..b72ed357fa36 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -23,7 +23,7 @@ ENV ARCHS="aarch64 arc i386 m68k mips microblaze nios2 powerpc riscv64 riscv32 s ENV MIRROR=https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin # Toolchain version -ENV TCVER=13.2.0 +ENV TCVER=14.2.0 RUN echo "Building on $BUILDPLATFORM, for target $TARGETPLATFORM" @@ -32,7 +32,7 @@ RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \ --mount=type=cache,target=/var/lib/apt,sharing=locked \ apt-get update && apt-get install -y gnupg2 wget xz-utils RUN wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - -RUN echo deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-17 main | tee /etc/apt/sources.list.d/llvm.list +RUN echo deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-18 main | tee /etc/apt/sources.list.d/llvm.list # Create a list of URLs to process, then pass them into a 'while read' loop RUN if [ "$TARGETPLATFORM" = "linux/amd64" ]; then HOSTARCH=x86_64; else HOSTARCH=arm64; fi; ( \ @@ -65,7 +65,7 @@ RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \ bison \ build-essential \ cgpt \ - clang-17 \ + clang-18 \ coreutils \ cpio \ curl \ @@ -182,7 +182,7 @@ RUN git clone git://git.savannah.gnu.org/grub.git /tmp/grub && \ search search_fs_file search_fs_uuid search_label serial sleep test \ true && \ make clean && \ - ./configure --target=riscv64 --with-platform=efi \ + grub_cv_cc_mcmodel=no ./configure --target=riscv64 --with-platform=efi \ CC=gcc \ TARGET_CC=/opt/gcc-${TCVER}-nolibc/riscv64-linux/bin/riscv64-linux-gcc \ TARGET_OBJCOPY=/opt/gcc-${TCVER}-nolibc/riscv64-linux/bin/riscv64-linux-objcopy \ -- 2.43.0

1 0

Proposal for a New Command to U-Boot Fuse Programming
by Harsha Vardhan V M 28 Jan '25

28 Jan '25

I would like to propose a new command for U-Boot's fuse programming functionality to address the challenges posed by the current implementation. While the existing fuse prog command works well for programming individual fuse values, it becomes cumbersome especially when dealing with large-scale programming requirements. Current Command: fuse prog [-y] <bank> <word> <hexval> [<hexval>...] This command programs one or more fuse words starting from a specific <bank> and <word> with the hex values given as input. While functional, it lacks the efficiency and robustness needed for programming a significant number of fuses or handling structured fuse configuration data. Repeatedly specifying values for each fuse bank and word is not only time-consuming but also prone to errors during manual input or scripting. This approach does not leverage the ability to process pre-structured data in memory. For users with complex programming needs, the current method becomes an obstacle rather than a tool. Proposed Command: fuse writebuff NAME fuse writebuff - Program fuse data using a memory-based structured buffer. SYNOPSIS fuse writebuff <command_id> <addr> DESCRIPTION The fuse writebuff command provides a new method for programming fuses by leveraging a structured buffer in memory. Instead of requiring explicit <bank> and <word> parameters for each fuse word, this command operates on a structured buffer in memory at <addr>, that contains all the necessary data and programming details, allowing bulk or structured programming in a single operation. This approach simplifies workflows, reduces manual input, and improves flexibility for complex programming scenarios. PARAMETERS • <command_id> Specifies the programming mode or indicates how the buffer data should be interpreted. This parameter is a u32 value that identifies the operational context or configuration for the programming process. Examples of command_id usage might include: • A programming mode • A specific interpretation of the buffer layout. • A mode for validating the buffer before programming. • <addr> The starting memory address of the buffer containing the structured fuse programming data. This parameter is of type ulong and points to a block of memory where the programming data and any associated metadata reside. USAGE The fuse writebuff command reads the buffer at <addr> and interprets it according to the specified <command_id>. The structure of the buffer should contain all necessary details for programming fuses, such as the values to be written to the fuse, optional metadata for validation or programming constraints and any configuration data required for the operation. EXAMPLES 1. fuse writebuff 1 0x80000000 In this example: • command_id is 1, specifying a particular programming mode or a buffer format. • addr is 0x80000000, pointing to the starting memory address where the structured buffer resides. RETURN VALUES • 0: The operation was successful. • Non-zero: An error occurred during the operation. Errors may include invalid command_id, inaccessible memory at <addr>, or issues with the buffer contents. The corresponding function, fuse_writebuff(u32 command_id, ulong addr), would process this data in a single invocation. This approach significantly streamlines and simplifies workflows where fuse programming involves predefined rules or structured data, enabling users to prepare a struct buffer in memory that encapsulates the entire fuse programming configuration. I believe fuse writebuff simplifies workflows, reduces error risks, and provides the extensibility needed for advanced usage scenarios like programming large or complex fuse configurations. Request for Feedback Does this proposal look good? If so, I will start to work on an RFC patch to implement the proposed changes. Best regards, Harsha Vardhan V M h-vm(a)ti.com

3 8

[PATCH v2 0/5] rockchip: rk3399: rk3399-nanopi-4: Fix SD power initialization in SPL
by Justin Klaassen 28 Jan '25

28 Jan '25

The NanoPi RK3399 boards support UHS-I (up to SDR104) SD cards, however using any of these 1.8v modes results in a boot failure in SPL upon soft reboot. The issue is that the "vcc_sdio" regulator is left at 1.8v on reboot and the corresponding GPIO defaults to 3.3v. This prevents the SD card from being reinitialized and read successfully. This change series resolves this issue by allowing the proper initialization and control of the "vcc3v0_sd" (vmmc-supply) and "vcc_sdio" (vqmmc-supply) regulators and corresponding GPIO in SPL. Changes in v2: - Made added IO-domain driver logs verbose and consistent - Added separate patch for added CONFIG_SPL_ROCKCHIP_IODOMAIN Kconfig - Added separate patch for added CONFIG_SPL_REGULATOR_RK8XX Kconfig - Added patch to remove device-tree properties that conflicted with MMC driver initialization - Added defconfig changes for all NanoPi RK3399 boards Justin Klaassen (5): rockchip: io-domain: Add debug logging for regulators during probe rockchip: io-domain: Add CONFIG_SPL_ROCKCHIP_IODOMAIN regulator: rk8xx: Add CONFIG_SPL_REGULATOR_RK8XX rockchip: rk3399-nanopi-4: Allow MMC driver to control SD regulators rockchip: rk3399-nanopi-4: Enable IO-domain driver in SPL arch/arm/dts/rk3399-nanopi4-u-boot.dtsi | 12 ++++++++++++ configs/nanopc-t4-rk3399_defconfig | 7 +++++++ configs/nanopi-m4-2gb-rk3399_defconfig | 7 +++++++ configs/nanopi-m4-rk3399_defconfig | 7 +++++++ configs/nanopi-m4b-rk3399_defconfig | 7 +++++++ configs/nanopi-neo4-rk3399_defconfig | 7 +++++++ configs/nanopi-r4s-rk3399_defconfig | 7 +++++++ drivers/misc/Kconfig | 8 ++++++++ drivers/misc/rockchip-io-domain.c | 7 ++++++- drivers/power/regulator/Kconfig | 9 +++++++++ drivers/power/regulator/rk8xx.c | 8 ++------ 11 files changed, 79 insertions(+), 7 deletions(-) -- 2.45.3

1 5

[RFC PATCH v2 0/3] Coroutines
by Jerome Forissier 28 Jan '25

28 Jan '25

This series introduces a simple coroutines framework and uses it to speed up the efi_init_obj_list() function. It is just an example to trigger discussions; hopefully other places in U-Boot can benefit from a similar treatment. Suggestions are welcome. I came up with this idea after analyzing some profiling data (ftrace) taken during the execution of the "printenv -e" command on a Kria KV260 board. When the command is first invoked, efi_init_obj_list() is called which takes a significant amount of time (2.872 seconds). This time can be split into 0.570 s for efi_disks_register(), 0.811 s for efi_tcg2_register() and 1.418 s for efi_tcg2_do_initial_measurement(). All the other child functions are much quicker. Another interesting observation is that a large part of the time is actually spent waiting in __udelay(). More precisely: - For efi_disks_register(): 421 ms / 570 ms = 73.8 % spent in __udelay() - For efi_tcg2_register(): 805 ms / 811 ms = 99.1 % spent in __udelay() - For efi_tcg2_do_initial_measurement(): 1395.025 ms / 1418.372 ms = 98.3 % spent in __udelay() Given the above data, it is reasonable to think that a nice speedup could be obtained if these functions could somehow be run in parallel. efi_tcg2_do_initial_measurement() unfortunately needs to be excluded because it depends on the first two. But efi_disks_register() and efi_tcg2_register() are clearly independant and are therefore good candidates for concurrent execution. So, I considered two options: - Spin up a secondary core to take care of one function while the other one runs on the main core - Introduce some kind of software scheduling I quickly ruled out the first one for several reasons: initializing a secondary core is typically quite hardware-specific, it would not scale well if more functions than available cores would need to be run in parallel, it would make debugging harder etc. Software scheduling however can be accomplished quite easily, especially since we don't need to consider preemptive multitasking. Coroutines [1] for example can perfectly do the job. They provide a way to save and restore the execution context (registers and stack). Here is how it look like: static void do_some_work(int v) { int i; for (i = 0; i < 5; i++) { printf("%d", v); /* Save context and resume main thread */ co_yield(); } } static void co1(void *arg) { do_some_work(1); /* Mark coroutine as "done" and resume main thread */ co_exit(); } static void co2(void *arg) { do_some_work(2); co_exit(); } void main_thread(void) { struct co *co1, *co2; co1 = co_create(co1, ...); co2 = co_create(co2, ...); do { printf("A"); if (!co1->done) { /* Invoke or resume first coroutine */ co_resume(co1); } printf("B"); if (!cor21->done) { /* Invoke or resume second coroutine */ co_resume(co2); } } while (!(co1->done && co2->done)); /* At this point, co1 and co2 have both called co_exit() */ } The above example would print: A1B2A1B2A1B2A1B2A1B2. - The first commit introduces the coroutine framework, loosely based on libaco [2]. The code was simplified and reformatted to better suit U-Boot. - The second commit modifies efi_init_obj_list() in order to turn efi_disks_register() and efi_tcg2_register() into coroutines when COROUTINES in enabled. On a KV260 board with a SD card inserted, this saves about .6 second (2.2 s instead of 2.8 s). - The third commit applies coroutines to usb_init(), which can significantly reduce the time it takes to scan multiple buses. Tested on arm64 QEMU with 4 XHCI buses: the USB scan takes 2.2 s instead of 5.8 s. [1] https://en.wikipedia.org/wiki/Coroutine [2] https://github.com/hnes/libaco/ Changes in v2 - Remove x86 and x86_64 arch code since it is untested - Add missing SPDX license tag to arch/arm/cpu/armv8/co_switch.S - Change Apache-2.0 SPDX license tag to "Apache-2.0 OR GPL-2.0-or-later" - Apply coroutines to the USB bus scan in usb_init() Jerome Forissier (3): Introduce coroutines framework efi_loader: optimize efi_init_obj_list() with coroutines usb: scan multiple buses simultaneously with coroutines arch/arm/cpu/armv8/Makefile | 1 + arch/arm/cpu/armv8/co_switch.S | 36 +++++++ drivers/usb/host/usb-uclass.c | 152 +++++++++++++++++++++++++++++- include/coroutines.h | 130 ++++++++++++++++++++++++++ lib/Kconfig | 10 ++ lib/Makefile | 2 + lib/coroutines.c | 165 +++++++++++++++++++++++++++++++++ lib/efi_loader/efi_setup.c | 113 +++++++++++++++++++++- lib/time.c | 14 ++- 9 files changed, 615 insertions(+), 8 deletions(-) create mode 100644 arch/arm/cpu/armv8/co_switch.S create mode 100644 include/coroutines.h create mode 100644 lib/coroutines.c -- 2.43.0

5 9

[ANN] U-Boot v2025.04-rc1 released
by Tom Rini 28 Jan '25

28 Jan '25

Hey all, It's release day and so here's v2025.04-rc1. For a -rc1, I think we're in fine enough shape. The next window won't open until after -rc2 so if you have some outstanding patches that you think should be merged to mainline for v2025.04 please speak up (or for custodians, send a pull request). As I mentioned elsewhere, I've scheduled a video call tomorrow at 9am -0600 and the calendar link is: https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=N280N2tlcX… and I also send the meeting invite via Google to the mailing list. I plan to do these regularly, post release and depending on reception the time can be adjusted or perhaps duplicate meetings held. In terms of a changelog, git log --merges v2025.01..v2025.04-rc1 As always, more details in pull requests (or the tags referenced by them) will result in more details here. I continue to plan to do an rc release every two weeks and the final release will be 07 April 2025. Thanks all! -- Tom

1 2

dtc: "syntax error" linked to &{label/subnode} syntax
by Patrice CHOTARD 28 Jan '25

28 Jan '25

Hi I am currently converting STM32MP platforms to OF_UPSTREAM. As we use same binary for several boards, flags CONFIG_OF_UPSTREAM_BUILD_VENDOR=y and CONFIG_OF_UPSTREAM_VENDOR="st" are set. So all dts/upstream/src/arm/st/* dts files are compiled. I am facing an issue with dts/upstream/src/arm/st/stm32mp151a-prtt1* and dts/upstream/src/arm/st/stm32mp15*-mec*.* files. To be more precise, these files are using a syntax which follows this format &{label/subnode} to override some nodes. This leads to DTC error: AR drivers/usb/gadget/built-in.o LD u-boot OBJCOPY u-boot.srec OBJCOPY u-boot-nodtb.bin SYM u-boot.sym DTC dts/upstream/src/arm/st/stm32mp157c-dhcom-picoitx.dtb DTC dts/upstream/src/arm/st/stm32h750i-art-pi.dtb DTC dts/upstream/src/arm/st/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dtb DTC dts/upstream/src/arm/st/stm32mp157a-iot-box.dtb DTC dts/upstream/src/arm/st/stm32746g-eval.dtb DTC dts/upstream/src/arm/st/stm32mp151c-mecio1r0.dtb DTC dts/upstream/src/arm/st/stm32mp157a-dhcor-avenger96.dtb DTC dts/upstream/src/arm/st/ste-nomadik-s8815.dtb Error: ../dts/upstream/src/arm/st/stm32mp15x-mecio1-io.dtsi:338.1-2 syntax error FATAL ERROR: Unable to parse input tree At line 338 in dts/upstream/src/arm/st/stm32mp15x-mecio1-io.dtsi we got : &{qspi_bk1_pins_a/pins} { pinmux = <STM32_PINMUX('F', 8, AF10)>, /* QSPI_BK1_IO0 */ <STM32_PINMUX('F', 9, AF10)>, /* QSPI_BK1_IO1 */ <STM32_PINMUX('F', 7, AF9)>, /* QSPI_BK1_IO2 */ <STM32_PINMUX('F', 6, AF9)>; /* QSPI_BK1_IO3 */ /delete-property/ bias-disable; bias-pull-up; }; If i update it as following , the DTC compilation is OK : &qspi_bk1_pins_a { pins { pinmux = <STM32_PINMUX('F', 8, AF10)>, /* QSPI_BK1_IO0 */ <STM32_PINMUX('F', 9, AF10)>, /* QSPI_BK1_IO1 */ <STM32_PINMUX('F', 7, AF9)>, /* QSPI_BK1_IO2 */ <STM32_PINMUX('F', 6, AF9)>; /* QSPI_BK1_IO3 */ /delete-property/ bias-disable; bias-pull-up; }; }; On kernel side, the DTC compilation is ok, but not on U-Boot side. I am not able to understand the difference. Thanks Patrice

3 7

[PATCH v4 0/2] led: add function naming option from linux
by Heiko Schocher 28 Jan '25

28 Jan '25

in linux we have the option to create the name of a led optionally through the following properties: - function - color - function-enumerator This series adds support for parsing this properties if there is no label property. patch 1 is new in this series since v4, which deletes the file doc/device-tree-bindings/leds/common.txt as Tom suggested. Azure build: https://dev.azure.com/hs0298/hs/_build/results?buildId=168&view=results shows an error: https://dev.azure.com/hs0298/hs/_build/results?buildId=168&view=logs&j=c680… for sandbox64_clang ... sandbox64 target works! The error has nothing ToDo with this patchseries, as it is in dm_test_cmd_hash_md5, which tests content from source files, this series do not touch. Changes in v4: - new in version 4 - remove ./doc/device-tree-bindings/leds/common.txt in seperate patch as this is now already in ./dts/upstream/Bindings/leds/common.txt as Tom commented. measured size impact of patch "led: add function naming option from linux": $ ./u-boot-size-test.sh capricorn_cxg3 --branch led-mainline [...] aarch64: (for 1/1 boards) all +886.0 rodata +230.0 text +656.0 capricorn_cxg3 : all +886 rodata +230 text +656 u-boot: add: 1/0, grow: 1/0 bytes: 416/0 (416) function old new delta led_post_bind 220 516 +296 led_colors - 120 +120 $ ./u-boot-size-test.sh aristainetos2c --branch led-mainline [...] 01: Merge patch series "add the support of sha256_hmac and sha256_hkdf" 40: led: add function naming option from linux arm: (for 2/2 boards) all +557.0 bss +20.0 rodata +161.0 text +376.0 aristainetos2c : all +557 bss +20 rodata +161 text +376 u-boot: add: 1/0, grow: 1/0 bytes: 264/0 (264) function old new delta led_post_bind 128 332 +204 led_colors - 60 +60 aristainetos2ccslb: all +557 bss +20 rodata +161 text +376 u-boot: add: 1/0, grow: 1/0 bytes: 264/0 (264) function old new delta led_post_bind 128 332 +204 led_colors - 60 +60 - rebase to current HEAD d8a7100d658. ("Subtree merge tag 'v6.13-dts' of dts repo [1] into dts/upstream") Changes in v3: - work in comment from Tom: remove new file include/dt-bindings/leds/common.h in this patch as it is already in dts/upstream/include/dt-bindings/leds/common.h and so the checkpatch warnings from this file are gone! Thanks! Good catch! remove file include/linux/uapi/linux/uleds.h and as we only need one define from it, add this define in include/led.h Changes in v2: - remove unused name variable in function led_get_label() - rebased patch to current HEAD 82d262ae162 ("Merge patch series "MediaTek MT7629 OF_UPSTREAM migration (v2)"") Heiko Schocher (2): doc: remove redundant leds bindings led: add function naming option from linux arch/sandbox/dts/test.dts | 37 ++++++++++++- doc/device-tree-bindings/leds/common.txt | 23 -------- drivers/led/led-uclass.c | 70 ++++++++++++++++++++++-- include/led.h | 6 ++ test/dm/led.c | 22 +++++++- test/dm/ofnode.c | 2 +- 6 files changed, 130 insertions(+), 30 deletions(-) delete mode 100644 doc/device-tree-bindings/leds/common.txt -- 2.20.1

2 4

[PATCH 0/6] MSM8916: Bring secondary cores online with spin-table
by Sam Day 28 Jan '25

28 Jan '25

This patch series depends on the "mach-snapdragon: handle platforms without PSCI support" patch that was submitted earlier today. That first patch lays some groundwork to handle detecting when a device is booting without PSCI and deletes the /psci node in that case. This series builds on top of that detection by rewriting all CPUs with enable-method="psci" to "spin-table". Once this is done, the existing spin-table support in U-Boot handles further patching the nodes with the appropriate cpu-release-addr and reserving the memory with the spin-table instructions. Interestingly, this spin-table code doesn't seem to be in active use anywhere, and it had bitrotted a little. But after blowing the dust off it and fixing a couple of missing #includes, it works great. I extended the spin-table support a little to make it easier for consumers to plug in a method that is called for each CPU that needs to be brought online. This saves the qcom board code from needing to hook into ft_board_setup or something that runs before booting the OS. Signed-off-by: Sam Day <me(a)samcday.com> --- Sam Day (6): armv8: spin_table: Fix missing includes armv8: spin_table: add hook for booting cores mach-snapdragon: qcom SCM call support mach-snapdragon: fixup CPUs with PSCI enable-method mach-snapdragon: MSM8916 spin-table CPU boot support qcom_defconfig: enable spin-table support arch/arm/cpu/armv8/spin_table.c | 10 ++ arch/arm/include/asm/spin_table.h | 3 + arch/arm/mach-snapdragon/Makefile | 2 + arch/arm/mach-snapdragon/board.c | 41 ++++++++ arch/arm/mach-snapdragon/msm8916-smp.c | 135 +++++++++++++++++++++++++++ arch/arm/mach-snapdragon/qcom-scm.c | 145 +++++++++++++++++++++++++++++ arch/arm/mach-snapdragon/qcom-scm.h | 165 +++++++++++++++++++++++++++++++++ configs/qcom_defconfig | 2 + 8 files changed, 503 insertions(+) --- base-commit: 2eed5a1ff36217372e19f7513bd07077fc76718a change-id: 20250127-msm8916-smp-support-5f5e7b49d07e prerequisite-change-id: 20250127-qcom-handle-absent-psci-6e8e8af7bcd7:v1 prerequisite-patch-id: 6f85e145b7a25346a286396d9edf6106ae131c0b prerequisite-patch-id: 3b11763ea1d10ae9e23cb5c1b888f02220919284 prerequisite-patch-id: 030300d29b72f14fc528f2ad46c0d9e229934e9e prerequisite-patch-id: de0427537d887654f8dbf2e97ca6a3bc956512cd prerequisite-patch-id: 30db99afc91f657e484d4bb5a6613b64fb77649b prerequisite-patch-id: b1c46de57d0f82756d2bbeee6d13cf31c1f27a0f prerequisite-patch-id: 2d7d38f6ea846a5f183462d07ff962182e20a87e prerequisite-patch-id: 76ce7f79c8f4e2a5042dc8804194b0bef2d0a24b prerequisite-patch-id: 05eac938e6d33019a091ee721eba2d2dc7a03960 prerequisite-patch-id: 243fe8829719909ab6d65b512b0efcff4f4c9438 prerequisite-patch-id: fb7780ba617c036bc3b4e8fbc53541d485ae89d8 prerequisite-patch-id: 16e2a268f01739da59598b5f5b0d86a80c31449f prerequisite-patch-id: 43e1512fd0768b763cdf2079dce0054a736e97ea prerequisite-patch-id: 02cffb68f48d9d64c26373d6366c82bfcb86a7a2 prerequisite-patch-id: 19f382ead12fd5f583ad8b82fe618e6dd2c59615 prerequisite-patch-id: 764cc2a29ae7486610b6279cd71bedfb267f18bd prerequisite-patch-id: e22fa6b807a5df8e0257636a3edf8de92d4b3a36 prerequisite-patch-id: 159efbb7a5bd037b11eb20993716bdc7e641c89f prerequisite-patch-id: 0c4373ed5bda9e74a488796de8ce2e0c59c62c46 prerequisite-patch-id: fb2e81bbe11eed5d7af8ac4b1c2a29e2bdb6b237 prerequisite-patch-id: b105b1ec3f2ab8d9ad212eacf3a4736417950930 prerequisite-patch-id: 302c34fd65875a4a750a5a36b933e43639859487 prerequisite-patch-id: b1b62ac7e28eb0cc8a66d529911d6294b40cc5cd prerequisite-patch-id: 43de5453463d592c16d5669345528ded4e897605 prerequisite-patch-id: 861de3de3e008cfffcbcbfdd25c5bf1cdd9925ea prerequisite-patch-id: c91bbc83ea9d167f2451c7e9a13692c4cc92d1cb prerequisite-patch-id: cf9a09214da66d4bb1175b40a4e49c98212aaae3 prerequisite-patch-id: 671819fe6f2c93b420fec5ee283149d8e51a4f1c prerequisite-patch-id: 02a9a32547b5e850d27ada3bed7e88b4c970d342 prerequisite-patch-id: cb7baa3ce35948742a83d9b4acb7449f660818a6 prerequisite-patch-id: 9dd97eb36b380b64b43fb6718075106e1f4186c5 prerequisite-patch-id: c9ef7bfbbcf3a55a821dac749236440ae10fc89c prerequisite-patch-id: d37f02b2f520d3a84e5b4a515f88d217f78841ee prerequisite-patch-id: ad99b38cc1326272ec03e7cdced069e76b850d59 prerequisite-patch-id: b7467e24f0a21c08a52008374e18d3af996e0668 prerequisite-patch-id: a7d97af191a6adfb55af0fd89bdb97c378f86f65 prerequisite-patch-id: 87de3dd294acc2a220d97142bd615bdcd01fb00b prerequisite-patch-id: 5f2a37841670e9b941dce8f8b28c3e7e6c6048f6 prerequisite-patch-id: 5a77c17b8b78e760cd9bd4982d564fdb60ba667e prerequisite-patch-id: afa8a5a8572452ff8ac2f0dac1fc132fc5423150 prerequisite-patch-id: d68ce45f8993ba7c6967c28c25abdbc0f78a2cb3 prerequisite-patch-id: 218f70c55c7ca23f1de87e5370655137e796c725 prerequisite-patch-id: 2f5b57d1cf40ef18ed9f942bee4dd35ad60f5c43 prerequisite-patch-id: 2e2278e28f7795aa48916be2e4865cc915d602fd prerequisite-patch-id: e86660dfec6465dc87f3deaeddc1bb814c7dd801 prerequisite-patch-id: a5136d73559a8eaee5ce7e460842ba02d8c7f7c7 prerequisite-patch-id: fae5d78eb2da7d044ee6408d03a887d537dedaae prerequisite-patch-id: 27dfcabf70c4b88395eabf07a60b286d4d1856d2 prerequisite-patch-id: 5414352fb0926632f6b9c4904f0240c2976ea38f prerequisite-patch-id: 3036949e76a7d5467b4c0842f852b84a1a48ae84 prerequisite-patch-id: 76cc9440f2cbd13090eebeb4c25c20dbb990049c prerequisite-patch-id: 7549f8d500cf0ce56b49c78fc3412353cd080ac4 prerequisite-patch-id: 19e7341bcdce3e1f39acf2125b44ea011f3352e1 prerequisite-patch-id: 2830a95408413ac5d4b8869e58006b2529fb1af7 prerequisite-patch-id: 097945624a0249b81bc3e7f747d7c54b1552f121 prerequisite-patch-id: 12e71f9202bdab483de4fb275710fcd738b89e99 prerequisite-patch-id: 6ae4a39f434fd00c4ba139ff1d91d0c9275cb208 prerequisite-patch-id: a0c8c2f64bb5951eb1794a6cf685d9898baa56ca prerequisite-patch-id: b5143f5cfec77eb66f2f3c65a2614d715255c1a7 prerequisite-patch-id: 7042961e52dc6a3691064c8f0cdeea611ad2d5ec prerequisite-patch-id: 36f5fed167531209347d743c8289150508684979 prerequisite-patch-id: 3ddd71ec0fa373ce98a05a7a5cbdc84399a66efc prerequisite-patch-id: 7fdce16aa47fe89f7c1afae677042edf2735385a prerequisite-patch-id: b841df88415770b8e7771104233179b35773e473 prerequisite-patch-id: 60085daf50c7c2b629f522069a51c480b3218f05 prerequisite-patch-id: 873eed9fa8f975be3cf37fac3ed662250ce11771 prerequisite-patch-id: a5ac5acc7b7c182fe008d856cc9bbaa2c5e9633a prerequisite-patch-id: 3939201e8927f038d843dcc9e0dd67781d73ce53 prerequisite-patch-id: cf6b26bdc312e808b1ef702e323cb7ab0f82b6a2 prerequisite-patch-id: 2dc7feea1ab83bab9852bc95a6c9a7d6a7006aac prerequisite-patch-id: 5ec17e2221f23dc8f10803404256db6b2ea86f17 prerequisite-patch-id: 0f8b032d456dda766799580f1185a124bafe3ee3 prerequisite-patch-id: b168c68d649ac27e2416a3bf1ae7b9b6a90822b8 prerequisite-patch-id: 69a892386b52cb7aa0839472ee96f5c0f9ac5ef3 prerequisite-patch-id: 7c0fd076b848535a0f0d5abb6fcbbc836f71b4e4 prerequisite-patch-id: 0800bc8110bdb23f177cdc8e6d80dcdb2f3b3059 prerequisite-patch-id: 22c12428b5345883a30f2e0dfbea78defb2cc5e2 prerequisite-patch-id: 889de73156ee67862e5a9eb00cb43934d1848afb prerequisite-patch-id: 122e9b8f48e2f67e10ec4345b4aaf5feba81b40a prerequisite-patch-id: ec144dd1adc629a0d8d7bc4ee0b520344faf0322 prerequisite-patch-id: a7c6c37875075e7d31a9eec9e50fb0cf960ccfa6 prerequisite-patch-id: a1f683dae05a61bdf15df04454960af2481b9ff0 prerequisite-patch-id: f031c546205485ab0dbde83e962f7a2341c62645 prerequisite-patch-id: 05c5e3f7c07d0c3072c59cd0cb1262e5f480a589 prerequisite-patch-id: f54e3917db830329ef185dd89c27085cbefb1881 prerequisite-patch-id: dfe80f29b2ef88d5cbe668949a74459ef53c660d prerequisite-patch-id: 2d85a2c47df09ba5831265c2119bf045d6bdeacd prerequisite-patch-id: 1439383a5a62edd6186af4705a5b4f59d27f4c40 prerequisite-patch-id: 11defde4d0eb072a2c2bcf022af0598edd597051 prerequisite-patch-id: 92b8c0b688026554b3633440f61572fd451c617e prerequisite-patch-id: 09c8682d1d6cb5ff1af975308ca039f25fe4c59a prerequisite-patch-id: e7c5c0b05eb4a395c93908dab766b3840dc3b302 prerequisite-patch-id: fa4c72a2c5d13579a831a41e9235e245b78a7dbc prerequisite-patch-id: a4ad3b9360284a935f1dd98a3bd01a765c8aa5bc prerequisite-patch-id: 32e46850ee3f2ae42aa806bc236ec4474c35dca0 prerequisite-patch-id: b0ba05b2600ec4767e8deb88fb39c261ea317a6d prerequisite-patch-id: a6841b49255ec70ffeff8470ffe3a0dbf65ee7b8 prerequisite-patch-id: ec523fb216a7dffabeb1b0966603c01bcd30c425 prerequisite-patch-id: 29559b5916dd715a8daec623c4a52a2896c4f853 prerequisite-patch-id: 935e2b0efe1f56f9c02d61a44ebd169b8aa01757 prerequisite-patch-id: 207cdd32d4721253767e87bad783e6cfd7894885 prerequisite-patch-id: d4fede4e48324bcbad94166381520e86de8c6b58 prerequisite-patch-id: 37e1e35c443f31444a815e7fa09ab9193b58ff33 prerequisite-patch-id: 89cfa619d48fc54564390069b445617e9cd3f272 prerequisite-patch-id: a4934111361709dec17274b4a9840b388e40927a prerequisite-patch-id: 84f11a9b07d4f28ecef51a8e689840c6650c29fb prerequisite-patch-id: 62f7cfc8675a161612ab84e6884baa0289140037 prerequisite-patch-id: fb6f1d0041b49bcf1a568af97be5221fba0bee68 prerequisite-patch-id: 4542cc51d6726e7993581124a2691821eaef06c7 prerequisite-patch-id: f801ea78e28a1d6a2f8a25c3376de7517b3a4f2c prerequisite-patch-id: 1e50e99eef583a5ea2e03a66363045b57146305f prerequisite-patch-id: 333e1147f78607d03964774cf2ccf7c16eea5e4a prerequisite-patch-id: 501c4d1e9f26129440505bcd08f62eee38605c31 prerequisite-patch-id: e58d99831b9ff24ebfa92ec5cab91eefa3bde05f prerequisite-patch-id: c29d323121307cf9e14bfae5b72aff0b281adb42 prerequisite-patch-id: 78c5227d2d0aebd3039d084bbeb517330c3f258e prerequisite-patch-id: eb502f8a13b74b8689304ab1e8993bb79ff4518b prerequisite-patch-id: c91159b4e90be4afa72dcda32efdf42dd8ca3888 prerequisite-patch-id: 0f125a3f46e7bb243cb78e9be0d74f318858a3ab prerequisite-patch-id: e3a1f152d9bb9c949a32ae1ec233c63bd7ad24bd prerequisite-patch-id: d6f656b49d9c1e0ed666732305db8d4e6ae9c9c9 prerequisite-patch-id: c41aff811e5487ecb069cacea0e85a358333dc37 prerequisite-patch-id: ff87d23252f02cd6a9abd43e71740968057f263a prerequisite-patch-id: fcab7e05ba0af8c43fce5149e952c69833c7c3b4 prerequisite-patch-id: b044600fd11584b74923079843b1456b480d5fa5 prerequisite-patch-id: bb963c51f31c76af938f8561c8779ed0f8511b7f prerequisite-patch-id: a9a675e9db9d2a0ec36a6ade80855636878b7d21 prerequisite-patch-id: 37caa389ca0cee716ab9408370bf9dbcac6a9d09 prerequisite-patch-id: ecc7ad1d94f8290f27c7749d27d1bebf5d11bf19 prerequisite-patch-id: 0966beb3fd1f486a79c791fc0a58c090533e789a prerequisite-patch-id: 2695a9bbf667850304a9c87c33d96db47f15504c prerequisite-patch-id: 1056292d88bb2ba81223a3315e52204078aa34f8 prerequisite-patch-id: 8c8bea9e74f88cd68e7096479f03353b0a77d35e prerequisite-patch-id: 3fb86a0aa7f1431e5480101cf992174eb9763c5c prerequisite-patch-id: 4229a08c9b3e78251f0fd12cca3b33b38f9c53b2 prerequisite-patch-id: 5b023bd57576a846cce1f9091926cf01af1e09e0 prerequisite-patch-id: 760da8469c8db63b0e5173079057ba1c91748688 prerequisite-patch-id: 8bc19d02fe8fd85c2c729de88e12a236549386b0 prerequisite-patch-id: 6c67a9cae4b0a873402355eac2e26943e6ac4ad6 prerequisite-patch-id: cffe93501f50aa986a4d0546614e59ad16b1b6b8 prerequisite-patch-id: cb823554e6cd1c736535944e1c87fb397e31d7e0 prerequisite-patch-id: b6b2b1079cd9864d9d785cbba7656706f2019357 prerequisite-patch-id: aaa2d626cfc8cdb4130a45706fdcb743de34e06f prerequisite-patch-id: 6511f02f5192e70025a03c323232c1925d5ec9ab prerequisite-patch-id: 4d49e42ca5ead7cc03372c6d99189d98d4af03ba prerequisite-patch-id: ee16181118c1b9f04a802ac725da9681fa5473b8 prerequisite-patch-id: 65448b5a93120d2117c1361035afc9bd911d005f prerequisite-patch-id: a1a62f04d90fb71042e2dabb15d1b37c7e7bbff2 Best regards, -- Sam Day <me(a)samcday.com>

2 8

[PATCH] arm: kconfig should not display the STATIC_MACH_TYPE option when SUPPORT_PASSING_ATAGS is not selected
by 1425075683＠qq.com 28 Jan '25

28 Jan '25

From: Liya Huang <1425075683(a)qq.com> When I use arch armv7, menuconfig shows the STATIC_MACH_TYPE option causing me confusion. As we know, this should not occur when SUPPORT_PASSING_ATAGS is not selected Signed-off-by: Liya Huang <1425075683(a)qq.com> --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 314916527c9..349cfa1bdbc 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -2184,6 +2184,7 @@ config SERIAL_TAG config STATIC_MACH_TYPE bool "Statically define the Machine ID number" default y if TARGET_DS109 || TARGET_DS414 || DEFAULT_DEVICE_TREE = "sun7i-a20-icnova-swac" + depends on SUPPORT_PASSING_ATAGS help When booting via ATAGs, enable this option if we know the correct machine ID number to use at compile time. Some systems will be -- 2.25.1

1 0