July 2024 - U-Boot

[RESEND PATCH v2 0/5] net: dwc_eth_qos: Add glue driver for Intel MAC
by Philip Oberfichtner 13 Jul '24

13 Jul '24

This patch series implements the dwc_eth_qos glue driver for Intel SOCs. Before doing that, a few general adaptions to the dwc_eth_qos.c main driver are required. Most notably, the preparation for PCI based driver instances, which do not necessarily use a device tree. This patch series depends on: "net: dwc_eth_qos: mdio: Implement clause 45": https://patchwork.ozlabs.org/project/uboot/patch/20240507094237.168238-1-pr… Changes in V2: Improve coding-style in PATCH 5/5 Philip Oberfichtner (5): x86: provide mb() macro net: dwc_eth_qos: Fix header to be self-contained net: dwc_eth_qos: Adapt probe() for PCI devices net: dwc_eth_qos: Implement bind() for PCI devices net: dwc_eth_qos: Add glue driver for Intel MAC arch/x86/include/asm/io.h | 1 + drivers/net/Kconfig | 7 + drivers/net/Makefile | 1 + drivers/net/dwc_eth_qos.c | 44 ++- drivers/net/dwc_eth_qos.h | 8 +- drivers/net/dwc_eth_qos_imx.c | 1 + drivers/net/dwc_eth_qos_intel.c | 446 +++++++++++++++++++++++++++++ drivers/net/dwc_eth_qos_intel.h | 58 ++++ drivers/net/dwc_eth_qos_qcom.c | 1 + drivers/net/dwc_eth_qos_rockchip.c | 1 + drivers/net/dwc_eth_qos_starfive.c | 1 + drivers/net/dwc_eth_qos_stm32.c | 1 + include/pci_ids.h | 9 + 13 files changed, 575 insertions(+), 4 deletions(-) create mode 100644 drivers/net/dwc_eth_qos_intel.c create mode 100644 drivers/net/dwc_eth_qos_intel.h -- 2.39.2

3 13

[RFC v4 0/2] FIT documentation link vs copy
by Sam Povilus 13 Jul '24

13 Jul '24

I'm proposing linking the FIT documentation instead of double book keeping it, it does have the disadvantage of making it more difficult to see the documentation especially if offline. v2: update table of contents instead of removing v3: remove duplicate entries, provide commit message v4: cleanup: newlines, duplicated word, commit order Sam Povilus (2): doc: Remove FIT documentation that is elsewhere doc: add missing table of content links doc/usage/fit/index.rst | 25 +- doc/usage/fit/source_file_format.rst | 682 +-------------------------- 2 files changed, 22 insertions(+), 685 deletions(-) -- 2.34.1

2 4

[PATCH] doc/sphinx/requirements.txt: Bump certifi and urllib3
by Tom Rini 13 Jul '24

13 Jul '24

As reported by GitHub dependabot, both of these packages should be bumped to their latest versions to address security issues (neither of which has a CVE assigned). Reported-by: GitHub dependabot Signed-off-by: Tom Rini <trini(a)konsulko.com> --- doc/sphinx/requirements.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index 306b05a995e6..40dde599916e 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -1,6 +1,6 @@ alabaster==0.7.16 Babel==2.15.0 -certifi==2024.6.2 +certifi==2024.7.4 charset-normalizer==3.3.2 docutils==0.20.1 idna==3.7 @@ -22,4 +22,4 @@ sphinxcontrib-jquery==4.1 sphinxcontrib-jsmath==1.0.1 sphinxcontrib-qthelp==1.0.7 sphinxcontrib-serializinghtml==1.1.10 -urllib3==2.2.1 +urllib3==2.2.2 -- 2.34.1

2 1

[PATCH 0/6] Add Turris 1.x board
by Marek Mojík 13 Jul '24

13 Jul '24

