I've been automating the process in doc/README.chromium-chainload and
while experimenting with whether a "kernel" image with u-boot-spl and
u-boot would work, noticed I couldn't align/offset/pad the two parts.
E.g. in something like the following, binman doesn't add the necessary
padding to place the "u-boot" to the correct offset within the
"kernel-1" data:
fit {
description = "example";
images {
kernel-1 {
description = "U-Boot with SPL";
type = "kernel";
arch = "arm64";
os = "linux";
compression = "none";
u-boot-spl {
};
u-boot {
offset = <CONFIG_SPL_PAD_TO>;
};
};
};
};
Not sure if that'll ever be really necessary besides my experiment, but
it doesn't seem like skipping the padding was a deliberate choice, so
here are some fixes I wrote for that.
Changes in v2:
- Add test to check that sections ignore hash*, signature* nodes
- Move section padding test to the end of file
- Renumber tests to accommodate for the first patch's new test
- Use 'section' instead of 'image' for FIT subimage sections
- Also rename 'Members:' comment for the renamed _fit_content variable
- Clarify comments around FIT subimage section/content processing
- Don't check for section.ObtainContents() returning False (never does)
v1: https://patchwork.ozlabs.org/project/uboot/list/?series=197693
Alper Nebi Yasak (3):
binman: Ignore hash*, signature* nodes in sections
binman: Respect pad-before property of section subentries
binman: Build FIT image subentries with the section etype
tools/binman/etype/fit.py | 41 +++++++------
tools/binman/etype/section.py | 4 +-
tools/binman/ftest.py | 37 ++++++++++++
.../165_section_ignore_hash_signature.dts | 40 +++++++++++++
tools/binman/test/166_pad_in_sections.dts | 26 +++++++++
.../test/167_fit_image_subentry_alignment.dts | 57 +++++++++++++++++++
6 files changed, 186 insertions(+), 19 deletions(-)
create mode 100644 tools/binman/test/165_section_ignore_hash_signature.dts
create mode 100644 tools/binman/test/166_pad_in_sections.dts
create mode 100644 tools/binman/test/167_fit_image_subentry_alignment.dts
--
2.28.0
