Message ID | 20230506-seama-partitions-v1-0-5806af1e4ac7@linaro.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1124489vqo; Sat, 6 May 2023 08:46:37 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5OY2T/PHl+7Xbo3ezTTsC2jOp2d1QfAvMITC3cHPoDRuV39Gh3B+Dpfwv9fD6bkKnTIax3 X-Received: by 2002:a17:902:70ca:b0:19d:20a:a219 with SMTP id l10-20020a17090270ca00b0019d020aa219mr4464160plt.66.1683387997339; Sat, 06 May 2023 08:46:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683387997; cv=none; d=google.com; s=arc-20160816; b=NOQF4QNaRvzUWr5pgCai0hEg6AL3Yvmm6ARhbvWCXfMnOaW99TKzXut0ucGBZR9o3f rOnRavqQrdf/3pEEmCZz1e3w8vJjqFvjfeJ5j31FM0PGj3CXpyRzzhVhWhyjeHJOC3RU O4zqHjoDoIQJ8+Nso6e5BIIdmRQvSLlGfF3bknptXv59ZVkpCrZsrE5f0x1sRyWqQ7Sy HTya58MzXL+RtCvkxGBcjgeqqo0xvl6I0ZKSNPo6+sJ6SppwhgM8Dv2ezRF0mRMTTQOL AGXkcOwQDvd+4KpB3WHJLCvfELu+AVh7w4Faccidc+uAiZmZdK8iKYY316pgBfKWlyk4 bLvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:content-transfer-encoding:mime-version :message-id:date:subject:from:dkim-signature; bh=T8hWHGuwmr5mvcRO9xWp0sVfGZwfYtl73f18uwHlJMc=; b=ojVlDryqvEGBcuhcWjUILVpiFD7MJsIZ+HLwD+cZCUVyqpmfTRZutddJ/60ggpoQoe Fhy/iNsLOPY/La+PWQK+imVIq+3tOKBlIYlqPcLwKCNv4SP7DpkCjf8KYFkmALg8BZyF moU2W3YafwN65EUyT905WiXrk6iPyJVRYXpLm/mKdDT3ylyJ4bhmsJsgEaGb0gtCTsR+ ncThpecDKBS3oYm+cyhhGVS+tnVA8Vdl/JGL8N2SgYAOuUr3p95JInY0A76GfVEBZV7t YfhDYP8Yrv0n/ZrsDhcFW7BIbUb0FxE9B/GTtVzYlNV8Vlhd/1lRponvCbaKWf+o+J5D FI8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=mNiQ0UDS; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t12-20020a170902e84c00b001a1d78af685si3201895plg.466.2023.05.06.08.46.22; Sat, 06 May 2023 08:46:37 -0700 (PDT) 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; dkim=pass header.i=@linaro.org header.s=google header.b=mNiQ0UDS; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232975AbjEFP3x (ORCPT <rfc822;baris.duru.linux@gmail.com> + 99 others); Sat, 6 May 2023 11:29:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50020 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232919AbjEFP3t (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 6 May 2023 11:29:49 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46AC218DD8 for <linux-kernel@vger.kernel.org>; Sat, 6 May 2023 08:29:47 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-4f14f266b72so1047934e87.1 for <linux-kernel@vger.kernel.org>; Sat, 06 May 2023 08:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1683386985; x=1685978985; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:from:to:cc:subject:date:message-id:reply-to; bh=T8hWHGuwmr5mvcRO9xWp0sVfGZwfYtl73f18uwHlJMc=; b=mNiQ0UDS2BUcvU4LntQeVmsiQUODFkPh8PySaX6ucBq7F5zKYFGH5BIL21VYHsS/Rb Ad5fGY92zFbpAHSC72PDkEukkm0w6dfI8dRd1g82wyUJu2Z3Kx7btxOZSpUfpiylCGi+ RKP2R1pTVir2VeqCumdztRmrt3CV4ui0t6GVMu7B4E6JDFYM7hRR85TjzWdaU154eopl BrB4meyYy2XHysDZBB0CMAVgGR9NlI8G9v1faKidLOJqS48ZeD6SEXN2lD8SqHnBITJW ddbCKpkw03apGuuPuM3UMWMQ+dX0CCi9WFyL0p/hM+g2uGpTzWAUQAt9MAAMPGKmk2Ja CAaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683386985; x=1685978985; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=T8hWHGuwmr5mvcRO9xWp0sVfGZwfYtl73f18uwHlJMc=; b=WXBSy6ruvlxmRfSLrrl+gsS3UWgLHRneXIbdNnnTlBspXipViGf7UQpqjQlWRFSwBT z2aw+l+5Fue/lxJRnZQhk04rDNtYGlhjtM2MIG3ZeYkMh8WgHCvHFpccP6dtp1ulUVar SVQzAkgFSk2t57MbTSBAiRy2d9G+fkvCqqCygRcmGu4nq3rFUtOYPjvRIW/hHAl4UOSg cUjjFZjyNvvsNq+bKFZ458KurTZzqZ9UZGxY62pSmBM0c3B6V66tcMRBcxN85y9ehGhd 8Zoz76T2RaWxjX3qGvfLzy/69K4sDEcglNXxqTQiIouS3OaBrz1lySlhr9ADxrKVWlq3 O6gA== X-Gm-Message-State: AC+VfDzy/VL2TesS54IdJmnTD8OsoAYWJQw7SHDxqDcry3gfxHjZEkj6 DqwN2eWN3HTt9oQ1n8HsMo8k9Q== X-Received: by 2002:ac2:5dfb:0:b0:4f1:3ef5:35a6 with SMTP id z27-20020ac25dfb000000b004f13ef535a6mr1250503lfq.8.1683386985531; Sat, 06 May 2023 08:29:45 -0700 (PDT) Received: from [127.0.1.1] ([85.235.12.238]) by smtp.gmail.com with ESMTPSA id v5-20020a197405000000b004eff32d6a21sm680814lfe.121.2023.05.06.08.29.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 May 2023 08:29:45 -0700 (PDT) From: Linus Walleij <linus.walleij@linaro.org> Subject: [PATCH 0/2] Add SEAMA partition types Date: Sat, 06 May 2023 17:29:43 +0200 Message-Id: <20230506-seama-partitions-v1-0-5806af1e4ac7@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAGdyVmQC/0WNQQqDQAxFryJZG5gZ0dZeRVxkNK1ZdCqJiCDe3 bEbl4//Hn8HYxU2eBU7KK9i8ksZfFnAMFH6MMqYGYILlatdg8b0JZxJF1myaxib4Lx/xLZ91pC zSMYYldIwXeHtX+Os/Jbt/9f1x3ECx3j3K38AAAA= To: Miquel Raynal <miquel.raynal@bootlin.com>, Richard Weinberger <richard@nod.at>, Vignesh Raghavendra <vigneshr@ti.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Florian Fainelli <f.fainelli@gmail.com>, Hauke Mehrtens <hauke@hauke-m.de>, =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>, Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Cc: linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Linus Walleij <linus.walleij@linaro.org> X-Mailer: b4 0.12.1 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable 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?1765160252929777780?= X-GMAIL-MSGID: =?utf-8?q?1765160252929777780?= |
Series |
Add SEAMA partition types
|
|
Message
Linus Walleij
May 6, 2023, 3:29 p.m. UTC
This type of firmware partition appear in some devices in
NAND flash, so we need to be able to tag the partitions
with the appropriate type.
The origin of the "SEAttle iMAge" is unknown.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Linus Walleij (2):
dt-bindings: mtd: Add SEAMA partition bindings
ARM: dts: bcm5301x: Add SEAMA compatibles
.../devicetree/bindings/mtd/partitions/seama.yaml | 50 ++++++++++++++++++++++
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 1 +
arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts | 1 +
3 files changed, 52 insertions(+)
---
base-commit: caad71e7d226920623d78be2e6283516decdc502
change-id: 20230506-seama-partitions-b620117b9985
Best regards,
Comments
Hi Linus, linus.walleij@linaro.org wrote on Sat, 06 May 2023 17:29:43 +0200: > This type of firmware partition appear in some devices in > NAND flash, so we need to be able to tag the partitions > with the appropriate type. > > The origin of the "SEAttle iMAge" is unknown. I don't see any kernel changes, why do we need an additional binding? > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> > --- > Linus Walleij (2): > dt-bindings: mtd: Add SEAMA partition bindings > ARM: dts: bcm5301x: Add SEAMA compatibles > > .../devicetree/bindings/mtd/partitions/seama.yaml | 50 ++++++++++++++++++++++ > arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 1 + > arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts | 1 + > 3 files changed, 52 insertions(+) > --- > base-commit: caad71e7d226920623d78be2e6283516decdc502 > change-id: 20230506-seama-partitions-b620117b9985 > > Best regards, Thanks, Miquèl
On Tue, May 9, 2023 at 9:31 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > linus.walleij@linaro.org wrote on Sat, 06 May 2023 17:29:43 +0200: > > > This type of firmware partition appear in some devices in > > NAND flash, so we need to be able to tag the partitions > > with the appropriate type. > > > > The origin of the "SEAttle iMAge" is unknown. > > I don't see any kernel changes, why do we need an additional binding? The bindings are not strictly bound to Linux, it's more like all OS:es uses the Linux DT binding repo because it is the biggest project. Also we actually merge a bunch of bindings just to describe hardware (or things like partitions), in the hope of making use of them in the long run. Anyways, for the record, the full story: Currently this binding is used in out-of-tree OpenWrt code, where it is used as magic for splitting partitions with mtdsplit. I guess you might be familiar with mtdsplit. It is a software partition splitter that makes it possible to split a big partition into smaller partitions dynamically, using magic block identifiers. The typical usecase is to put the kernel in the first flash blocks, then pad up to the nearest even erase block, and then add a JFFS2 or UBI filesystem immediately there. This way it avoids using static partitioning, the tools rebuilding the firmware can dynamically split off more flash as the kernel image grows. The mtdsplit code uses different magic numbers to identify where the different partitions start. One such type of partition is seama, so the code needs to know that it should look for seama magic to determine the size and split this partition in a kernel and rootfs part. This is the code: https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/generic/files/drivers/mtd/mtdsplit;h=3e0df856713a84b1decf17190f171cb10ce7a757;hb=HEAD It is a bit sad that no-one has the energy to propose mtdsplit upstream, I think it is quite generic and generally useful. I started to make an upstream patch but got exhausted with the task. Yours, Linus Walleij
Hi Linus, linus.walleij@linaro.org wrote on Tue, 9 May 2023 20:30:33 +0200: > On Tue, May 9, 2023 at 9:31 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > linus.walleij@linaro.org wrote on Sat, 06 May 2023 17:29:43 +0200: > > > > > This type of firmware partition appear in some devices in > > > NAND flash, so we need to be able to tag the partitions > > > with the appropriate type. > > > > > > The origin of the "SEAttle iMAge" is unknown. > > > > I don't see any kernel changes, why do we need an additional binding? > > The bindings are not strictly bound to Linux, it's more like all OS:es > uses the Linux DT binding repo because it is the biggest project. Yes, that's why I wanted more context :-) > Also we actually merge a bunch of bindings just to describe hardware > (or things like partitions), in the hope of making use of them in the > long run. It's always problematic to do it this way because no user == no precise requirement. As binding are supposed to remain stable, and because we, human are far from perfect when it comes to read the future, I of course prefer when there is an implementation that uses the new binding so we can more easily spot the issues. > Anyways, for the record, the full story: > > Currently this binding is used in out-of-tree OpenWrt code, where it > is used as magic for splitting partitions with mtdsplit. > > I guess you might be familiar with mtdsplit. It is a software partition > splitter that makes it possible to split a big partition into smaller > partitions dynamically, using magic block identifiers. > > The typical usecase is to put the kernel in the first flash blocks, > then pad up to the nearest even erase block, and then add a > JFFS2 or UBI filesystem immediately there. > > This way it avoids using static partitioning, the tools rebuilding the > firmware can dynamically split off more flash as the kernel image > grows. > > The mtdsplit code uses different magic numbers to identify where > the different partitions start. Is mtdsplit acting on a device or on a partition? Right now you define a partition to be compatible with seama, I would have imagined the partitions container should be compatible with seama instead of fixed-partitions, but I haven't looked at the whole implementation, so maybe my comment is just wrong. > One such type of partition is seama, so the code needs to know > that it should look for seama magic to determine the size and > split this partition in a kernel and rootfs part. This is the code: > https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/generic/files/drivers/mtd/mtdsplit;h=3e0df856713a84b1decf17190f171cb10ce7a757;hb=HEAD That's very informative, thanks for all the context. I believe this could actually be part of the binding description (not the "this is an openWRT stuff", of course). > It is a bit sad that no-one has the energy to propose mtdsplit > upstream, I think it is quite generic and generally useful. I started > to make an upstream patch but got exhausted with the task. :-) Thanks, Miquèl
On Mon, May 22, 2023 at 4:46 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > The mtdsplit code uses different magic numbers to identify where > > the different partitions start. > > Is mtdsplit acting on a device or on a partition? It acts on a partition, usually you use a fixed-partitition scheme to point out the different chunks in the flash and then mtdsplit comes in to do its job. > Right now you define > a partition to be compatible with seama, I would have imagined the > partitions container should be compatible with seama instead of > fixed-partitions, but I haven't looked at the whole implementation, so > maybe my comment is just wrong. The NAND flash on my device needs it to be a partition, it looks like so: &nandcs { /* Spansion S34ML01G2, 128MB with 128KB erase blocks */ partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; firmware@0 { compatible = "seama"; label = "firmware"; reg = <0x00000000 0x08000000>; }; }; }; The reason is mainly that other devices may put eraseblocks aside for other things, and the SEAMA format itself does not know its extents (it needs to be told where the end of the partition is). > > One such type of partition is seama, so the code needs to know > > that it should look for seama magic to determine the size and > > split this partition in a kernel and rootfs part. This is the code: > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/generic/files/drivers/mtd/mtdsplit;h=3e0df856713a84b1decf17190f171cb10ce7a757;hb=HEAD > > That's very informative, thanks for all the context. I believe this > could actually be part of the binding description (not the "this is an > openWRT stuff", of course). Hm I'll think about what I can put in there... Yours, Linus Walleij