On Thu, May 07, 2026 at 05:40:15PM +0100, Daniel Golle wrote: > 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.
So one thing is that sandbox needs to enable this, so that CI can run the tests (and we can see the tests run, and there's no new warnings, etc). That can be a follow-up and not a full respin, pending other feedback. -- Tom
signature.asc
Description: PGP signature
