From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "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>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Broadcom internal kernel review list"
<bcm-kernel-feedback-list@broadcom.com>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/2] Add SEAMA partition types
Date: Mon, 22 May 2023 16:45:59 +0200 [thread overview]
Message-ID: <20230522164559.6c599c61@xps-13> (raw)
In-Reply-To: <CACRpkdYLZ36Ad5y7qLUTFix6yx=jBQ=ZvxaB9U-fhqQ_fvvXCQ@mail.gmail.com>
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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "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>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Broadcom internal kernel review list"
<bcm-kernel-feedback-list@broadcom.com>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/2] Add SEAMA partition types
Date: Mon, 22 May 2023 16:45:59 +0200 [thread overview]
Message-ID: <20230522164559.6c599c61@xps-13> (raw)
In-Reply-To: <CACRpkdYLZ36Ad5y7qLUTFix6yx=jBQ=ZvxaB9U-fhqQ_fvvXCQ@mail.gmail.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "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>,
"Rafał Miłecki" <zajec5@gmail.com>,
"Broadcom internal kernel review list"
<bcm-kernel-feedback-list@broadcom.com>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/2] Add SEAMA partition types
Date: Mon, 22 May 2023 16:45:59 +0200 [thread overview]
Message-ID: <20230522164559.6c599c61@xps-13> (raw)
In-Reply-To: <CACRpkdYLZ36Ad5y7qLUTFix6yx=jBQ=ZvxaB9U-fhqQ_fvvXCQ@mail.gmail.com>
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
next prev parent reply other threads:[~2023-05-22 14:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-06 15:29 [PATCH 0/2] Add SEAMA partition types Linus Walleij
2023-05-06 15:29 ` Linus Walleij
2023-05-06 15:29 ` Linus Walleij
2023-05-06 15:29 ` [PATCH 1/2] dt-bindings: mtd: Add SEAMA partition bindings Linus Walleij
2023-05-06 15:29 ` Linus Walleij
2023-05-06 15:29 ` Linus Walleij
2023-05-10 14:57 ` Krzysztof Kozlowski
2023-05-10 14:57 ` Krzysztof Kozlowski
2023-07-05 10:10 ` Linus Walleij
2023-07-05 10:10 ` Linus Walleij
2023-07-05 10:10 ` Linus Walleij
2023-05-06 15:29 ` [PATCH 2/2] ARM: dts: bcm5301x: Add SEAMA compatibles Linus Walleij
2023-05-06 15:29 ` Linus Walleij
2023-05-06 15:29 ` Linus Walleij
2023-05-09 7:31 ` [PATCH 0/2] Add SEAMA partition types Miquel Raynal
2023-05-09 7:31 ` Miquel Raynal
2023-05-09 18:30 ` Linus Walleij
2023-05-09 18:30 ` Linus Walleij
2023-05-22 14:45 ` Miquel Raynal [this message]
2023-05-22 14:45 ` Miquel Raynal
2023-05-22 14:45 ` Miquel Raynal
2023-05-23 13:19 ` Linus Walleij
2023-05-23 13:19 ` Linus Walleij
2023-05-23 13:19 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230522164559.6c599c61@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=hauke@hauke-m.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=vigneshr@ti.com \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.