Message ID | 7526fc5a461a0d68eb1dab575f9c1950638fc21a.1668548123.git.daniel@makrotopia.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2957503wru; Tue, 15 Nov 2022 13:53:46 -0800 (PST) X-Google-Smtp-Source: AA0mqf5BXRGNI4kY2b9KD83rQCzT2Xg7fBZgK/YlElrpVyqiBKGAZcylYand37Spt5sOBpOUMcui X-Received: by 2002:a17:90b:394d:b0:212:b4a9:889f with SMTP id oe13-20020a17090b394d00b00212b4a9889fmr438203pjb.12.1668549226428; Tue, 15 Nov 2022 13:53:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668549226; cv=none; d=google.com; s=arc-20160816; b=TIpg3ujTN0gNN5M8/aQAzeXDrARnCgQiTRdDGWMszrnP94LqhqhOjtyK/sQWC7VEb8 +7LGXwHDU2/rRbBPOZCVjBBlN2qLJyNsKMo7LHh8fNeabJWEMpv9MDMORWrhh+vVi82q /Y2ztjqn/2DmmLtF6WdYtAplwHNx6EKhAQzDaAbvO813rrwfO/yMhonnoL8L5h8FtxnL gMhNKAXDStScuvKk0yc9+Pc9/6OypTdVTRJZKVdgdJFD0DA5k843ZqP/YVn0zHHvW2Gj QAZkLwDhbF0S/QJfMViKGL1pEno45qJgzpcMzUbnHJ8cTRokPVKqliFBFCrXQZlIOkYL pbGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:to:from:date; bh=hSZi5QRdPDDviI5ZDNgYy4bFj8rimMdXcbfby/fdbd0=; b=g4WKlgV7t5zeYyYYTlD03WYhqHH2R77+qf3rHCxKFmj5XjPbr7pvy9kWWEnbh747Qj mK410DASRyNj//bmz9xk8iOFomNC0ja+cs57fp4gv7Viq0R/aGtnoFL6nUJagAiYSgih qixmh0iQl91GVVJ3yxrxziIWDyqoL/MspP9JocwDMTAmlXBBP5tjYDUe9h63QyrXaF8H +U0D/j+2ggB29ZElExQohBXQxUe96f9dtTN6UX9aOnyo72gmrc95tKs3Qwh2bNHtlgWo JrwyIP9FYAf2IhWqqBcQfoplkoOtpFBrNQvJWyxtRK4KqqQetLPf30CM14XYegiZCMWX pG/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v191-20020a6389c8000000b0046ebb8fc292si13584295pgd.7.2022.11.15.13.53.31; Tue, 15 Nov 2022 13:53:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231628AbiKOVsu (ORCPT <rfc822;maxim.cournoyer@gmail.com> + 99 others); Tue, 15 Nov 2022 16:48:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231540AbiKOVsl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 15 Nov 2022 16:48:41 -0500 Received: from fudo.makrotopia.org (fudo.makrotopia.org [IPv6:2a07:2ec0:3002::71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18CD1B1EF; Tue, 15 Nov 2022 13:48:41 -0800 (PST) Received: from local by fudo.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.94.2) (envelope-from <daniel@makrotopia.org>) id 1ov3nD-0005Jl-C3; Tue, 15 Nov 2022 22:48:31 +0100 Date: Tue, 15 Nov 2022 21:47:06 +0000 From: Daniel Golle <daniel@makrotopia.org> To: Jens Axboe <axboe@kernel.dk>, Miquel Raynal <miquel.raynal@bootlin.com>, Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Matthew Wilcox <willy@infradead.org>, Daniel Golle <daniel@makrotopia.org>, "Martin K. Petersen" <martin.petersen@oracle.com>, Chaitanya Kulkarni <kch@nvidia.com>, Michal Orzel <michalorzel.eng@gmail.com>, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org Subject: [PATCH v5 3/4] partitions/efi: add support for uImage.FIT sub-partitions Message-ID: <7526fc5a461a0d68eb1dab575f9c1950638fc21a.1668548123.git.daniel@makrotopia.org> References: <cover.1668548123.git.daniel@makrotopia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <cover.1668548123.git.daniel@makrotopia.org> X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,PDS_OTHER_BAD_TLD, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749600673297699006?= X-GMAIL-MSGID: =?utf-8?q?1749600673297699006?= |
Series |
partition parser for U-Boot's uImage.FIT
|
|
Commit Message
Daniel Golle
Nov. 15, 2022, 9:47 p.m. UTC
Add new GUID allowing to parse uImage.FIT stored in a GPT partition
and map filesystem sub-image as sub-partitions.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
block/partitions/efi.c | 9 +++++++++
block/partitions/efi.h | 3 +++
2 files changed, 12 insertions(+)
Comments
On Tue, Nov 15, 2022 at 09:47:06PM +0000, Daniel Golle wrote: > Add new GUID allowing to parse uImage.FIT stored in a GPT partition > and map filesystem sub-image as sub-partitions. NAK, we should not go out from the partition code to parse random weird image formats. If you want to support uImage.FIT just write a tinty stackable block driver or dm table for it.
Hi Christoph, On Tue, Nov 15, 2022 at 10:01:05PM -0800, Christoph Hellwig wrote: > On Tue, Nov 15, 2022 at 09:47:06PM +0000, Daniel Golle wrote: > > Add new GUID allowing to parse uImage.FIT stored in a GPT partition > > and map filesystem sub-image as sub-partitions. > > NAK, we should not go out from the partition code to parse random > weird image formats. While weirdness is certainly subjective, uImage.FIT is not just a random image format but used by a great majority of headless embedded Linux devices out there. It's the default image format of many of the SDKs distributed by chip vendors such as Allwinner, Marvell, MediaTek, NXP, Qualcomm/Atheros, ... Having better support for it in Linux hence doesn't seem too far-fetched to me, especially given that we got partition parsers for all sorts of historic (Acorn, Amiga, Atari, ...) or actually exotic (Karma?) formats. Even Microsoft Windows' Logical Disk Manager is supported natively by the kernel... > If you want to support uImage.FIT just write a tiny stackable block > driver or dm table for it. As this is used on rather tiny embedded devices my hope was to keep things simple and not having to enable device mapper on systems which have anyway only very small amounts of storage and won't ever need most of the device mapper features. Using a tiny block driver instead is an option, I've implemented this approach in the past couple of hours and it works just as fine. In this case I would introduce a new kernel cmdline option allowing to specify which block device (ie. a partition on eMMC, or mtdblock or ubiblock device) to launch the uImage.FIT parser on. Allowing this new driver to add block partitions by exporting a new helper functions for that in block/partition/core.c would greatly simplify things, as then the existing partitioning code could still be used (instead of basically having to re-implement loopdev and introduce a whole new type of block devices). I will post an RFC series illustrating this approach. Please let me know if this sounds acceptable, so I won't put effort into implementing something which will then be rejected again after 5 iterations on the mailing list for reasons which could have been expressed from the beginning. An RFC for this series was posted on 2022-04-25 [1], I wouldn't have worked months to fix all requests of other maintainers and tested it on a variety of different hardware knowing that the whole approach will be NACK'ed... And, of course, thank you anyway for reviewing! Cheers Daniel [1]: https://patchwork.kernel.org/project/linux-block/list/?series=635369&state=*
On Thu, Nov 17, 2022 at 12:19:10AM +0000, Daniel Golle wrote: > While weirdness is certainly subjective, uImage.FIT is not just a > random image format but used by a great majority of headless embedded > Linux devices out there. It's the default image format of many of the > SDKs distributed by chip vendors such as Allwinner, Marvell, MediaTek, > NXP, Qualcomm/Atheros, ... "Look see, my weird format is used by all these companies building crappy SOCs, it is not weird.." > Please let me know if this sounds acceptable, so I won't put effort > into implementing something which will then be rejected again after 5 > iterations on the mailing list for reasons which could have been > expressed from the beginning. An RFC for this series was posted on > 2022-04-25 [1], I wouldn't have worked months to fix all requests of > other maintainers and tested it on a variety of different hardware > knowing that the whole approach will be NACK'ed... If people ignore something that is obviously broken they might just hope for it to go away, becaue often it does.
----- Ursprüngliche Mail ----- > Von: "Christoph Hellwig" <hch@infradead.org> > On Thu, Nov 17, 2022 at 12:19:10AM +0000, Daniel Golle wrote: >> While weirdness is certainly subjective, uImage.FIT is not just a >> random image format but used by a great majority of headless embedded >> Linux devices out there. It's the default image format of many of the >> SDKs distributed by chip vendors such as Allwinner, Marvell, MediaTek, >> NXP, Qualcomm/Atheros, ... > > "Look see, my weird format is used by all these companies building > crappy SOCs, it is not weird.." Well, FIT is not something strange invented by SoC companies, it comes from u-boot and is more or less a de-facto standard. While I agree that using the block layer for partition parsing is questionable I think supporting these images in Linux is a worthwhile goal. Thanks, //richard
On Thu, Nov 17, 2022 at 07:50:08AM +0100, Richard Weinberger wrote:
> I think supporting these images in Linux is a worthwhile goal.
I never argued against that. But it is not a fit for partitions.
So write a proper stacked block driver or dm driver for it if you
care enough. The format is a complete mess and should be isolated
to not affect the rest of the kernel.
On Wed, Nov 16, 2022 at 10:00:25PM -0800, Christoph Hellwig wrote: > On Thu, Nov 17, 2022 at 12:19:10AM +0000, Daniel Golle wrote: > > While weirdness is certainly subjective, uImage.FIT is not just a > > random image format but used by a great majority of headless embedded > > Linux devices out there. It's the default image format of many of the > > SDKs distributed by chip vendors such as Allwinner, Marvell, MediaTek, > > NXP, Qualcomm/Atheros, ... > > "Look see, my weird format is used by all these companies building > crappy SOCs, it is not weird.." I didn't invent this, and it's just as broken and yet perdominant as, let's say, MS LDM on x86. > > > Please let me know if this sounds acceptable, so I won't put effort > > into implementing something which will then be rejected again after 5 > > iterations on the mailing list for reasons which could have been > > expressed from the beginning. An RFC for this series was posted on > > 2022-04-25 [1], I wouldn't have worked months to fix all requests of > > other maintainers and tested it on a variety of different hardware > > knowing that the whole approach will be NACK'ed... > > If people ignore something that is obviously broken they might just hope > for it to go away, becaue often it does. While I'm sure that strategy works seen from your perspective, it does waste resources on the other end. In this case it might not have been obvious to everybody, I did receive feedback from other maintainers, as I said. It's not that everybody ignored this contribution. Hence, looking at it from my end, the picture is a bit different. Anyway. I would have appreciated an earlier explicite NACK, that's all I wanted to say.
diff --git a/block/partitions/efi.c b/block/partitions/efi.c index 5e9be13a56a8..f4406b443f04 100644 --- a/block/partitions/efi.c +++ b/block/partitions/efi.c @@ -716,6 +716,9 @@ int efi_partition(struct parsed_partitions *state) gpt_entry *ptes = NULL; u32 i; unsigned ssz = queue_logical_block_size(state->disk->queue) / 512; +#ifdef CONFIG_FIT_PARTITION + u32 extra_slot = 65; +#endif if (!find_valid_gpt(state, &gpt, &ptes) || !gpt || !ptes) { kfree(gpt); @@ -749,6 +752,12 @@ int efi_partition(struct parsed_partitions *state) ARRAY_SIZE(ptes[i].partition_name)); utf16_le_to_7bit(ptes[i].partition_name, label_max, info->volname); state->parts[i + 1].has_info = true; + /* If this is a U-Boot FIT volume it may have subpartitions */ +#ifdef CONFIG_FIT_PARTITION + if (!efi_guidcmp(ptes[i].partition_type_guid, PARTITION_LINUX_FIT_GUID)) + (void) parse_fit_partitions(state, start * ssz, size * ssz, + &extra_slot, 127, 1); +#endif } kfree(ptes); kfree(gpt); diff --git a/block/partitions/efi.h b/block/partitions/efi.h index 84b9f36b9e47..06c11f6ae398 100644 --- a/block/partitions/efi.h +++ b/block/partitions/efi.h @@ -51,6 +51,9 @@ #define PARTITION_LINUX_LVM_GUID \ EFI_GUID( 0xe6d6d379, 0xf507, 0x44c2, \ 0xa2, 0x3c, 0x23, 0x8f, 0x2a, 0x3d, 0xf9, 0x28) +#define PARTITION_LINUX_FIT_GUID \ + EFI_GUID( 0xcae9be83, 0xb15f, 0x49cc, \ + 0x86, 0x3f, 0x08, 0x1b, 0x74, 0x4a, 0x2d, 0x93) typedef struct _gpt_header { __le64 signature;