Hello all, this is a continuation of previous work by Pali to add support for the Turris 1.x board. As the patches were based on u-boot v2022.04, a nontrivial rebasing was needed. Some notes: - Some options that are in SD defconfig are disabled in NOR defconfig because over the years u-boot grew and the old NOR defconfig will not fit into NOR memory. - SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We were not able to fix this yet) Marek Mojík (2): powerpc: mpc85xx: use CONFIG_VAL() for SYS_MONITOR_BASE in start.s powerpc: use CONFIG_IS_ENABLED() when checking for DM_SERIAL in include/asm/config.h This contributor prefers not to receive mails (4): board_f: Add support for CONFIG_OF_BOARD_FIXUP for XIP images board: freescale: p1_p2_rdb_pc: Add weak function p1_p2_rdb_pc_fix_fdt_model() for fixing DT model string powerpc: mpc8xxx: Extend find_law() to find_law_by_addr_id() powerpc: Add support for CZ.NIC Turris 1.x routers arch/powerpc/cpu/mpc85xx/Kconfig | 7 + arch/powerpc/cpu/mpc85xx/start.S | 2 +- arch/powerpc/cpu/mpc8xxx/law.c | 5 +- arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/turris1x-u-boot.dtsi | 17 + arch/powerpc/dts/turris1x.dts | 511 ++++++++++++++++++ arch/powerpc/include/asm/config.h | 2 +- arch/powerpc/include/asm/fsl_law.h | 8 +- board/CZ.NIC/turris_1x/Kconfig | 155 ++++++ board/CZ.NIC/turris_1x/MAINTAINERS | 13 + board/CZ.NIC/turris_1x/Makefile | 15 + board/CZ.NIC/turris_1x/ddr.c | 28 + board/CZ.NIC/turris_1x/law.c | 13 + board/CZ.NIC/turris_1x/tlb.c | 143 +++++ board/CZ.NIC/turris_1x/turris_1x.c | 571 ++++++++++++++++++++ board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 13 +- boot/Kconfig | 2 +- common/board_f.c | 8 +- configs/turris_1x_nor_defconfig | 87 +++ configs/turris_1x_sdcard_defconfig | 106 ++++ dts/Kconfig | 6 + include/configs/turris_1x.h | 335 ++++++++++++ 22 files changed, 2041 insertions(+), 7 deletions(-) create mode 100644 arch/powerpc/dts/turris1x-u-boot.dtsi create mode 100644 arch/powerpc/dts/turris1x.dts create mode 100644 board/CZ.NIC/turris_1x/Kconfig create mode 100644 board/CZ.NIC/turris_1x/MAINTAINERS create mode 100644 board/CZ.NIC/turris_1x/Makefile create mode 100644 board/CZ.NIC/turris_1x/ddr.c create mode 100644 board/CZ.NIC/turris_1x/law.c create mode 100644 board/CZ.NIC/turris_1x/tlb.c create mode 100644 board/CZ.NIC/turris_1x/turris_1x.c create mode 100644 configs/turris_1x_nor_defconfig create mode 100644 configs/turris_1x_sdcard_defconfig create mode 100644 include/configs/turris_1x.h -- 2.45.1

4 14

[PATCH v5 00/23] qcom: rpmh core and regulator support
by Caleb Connolly 13 Jul '24

13 Jul '24

