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?
> 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 ;)
