On Mon, Feb 23, 2026 at 10:32:32PM +0300, Mikhail Kshevetskiy wrote:
>
> On 2/23/26 22:30, Mikhail Kshevetskiy wrote:
> > There are UBI based block storage emulation, see CONFIG_UBI_BLOCK
> > commits:
> > * 9daad11ad178646c288aca3615a7ba1e6039aed3 ("drivers: introduce UBI
> > block abstraction")
> > * aa5b67ce226267440e64fadc57d3a21e5842027c ("disk: support UBI partitions")
> >
> There is the block storage abstraction for mtd devices as well.
During my evening walk outside I thought about this a bit more, and if
it would be possible to use the ubiblock and mtdblock devices instead of
introducing dedicated bootdevs and imagemap backends for both of them.
In the simple case of only a single boot option this would probably
work: bootmeth_openwrt detects the uImage.FIT on the raw block device
and may go ahead, load and launch it.
However, there is often more than one of them. And as they are stored in
directly on MTD partitions or UBI volumes, knowing the name of the
partition or volume, and which device it sits on is crucial for
bootmeth_openwrt, which should support also complex multi-slot dual-boot
arrangement, typically identifying the slots by UBI volume name or MTD
partition name. When using the mtdblock or ubiblock devices this
information is hidden, and can only be accessed in a very tricky way,
especially for ubiblock devices, which lack a device parent. Matching
the UCLASS type of the device parent of a block device in the bootmeth
also feels sketchy and inappropriate.
So while having mtdblock and ubiblock devices is generally nice,
especially if U-Boot has to access a filesystem (eg. squashfs) stored on
them, for the case of OpenWrt it would at least be a bit ugly, as the
metadata of the actual storage backend (MTD or UBI) is crucial. We need
the UBI volume name or the label of the MTD partition.
In a way you could say that OpenWrt uses block devices (eg. MMC) it
boots from more like MTD, and not the other way around. And in some way,
bootmeth_openwrt will do some extra lifting when started on a block
device (extract the GPT partition name and present it as the bootflow's
fname), while the imagemap API provides an abstraction to read raw
images from all three storage backends (blk, mtd, ubi).
That being said, I'm happy we have overcome things like block2mtd or
gluebi, and do use the appropriate APIs (and filesystem types) on each
class of storage devices in OpenWrt nowadays. Some of the helpful
patterns borrowed from our MTD and UBI boot flows (avoiding a boot
filesystem, identifying storage volumes, ...) remain, however, and are
applied equally also on block storage (ie. MMC).
tl;dr: We'd rather use block2mtd than using mtdblock ;)
