On Mon, Feb 23, 2026 at 10:30:03PM +0300, Mikhail Kshevetskiy wrote: > > On 2/23/26 22:24, Daniel Golle wrote: > > On Mon, Feb 23, 2026 at 10:51:09AM -0700, Simon Glass wrote: > >> Hi Daniel, > >> > >> On Thu, 19 Feb 2026 at 09:51, Daniel Golle <[email protected]> wrote: > >>> On Thu, Feb 19, 2026 at 06:09:27AM -0700, Simon Glass wrote: > >>>> Hi Daniel, > >>>> > >>>> On Mon, 16 Feb 2026 at 14:22, Daniel Golle <[email protected]> wrote: > >>>>> Add a UBI volume storage backend for the image_loader framework. > >>>>> > >>>>> image_loader_init_ubi() takes a volume name, ensures the UBI device > >>>>> is attached (auto-attaching if needed), and installs a .read() callback > >>>>> wrapping ubi_volume_read(). > >>>>> > >>>>> Auto-attach works by scanning the device tree for the first MTD > >>>>> partition with compatible = "linux,ubi", then calling ubi_part() on > >>>>> that partition. The partition name is resolved using the same > >>>>> precedence as the MTD partition parser: the "label" property first, > >>>>> then "name", then the node name. Since U-Boot only supports a single > >>>>> attached UBI device at a time, only the first matching partition is > >>>>> used. If a UBI device is already attached, the auto-attach step is > >>>>> skipped. > >>>>> > >>>>> UBI handles bad-block management and wear leveling internally, so the > >>>>> read callback is a straightforward passthrough. Note that > >>>>> ubi_volume_read() returns positive errno values; the wrapper negates > >>>>> them for the image_loader convention. > >>>>> > >>>>> Gated by CONFIG_IMAGE_LOADER_UBI (depends on CMD_UBI && IMAGE_LOADER). > >>>>> > >>>>> Signed-off-by: Daniel Golle <[email protected]> > >>>>> --- > >>>>> boot/Kconfig | 8 +++ > >>>>> boot/Makefile | 1 + > >>>>> boot/image-loader-ubi.c | 112 ++++++++++++++++++++++++++++++++++++++++ > >>>>> include/image-loader.h | 13 +++++ > >>>>> 4 files changed, 134 insertions(+) > >>>>> create mode 100644 boot/image-loader-ubi.c > >>>>> > >>>>> diff --git a/boot/Kconfig b/boot/Kconfig > >>>>> index 23848a0f57e..89832014af6 100644 > >>>>> --- a/boot/Kconfig > >>>>> +++ b/boot/Kconfig > >>>>> @@ -1203,6 +1203,14 @@ config IMAGE_LOADER_MTD > >>>>> parallel NAND, etc.) using the image_loader framework. > >>>>> NAND bad blocks are skipped transparently. > >>>>> > >>>>> +config IMAGE_LOADER_UBI > >>>>> + bool "UBI volume backend for image loader" > >>>>> + depends on IMAGE_LOADER && CMD_UBI > >>>>> + help > >>>>> + Allows loading images from UBI volumes using the image_loader > >>>>> + framework. Auto-attaches the UBI device from the device tree > >>>>> + if not already attached. > >>>>> + > >>>>> config DISTRO_DEFAULTS > >>>>> bool "(deprecated) Script-based booting of Linux distributions" > >>>>> select CMDLINE > >>>>> diff --git a/boot/Makefile b/boot/Makefile > >>>>> index 1dde16db694..7d1d4a28106 100644 > >>>>> --- a/boot/Makefile > >>>>> +++ b/boot/Makefile > >>>>> @@ -76,6 +76,7 @@ obj-$(CONFIG_$(PHASE_)BOOTMETH_ANDROID) += > >>>>> bootmeth_android.o > >>>>> obj-$(CONFIG_IMAGE_LOADER) += image-loader.o > >>>>> obj-$(CONFIG_IMAGE_LOADER_BLK) += image-loader-blk.o > >>>>> obj-$(CONFIG_IMAGE_LOADER_MTD) += image-loader-mtd.o > >>>>> +obj-$(CONFIG_IMAGE_LOADER_UBI) += image-loader-ubi.o > >>>>> > >>>>> obj-$(CONFIG_$(PHASE_)BOOTMETH_VBE_ABREC) += vbe_abrec.o vbe_common.o > >>>>> obj-$(CONFIG_$(PHASE_)BOOTMETH_VBE_ABREC_FW) += vbe_abrec_fw.o > >>>>> diff --git a/boot/image-loader-ubi.c b/boot/image-loader-ubi.c > >>>>> new file mode 100644 > >>>>> index 00000000000..64901a13378 > >>>>> --- /dev/null > >>>>> +++ b/boot/image-loader-ubi.c > >>>>> @@ -0,0 +1,112 @@ > >>>>> +// SPDX-License-Identifier: GPL-2.0+ > >>>>> +/* > >>>>> + * UBI volume backend for image_loader > >>>>> + * > >>>>> + * Copyright (C) 2026 Daniel Golle <[email protected]> > >>>>> + */ > >>>>> + > >>>>> +#include <dm/ofnode.h> > >>>>> +#include <image-loader.h> > >>>>> +#include <log.h> > >>>>> +#include <malloc.h> > >>>>> +#include <mtd.h> > >>>>> +#include <ubi_uboot.h> > >>>>> + > >>>>> +struct image_loader_ubi_priv { > >>>>> + char *vol_name; > >>>>> +}; > >>>>> + > >>>>> +/** > >>>>> + * ubi_auto_attach() - attach UBI if not already attached > >>>>> + * > >>>>> + * If no UBI device is currently attached, walk the device tree for the > >>>>> + * first MTD partition node with compatible = "linux,ubi", find the > >>>>> + * corresponding MTD device by matching flash_node, and attach UBI to > >>>>> + * it via ubi_part_from_mtd(). > >>>>> + * > >>>>> + * Since U-Boot only supports a single attached UBI device at a time, > >>>>> + * only the first matching partition is used. > >>>>> + * > >>>>> + * Return: 0 on success or if already attached, negative errno on > >>>>> failure > >>>>> + */ > >>>>> +static int ubi_auto_attach(void) > >>>>> +{ > >>>>> + struct mtd_info *mtd; > >>>>> + ofnode node; > >>>>> + > >>>>> + /* Already attached? */ > >>>>> + if (ubi_devices[0]) > >>>>> + return 0; > >>>>> + > >>>>> + mtd_probe_devices(); > >>>> This should be handled by your new ubi driver for your uclass. > >>>> > >>>>> + > >>>>> + ofnode_for_each_compatible_node(node, "linux,ubi") { > >>>>> + mtd_for_each_device(mtd) { > >>>>> + if (ofnode_equal(mtd->flash_node, node)) > >>>>> + goto found; > >>>>> + } > >>>>> + } > >>>> Eek this is really strange. There should be a device so you can use > >>>> uclass_first_device(UCLASS_...). > >>> I carefully considered turning UBI devices into a UCLASS, but it would > >>> be a huge major rewrite of how UBI works in U-Boot, and while that would > >>> be a good thing to do, I consider far beyond the scope of supporting a > >>> boot method for OpenWrt. > >> Oh, I just assumed it supports driver model. But surely it must have a > >> UCLASS_BLK device? > > Sadly no. Neither UBI devices nor UBI volumes are block storage devices. > > > > Every UBI device does have a UCLASS_MTD parent device, but that > > obviously also doesn't uniquely identify the partition on the flash chip > > which is used as UBI device -- there can be (and sometimes are, for > > dual-boot/redundancy reasons) multiple UBI devices in different > > partitions on the same flash. > > > > What I ended up doing now is to move more of the UBI detection and > > enumeration logic into ubi_bootdev.c and have imagemap-ubi.c rely > > on getting the MTD device and partition index from there. > > There are UBI based block storage emulation, see CONFIG_UBI_BLOCK > commits: > * 9daad11ad178646c288aca3615a7ba1e6039aed3 ("drivers: introduce UBI > block abstraction") > * aa5b67ce226267440e64fadc57d3a21e5842027c ("disk: support UBI partitions")
Yes, but that also only works once the UBI device is already attached. Before that, and for any UBI device not currently attached, there aren't any UBI_BLOCK devices. However, in both cases we'd also need to scan them for volumes to be presented as potential bootdevs.
