[PATCH v2 0/7] fit: dm-verity support

[Marek Vasut]

On 4/23/26 3:20 PM, Daniel Golle wrote:
> On Thu, Apr 23, 2026 at 02:59:19PM +0200, Rasmus Villemoes wrote:
>> On Thu, Apr 16 2026, Daniel Golle <daniel at makrotopia.org> 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,
>>
>> Can you show me where that fitblk driver lives, because I can't find
>> anything like that in the linux source code. Grepping for 'fitblk' or
>> 'dev/fit' turns up nothing.
> 
> The driver is currently downstream, but going to be (re-)submitted upsteam.
> See below for more.
> 
>>
>>> ...), the goal is that the bootloader never even copies it to RAM.
>>
>> Hm, how is that achieved? I.e., how do you load and boot the FIT image
>> without loading that part, but still reading in e.g. the kernel?
> 
> The next series after this is going to suggest a way for on-demand
> loading only the actually necessary FIT images from a storage backend.
> See
> https://github.com/u-boot/u-boot/pull/870

This should be posted on the ML, see .github/pull_request_template.md :

"
Please do not submit a Pull Request via github.  Our project makes use of
mailing lists for patch submission and review.  For more details please
see https://u-boot.readthedocs.io/en/latest/develop/sending_patches.html
"

That said, U-Boot SPL already handles on-demand loading of parts of 
fitImages generated with mkimage -E (fitImage with external data). There 
is no need to reinvent the wheel.