On Tue, Feb 24, 2026 at 03:40:47AM +0300, Mikhail Kshevetskiy wrote:
>
> On 2/24/26 03:12, Daniel Golle wrote:
> > 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.
>
> what about querying available partitions using the command 'read' way?
Please explain how you imagine that to work. I mean, sure, we can read
them, and then we know that they contain an uImage.FIT.
mtdblock and ubiblock devices are generally whole-disk devices, each
representing the backing MTD partition or UBI volume.
So first of all, ubiblock devices in U-Boot only exist for already
attached UBI devices, and only one UBI devices can be attached at a
time.
Apart from that problem (which would limit bootmeth_openwrt to operate
on exactly one, and already attached UBI device, which is unfortunate,
but not a complete show-stopper), there are often more than one UBI
volumes holding an uImage.FIT blob. They can be identified by the
out-of-band metadata, ie. the UBI volume name (or MTD partition label),
typically "production" and "recovery", you get the idea, right?
They **cannot** be identified by inband metadata (ie. anything you could
read from inside that volume). While (in theory) we could add metadata
to identify and distinguis "production" from "recovery" images, this
(by definition) isn't possible in case of a symmetric A/B dual boot
arrangement. Also, what I'm creating here is not a new design from
scratch, but rather the formalization of a historically grown
reality, present on countless consumer-grade devices out there.
Making fundamental changes to the design (such as carrying additional
metadata within the firmware image itself, instead of relying on
out-of-band metadata like the MTD partition label or UBI volume name)
will make the newly introduced bootmeth_openwrt de-facto incompatible
with all existing OpenWrt devices out there -- and compatibility is an
important part and purpose of the exercise.
Hence, the user (or the bootmeth) need to identify which of the available
UBI volumes or MTD partitions the system should boot from, and do so
using aforementioned out-of-band, storage-type-specific metadata.
Now, assuming that I'd have to use the ubiblock (for example), the only
way to get back to those crucial bits of metadata would be to traverse
from the blk device to the parent udevice, checking whether it's of type
UCLASS_MTD and if the blk's type is part_type PART_TYPE_UBI, and then
interpreting block_dev->hwpart as the volume name. Imho that's an overly
intrusive operation, messing with the block_dev and ubi subsystem
internals which should not be touched from outside of the respective
subsystems.
For mtdblock devices it's even much worse, I'd have to cast bdev's priv
back into struct mtd_info in order to get to the partition label, and
that feels extremely wrong (arguably, we could patch mtdblock.c to also
set the hwpart string, but even that would still be more of a hack than
actually being correct imho).
>
> > 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 ;)
