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.
I know it would be better to allow cross-image collections, etc. but that is not implemented at present.
Regards, SImon