On 2/23/26 22:30, 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") > There is the block storage abstraction for mtd devices as well.
> >>>> Or did you mean the to-be-create UCLASS_IMAGE_MAPPER? >>> No I was talking about ubi. >>> >>> Regards, >>> Simon
