From: Rob Herring <robh@kernel.org>
To: Simon Glass <sjg@chromium.org>
Cc: devicetree@vger.kernel.org,
"U-Boot Mailing List" <u-boot@lists.denx.de>,
linux-mtd@lists.infradead.org, "Tom Rini" <trini@konsulko.com>,
"Conor Dooley" <conor+dt@kernel.org>,
"Dhruva Gole" <d-gole@ti.com>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Rafał Miłecki" <rafal@milecki.pl>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: mtd: Add a schema for binman
Date: Fri, 22 Sep 2023 12:46:49 -0500 [thread overview]
Message-ID: <20230922174649.GA3320366-robh@kernel.org> (raw)
In-Reply-To: <CAPnjgZ1pfxaMG1n5yOBhiOhsNrRjck1K92U7Ga=+VTY_jjjrVg@mail.gmail.com>
On Fri, Sep 22, 2023 at 11:01:18AM -0600, Simon Glass wrote:
> Hi Rob,
>
> On Fri, 22 Sept 2023 at 10:00, Rob Herring <robh@kernel.org> wrote:
> >
> > On Thu, Sep 21, 2023 at 1:45 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Binman[1] is a tool for creating firmware images. It allows you to
> > > combine various binaries and place them in an output file.
> > >
> > > Binman uses a DT schema to describe an image, in enough detail that
> > > it can be automatically built from component parts, disassembled,
> > > replaced, listed, etc.
> > >
> > > Images are typically stored in flash, which is why this binding is
> > > targeted at mtd. Previous discussion is at [2] [3].
> > >
> > > [1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html
> > > [2] https://lore.kernel.org/u-boot/20230821180220.2724080-3-sjg@chromium.org/
> > > [3] https://www.spinics.net/lists/devicetree/msg626149.html
> >
> > You missed:
> >
> > https://github.com/devicetree-org/dt-schema/pull/110
> >
> > where I said: We certainly shouldn't duplicate the existing partitions
> > bindings. What's missing from them (I assume we're mostly talking
> > about "fixed-partitions" which has been around forever I think (before
> > me))?
> >
> > To repeat, unless there is some reason binman partitions conflict with
> > fixed-partitions, you need to start there and extend it. From what's
> > posted here, it neither conflicts nor needs extending.
>
> I think at this point I am just hopelessly confused. Have you taken a
> look at the binman schema? [1]
Why do I need to? That's used for some tool and has nothing to do with a
device's DTB. However, I thought somewhere in this discussion you showed
it under a flash device node. Then I care because then it overlaps with
what we already have for partitions. If I misunderstood that, then just
put your schema with your tool. Only users of the tool should care about
the tool's schema.
>
> I saw this file, which seems to extend a partition.
>
> Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
IIRC, that's a different type where partition locations are stored in
the flash, so we don't need location and size in DT.
>
> I was assuming that I should create a top-level compatible = "binman"
> node, with subnodes like compatible = "binman,bl31-atf", for example.
> I should use the compatible string to indicate the contents, right?
Yes for subnodes, and we already have some somewhat standard ones for
"u-boot" and "u-boot-env". Though historically, "label" was used.
Top-level, meaning the root of the DT? That sound like just something
for the tool, so I don't care, but it doesn't belong in the DTB.
>
> Re extending, what is the minimum I can do? Are you looking for
> something like a "compress" property that indicates that the entry is
> compressed?
>
> I'm really just a bit lost.
Me too.
Rob
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Simon Glass <sjg@chromium.org>
Cc: devicetree@vger.kernel.org,
"U-Boot Mailing List" <u-boot@lists.denx.de>,
linux-mtd@lists.infradead.org, "Tom Rini" <trini@konsulko.com>,
"Conor Dooley" <conor+dt@kernel.org>,
"Dhruva Gole" <d-gole@ti.com>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Rafał Miłecki" <rafal@milecki.pl>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: mtd: Add a schema for binman
Date: Fri, 22 Sep 2023 12:46:49 -0500 [thread overview]
Message-ID: <20230922174649.GA3320366-robh@kernel.org> (raw)
In-Reply-To: <CAPnjgZ1pfxaMG1n5yOBhiOhsNrRjck1K92U7Ga=+VTY_jjjrVg@mail.gmail.com>
On Fri, Sep 22, 2023 at 11:01:18AM -0600, Simon Glass wrote:
> Hi Rob,
>
> On Fri, 22 Sept 2023 at 10:00, Rob Herring <robh@kernel.org> wrote:
> >
> > On Thu, Sep 21, 2023 at 1:45 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Binman[1] is a tool for creating firmware images. It allows you to
> > > combine various binaries and place them in an output file.
> > >
> > > Binman uses a DT schema to describe an image, in enough detail that
> > > it can be automatically built from component parts, disassembled,
> > > replaced, listed, etc.
> > >
> > > Images are typically stored in flash, which is why this binding is
> > > targeted at mtd. Previous discussion is at [2] [3].
> > >
> > > [1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html
> > > [2] https://lore.kernel.org/u-boot/20230821180220.2724080-3-sjg@chromium.org/
> > > [3] https://www.spinics.net/lists/devicetree/msg626149.html
> >
> > You missed:
> >
> > https://github.com/devicetree-org/dt-schema/pull/110
> >
> > where I said: We certainly shouldn't duplicate the existing partitions
> > bindings. What's missing from them (I assume we're mostly talking
> > about "fixed-partitions" which has been around forever I think (before
> > me))?
> >
> > To repeat, unless there is some reason binman partitions conflict with
> > fixed-partitions, you need to start there and extend it. From what's
> > posted here, it neither conflicts nor needs extending.
>
> I think at this point I am just hopelessly confused. Have you taken a
> look at the binman schema? [1]
Why do I need to? That's used for some tool and has nothing to do with a
device's DTB. However, I thought somewhere in this discussion you showed
it under a flash device node. Then I care because then it overlaps with
what we already have for partitions. If I misunderstood that, then just
put your schema with your tool. Only users of the tool should care about
the tool's schema.
>
> I saw this file, which seems to extend a partition.
>
> Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml
IIRC, that's a different type where partition locations are stored in
the flash, so we don't need location and size in DT.
>
> I was assuming that I should create a top-level compatible = "binman"
> node, with subnodes like compatible = "binman,bl31-atf", for example.
> I should use the compatible string to indicate the contents, right?
Yes for subnodes, and we already have some somewhat standard ones for
"u-boot" and "u-boot-env". Though historically, "label" was used.
Top-level, meaning the root of the DT? That sound like just something
for the tool, so I don't care, but it doesn't belong in the DTB.
>
> Re extending, what is the minimum I can do? Are you looking for
> something like a "compress" property that indicates that the entry is
> compressed?
>
> I'm really just a bit lost.
Me too.
Rob
next prev parent reply other threads:[~2023-09-22 17:47 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-21 18:45 [PATCH] dt-bindings: mtd: Add a schema for binman Simon Glass
2023-09-21 18:45 ` Simon Glass
2023-09-22 4:21 ` Rob Herring
2023-09-22 4:21 ` Rob Herring
2023-09-22 7:01 ` Krzysztof Kozlowski
2023-09-22 7:01 ` Krzysztof Kozlowski
2023-09-22 15:26 ` Simon Glass
2023-09-22 15:26 ` Simon Glass
2023-09-22 13:56 ` Alper Nebi Yasak
2023-09-22 13:56 ` Alper Nebi Yasak
2023-09-22 15:09 ` Simon Glass
2023-09-22 15:09 ` Simon Glass
2023-09-22 16:00 ` Rob Herring
2023-09-22 16:00 ` Rob Herring
2023-09-22 17:01 ` Simon Glass
2023-09-22 17:01 ` Simon Glass
2023-09-22 17:46 ` Rob Herring [this message]
2023-09-22 17:46 ` Rob Herring
2023-09-22 18:12 ` Simon Glass
2023-09-22 18:12 ` Simon Glass
2023-09-22 19:43 ` Rob Herring
2023-09-22 19:43 ` Rob Herring
2023-09-22 19:51 ` Simon Glass
2023-09-22 19:51 ` Simon Glass
2023-09-25 7:21 ` Miquel Raynal
2023-09-25 7:21 ` Miquel Raynal
2023-09-25 12:33 ` Simon Glass
2023-09-25 12:33 ` Simon Glass
2023-09-25 14:47 ` Miquel Raynal
2023-09-25 14:47 ` Miquel Raynal
2023-09-25 14:53 ` Simon Glass
2023-09-25 14:53 ` Simon Glass
2023-09-25 15:24 ` Miquel Raynal
2023-09-25 15:24 ` Miquel Raynal
2023-09-25 16:25 ` Simon Glass
2023-09-25 16:25 ` Simon Glass
2023-09-25 18:49 ` Rob Herring
2023-09-25 18:49 ` Rob Herring
2023-09-25 22:25 ` Simon Glass
2023-09-25 22:25 ` Simon Glass
2023-09-26 7:48 ` Miquel Raynal
2023-09-26 7:48 ` Miquel Raynal
2023-09-26 17:29 ` Rob Herring
2023-09-26 17:29 ` Rob Herring
2023-09-27 16:43 ` Simon Glass
2023-09-27 16:43 ` Simon Glass
2023-09-28 15:20 ` Simon Glass
2023-09-28 15:20 ` Simon Glass
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=20230922174649.GA3320366-robh@kernel.org \
--to=robh@kernel.org \
--cc=conor+dt@kernel.org \
--cc=d-gole@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=vigneshr@ti.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.