u-boot.git/include, branch next

Merge patch series "fit: dm-verity support"

2026-05-27T19:44:20+00:00

Daniel Golle  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/u-boot@lists.denx.de/msg565945.html
    v1:  https://www.mail-archive.com/u-boot@lists.denx.de/msg569472.html
    v2:  https://www.mail-archive.com/u-boot@lists.denx.de/msg570599.html
    v3:  https://www.mail-archive.com/u-boot@lists.denx.de/msg573223.html
    v4:  https://www.mail-archive.com/u-boot@lists.denx.de/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/cover.1778887196.git.daniel@makrotopia.org

tools: mkimage: add dm-verity Merkle-tree generation

2026-05-27T19:41:33+00:00

When mkimage encounters a dm-verity subnode inside a component image
node it now automatically invokes veritysetup(8) with --no-superblock
to generate the Merkle hash tree, screen-scrapes the Root hash and Salt
from the tool output, and writes the computed properties back into the
FIT blob.

The user only needs to specify algorithm, data-block-size, and
hash-block-size in the ITS; mkimage fills in digest, salt,
num-data-blocks, and hash-start-block. Because --no-superblock is
used, hash-start-block equals num-data-blocks with no off-by-one.

The image data property is replaced with the expanded content (original
data followed directly by the hash tree) so that subsequent hash and
signature subnodes operate on the complete image.

fit_image_add_verification_data() is restructured into two passes:
dm-verity first (may grow data), then hashes and signatures.

Signed-off-by: Daniel Golle 
Reviewed-by: Simon Glass

include: hexdump: make hex2bin() usable from host tools

2026-05-27T19:41:33+00:00

Make hexdump.h work in host-tool builds by using 'uint8_t' instead
of 'u8', and including either user-space libc  for host-tools
or  when building U-Boot itself.

Signed-off-by: Daniel Golle 
Reviewed-by: Simon Glass

boot: fit: support generating DM verity cmdline parameters

2026-05-27T19:41:33+00:00

Add fit_verity_build_cmdline(): when a FILESYSTEM loadable carries a
dm-verity subnode, construct the dm-mod.create= kernel cmdline parameter
from the verity metadata (block-size, data-blocks, algo, root-hash,
salt) and append it to bootargs.

Also add dm-mod.waitfor=/dev/fit0[,/dev/fitN] for each dm-verity device
so the kernel waits for the underlying FIT block device to appear before
setting up device-mapper targets. This is needed when the block driver
probes late, e.g. because it depends on NVMEM calibration data.

The dm-verity target references /dev/fitN where N is the loadable's
index in the configuration -- matching the order Linux's FIT block
driver assigns block devices.  hash-start-block is read directly from
the FIT dm-verity node; mkimage ensures its value equals num-data-blocks
by invoking veritysetup with --no-superblock.

Signed-off-by: Daniel Golle 
Reviewed-by: Simon Glass

image: fit: add dm-verity property name constants

2026-05-27T19:41:33+00:00

Add FIT_VERITY_NODENAME and the complete set of FIT_VERITY_*_PROP
constants for the dm-verity child node of filesystem-type images, plus
the five optional boolean error-handling property names aligned with the
flat-image-tree specification.

Signed-off-by: Daniel Golle 
Reviewed-by: Simon Glass 
Reviewed-by: Tom Rini

Merge patch series "env: migrate static flags list to Kconfig"

2026-05-25T19:44:45+00:00

This series from James Hilliard  converts the
static flags list for the environment to be configured via Kconfig and
updates the documentation.

Link: https://lore.kernel.org/r/20260511182036.50453-1-james.hilliard1@gmail.com

env: migrate static flags list to Kconfig

2026-05-25T19:44:40+00:00

Environment callbacks can already be configured from Kconfig with
CONFIG_ENV_CALLBACK_LIST_STATIC, but static environment flags still
require board headers to define CFG_ENV_FLAGS_LIST_STATIC.

Add CONFIG_ENV_FLAGS_LIST_STATIC and use it as the only board-provided
static environment flags list. Convert the remaining default-config users
from CFG_ENV_FLAGS_LIST_STATIC to defconfig settings and drop the legacy
header macro from ENV_FLAGS_LIST_STATIC.

Move the environment flags format documentation out of README and into
the developer environment documentation. Include the format in the
Kconfig help as well.

This lets boards configure writeable-list policy and type validation
from defconfig without adding a config header solely for env flags.

This preserves the behavior of default configs. Header-only cases that
were inactive in upstream defconfigs are not converted into defconfig
entries: iot2050 can add its list when enabling ENV_WRITEABLE_LIST, and
smegw01 can add mmcdev:dw support if the unlocked SYS_BOOT_LOCKED=n
configuration is needed.

Signed-off-by: James Hilliard 
Reviewed-by: Tom Rini 
Reviewed-by: Simon Glass 
Reviewed-by: Alexander Sverdlin 
Reviewed-by: Walter Schweizer

cros_ec: Sync ec_commands.h from upstream Chrome OS EC

2026-05-25T19:43:31+00:00

Sync include/ec_commands.h from upstream commit 4f3d17aa34
("skywalker: set SLEEP_TIMEOUT_MS to 50 seconds"). The new file makes
two build assumptions that do not hold for U-Boot.

It hides '' from __KERNEL__ builds, leaving UINT16_MAX
(used by EC_RES_MAX) undefined for U-Boot; widen the gate to
'!defined(__KERNEL__) || defined(__UBOOT__)'

It gates '' on '#ifdef __KERNEL__'; the matching
'#else' branch defines BIT()/BIT_ULL()/GENMASK()/GENMASK_ULL()
locally, assuming kernel headers provide those macros otherwise.
U-Boot defines __KERNEL__ too but has no . Nest a
'!defined(__UBOOT__)' check around the include so the __UBOOT__ path
stays in the __KERNEL__ branch (no local BIT/GENMASK defines), which
avoids redefinition warnings against U-Boot's linux/bitops.h. Pull
in linux/bitops.h up front for U-Boot so the file's own BIT() and
GENMASK() uses still resolve.

Adapt callers to two interface changes. The 'ec_current_image' enum
tag is now 'ec_image' (EC_IMAGE_* constants unchanged); rename it in
affected files to match. The VBNV-context interface was dropped
upstream, but it still used in lab Chromebooks; keep those constants and
structs in cros_ec.h

Likewise, MEC_EMI_BASE and MEC_EMI_SIZE are a U-Boot-local addition to
ec_commands.h that the upstream sync removes; preserve them in cros_ec.h
next to the VBNV block, and switch the only consumer
(arch/x86/cpu/apollolake/cpu_spl.c) to include cros_ec.h

Signed-off-by: Simon Glass

Merge tag 'v2026.07-rc3' into next

2026-05-25T17:35:35+00:00

Prepare v2026.07-rc3

virtio: blk: Fix converting the vendor id to a string

2026-05-22T22:47:54+00:00

Currently we are trying to work out if the vendor id is from
a virtio-mmio device and then casting a u32 to a char* and using
it as a C-string. By chance there is usually a zero after the u32
and it works.

Since the vendor id we are trying to convert to a string is QEMU's
just define a value for the QEMU vendor id, check if the vendor
id matches and then use a predefined string for "QEMU".

I don't think we should have been assumming all virtio-mmio vendor
ids are printable ASCII chars in the first place so do this special
casing just for QEMU. If the vendor id isn't QEMU print the hex
value of it.

Reviewed-by: Simon Glass 
Reviewed-by: Kuan-Wei Chiu 
Signed-off-by: Daniel Palmer