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

[Daniel Golle]

On Sun, Apr 26, 2026 at 06:20:55PM +0200, Marek Vasut wrote:
> 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
> "

I of course had also posted it to the mailing list back then.
I just thought it'd be easier to look at it on Github than in the list
archive:

https://lists.denx.de/pipermail/u-boot/2026-February/610274.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.

This has been discussed in detail already when the RFC series was
posted:

https://lists.denx.de/pipermail/u-boot/2026-February/611074.html

tl;dr:
|> So there really isn't much overlap other than the fact that there is a
|> struct with a priv pointer and a .read callback, and even that uses a
|> different addressing parameter (sectors vs. bytes).