| Age | Commit message (Collapse) | Author |
|---|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-net
Pull request net-20260813.
net:
- phy: dp83867: enable extended read / write for driver
- phy: fix duplicate eth_phy binding
- Drop unnecessary device_set_name
- dwc_eth_xgmac: Return -ENODEV when phy_connect() fails
- nfs: clean up bounds checks in nfs_readlink_reply()
- rtl8169: add support for RTL8126A and RTL8127A
- srand_mac(): fix -ENODEV crash with CONFIG_DM_RNG
net-legacy:
- Fix out-of-bounds write in IP fragment reassembly
- test: net: add regression test for IP reassembly overflow
net-lwip:
- Add tftpsrv command
- Handle chained pbufs in transmit path
- sntp: fix netif leak when ntpserverip is unset
- wget: free mbedtls x509 cert context to avoid memory leak
- Fix DHCP fine timer interval
|
|
Daniel Golle <[email protected]> says:
A signed FIT configuration can delegate the integrity of a (potentially
large) root filesystem image to the kernel's dm-verity instead of having
U-Boot hash the whole payload at boot: the FIT carries a "dm-verity"
subnode with the roothash, salt and block parameters, U-Boot passes the
roothash to Linux through the dm-mod.create bootargs, and dm-verity then
validates the filesystem block by block against it.
For that to be safe the roothash has to be trusted, and in a signed
configuration the only thing that establishes trust is the configuration
signature. The roothash was not covered by it. fit_config_add_hash()
collected the image node, its hash subnodes and its cipher subnode into
the signed region, but not the dm-verity subnode, so the roothash, the
sole integrity anchor for the filesystem, was left unsigned.
The result is a verified-boot bypass for the root filesystem: an
attacker who can rewrite the boot medium can replace the filesystem,
recompute a matching dm-verity tree, write the new roothash into the
unsigned dm-verity subnode, and the configuration signature still
verifies. dm-verity then faithfully validates the malicious filesystem
against the attacker's roothash.
This series closes the gap.
Link: https://lore.kernel.org/r/[email protected]
|
|
A dm-verity protected filesystem image is not hashed by U-Boot when it
is loaded; its integrity is delegated to the kernel, which validates the
filesystem on the fly against the roothash taken from the FIT dm-verity
subnode. The roothash is therefore the sole integrity anchor for the
filesystem, yet fit_config_add_hash() only adds the image node, its
hash subnodes and its cipher subnode to the signed region, leaving the
dm-verity subnode (roothash, salt and block parameters) unsigned.
An attacker able to rewrite the boot medium could then replace both the
filesystem and the roothash, recompute a matching dm-verity tree and
keep the configuration signature valid, defeating verified boot for the
root filesystem.
Add the dm-verity subnode to the list of nodes covered by the
configuration signature, both when signing (tools/image-host.c) and when
verifying (boot/image-fit-sig.c), so the roothash and salt are
authenticated together with the rest of the configuration.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Commit dc3765ede5a4 ("doc: Switch from setenv to env set") was
too eager to switch "setenv" to "env set" and also incorrectly
rewrote "gpt setenv" to "gpt env set". Undo this error.
Fixes: dc3765ede5a4 ("doc: Switch from setenv to env set")
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The attribute mnemonic table did not cover EFI_MEMORY_ISA_VALID and the
EFI_MEMORY_ISA_MASK field, and attribute bits without a mnemonic were
silently dropped, so a memory map carrying ISA-specific, invalid or not
yet known attributes displayed incomplete information without any hint
that something was missing.
Add a mnemonic for EFI_MEMORY_ISA_VALID and print the ISA-specific
field as ISA=<value> when it is valid, instead of decoding bits whose
meaning U-Boot cannot know. Any remaining bits that match neither the
mnemonic table nor the ISA field are printed as a hexadecimal value.
Suggested-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Aristo Chen <[email protected]>
|
|
The efi and efidebug commands each carried their own code for printing
the EFI memory map, with separate tables of memory type and attribute
names. The copies had drifted: efidebug knew EFI_PERSISTENT_MEMORY_TYPE
while 'efi mem' printed it as '<invalid>', neither table knew
EFI_UNACCEPTED_MEMORY_TYPE, and the 'efi mem' printer had misaligned
column headers, a broken '<gap>' line and a superfluous Virtual column:
the map is identity mapped before SetVirtualAddressMap() is called, so
the field carries no information at the time the command can run.
Move the printing loop of 'efidebug memmap' into efi_common.c as
efi_show_memmap(), which is linked into both commands, and use it from
both. The second copy in 'efi mem' is deleted together with
efi_print_mem_table() and the private sorting and merging code,
including the 'all' argument.
The memory type names follow the UEFI specification with the leading
'Efi' and the trailing 'Type' stripped, for example ConventionalMemory
for EfiConventionalMemory, and the missing name for unaccepted memory
is added. The type column is widened to fit the longest name,
MemoryMappedIOPortSpace.
The shared function iterates the map with the descriptor size reported
by the firmware instead of assuming sizeof(struct efi_mem_desc). This
matters for 'efi mem' under EDK II based firmware, which reports a
descriptor size of 0x30. The memory map key, which was printed
uninitialized on the payload path, is now initialized. The command
documentation is updated with output captured from the app running
under OVMF, and documents why virtual addresses are not shown.
Suggested-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Aristo Chen <[email protected]>
|
|
https://git.u-boot-project.org/u-boot/custodians/u-boot-efi
Pull request efi-2026-01-rc2
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-efi/-/pipelines/753
Documentation:
* sandbox: fix enum host_platform_flags description
* switch from setenv to env set and from printenv to env print
* document Renesas R-Car Gen5 RSIP Cortex-R52 start
* thead: lpi4a: detail how to enable fastboot
UEFI:
* unify and correct GUID selection for security database variables
* test: check default GUID selection of security database variables
* set correct frame buffer address
* check efi_deserialize_load_option() in get_dp_device()
|
|
fstypes"
Vincent Jardin <[email protected]> says:
3 commits providing documentation of impacts and testing the dispatch
for null_dev_desc_ok fstypes (semihosting, ubifs, sandbox) in the
generic `load <iface> ...` command.
The test does not cover ubifs, I could not make it work with
qemu. Since the code logic is there and testing with semihost
is done, it should cover the needed cases.
Link: https://lore.kernel.org/r/[email protected]
|
|
The "env" command is the recommended environment management command,
its "print" subcommand is the equivalent replacement for legacy "printenv"
command. Update the documentation to use the contemporary "env print"
command instead of legacy "printenv" command.
Note that the "printenv" command is unlikely to be removed from U-Boot
in the near future due to it being integral part of the command line
ABI.
Implemented using:
$ sed -i 's@\<printenv\>@env print@g' $(git grep -li '\<printenv\>' doc/) README
Signed-off-by: Marek Vasut <[email protected]>
|
|
The "env" command is the recommended environment management command,
its "set" subcommand is the equivalent replacement for legacy "setenv"
command. Update the documentation to use the contemporary "env set"
command instead of legacy "setenv" command.
Note that the "setenv" command is unlikely to be removed from U-Boot
in the near future due to it being integral part of the command line
ABI.
Implemented using:
$ sed -i 's@\<setenv\>@env set@g' $(git grep -li '\<setenv\>' doc/) README
Signed-off-by: Marek Vasut <[email protected]>
|
|
Document the dispatch path added by the former commit
fs: dispatch null_dev_desc_ok filesystems before lookup
Add a null-block-device interfaces section that:
* lists the three fstypes that can benefit of it (semihosting, ubifs,
sandbox) and the CONFIG option that builds each
* explains the '-' convention for the unused <dev[:part]> field
Suggested-by: Simon Glass <[email protected]>
Signed-off-by: Vincent Jardin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
With CONFIG_FIT_BEST_MATCH, fit_conf_find_compat() selects the
configuration matching the most specific U-Boot compatible string; on
equal matches the first listed configuration wins and the configurations
node 'default' property is never consulted.
A FIT whose configurations all share the same base devicetree compatible
(e.g. one manifest carrying a base tree plus overlay combinations for a
single board) therefore always boots the first configuration, silently
ignoring the default chosen by the manifest author.
Break score ties in favour of the default configuration. A strictly
better compatible match still wins over it, and FITs without a default
keep the current first-listed behaviour.
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Carlo Caione <[email protected]>
|
|
The legacy network stack supports tftpsrv, which listens for an
incoming TFTP write request and receives the first file into memory.
Despite the old command help wording, the command returns after
receiving the file and does not boot it automatically.
The lwIP stack already builds the lwIP TFTP application, but only wires
it up for client-side tftpboot. Add a lwIP tftpsrv command and
implement the server path with tftp_init_server(). Reuse the existing
lwIP TFTP write callback and memory copy path so LMB checks, progress
output, filesize/fileaddr updates and EFI bootdev handling stay
consistent with tftpboot.
Track receive timeout and write-failure state around the lwIP callbacks
so a stalled or rejected receive is not reported as a successful close.
Move CMD_TFTPSRV out of the legacy-only Kconfig block so it can be
enabled with either network stack. Update the command help text and add
usage documentation for the receive-only behavior.
Add pytest coverage for tftpsrv using a generated host file and curl's
TFTP upload support. Enable the command in qemu_arm64_lwip_defconfig so
the test can be run with the existing lwIP QEMU build when the boardenv
provides env__net_tftpsrv_file.
Signed-off-by: James Hilliard <[email protected]>
[Jerome Forissier: remove trailing ':' after SPDX tag]
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Jerome Forissier <[email protected]>
|
|
Rasmus Villemoes <[email protected]> says:
This started by me wanting something like what patch 8 does. That
wasn't too hard, except we had no strcasestr(), and also our regex
engine (which I didn't really want to pull into the mix anyway)
doesn't have a flag that requests case-insensitive matching. So I
wanted to add strcasestr(), but then I stumbled on a bunch of stuff
that should be cleaned up in str-land.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a little documentation for the config command and its new ability
to filter the output.
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add a sandbox LDO3 with a configurable 1.8V to 3.3V range and use it
to test regulator_set_value_clamp().
Test in-range requests, clamping against the regulator limits, invalid
ranges outside the regulator limits and a min value higher than max.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
|
|
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/[email protected]/
Acked-by: Casey Connolly <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
|
|
|
|
Daniel Golle <[email protected]> says:
This series adds dm-verity support to U-Boot's FIT image infrastructure.
It is the first logical subset of the larger OpenWrt boot method series
posted as an RFC in February 2026 [1], extracted here for independent
review and merging.
OpenWrt's firmware model embeds a read-only squashfs or erofs root
filesystem directly inside a uImage.FIT container as a FILESYSTEM-type
loadable FIT image. At boot the kernel maps this sub-image directly from
the underlying block device via the fitblk driver (/dev/fit0, /dev/fit1,
...), the goal is that the bootloader never even copies it to RAM.
dm-verity enables the kernel to verify the integrity of those mapped
filesystems at read time, with a Merkle hash tree stored contiguously in
the same sub-image just after the data. Two kernel command-line
parameters are required:
dm-mod.create= -- the device-mapper target table for the verity device
dm-mod.waitfor= -- a comma-separated list of block devices to wait for
before dm-init sets up the targets (needed when fitblk
probes late, e.g. because it depends on NVMEM
calibration data)
The FIT dm-verity node schema was upstreamed into the flat-image-tree
specification [2], which this implementation tries to follow exactly.
The runtime feature is guarded behind CONFIG_FIT_VERITY. If not
enabled the resulting binary size remains unchanged. If enabled the
binary size increases by about 3kB.
[1] previous submissions:
RFC: https://www.mail-archive.com/[email protected]/msg565945.html
v1: https://www.mail-archive.com/[email protected]/msg569472.html
v2: https://www.mail-archive.com/[email protected]/msg570599.html
v3: https://www.mail-archive.com/[email protected]/msg573223.html
v4: https://www.mail-archive.com/[email protected]/msg574000.html
[2] flat-image-tree dm-verity node spec:
https://github.com/open-source-firmware/flat-image-tree/commit/795fd5fd7f0121d0cb03efb1900aafc61c704771
Link: https://lore.kernel.org/r/[email protected]
|
|
Add documentation for CONFIG_FIT_VERITY which allows U-Boot to
construct dm-mod.create= and dm-mod.waitfor= kernel command-line
parameters from dm-verity metadata embedded in FIT filesystem
sub-images.
The new document covers the relationship between FIT loadable indices
and the /dev/fitN block devices that the Linux uImage.FIT block driver
creates, provides a complete .its example with a dm-verity-protected
SquashFS root filesystem, describes all required and optional dm-verity
subnode properties and explains how mkimage generates the verity
metadata automatically.
dm-verity is only supported for external-data FIT images (mkimage -E);
mkimage aborts with an error if the flag is omitted.
Signed-off-by: Daniel Golle <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
"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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Quentin Schulz <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Add help text about '-edl' option to reset command definition and
related documentation.
Reviewed-by: Casey Connolly <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Signed-off-by: Varadarajan Narayanan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Casey Connolly <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
|
|
The requirement that .dtbos have load addresses in the FIT image
vanished five years ago with
4c531d9f58b ("fit: Load DTO into temporary buffer and ignore load address")
Fix the documentation accordingly.
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
Use "parameters have been set" and "they need" for correct grammar
in the pstore documentation.
Signed-off-by: Aristo Chen <[email protected]>
|
|
Commit 488445cefa1 ("doc: Move FIT into its own directory") moved the
documentation in doc/uImage.FIT to doc/usage/fit, subsequently all
documents and example sources have been converted to reStructuredText.
Fix (almost) all of the remaining occurrences of the old path and
filenames across the tree.
The exception is doc/uImage.FIT/command_syntax_extensions.txt which
apparently has been removed entirely, or at least I was unable to
locate where that document is now.
Signed-off-by: Daniel Golle <[email protected]>
|
|
Signed-off-by: Rasmus Villemoes <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
|
|
The hashed-nodes property in a FIT signature node lists which FDT paths
are included in the signature hash. It is intended as a hint so should
not be used for verification.
Add a function to build the node list from scratch by iterating the
configuration's image references. Skip properties known not to be image
references. For each image, collect the path plus all hash and cipher
subnodes.
Use the new function in fit_config_check_sig() instead of reading
'hashed-nodes'.
Update the test_vboot kernel@ test case: fit_check_sign now catches the
attack at signature-verification time (the @-suffixed node is hashed
instead of the real one, causing a mismatch) rather than at
fit_check_format() time.
Update the docs to cover this. The FIT spec can be updated separately.
Signed-off-by: Simon Glass <[email protected]>
Closes: https://lore.kernel.org/u-boot/[email protected]/
Reported-by: Apple Security Engineering and Architecture (SEAR)
Tested-by: Tom Rini <[email protected]>
|
|
add documentation for sm3sum command.
Signed-off-by: Heiko Schocher <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Add documentation for memsize command.
Signed-off-by: Frank Wunderlich <[email protected]>
|
|
bdinfo may also have -a, -e and -m options depending on some symbols
being set. Document all this and provide an example on how to use them
and what they typically output.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
The devicetree, current eth and IP addr info are only available when
certain symbols are defined, so let's make the dependencies explicit.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
This pull request brings together a set of fixes and enhancements across
the SoCFPGA platform family, with a focus on MMC/SPL robustness, EFI
boot enablement, and Agilex5 SD/eMMC support.
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/28776
Highlights:
*
SPL / MMC:
o
Fix Kconfig handling for
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
o
Correct raw sector calculations and respect explicit sector values
when loading U-Boot from MMC in SPL
o
Adjust raw MMC loading logic for SoCFPGA platforms
*
EFI boot:
o
Permit EFI booting on SoCFPGA platforms
o
Disable mkeficapsule tool build for Arria 10 where unsupported
*
Agilex5:
o
Upgrade SDHCI controller from SD4HC to SD6HC
o
Enable MMC and Cadence SDHCI support in defconfig
o
Add dedicated eMMC device tree and defconfig for Agilex5 SoCDK
o
Revert incorrect GPIO configuration for SDIO_SEL
o
Refine U-Boot DT handling for SD and eMMC boot variants
*
SPI:
o
Allow disabling the DesignWare SPI driver in SPL via Kconfig
*
Board / configuration fixes:
o
Enable random MAC address generation for Cyclone V
o
Fix DE0-Nano-SoC boot configuration
o
Remove obsolete or conflicting options from multiple legacy
SoCFPGA defconfigs
|
|
Signed-off-by: Jonathan GUILLOT <[email protected]>
Fixes: ff6ef4b9093f ("doc: man-page for the part command")
Reviewed-by: Quentin Schulz <[email protected]>
|
|
cmd doc"
Quentin Schulz <[email protected]> says:
u-boot,boot-led and u-boot,error-led aren't actually handled by some
generic code but rather by board or architecture specific code. They
also aren't properties that are part of the official dt-binding so they
cannot be upstreamed. For u-boot,boot-led, there's actually a proper
replacement which is /options/u-boot/boot-led[1] (+ CONFIG_LED_BOOT=y).
For Rockchip boards, either nothing (for RK3066, PX30 and RK3399) was
using that property or (for RK3188) the code handling it was guarded by
symbols that were not enabled in the defconfig. For those, the property
and guarded code are removed.
For the Sam9x60 Curiosity, it seems that even though the LED is
controlled whenever CONFIG_LED is enabled, it isn't enabled by default
in the defconfig (but the code was added without modifying the
defconfig, explicitly leaving a choice to the user). I decided to keep
that feature by simply migrating it to the new API, though I cannot test
it as I do not own the device.
The STM32 boards will be migrated in the near future once their upstream
(kernel) Device Trees gain the new way to specify this (via
/options/u-boot/boot-led). I'll let Patrice handle this, see
https://lore.kernel.org/u-boot/[email protected]/
and
https://lore.kernel.org/u-boot/[email protected]/
After this, only one user of u-boot,boot-led will be left, based on
STM32: board/dhelectronics/dh_stm32mp1/board.c. @Patrice, maybe that's
something you want to have a look at as well, this seems to be some
evaluation kit?
The only users of u-boot,error-led are STM32 boards, so I'll leave this
to Patrice as well, I do not know what's the way to go for that one.
In any case, I would like to not encourage people to use out-of-spec DT
properties when there is another option (u-boot,boot-led), so I remove
the properties from the dt-binding document from U-Boot.
The help text for the blink subcommand of the led command was misleading
so this is now fixed.
This also moves the content of doc/README.LED into the doc/api/led.rst,
while clearly stating one shouldn't be using this anymore.
This also gets rid of dt-binding that we already have in dts/upstream.
Finally, this adds documentation for the led shell command.
[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116
Link: https://lore.kernel.org/r/[email protected]
|
|
This adds documentation on how to use the led shell command.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
This is a natural buddy to the existing "part number", allowing one to
get the partition name for a given partition number.
Acked-by: Quentin Schulz <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Quentin Schuloz <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
|
|
Update the command to show the size and selected file, since this is
useful information at times. Add a heading so it is clear what each
field refers to.
Add a simple test as well.
Signed-off-by: Simon Glass <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
OPTEE-OS on ARMv7a"
This series from Marek Vasut <[email protected]> brings some
enhancements to use cases using OPTEE-OS on ARMv7a platforms, some of
which already existed on ARMv8.
Link: https://lore.kernel.org/r/[email protected]
|
|
Add support for jumping to Linux kernel through OPTEE-OS on ARMv7a.
This is only supported if U-Boot runs in PL1 secure. This change adds
two components, one is fitImage OPTEE-OS loadable handler, which makes
a note of OPTEE-OS being loaded and stores the load address for later
jump to it. The second part is the actual jump to Linux through OPTEE-OS.
The jump through OPTEE-OS requires set up of multiple CPU registers, r1
and r2 are passed through, r0 and r3 have to be set to 0, lr is set to
Linux kernel entry point. This setup is done by new assembler function
boot_jump_linux_via_optee().
The boot_jump_linux_via_optee() also includes STM32MP13xx late TZC
configuration write, this cannot be moved easily, hence the ifdef.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Add documentation for rproc cmd usage.
Signed-off-by: Peng Fan <[email protected]>
|
|
to boot flows"
Kory Maincent (TI.com) <[email protected]> says:
This series converts the extension board framework to use UCLASS as
requested by Simon Glass, then adds extension support to pxe_utils
and bootmeth_efi (not tested) to enable extension boards devicetree load
in the standard boot process.
I can't test the imx8 extension scan enabled by the
imx8mm-cl-iot-gate_defconfig as I don't have this board.
I also can't test the efi bootmeth change as I don't have such board.
Link: https://lore.kernel.org/r/20251030-feature_sysboot_extension_board-v5-0-cfb77672fc68@bootlin.com
|
