summaryrefslogtreecommitdiff
path: root/doc
AgeCommit message (Collapse)Author
3 hoursPrepare v2026.07HEADv2026.07masterTom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
13 hourstest: Stop running the patman testsSimon Glass
The patman tests no longer exist in the tree, so drop them from the test/run script (used by 'make tcheck' and friends) and from the tools-testing example in the documentation. Signed-off-by: Simon Glass <sjg@chromium.org>
13 hoursdoc: Remove the patman documentationSimon Glass
The full patman manual now lives with the standalone patch-manager package, making the 1000-line copy in the tree redundant. Remove the in-tree manual, its README and the doc/develop/patman.rst toctree page. The sending-patches guide already introduces patman, so point it at the patch-manager package instead of the now-dead ':doc:' cross-reference and, with the manual gone, add a couple of lines on how the tool works. Point the SPI howto at that guide too, rather than repeating the install details. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
13 hoursdoc: Move the b4 guide into sending_patchesSimon Glass
The b4 contributor guide sits in the coding-style document, which is an odd place for it. Move it into sending_patches.rst, next to the patman note, so both patch-sending tools are described together. The b4_contrib label moves with it, so the reference from process.rst still resolves. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Reviewed-by: Tom Rini <trini@konsulko.com>
3 daystreewide: change email links from mailman to patch.msgid.link with message-idNeil Armstrong
In preparation of the migration of the mailman mailing-list currently hosted on the denx.de infrastructure, migrate the links in the code, comments and documentation to https://patch.msgid.link to be future proof and always link to the expected content data and uses the message-id in the URL which will help find the appropriate e-mail in the future. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
3 daysdrivers: sysreset: revert support for args in requestQuentin Schulz
This reverts: - commit e49c84f7bb7b ("doc: usage: cmd: reset: specify when the -edl option is available") - commit 1076feb8a3f9 ("cmd: boot: fix edl being shown when not supported") - commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset") - commit ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command documentation") - commit 32825eaddc37 ("sysreset: Implement PSCI based reset to EDL mode for QCOM SoCs") - commit fcb48b89813b ("drivers: sysreset: Add sysreset op that can take arguments") There was a conflict reverting commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset") due to commit 02ef1859b44f ("configs: Resync with savedefconfig"), but the conflict resolution was trivial. The args support for the sysreset uclass contains a logic bug. The first sysreset device implementing the request_arg callback will consume the args, not support the specified arg and thus return -EPROTONOSUPPORT which will stop the iteration over all sysreset devices. This is an issue if one has multiple sysreset devices and each with support for different (valid) args. If a sysreset device implements a -dummy argument and another -foo and a user calls reset -dummy from the U-Boot CLI, it'll depend on which sysreset device will be attempted first. If it is the one implementing -foo, it'll return it doesn't support the argument with -EPROTONOSUPPORT in which case the device implementing -dummy will never be attempted and instead we'll do a cold reset which is very likely not what's expected from the user. Casey suggested[1] we revert this and start from scratch again with a different implementation instead. [1] https://lore.kernel.org/u-boot/77ff0f56-5c3b-42e7-bdd1-bf90296da900@linaro.org/ Acked-by: Casey Connolly <casey.connolly@linaro.org> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
2026-06-22Prepare v2026.07-rc5v2026.07-rc5Tom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2026-06-21doc: android: fastboot: Document halt behaviourMattijs Korpershoek
It's possible to interrupt the fastboot command from the U-Boot shell using the Ctrl-c keybinding. Document this. Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Reviewed-by: Sam Day <me@samcday.com>
2026-06-21doc: board: renesas: Document Renesas Ironhide board supportMarek Vasut
Document support for Renesas Ironhide development board based on Renesas R-Car X5H (R8A78000) SoC. Fixes: cf71963778ee ("arm64: dts: renesas: Add Renesas R-Car X5H R8A78000 Ironhide board code") Fixes: 9d47a5a4d560 ("arm: renesas: Add Renesas R-Car R8A78000 X5H Cortex-M33 RSIP port") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2026-06-21doc: board: renesas: Document Renesas Gray Hawk board supportMarek Vasut
Document support for Renesas Gray Hawk Single development board based on Renesas R-Car V4M (R8A779H0) SoC. Fixes: 53066deccbed ("ARM: renesas: Add Renesas R8A779H0 V4M Gray Hawk board code") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2026-06-21doc: board: renesas: Document Renesas Geist board supportMarek Vasut
Document support for Renesas Geist development board based on Renesas R-Car M3Le (R8A779MD) SoC. Fixes: c8523795d796 ("arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2026-06-21doc: board: renesas: Document Renesas RZ/N1D and RZ/N1S as armMarek Vasut
The RZ/N1D and RZ/N1S contain Cortex-A7 core, which is 32bit ARM core. Document the SoC as 32bit ARM instead of aarch64. Fixes: a5b9f959439b ("doc: renesas: add Renesas board docs") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2026-06-10Merge tag 'u-boot-rockchip-20260610' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-rockchip CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/30398 Please pull the updates for rockchip platform: - New Board support: rk3588 FriendlyElec NanoPi R76S - UFS boot from SPL for rk3576 (NanoPi M5, ROCK 4D) - Clock support for RK3576 GMAC 25MHz output and RK3528/RK3576 USB3 OTG - Switch rk3128/rk3229 boards to upstream devicetree - MAINTAINERS update for upstream devicetree references - rk3588-rock-5b: Remove USB-C controller from u-boot.dtsi
2026-06-09Merge tag 'efi-2026-07-rc5' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-efi Pull request efi-2026-07-rc5 CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/30365 Documentation: * Update urllib3 version for building * usb: typos 'requird', 'current' UEFI * Improve PE-COFF relocation data validation Devicetree-to-C generator: * dtoc: test: add missing escape in help text
2026-06-09Merge patch series "ti: j7: Update to v0.12.0 of DDR config tool"Tom Rini
Neha Malcom Francis <n-francis@ti.com> says: Update all DDR configuration DTSIs to the latest auto-generated output of the Sysconfig Tool (DDR Configuration for TDA4x, DRA8x, AM67x, AM68x, AM69x (0.12.00.0000)) [0] The auto-generated files must not be modified, but effort will be taken to change the tool output to adhere to the latest checkpatch.pl rules. J722S and J721E will also be updated in a subsequent series. All the changes have been kernel boot tested and memtester has passed (same as v1, as no functional changes made). [0] https://dev.ti.com/sysconfig/#/start Link: https://lore.kernel.org/r/20251103071035.674604-1-n-francis@ti.com
2026-06-09doc: ti: k3: Add section for DDR configurationNeha Malcom Francis
Add a concise section for DDR configuration pointing to the public tool that can be used to generate the configuration DTSI. Signed-off-by: Neha Malcom Francis <n-francis@ti.com> Reviewed-by: Romain Naour <romain.naour@smile.fr>
2026-06-08Prepare v2026.07-rc4v2026.07-rc4Tom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2026-06-08board: rockchip: Add FriendlyElec NanoPi R76SJonas Karlman
The NanoPi R76S (as "R76S") is an open-sourced mini IoT gateway device with two 2.5G, designed and developed by FriendlyElec. Features tested on a NanoPi R76S 2411: - SD-card boot - eMMC boot - LEDs and button - PCIe/Ethernet - USB host Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2026-06-07doc: Update urllib3 version for buildingTom Rini
The GitHub dependabot tool has reported two "high" priority bug, CVE-2026-44431 and CVE-2026-44432, with this package. Update to the patched version. Reported-by: GitHub dependabot Signed-off-by: Tom Rini <trini@konsulko.com>
2026-05-25Prepare v2026.07-rc3v2026.07-rc3Tom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2026-05-25global: Update URL for U-Boot projectTom Rini
Our official domain is now u-boot-project.org, so update all in-tree references to use the correct domain. Reviewed-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2026-05-18doc: usage: cmd: reset: specify when the -edl option is availableQuentin Schulz
The option is only available when CONFIG_SYSRESET_QCOM_PSCI is enabled, so let's make that explicit in the boot cmd documentation. Due to the implementation in drivers/sysreset/sysreset-uclass.c do_reset() function, all options to the reset command are passed to all sysreset drivers' sysreset_ops.request_arg callback (including -w) which is only available when CONFIG_SYSRESET_CMD_RESET_ARGS=y. -w, however, works also without this option. Fixes: ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command documentation") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2026-05-18doc: usage: cmd: reset: fix typoQuentin Schulz
"Do warm WARM" doesn't mean anything, I'm assuming the intent was to say "Do WARM reset" so reword. Fixes: 34e452dd0252 ("doc: usage: Group all shell command docs into cmd/ sub-directory") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2026-05-13Merge tag 'u-boot-stm32-20260512' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-stm CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/30081 - reset: stm32: Fix compilation error - Remove remaining non-existant STM32_RESET flag - configs: stm32mp13: Add SPI-NAND UBI boot support - Support metadata-driven A/B boot for STM32MP25
2026-05-12Merge patch series "Switch Apple silicon boards to upstream device trees"Tom Rini
Janne Grunau <j@jannau.net> says: The Linux device trees for Apple silicon devices cover now most of the hardware as u-boot's internal device trees for M1 devices. Linux has in addition device trees M2 and M1 and M2 Pro/Max/Ultra devices which were never added in u-boot. The most common use case for u-boot on Apple silicon devices does not use DTBs from u-boot but passes runtime modified device trees from an earlier boot loader (m1n1). This change regresses support for the SPI on M1 and M1 Pro/Max notebooks as SPI keyboard support is not in upstream Linux. This regression is in my opinion acceptable due to the limited use of u-boot's DTBs for these targets. Link: https://lore.kernel.org/r/20260507-apple-dt-upstream-v2-0-35181f2b0509@jannau.net
2026-05-12arm: dts: Switch Apple silicon devices to dts/upstreamJanne Grunau
The device tree on Apple silicon devices is passed from a previous bootloader stage. The bootloader fills in dynamic information so u-boot can not use its own device tree. As documented in doc/board/apple/m1.rst it is possible to build boot bundles (bootloader + device tree + gzipped u-boot binary). These are useful for testing. Instead of using u-boot's own device trees for M1 (t8103) devices use upstream device trees from dts/upstream/src/arm64/apple. The u-boot device trees have not seen updates since 2022. The upstream linux device trees have feature parity for the M1 devices. In addition linux has device trees for M1 Pro/Max/Ultra, M2 and M2 Pro/Max/Ultra devices. Keep t8103-j274 as default device tree to avoid further updates. Signed-off-by: Janne Grunau <j@jannau.net> Acked-by: Mark Kettenis <kettenis@openbsd.org>
2026-05-12doc: device-tree-bindings: Remove apple,pinctrl.yamlJanne Grunau
Remove outdated apple,pinctrl.yaml. The dts/upstream contains the current version of this binding. Signed-off-by: Janne Grunau <j@jannau.net> Acked-by: Mark Kettenis <kettenis@openbsd.org>
2026-05-12doc: board: apple: Mention M2 and M2 Pro/Max/Ultra SoCsJanne Grunau
These SoCs are supported since 2022/2023 but were never added to the documentation. The devices very similar to the equivalent M1 devices. The biggest difference is that the M2 and M2 Pro/Max based laptops no longer use SPI for the keyboard. Signed-off-by: Janne Grunau <j@jannau.net> Acked-by: Mark Kettenis <kettenis@openbsd.org>
2026-05-12cmd: part: support lookup by UUIDDario Binacchi
The 'part' command currently allows looking up a partition only by its number or name. Extend the 'number', 'start', and 'size' subcommands to support looking up the partition via its UUID. Unlike names, UUIDs guarantee unique partition identification, avoiding ambiguity. The logic is updated to check if the provided string is a valid UUID before falling back to a name-based search. The help strings for these subcommands are updated accordingly. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2026-05-12lib: uuid: add partition type GUID for extended bootloaderDario Binacchi
The Extended Boot Loader Partition (XBOOTLDR) is a standard defined by the Discoverable Partitions Specification (DPS) to host boot loader resources outside of the EFI System Partition ([1], [2]). Defining this GUID (bc13c2ff-59e6-4262-a352-b275fd6f7172) allows U-Boot to correctly identify and label these partitions using the "xbootldr" shorthand. [1] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/#extended-boot-loader-partition:~:text=UEFI%20Specification.-,Extended%20Boot%20Loader%20Partition,-bc13c2ff%2D59e6%2D4262 [2] https://uapi-group.org/specifications/specs/boot_loader_specification/ Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2026-05-11Prepare v2026.07-rc2v2026.07-rc2Tom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2026-05-01doc: bootstd: specify CONFIG_BOOTSTD_DEFAULTS provides network features when ↵Quentin Schulz
NET=y In the past, we only had one network stack which was called NET. The network features were enabled for the legacy (and then only) networking stack since commit 22353fa6b585 ("bootstd: Add some default filesystems and commands"). Then instead on relying on NET legacy stack for enabling networking features, the dependencies were (mostly) changed to depend on CMD_NET in commit a0c739c184ca ("boot: Create a common BOOT_DEFAULTS for distro and bootstd"). Then a new stack (lwIP) appeared, then CMD_NET was made available with this new stack in commit 98ad145db61a ("net: lwip: add DHCP support and dhcp commmand") making the networking features possible to enable and finally commit f1e978fd54d9 ("boot: Update tests around network symbols in BOOT_DEFAULTS_CMDS") made it explicit that we need *a* network stack to enable some networking features. Align the bootstd documentation with what's actually implemented as Kconfig dependencies. Note that BOOTSTD_DEFAULTS selects BOOT_DEFAULTS which selects BOOT_DEFAULTS_CMDS which then selects network features. The CMDLINE symbol needs to be enabled as well for BOOT_DEFAULTS to select BOOT_DEFAULTS_CMDS, but I don't think we need to go that far into explaining what's required to enable some commands. Reported-by: Simon Glass <sjg@chromium.org> Closes: https://lore.kernel.org/u-boot/CAFLszTgZC1FGy8965pHiG-u=FhrguftRv41ghQ_Qb_RRXx6tyg@mail.gmail.com/ Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
2026-05-01doc: .clang-format descriptionHeinrich Schuchardt
We cannot use .clang-format without modification. For instance U-Boot has some for each macros that Linux does not have. Adjust the description. Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2026-05-01doc: board: ti: k3: Add fTPM support documentationShiva Tripathi
Add fTPM support documentation including an overview, configuration steps for RPMB provisioning, OP-TEE TA build instructions, and verification procedure. Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
2026-05-01doc: emulation: qemu-arm: add secure state stepsJohannes Krottmayer
Add build steps for building U-Boot in secure state with TF-A and OP-TEE. It includes the full steps for building OP-TEE and TF-A to use with U-Boot. Also a short description how to invoke QEMU with enabled EL3 and EL2. EL3 (machine option secure=on) is required to run TF-A. Signed-off-by: Johannes Krottmayer <krotti83@proton.me> Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
2026-04-27Prepare v2026.07-rc1v2026.07-rc1Tom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2026-04-27Merge patch series "net: migrate NO_NET out of the networking stack choice"Tom Rini
Quentin Schulz <foss+uboot@0leil.net> says: This migrates the net options away from the main Kconfig to net/Kconfig, rename the current NET option to NET_LEGACY to really highlight what it is and hopefully encourage more people to use lwIP, add a new NET menuconfig (but keep NO_NET as an alias to NET=n for now) which then allows us to replace all the "if legacy_stack || lwip_stack" checks with "if net_support" which is easier to read and maintain. The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed for now even when no network is configured? Likely due to include/net-common.h with PKTBUFSRX? No change in behavior is intended. Only change in defconfig including other defconfigs where NO_NET=y or NET is not set, in which case NO_NET is not set or NET=y should be set in the top defconfig. Similar change required for config fragments. See commit log in patch adding NET menuconfig for details. This was tested based on 70fd0c3bb7c2 ("x86: there is no CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up similarly as in "build all platforms in a single job" GitLab CI job. #!/usr/bin/env bash set -o pipefail set -eux ARGS="-BvelPEWM --reproducible-builds --step 0" ./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $* ./tools/buildman/buildman -o ${O} $ARGS -Ssd $* O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt I can't really decipher the log.txt, but there's no line starting with + which would be an error according to tools/buildman/builder.py help text. Additionally, because I started the script with set -e set and because buildman has an exit code != 0 when it fails to build a board, and I have the summary printed (which is the second buildman call), I believe it means all builds passed. The summary is the following: aarch64: (for 537/537 boards) all +0.0 rodata +0.0 uniphier_v8 : all +1 rodata +1 u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1) function old new delta data_gz 10640 10641 +1 arm: (for 733/733 boards) all -0.0 rodata -0.0 uniphier_v7 : all -1 rodata -1 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1) function old new delta data_gz 11919 11918 -1 opos6uldev : all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 18778 18775 -3 uniphier_ld4_sld8: all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 11276 11273 -3 stemmy : all -20 rodata -20 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20) function old new delta data_gz 15783 15763 -20 As far as I could tell this data_gz is an automatically generated array when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored in binary form. Because I'm changing the name of symbols, replacing a menu with a menuconfig, additional text makes it to .config and the "# Networking" section in .config disappears. Here is the diff for the 5 defconfigs listed above, generated with: for f in build/*-m; do diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config done (-m is the build directory for master, and without the suffix, it's the top commit of this series) """ --- build/opos6uldev-m/.config 2026-04-20 10:53:49.804528526 +0200 +++ build/opos6uldev/.config 2026-04-20 11:03:37.430242767 +0200 @@ -970,4 +969,0 @@ - -# -# Networking -# @@ -975,0 +972 @@ +CONFIG_NET_LEGACY=y --- build/stemmy-m/.config 2026-04-20 11:01:33.653698123 +0200 +++ build/stemmy/.config 2026-04-20 11:04:53.452577311 +0200 @@ -733,4 +732,0 @@ - -# -# Networking -# @@ -738,2 +733,0 @@ -# CONFIG_NET is not set -# CONFIG_NET_LWIP is not set --- build/uniphier_ld4_sld8-m/.config 2026-04-20 11:00:41.605469071 +0200 +++ build/uniphier_ld4_sld8/.config 2026-04-20 11:04:22.226439899 +0200 @@ -997,4 +996,0 @@ - -# -# Networking -# @@ -1002,0 +999 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v7-m/.config 2026-04-20 10:53:04.019307319 +0200 +++ build/uniphier_v7/.config 2026-04-20 11:03:01.688085486 +0200 @@ -1004,4 +1003,0 @@ - -# -# Networking -# @@ -1009,0 +1006 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v8-m/.config 2026-04-20 10:43:05.614441175 +0200 +++ build/uniphier_v8/.config 2026-04-20 10:41:03.214852130 +0200 @@ -875,4 +874,0 @@ - -# -# Networking -# @@ -880,0 +877 @@ +CONFIG_NET_LEGACY=y """ This is fine: - Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't be in .config anymore. - opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have (old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but CONFIG_NET_LEGACY also needs to be defined now to reflect the stack choice (even if default), - stemmy has CONFIG_NO_NET set, which means CONFIG_NET and CONFIG_NET_LWIP are not reachable anymore hence why they don't need to be part of .config, GitLab CI was run on this series (well, not exactly, but it's only changes to the git logs that were made): https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849 It passes. Link: https://lore.kernel.org/r/20260420-net-kconfig-v1-0-9900002d8e72@cherry.de
2026-04-27doc: remove mention to non-existing TPL_NETQuentin Schulz
TPL_NET symbol never existed in the first place, so let's remove this misleading piece of documentation. Fixes: 143c9a7e9d68 ("doc: describe TPL/VPL/SPL boot") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2026-04-27simplify NET_LEGACY || NET_LWIP condition with NET conditionQuentin Schulz
Since the move to make NET a menuconfig and NO_NET a synonym of NET=n, when NET is enabled, NET_LEGACY || NET_LWIP is necessarily true, so let's simplify the various checks across the codebase. SPL_NET_LWIP doesn't exist but SPL_NET_LEGACY is an alias for SPL_NET so the proper symbol is still defined in SPL whenever needed. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2026-04-27rename NET to NET_LEGACYQuentin Schulz
Highlight that NET really is the legacy networking stack by renaming the option to NET_LEGACY. This requires us to add an SPL_NET_LEGACY alias to SPL_NET as otherwise CONFIG_IS_ENABLED(NET_LEGACY) will not work for SPL. The "depends on !NET_LWIP" for SPL_NET clearly highlights that it is using the legacy networking app so this seems fine to do. This also has the benefit of removing potential confusion on NET being a specific networking stack instead of "any" network stack. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2026-04-27cmd: boot: Add '-edl' option to reset command documentationVaradarajan Narayanan
Add help text about '-edl' option to reset command definition and related documentation. Reviewed-by: Casey Connolly <casey.connolly@linaro.org> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Link: https://patch.msgid.link/20260121063920.1500293-5-varadarajan.narayanan@oss.qualcomm.com Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
2026-04-22Merge patch series "test: Refactor FIT test for clarity and extensibility"Tom Rini
Simon Glass <sjg@chromium.org> says: This series reworks the FIT test (test_fit.py) to make it easier to maintain and extend. It fixes the buildconfigspec so the test actually runs on sandbox, avoids unnecessary U-Boot restarts, renames the main test for easier selection, adds a missing-kernel check, fixes Python warnings, converts the test to use a class, splits into separate test functions, and adds Sphinx documentation. Link: https://lore.kernel.org/r/20260413130007.1987326-1-sjg@chromium.org
2026-04-22test: Add documentation for the FIT testSimon Glass
Add a Sphinx automodule page for test_fit.py so it appears in the pytest documentation alongside the other test modules. The index already uses a glob pattern, so this is picked up automatically. Signed-off-by: Simon Glass <sjg@chromium.org>
2026-04-21imx8mq: Correct signed_hdmi firmware positionPeng Fan
signed_hdmi_imx8m.bin is already signed and has a IVT header. It should not be put in u-boot-spl-mkimage.signed.bin. Move it to head of flash.bin following NXP imx-mkimage. Keeping it in u-boot-spl-mkimage.signed.bin also consumes a lot of TCM space which is not expected. While moving it to head of flash.bin, other changes are required, u-boot.itb is put at sector 768 per defconfig, so u-boot.itb binman offset should be updated and it should be moved out from binman section. Also binman symbol address are updated, so need to subtract u-boot-spl image_pos + CONFIG_SPL_TEXT_BASE to find the correct location of ddr phy firmware. Because there is 1KB padding in HDMI firmware, use 32KB when burning flash.bin to sd card. Signed-off-by: Peng Fan <peng.fan@nxp.com>
2026-04-21board: toradex: add Toradex Verdin iMX95Emanuele Ghidoli
Add support for the Toradex Verdin iMX95. Link: https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx95 Link: https://www.toradex.com/products/carrier-board/verdin-development-board-kit Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Co-developed-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com> Co-developed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2026-04-21doc: tqma7: add documentationAlexander Feilke
Add readme for the tqma7 board. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Alexander Feilke <alexander.feilke@ew.tq-group.com>
2026-04-17doc: board: ti: j784s4_evm: Automate BAR address lookup for PCIe BootSiddharth Vadapalli
When the J784S4-EVM is configured for PCIe Boot, the Bootloaders are to be written to the address specified by particular BARs. The existing documentation hard-codes the address corresponding to the BAR under the assumption that the Root-Complex transferring the Bootloaders is also a J784S4-EVM. The Root-Complex assigns addresses to the BARs depending on the currently available set of free system addresses. Since the free system addresses vary with the Root-Complex being used, instead of hard-coding the BARs, automate the process of identifying the appropriate BAR in the form of a command to be run by the user on the Root-Complex. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
2026-04-17doc: correct title of CONTRIBUTE.rstHeinrich Schuchardt
The title should be 'Contributing' as this is not the 'Overview' of the U-Boot project. The top title should be H1, the other titles H2. Fixes: 0290cec364f6 ("Add an initial CONTRIBUTE.rst") Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2026-04-17doc: api: bootcount: correct bootcount descriptionMichael Opdenacker
The bootcount variable is only incremented when the upgrade_variable is non-zero, as implemented in drivers/bootcount/bootcount_env.c Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2026-04-17doc: Fix fdt resize argument in fdt_overlays.rstMatwey V. Kornilov
The argument is parsed as hexadecimal number. Link: https://lists.denx.de/pipermail/u-boot/2026-April/613799.html Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-07 03:08:23 +0000