From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
Alper Nebi Yasak <alpernebiyasak@gmail.com>,
Dillon Min <dillon.minfei@gmail.com>,
Ivan Mikhaylov <fr0st61te@gmail.com>,
Jonas Karlman <jonas@kwiboo.se>,
Kamil Lulko <kamil.lulko@gmail.com>, Marek Vasut <marex@denx.de>,
Michael Walle <michael@walle.cc>,
Neha Malcom Francis <n-francis@ti.com>,
Patrice Chotard <patrice.chotard@foss.st.com>,
Patrick Delaunay <patrick.delaunay@foss.st.com>,
Peng Fan <peng.fan@nxp.com>,
Philippe Reynes <philippe.reynes@softathome.com>,
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>,
Vikas Manocha <vikas.manocha@st.com>,
u-boot@dh-electronics.com,
uboot-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH 0/6] Attempt to enforce standard extensions for build output
Date: Thu, 24 Aug 2023 10:45:35 -0400 [thread overview]
Message-ID: <20230824144535.GP3953269@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ1oY9SRWNj9RUe2L8=1ndE2LfxkmqqEj-MNtxL_ff-QyQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5388 bytes --]
On Thu, Aug 24, 2023 at 08:41:21AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 24 Aug 2023 at 07:38, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Aug 23, 2023 at 09:02:53PM -0600, Simon Glass wrote:
> >
> > > In this early stage of using binman to produce output files, we are mostly
> > > seeing people using common extensions such as '.bin' and '.rom'
> > >
> > > But unusual extensions appear in some places.
> > >
> > > We would like 'buildman -k' to keep the build outputs, but this is hard if
> > > there is no consistency as to the extension used.
> > >
> > > This series adjusts binman to enforce just 4 extensions for output images:
> > >
> > > .bin
> > > .rom
> > > .itb
> > > .img
> > >
> > > Other extensions will produce an error. With this rule observed, buildman
> > > can keep the required files.
> > >
> > > Some patches are included to fix up some easy problems. But the following
> > > boards generate 'custMpk.pem' and it is not clear how to fix this, so I am
> > > asking for help from the maintainers:
> > >
> > > am62ax_evm_r5 am62x_evm_r5 am64x_evm_r5 am65x_evm_r5
> > > am65x_evm_r5_usbdfu am65x_evm_r5_usbmsc am65x_hs_evm_r5
> > > j7200_evm_r5 j721e_evm_r5 j721s2_evm_r5 verdin-am62_r5
> > > am62ax_evm_a53 am62x_evm_a53 am64x_evm_a53 am65x_evm_a53
> > > am65x_hs_evm_a53 j7200_evm_a72 j721e_evm_a72 j721s2_evm_a72
> > > verdin-am62_a53
> > >
> > > It looks like the .pem files are listed as top-level images, e.g.:
> > >
> > > &custmpk_pem {
> > > filename = "../../ti/keys/custMpk.pem";
> > > };
> > >
> > > but if the only objective is to pick up an existing file, it is better to
> > > set BINMAN_INDIRS to include that directory. Also we should only have
> > > simple leafnames in the 'filename' property, so the '../../ti/keys' is not
> > > correct. It makes it harder for people to get the files from other places.
> > > Making this easier is one of binman's goals.
> > >
> > > Most likely the custmpk_pem node can be removed and the .pem file can be
> > > included directly in the place that needs it, e.g. by adjusting the
> > > ti-secure-rom etype (or ex509_cert) to use tools.get_input_filename() when
> > > reading the key file.
> > >
> > > For example, this:
> > >
> > > custMpk {
> > > filename = "custMpk.pem";
> > > custmpk_pem: blob-ext {
> > > filename = "../keys/custMpk.pem";
> > > };
> > > };
> > >
> > > is really just copying a file from '../keys/custMpk.pem' to 'custMpk.pem'
> > > so is equivalent to:
> > >
> > > custMpk {
> > > type = "blob";
> > > filename = "custMpk.pem";
> > > }
> > >
> > > (note that blob-ext implies that the blob may be missing, so blob is a
> > > better choice, since the key cannot be missing)
> > >
> > > The fact that the .pem files are at the top level means that they are
> > > output images, which surely is not intended. They should be buried in the
> > > image description, at a lower level, as part of something else.
> > >
> > > So please take a loke at the above and see if the binman descriptions can
> > > be reworked slightly to follow these new rules.
> > >
> > >
> > > Simon Glass (6):
> > > binman: Require image filenames to have certain extensions
> > > buildman: Keep all permitted output files
> > > buildman: Show progress when regenerating the board.cfg file
> > > buildman: Start the clock when the build starts
> > > kontron_sl28: Use u-boot-update.bin instead of u-boot.update
> > > stm32mp15: Use u-boot-spl-stm32.bin instead of u-boot-spl.stm32
> > >
> > > .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 2 +-
> > > arch/arm/dts/stm32mp15-u-boot.dtsi | 2 +-
> > > doc/board/kontron/sl28.rst | 4 ++--
> > > doc/board/st/stm32mp1.rst | 18 +++++++++---------
> > > include/configs/stm32mp15_dh_dhsom.h | 2 +-
> > > tools/binman/binman.rst | 5 +++++
> > > tools/binman/etype/section.py | 3 +--
> > > tools/binman/ftest.py | 12 ++++++++++--
> > > tools/binman/image.py | 9 +++++++++
> > > tools/binman/test/022_image_name.dts | 4 ++--
> > > tools/binman/test/311_bad_image_name.dts | 17 +++++++++++++++++
> > > tools/buildman/boards.py | 15 ++++++++++++---
> > > tools/buildman/builder.py | 3 ++-
> > > tools/buildman/builderthread.py | 11 +++++++----
> > > tools/buildman/control.py | 3 ++-
> > > 15 files changed, 81 insertions(+), 29 deletions(-)
> > > create mode 100644 tools/binman/test/311_bad_image_name.dts
> >
> > This doesn't seem to address the ones I pointed out on IRC as being the
> > first order (to me anyhow) problem of needing the _unsigned files on the
> > platforms you list above for PEM files.
>
> I think it should be xxx-unsigned.bin instead of xxx.bin_unsigned
As I was saying on IRC, you need to make that change then, if we're
going to go down this path, before v2023.10 is out.
And to repeat what I said inside another part of the thread, the u-boot*
glob is hiding other "arbitrary" extensions that we've had in-use for
forever.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2023-08-24 14:45 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 3:02 [PATCH 0/6] Attempt to enforce standard extensions for build output Simon Glass
2023-08-24 3:02 ` [PATCH 1/6] binman: Require image filenames to have certain extensions Simon Glass
2023-08-24 3:02 ` [PATCH 2/6] buildman: Keep all permitted output files Simon Glass
2023-08-24 14:26 ` Tom Rini
2023-08-24 3:02 ` [PATCH 3/6] buildman: Show progress when regenerating the board.cfg file Simon Glass
2023-08-24 3:02 ` [PATCH 4/6] buildman: Start the clock when the build starts Simon Glass
2023-08-24 3:02 ` [PATCH 5/6] kontron_sl28: Use u-boot-update.bin instead of u-boot.update Simon Glass
2023-08-24 7:35 ` Michael Walle
2023-08-24 3:02 ` [PATCH 6/6] stm32mp15: Use u-boot-spl-stm32.bin instead of u-boot-spl.stm32 Simon Glass
2023-08-24 3:12 ` Marek Vasut
2023-08-24 14:25 ` Tom Rini
2023-08-24 15:09 ` Marek Vasut
2023-08-24 15:14 ` Tom Rini
2023-08-24 15:26 ` Marek Vasut
2023-08-29 16:28 ` Patrick DELAUNAY
2023-09-02 0:09 ` Simon Glass
2023-08-24 7:32 ` [PATCH 0/6] Attempt to enforce standard extensions for build output Michael Walle
2023-08-24 14:43 ` Simon Glass
2023-08-24 14:55 ` Michael Walle
2023-08-24 12:26 ` Neha Malcom Francis
2023-08-24 14:41 ` Simon Glass
2023-08-24 13:38 ` Tom Rini
2023-08-24 14:41 ` Simon Glass
2023-08-24 14:45 ` Tom Rini [this message]
2023-08-24 14:49 ` Simon Glass
2023-08-24 15:16 ` Tom Rini
2023-08-27 19:17 ` Alper Nebi Yasak
2023-08-28 17:54 ` Simon Glass
2023-08-28 18:53 ` Tom Rini
2023-08-31 10:20 ` Alper Nebi Yasak
2023-08-31 19:01 ` Simon Glass
2023-08-31 19:07 ` Tom Rini
2023-08-31 19:22 ` Simon Glass
2023-08-31 19:24 ` Tom Rini
2023-09-01 1:10 ` 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=20230824144535.GP3953269@bill-the-cat \
--to=trini@konsulko.com \
--cc=alpernebiyasak@gmail.com \
--cc=dillon.minfei@gmail.com \
--cc=fr0st61te@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kamil.lulko@gmail.com \
--cc=marex@denx.de \
--cc=michael@walle.cc \
--cc=n-francis@ti.com \
--cc=patrice.chotard@foss.st.com \
--cc=patrick.delaunay@foss.st.com \
--cc=peng.fan@nxp.com \
--cc=philippe.reynes@softathome.com \
--cc=sjg@chromium.org \
--cc=stefan.herbrechtsmeier@weidmueller.com \
--cc=u-boot@dh-electronics.com \
--cc=u-boot@lists.denx.de \
--cc=uboot-stm32@st-md-mailman.stormreply.com \
--cc=vikas.manocha@st.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox