From: Simon Glass <sjg@chromium.org>
To: quentin.schulz@theobroma-systems.com
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
Roger Quadros <rogerq@ti.com>,
Alper Nebi Yasak <alpernebiyasak@gmail.com>,
Peter Geis <pgwipeout@gmail.com>,
Philippe Reynes <philippe.reynes@softathome.com>,
Ivan Mikhaylov <ivan.mikhaylov@siemens.com>,
Tom Rini <trini@konsulko.com>, huang lin <hl@rock-chips.com>,
Jeffy Chen <jeffy.chen@rock-chips.com>,
Kever Yang <kever.yang@rock-chips.com>,
Philipp Tomsich <philipp.tomsich@theobroma-systems.com>,
Heiko Thiery <heiko.thiery@gmail.com>,
Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Subject: Re: [PATCH v4 1/7] binman: Allow writing section contents to a file
Date: Mon, 7 Nov 2022 10:33:06 -0700 [thread overview]
Message-ID: <CAPnjgZ2XFdKEfGwJL2LijszTAXtcRO4E7j07p_Vq6cw-Pn-qcw@mail.gmail.com> (raw)
In-Reply-To: <a95d6a3d-1722-cb85-9a50-29ae4da907d5@theobroma-systems.com>
Hi Quentin,
On Mon, 7 Nov 2022 at 08:36, <quentin.schulz@theobroma-systems.com> wrote:
>
> Hi Simon,
>
> On 11/7/22 4:28 PM, Simon Glass <sjg@chromium.org> wrote:
> > Hi Quentin,
> >
> > On Mon, 7 Nov 2022 at 07:25, Quentin Schulz
> > <quentin.schulz@theobroma-systems.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On 11/6/22 23:40, Simon Glass wrote:
> > >> At present only the image (which is a section) has a filename. Move this
> > >> implementation to the entry_Section class so that any section can have a
> > >> filename. With this, the section data is written to a file.
> > >>
> > >> This allows parts of an image to be written, along with the entire image.
> > >>
> > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > >> ---
> > >>
> > >> (no changes since v1)
> > >>
> > >> tools/binman/binman.rst | 5 +++++
> > >> tools/binman/etype/section.py | 12 +++++++++-
> > >> tools/binman/ftest.py | 14 ++++++++++++
> > >> tools/binman/image.py | 3 ---
> > >> tools/binman/test/261_section_fname.dts | 29 +++++++++++++++++++++++++
> > >> 5 files changed, 59 insertions(+), 4 deletions(-)
> > >> create mode 100644 tools/binman/test/261_section_fname.dts
> > >>
> > >> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> > >> index fda16f1992d..79578ff127b 100644
> > >> --- a/tools/binman/binman.rst
> > >> +++ b/tools/binman/binman.rst
> > >> @@ -837,6 +837,11 @@ name-prefix:
> > >> renamed to 'ro-u-boot' and 'rw-u-boot'. This can be useful to
> > >> distinguish binaries with otherwise identical names.
> > >>
> > >> +filename:
> > >> + This allows the contents of the section to be written to a file in the
> > >> + output directory. This can sometimes be useful to use the data in one
> > >> + section in different image, since there is currently no way to share data
> > >> + beteen images other than through files.
> > >>
> > >
> > > IIRC, this is currently incorrect until we have inter-image dependencies
> > > since binman is building images in parallel by default. Suggesting this
> > > is a possible use-case is at beast misleading. For me, this is only
> > > useful for archiving embedded binaries, e.g. what we did for
> > > idbloader.img for Rockchip lately (which is "needed" only to keep the
> > > 3rd party tutorials/documentation not outdated).
> > >
> > > Maybe I missed some recent development that fixes this, lemme know if
> > > that's the case or if my assumptions are wrong.
> >
> > Images themselves are built one after the other, so far as I know:
> >
> > for image in images.values():
> > invalid |= ProcessImage(image, args.update_fdt, args.map,
> > allow_missing=args.allow_missing,
> > allow_fake_blobs=args.fake_ext_blobs)
> >
> > WIthin each image Binman tries to build everything in parallel if
> > possible, but it is currently possible to use the outputs of one image
> > in a subsequent one.
> >
>
> That seems right indeed. ProcessImage uses OrderedDict internally. Just need to trust that the parsing of the DTB is reproducible too but I guess that's fine.
>
> This also explains why you didn't change the u-boot-rockchip-spi.bin image generation I complained about in another review.
>
> I'm a bit scared that implicitly relying images being sequentially created is not going to bite us back in the future once/if we do parallel building of images.
Yes, we probably will want parallel images at some point but we'll
need to support collections that include things from other images.
>
> I guess this is fine then :)
OK.
Regards,
Simon
next prev parent reply other threads:[~2022-11-07 17:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-06 22:40 [PATCH v4 0/7] binman: rockchip: Migrate from rockchip SPL_FIT_GENERATOR script Simon Glass
2022-11-06 22:40 ` [PATCH v4 1/7] binman: Allow writing section contents to a file Simon Glass
2022-11-07 14:24 ` Quentin Schulz
2022-11-07 15:28 ` Simon Glass
2022-11-07 15:36 ` quentin.schulz
2022-11-07 17:33 ` Simon Glass [this message]
2022-11-06 22:40 ` [PATCH v4 2/7] rockchip: evb-rk3288: Drop raw-image support Simon Glass
2022-11-06 22:40 ` [PATCH v4 3/7] rockchip: Include binman script in 64-bit boards Simon Glass
2022-11-07 14:32 ` Quentin Schulz
2022-11-06 22:40 ` [PATCH v4 4/7] rockchip: Support building the all output files in binman Simon Glass
2022-11-07 14:17 ` Jerome Forissier
2022-11-07 14:45 ` Quentin Schulz
2022-11-06 22:40 ` [PATCH v4 5/7] rockchip: Convert all boards to use binman Simon Glass
2022-11-06 22:40 ` [PATCH v4 6/7] rockchip: Drop the FIT generator script Simon Glass
2022-11-06 22:40 ` [PATCH v4 7/7] treewide: Disable USE_SPL_FIT_GENERATOR by default Simon Glass
2022-12-07 1:08 ` [PATCH v4 0/7] binman: rockchip: Migrate from rockchip SPL_FIT_GENERATOR script Simon Glass
2022-12-07 10:19 ` Quentin Schulz
2022-12-07 18: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=CAPnjgZ2XFdKEfGwJL2LijszTAXtcRO4E7j07p_Vq6cw-Pn-qcw@mail.gmail.com \
--to=sjg@chromium.org \
--cc=alpernebiyasak@gmail.com \
--cc=heiko.thiery@gmail.com \
--cc=hl@rock-chips.com \
--cc=ivan.mikhaylov@siemens.com \
--cc=jeffy.chen@rock-chips.com \
--cc=kever.yang@rock-chips.com \
--cc=pgwipeout@gmail.com \
--cc=philipp.tomsich@theobroma-systems.com \
--cc=philippe.reynes@softathome.com \
--cc=quentin.schulz@theobroma-systems.com \
--cc=rogerq@ti.com \
--cc=stefan.herbrechtsmeier@weidmueller.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/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;
as well as URLs for NNTP newsgroup(s).