This series introduces support for the RPMh (Resource Power Manager (hardened)) co-processor and associated regulator driver found on most modern Qualcomm platforms (since ~2017). Even though most regulators are controlled via SPMI, the specific regions on the PMICs for controlling the regulators are restricted and can't be accessed by the Applications Processor (AP/HLOS). Instead, these resources are proxied via the RPMh where they can be voted on by multiple subsystems (Linux, the modem, and the other DSPs). This is done for security (to protect clocks, power domains, and regulators that are specifically relevant for the trustzone) as well as to simplify the management of shared peripherals and to allow for handover of peripherals like the USB controller. For U-Boot, our main concern is the regulators. Since all regulators on the system are controlled via the RPMh, it is necessary to support it to enable USB VBUS on some platforms, and may be needed for other peripherals in the future. Communicating with the RPMh additional requires accessing the cmd-db shared memory region, this contains key/value maps to determine the address of specific resources on the RPMh. Introduce support for the cmd-db, the RPMh framework, and some of the regulators that are necessary to enable USB VBUS on the RB5 development board. These drivers are taken from Linux, then modified and simplified for U-Boot. The original Linux drivers contain heavy optimisations related to multithreading and asynchronous probing, as well as support for idle and suspend states which we don't need to deal with here. This unused code is removed before finally adjusting the drivers to properly build for U-Boot and use its device model. The U-Boot version of the driver supports a single ACTIVE_ONLY TCS and waits for it to be cleared after use. We don't support programming low power states. --- Changes in v5: - Add Kconfig / Makefiles after introducing drivers to avoid breaking compilation when bisecting (Thanks Neil). - Link to v4: https://lore.kernel.org/r/20240709-b4-qcom-rpmh-v4-0-c06d0a26644a@linaro.org Changes in v4: - Denote original Linux version in bitmap.h patch - Rebased on Linux 6.10-rc6 and re-apply U-Boot changes preserving git history. Allowing for future changes to the Linux drivers to be ported over more easily. - Add missing check to wait for the TCS to be cleared after use (seems we were just racing the RPMh before, oops!). - Fix missing n_modes in pmic5_pldo regulator. - Link to v3: https://lore.kernel.org/r/20240708-b4-qcom-rpmh-v3-0-846cc6c5b728@linaro.org Changes in v3: - Don't call dm_scan_fdt_dev(), since DM core will scan. - Link to v2: https://lore.kernel.org/r/20240708-b4-qcom-rpmh-v2-0-8bc765606e56@linaro.org Changes in v2: - Implement Neil's suggestions and fixes for SM8[56]50 - Slightly refactor cmd_db_init() for better abstraction. - Improve logging (printf -> log_err/dev_err) - Add missing error check in rpmh_regulators_bind() - Link to v1: https://lore.kernel.org/r/20240617-b4-qcom-rpmh-v1-0-bd2336923e0a@linaro.org --- Caleb Connolly (23): linux/bitmap.h: add bitmap_empty helper soc: qcom: import rpmh and cmd-db drivers from Linux soc: qcom: cmd-db: adjust headers for U-Boot soc: qcom: cmd-db: drop unused functions soc: qcom: cmd-db: replace cmd_db_ready() with cmd_db_init() soc: qcom: cmd-db: adjust for U-Boot API soc: qcom: rpmh-rsc: drop unused multi-threading and non-active TCS support soc: qcom: rpmh-rsc: adjust headers for U-Boot soc: qcom: rpmh-rsc: adjust probe for U-Boot soc: qcom: rpmh-rsc: remaining U-Boot API changes soc: qcom: rpmh: adjust headers for U-Boot soc: qcom: rpmh: drop unused functions soc: qcom: rpmh: U-Boot API changes soc: qcom: add build infrastructure power: regulator: import qcom-rpmh-regulator from Linux power: regulator: qcom-rpmh-regulator: adjust headers for U-Boot power: regulator: qcom-rpmh-regulator: port over lineage_range helpers power: regulator: qcom-rpmh-regulator: adjust structs for U-Boot power: regulator: qcom-rpmh-regulator: remove unused regulators power: regulator: qcom-rpmh-regulator: port ops to U-Boot power: regulator: qcom-rpmh-regulator: adjust probe for U-Boot power: regulator: qcom-rpmh-regulator: add build infra qcom_defconfig: enable rpmh regulators configs/qcom_defconfig | 5 + drivers/power/regulator/Kconfig | 8 + drivers/power/regulator/Makefile | 1 + drivers/power/regulator/qcom-rpmh-regulator.c | 544 ++++++++++++++++++++++++++ drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/qcom/Kconfig | 27 ++ drivers/soc/qcom/Makefile | 4 + drivers/soc/qcom/cmd-db.c | 213 ++++++++++ drivers/soc/qcom/rpmh-internal.h | 138 +++++++ drivers/soc/qcom/rpmh-rsc.c | 518 ++++++++++++++++++++++++ drivers/soc/qcom/rpmh.c | 110 ++++++ include/linux/bitmap.h | 8 + include/soc/qcom/cmd-db.h | 33 ++ include/soc/qcom/rpmh.h | 28 ++ include/soc/qcom/tcs.h | 81 ++++ 16 files changed, 1720 insertions(+) --- change-id: 20240611-b4-qcom-rpmh-fcfd32ac2940 base-commit: 834df20b4ef50cda26936fbc435689fa0c5d47b1 // Caleb (they/them)

