From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 74262EEC2B3 for ; Tue, 24 Feb 2026 00:13:32 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 789BA83642; Tue, 24 Feb 2026 01:13:30 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 458BE83935; Tue, 24 Feb 2026 01:13:29 +0100 (CET) Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [IPv6:2a07:2ec0:3002::65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 989AE8063E for ; Tue, 24 Feb 2026 01:13:26 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=daniel@makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.99) (envelope-from ) id 1vug2n-000000001Qu-1JFR; Tue, 24 Feb 2026 00:12:53 +0000 Date: Tue, 24 Feb 2026 00:12:48 +0000 From: Daniel Golle To: Mikhail Kshevetskiy Cc: Simon Glass , Tom Rini , Quentin Schulz , Kory Maincent , Mattijs Korpershoek , Martin Schwan , Anshul Dalal , Ilias Apalodimas , Sughosh Ganu , Aristo Chen , =?utf-8?B?54mbIOW/l+Wujw==?= , Marek Vasut , Heinrich Schuchardt , Wolfgang Wallner , Frank Wunderlich , David Lechner , Osama Abdelkader , Michael Trimarchi , Miquel Raynal , Andrew Goodbody , Yegor Yefremov , Mike Looijmans , Weijie Gao , Alexander Stein , Neil Armstrong , Mayuresh Chitale , Paul HENRYS , u-boot@lists.denx.de, John Crispin , Paul Spooren Subject: Re: [RFC PATCH 08/20] boot: image-loader: add UBI volume backend Message-ID: References: <47725c58588200f631c918a56b770454d5721954.1771275704.git.daniel@makrotopia.org> <64a12e61-8e04-472e-8493-90b2e4a41d50@iopsys.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <64a12e61-8e04-472e-8493-90b2e4a41d50@iopsys.eu> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean 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 ;)