From patchwork Sat Aug 12 00:06:02 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sam Edwards X-Patchwork-Id: 1820444 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=SwUCC86y; dkim-atps=neutral Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4RN1Cz1yRRz1yf2 for ; Sat, 12 Aug 2023 10:06:23 +1000 (AEST) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 834538694E; Sat, 12 Aug 2023 02:06:20 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="SwUCC86y"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1B9FE8694B; Sat, 12 Aug 2023 02:06:19 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 0466986915 for ; Sat, 12 Aug 2023 02:06:17 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=cfsworks@gmail.com Received: by mail-ot1-x335.google.com with SMTP id 46e09a7af769-6bd3317144fso832863a34.1 for ; Fri, 11 Aug 2023 17:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691798775; x=1692403575; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=8Eh4YZRRA2xcncuMEJNfjX1xYF6Y+QS450BPvUof+ko=; b=SwUCC86yu4EpbKQTc8IR8dVA4fu3Ir+KM7oWo81xKFONljiPocN6PJwdgwfdkiA1wH SgQIE8z9dkGsljH2dw8DKcLu6wq884CHr2NKIAit4EQ8rX5958ogVqIVqsz+FS9fUrpO H18uHBsLcTFhDOlV3FZWHOj+KV4ZWSCwJ1pCd27rujPwLkWXTpDZNII2mzsODbKDePA7 APQViO5avs1GbyxH7nI1+/jn259YQSs7i0lmblBeyqlaAVKDfv1FCQUbePEMRA4XbD1U jg9prkzz+1MUBG+OIBI8wKADQebedGW+BvTLC9Pqt7jnJ+9JvibF+o5AJGGT9XUGMgT6 6r7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691798775; x=1692403575; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8Eh4YZRRA2xcncuMEJNfjX1xYF6Y+QS450BPvUof+ko=; b=Q4U8kuGvIp1JjA3nWhElaf/ar7ekgBTxMU47ZoKp4qmS8QvCHAJAxw0khPOs8WS3b0 XR0+ZLx1sbR2VTRFm6aQZMFHosjjiVvAVucZx1lqvk3InH4SdKfbGWEEHnFdBdosnIAz lpZoaqpHfzuL+hdWYj/y3+IbM7i5kFgtRRW5whIZsEjZiQTnWk72k0PK8xS6tXCBhV2p NJbNbgWjN8CQHKfEb7KmezCInq+jLYEcZ0QJDahefhmJWUoLJaVLjFW8RmfTw6gCzU4Z b0vnavZ7YuLUVfWFIdjRYjQaNyrHeX1yF4AA7oCKsPZperDCwXUW9joOEqLBYhkRfFis hl7w== X-Gm-Message-State: AOJu0YzoQ7QWhtUN1DLXPV+/wUXwWz+T9Kv38FNbcJSyIo5ZWApXnQXT Ds2Y51zA7X/fuzvfnquW1O0= X-Google-Smtp-Source: AGHT+IEji0HgVuW7h0IJsg6ASIyHZn2etT8BicVnwSzuuaubdBYl+H+qqC/Yvrrc+IKuwXGrOzGRQQ== X-Received: by 2002:a9d:67c3:0:b0:6bd:be5:daa2 with SMTP id c3-20020a9d67c3000000b006bd0be5daa2mr3343758otn.33.1691798775398; Fri, 11 Aug 2023 17:06:15 -0700 (PDT) Received: from celestia.nettie.lan (static-198-54-134-172.cust.tzulo.com. [198.54.134.172]) by smtp.gmail.com with ESMTPSA id x16-20020a62fb10000000b00686bef8e55csm3848834pfm.39.2023.08.11.17.06.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Aug 2023 17:06:14 -0700 (PDT) From: Sam Edwards X-Google-Original-From: Sam Edwards To: Heiko Schocher , Kyungmin Park Cc: u-boot@lists.denx.de, Sam Edwards Subject: [RFC PATCH 0/4] mtd: ubi: Enable accessing RO filesystems in UBI vols Date: Fri, 11 Aug 2023 18:06:02 -0600 Message-ID: <20230812000606.72319-1-CFSworks@gmail.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 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 Hi UBI maintainers, My target's rootfs is a read-only filesystem stored in a static UBI volume, mounted via a "ubiblock" device after boot. I'd also like to keep the boot files in the same filesystem, so that it's all coupled together. To that end, I'm working on a patchset so that U-Boot can read static UBI volumes as read-only block devices (paralleling Linux's ubiblock mechanism). I'm very happy with how the first 3 patches in this series turned out (so I'm not asking about them per se, though feedback is certainly welcome). The fourth is where I got stuck: while the code definitely works, it requires bringing DM headers into disk/part.c, which certainly will not fly in mainline. I need to plumb this through drivers/block/blk-uclass.c to do it "properly." Part of the problem here is that these are *volumes,* but they are (optionally) *named.* In U-Boot's current view of block devices, it is only a partition, and not a volume, that may have a name. These aren't "partitions" in U-Boot's view, since a partition is a contiguous slice of a bigger block device, while these are (logically) separate block devices. So, I would need to invent a new function that can look up a named (sub)volume. I also probably need to invent new syntax, so that I'm not overloading the 0:1 syntax for partitions. I'm not especially beholden to the ':', but I do want to use the same syntax for volume numbers and volume names, to mirror Linux's `ubi.block=x,y` syntax. I'm also trying to reclaim the name "ubi" to refer to a UBI volume, while U-Boot currently thinks it should refer to the presently-mounted UBIFS. In my current series, the meaning of "ubi" depends on whether ubifs is mounted, for backwards-compatibility. If this isn't palpable, I could consider other options like "ubivol"/"ubiblock"/"ubiblk"/"ubistatic"/... So, the feedback I'm hoping for would be: 1) What is a good syntax for referring to a logical volume by name or ID? Keeping in mind this may affect more than just UBI, if e.g. U-Boot learns to peer inside LVM2s in the future. 2) What should I call the block functions for looking up a block device's subvolume by type+parentidx+{name,ID}? 3) Is my strategy of reclaiming "ubi" sound, or should I be conceding that to UBIFS and using a new type name for static UBI volumes? 4) Does my choose_blksz_for_volume() function make sense, or should I always be using a preferred block size (like 512) if possible? Cheers, Sam Sam Edwards (4): mtd: ubi: register UBI attachments as DM devices mtd: ubi: bind block device driver for static volumes disk: part: fall-through if "ubi" requested but ubifs not mounted HACK: enable access to `ubi 0:volname` block devices cmd/ubi.c | 11 +++ disk/part.c | 70 +++++++++++-- drivers/mtd/ubi/Makefile | 1 + drivers/mtd/ubi/ubi-uclass.c | 184 +++++++++++++++++++++++++++++++++++ include/dm/uclass-id.h | 1 + include/ubi_uboot.h | 5 + 6 files changed, 264 insertions(+), 8 deletions(-) create mode 100644 drivers/mtd/ubi/ubi-uclass.c