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 <[email protected]>
---
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,
--
Linus Walleij <[email protected]>
Hi Linus,
[email protected] 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 <[email protected]>
> ---
> 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 <[email protected]> wrote:
> [email protected] 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,
[email protected] wrote on Tue, 9 May 2023 20:30:33 +0200:
> On Tue, May 9, 2023 at 9:31 AM Miquel Raynal <[email protected]> wrote:
> > [email protected] 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 <[email protected]> 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