2 24

Re: [coreboot] Announcement: Official V0.9.1 Release for Universal Payload Sepcification
by Simon Glass 13 Jul '24

13 Jul '24

+U-Boot Mailing List +Tom Rini On Fri, 12 Jul 2024 at 15:37, Lean Sheng Tan via coreboot <coreboot(a)coreboot.org> wrote: > > Hi everyone, > After 2 years of endless discussions and relentless effort, we officially landed the V0.9 (and V0.9.1) of Universal Payload Specification (UPL) yesterday!!! > > V0.9 formally introduces using Device Trees as the standardized Payload Handoff Format to pass data from Platform Init (e.g. coreboot) to Payload (e.g. UEFI payload or LinuxBoot). This reduces the data handoff friction and proprietary handoff formats currently exist in each and every firmware project (e.g. HOB, coreboot table). > > A brief historical background: Universal Payload started as a sub-project under Intel's Universal Scalable Firmware Initiative. Since its introduction, Intel has been actively seeking for the firmware community's input to help make it a reality, to help standardise a common architecture and interfaces between Platform Init and Payload. Later on, 9elements actively collaborated with Intel to work with all major firmware projects (coreboot, U-Boot, edk2, Linuxboot) with the support of all architecture (x86, Arm, RISC-V). We have been actively promoting and collecting feedback in every means we could (mailing lists, OSFC, OCP Global Summit, COSCUP). I could not find words to summarize the 2 years tireless efforts made by all the UPL contributors: with about 2-4 meetings per month since May 2022; countless back and forth discussion and some compromises made in between to find common ground that fits all Firmware solutions and projects; some technical setbacks with failed POCs and then persistent testings on coding sites; new expectations and issues pop up now and there that setback the initial timeline again and again... I owe all of them my greatest gratitude for their hard work. I would like to specially thanks Vincent Zimmer from Intel for making this happen in the first place - early commitment from ARM, Intel/ edk2 / Slimbootloaders maintainers, Chasel Chiu and Dong Guo, Maximilian Brune and Arther Heymans from coreboot, Dhaval Sharma and Aaron Durbin from Rivos, and Simon Glass & Ron Minnich who are both great visionaries in the Open Firmware world. In short, this is truly the first ever community effort that brings all firmware communities to collaborate together, in the very common goal to make Open Source Firmware a better place for everyone. > > For sure, this cannot and never will please everyone, and like all things there are always many issues in the first revision. Hence, I sincerely pledge to all of you, to help and contribute to this spec. This is an open invitation, as we follow the ethos of "For Community, By Community", the first open source spec that is owned by all the open firmware communities. > > Please refer here for the latest spec: > universalpayload.github.io/spec > > Feel free to contribute here: > https://github.com/UniversalPayload/spec > > WIP coreboot patch: > https://review.coreboot.org/c/coreboot/+/76591 > > Last but not least, I also wanted to specially thank 9elements Cyber Security for all the support since the very beginning that helps me to navigate through all the hurdles and issues for the past 2 years. > Let's continue to work together for a better Open Source Firmware for everyone. > > Thanks, > Sheng > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org

1 0

env: CONFIG_DEFAULT_ENV_FILE and CFG_EXTRA_ENV_SETTINGS
by Tony Dinh 12 Jul '24

12 Jul '24

Hi Tom, I'm trying to move some envs from a board header file to the default env file. I recall that the envs in CONFIG_DEFAULT_ENV_FILE are appended to the envs in CFG_EXTRA_ENV_SETTINGS. As you mentioned here before: https://lore.kernel.org/all/20220810170439.GJ1146598@bill-the-cat/ But it looks like envs in CFG_EXTRA_ENV_SETTINGS are completely erased, and then the envs are populated with what's in CONFIG_DEFAULT_ENV_FILE. Did I understand the usage correctly? Thanks, Tony

