From: Simon Glass <sjg@chromium.org>
To: U-Boot Mailing List <u-boot@lists.denx.de>
Cc: Xavier Drudis Ferran <xdrudis@tinet.cat>,
Quentin Schulz <quentin.schulz@theobroma-systems.com>,
Alper Nebi Yasak <alpernebiyasak@gmail.com>,
Simon Glass <sjg@chromium.org>
Subject: [PATCH 2/2] binman: Document how to handle dependent images
Date: Thu, 18 Aug 2022 02:16:46 -0600 [thread overview]
Message-ID: <20220818081647.210263-2-sjg@chromium.org> (raw)
In-Reply-To: <20220818081647.210263-1-sjg@chromium.org>
Binman does not support this properly at present. Add documentation about
it including a work-around.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
tools/binman/binman.rst | 50 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
index f85d13b700a..7cfac724b84 100644
--- a/tools/binman/binman.rst
+++ b/tools/binman/binman.rst
@@ -858,6 +858,55 @@ allow-repack:
image description to be stored in the FDT and fdtmap.
+Image dependencies
+------------------
+
+Binman does not currently support images that depend on each other. For example,
+if one image creates `fred.bin` and then the next uses this `fred.bin` to
+produce a final `image.bin`, then the behaviour is undefined. It may work, or it
+may produce an error about `fred.bin` being missing, or it may use a version of
+`fred.bin` from a previous run.
+
+Often this can be handled by incorporating the dependency into the second
+image. For example, instead of::
+
+ binman {
+ multiple-images;
+
+ fred {
+ u-boot {
+ };
+ fill {
+ size = <0x100>;
+ };
+ };
+
+ image {
+ blob {
+ filename = "fred.bin";
+ };
+ u-boot-spl {
+ };
+ };
+
+you can do this::
+
+ binman {
+ image {
+ fred {
+ type = "section";
+ u-boot {
+ };
+ fill {
+ size = <0x100>;
+ };
+ };
+ u-boot-spl {
+ };
+ };
+
+
+
Hashing Entries
---------------
@@ -1690,6 +1739,7 @@ Some ideas:
Perhaps it should completely regenerate the flat tree?
- Put faked files into a separate subdir and remove them on start-up, to avoid
seeing them as 'real' files on a subsequent run
+- Support images which depend on each other
--
Simon Glass <sjg@chromium.org>
--
2.37.1.595.g718a3a8f04-goog
next prev parent reply other threads:[~2022-08-18 8:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 8:16 [PATCH 1/2] binman: Mention split-elf in the main docs Simon Glass
2022-08-18 8:16 ` Simon Glass [this message]
2022-08-27 1:59 ` [PATCH 2/2] binman: Document how to handle dependent images Simon Glass
2022-08-27 1:59 ` [PATCH 1/2] binman: Mention split-elf in the main docs 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=20220818081647.210263-2-sjg@chromium.org \
--to=sjg@chromium.org \
--cc=alpernebiyasak@gmail.com \
--cc=quentin.schulz@theobroma-systems.com \
--cc=u-boot@lists.denx.de \
--cc=xdrudis@tinet.cat \
/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).