Message-ID: <20230522164559.6c599c61@xps-13>
Date:   Mon, 22 May 2023 16:45:59 +0200
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Rafał Miłecki <zajec5@...il.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@...adcom.com>,
        linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/2] Add SEAMA partition types

Hi Linus,

linus.walleij@...aro.org wrote on Tue, 9 May 2023 20:30:33 +0200:

> On Tue, May 9, 2023 at 9:31 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
> > linus.walleij@...aro.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

Powered by blists - more mailing lists