3 5

Pull request: rpi-2024.10 rc1
by Peter Robinson 12 Jul '24

12 Jul '24

Hi Tom, Please pull the updates for the Raspberry Pi: Updates for RPi for 2024.10: - board: rpi: remove leftover CONFIG_HW_WATCHDOG block - arm: bcm283x: remove unused empty hw_watchdog_disable - board: raspberrypi: Fix format specifier for printing rev_scheme - Revert "arm: dts: bcm283x: Add minimal smbios information" The following changes since commit 3f772959501c99fbe5aa0b22a36efe3478d1ae1c are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git tags/rpi-2024.10-rc1

2 1

adding fdt-overlay function - help needed
by Frank Wunderlich 12 Jul '24

12 Jul '24

Hi, i try to get overlay-merging working in uboot (for OF_UPSTREAM conversion), but failing on missing Makefile knowledge i have the state now, that upstream dtso get compiled to dtbo files (that needed further changes). now i added this from linux-tree: #merge CONFIG_DEFAULT_DEVICE_TREE + OF_OVERLAY_LIST_BASEDT to target DTB #manual: # dtc -I dtb -O dts dts/upstream/src/arm64/mediatek/mt7986a-bananapi-bpi-r3-sd.dtbo # fdtoverlay -i dts/upstream/src/arm64/mediatek/mt7986a-bananapi-bpi-r3.dtb -o dts/upstream/src/arm64/mediatek/mt7986a-bananapi-bpi-r3-sd.dtb dts/upstream/src/arm64/mediatek/mt7986a-bananapi-bpi-r3-sd.dtbo # dtc -I dtb -O dts dts/upstream/src/arm64/mediatek/mt7986a-bananapi-bpi-r3-sd.dtb | less #currently linux-version quiet_cmd_fdtoverlay = DTOVL $@ cmd_fdtoverlay = $(objtree)/scripts/dtc/fdtoverlay -o $@ -i $(real-prereqs) $(multi-dtb-y): FORCE $(call if_changed,fdtoverlay) $(call multi_depend, $(multi-dtb-y), .dtb, -dtbs) and created an config-option CONFIG_OF_OVERLAY_LIST_BASEDT which holds a space separated list of the dtbo-files without path, in my test CONFIG_DEFAULT_DEVICE_TREE="mediatek/mt7986a-bananapi-bpi-r3" CONFIG_OF_OVERLAY_LIST_BASEDT="mt7986a-bananapi-bpi-r3-nand.dtbo mt7986a-bananapi-bpi-r3-nor.dtbo mt7986a-bananapi-bpi-r3-sd.dtbo" i now want the list passed to the quiet_cmd_fdtoverlay which should handle each item and add the dtbo to a base-devicetree (like in comments above).... maybe anyone here can help getting this to work? if my source is needed: https://github.com/frank-w/u-boot/commits/2024-07-bpi-ofupstream-all/ regards Frank

2 3

[PATCH] fat: fat2rtc: Sanitize timestamps
by Richard Weinberger 12 Jul '24

12 Jul '24

Make sure that tm_mday and tm_mon are within the expected range. Upper layers such as rtc_calc_weekday() will use them as lookup keys for arrays and this can cause out of bounds memory accesses. Signed-off-by: Richard Weinberger <richard(a)nod.at> --- fs/fat/fat.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 2dd9d4e72d..f9096e8932 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -1253,8 +1253,9 @@ out: */ static void __maybe_unused fat2rtc(u16 date, u16 time, struct rtc_time *tm) { - tm->tm_mday = date & 0x1f; - tm->tm_mon = (date & 0x1e0) >> 5; + tm->tm_mday = max(1, date & 0x1f); + tm->tm_mon = clamp((date & 0x1e0) >> 5, 1, 12); + tm->tm_year = (date >> 9) + 1980; tm->tm_sec = (time & 0x1f) << 1; -- 2.35.3

4 4