Binman interfaces allow attempts to replace any entry in the image with
arbitrary data. When trying to replace sections, the changes in the
section entry's data are not propagated to its child entries. This,
combined with how sections rebuild their contents from its children,
eventually causes the replaced contents to be silently overwritten by
rebuilt contents equivalent to the original data.
Add a simple test for replacing a section that is currently failing due
to this behaviour, and mark it as an expected failure. Also, raise an
error when replacing a section instead of silently pretending it was
replaced.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When reading images from a file, each entry's data is read from its
parent section as specified in the Entry.Create() call that created it.
The FIT entry type has been creating its subentries under its parent
(their grandparent), as creating them under the FIT entry resulted in an
error until FIT was converted into a proper section.
FIT subentries have their offsets relative to the FIT section, and
reading those offsets in the parent section results in wrong data. The
subentries rightfully belong under the FIT entries, so create them
there. Add tests checking that we can extract the correct data for a FIT
entry and its subentries.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Binman entries can use other executables to compute their data, usually
in their ObtainContents() methods. Subclasses of Entry_section would use
bintools in their BuildSectionData() method instead, which is called
from several places including their Pack().
These binary tools are resolved correctly while building an image from a
device-tree description so that they can be used from these methods.
However, this is not being done when replacing entries in an image,
which can result in an error as the Pack() methods attempt to use them.
Collect and resolve entries' bintools also when replacing entries to fix
Pack() errors. Add a way to mock bintool usage in the testing entry type
and tests that check bintools are being resolved for such an entry.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Binman can embed a copy of the image description into the images it
builds as a fdtmap entry, but it omits the /binman/<image-name> prefix
from the node paths while doing so. When reading an already-built image
file, entries are reconstructed using this fdtmap and their associated
nodes still lack that prefix.
Some entries like fit and vblock create intermediate files whose names
are based on an entry unique name. This name is constructed from their
node's path by concatenating the parents with dots up to the binman
node, e.g. /binman/image/foo/bar becomes 'image.foo.bar'.
However, we don't have this /binman/image prefix when replacing entries
in such an image. The /foo/bar entry we read when doing so erroneously
has the unique name of '/.foo.bar', causing permission errors when the
entry attempts to create files based on that.
Fix the unique-name generation by stopping at the '/' node like how it
stops at the binman node. As the unique names are used as filenames, add
tests that check if they're safe to use as filenames.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Adds the support of the pre-load header with the image signature
to binman.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Some boards need to load an ELF file using the 'loadables' property, but
the file has segments at different memory addresses. This means that it
cannot be supplied as a flat binary.
Allow generating a separate node in the FIT for each segment in the ELF,
with a different load address for each.
Also add checks that the fit,xxx directives are valid.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Unfortunately mkimage gets upset with zero-sized files. Update the
ObtainContents() method to support specifying the size, if a fake blob is
created.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
At present the fit implementation creates the output tree while
scanning the FIT description. Then it updates the tree later when the
data is known.
This works, but is a bit confusing, since it requires mixing the scanning
code with the generation code, with a fix-up step at the end.
It is actually possible to do this in two phases, one to scan everything
and the other to generate the FIT. Thus the FIT is generated in one pass,
when everything is known.
Update the code accordingly. The only functional change is that the 'data'
property for each node are now last instead of first, which is really a
more natural position. Update the affected test to deal with this.
One wrinkle is that the calculated properties (image-pos, size and offset)
are now added before the FIT is generated. so we must filter these out
when copying properties from the binman description to the FIT.
Most of the change here is splitting out some of the code from the
ReadEntries() implementation into _BuildInput(). So despite the large
diff, most of the code is the same. It is not feasible to split this patch
up, so far as I can tell.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The word 'expand' is used for entries which generate subentries. It is
also used for entries that can have an '_expanded' version which is used
to break out its contents.
Rather than talking about expanding an entry's size, use the term
'extending'. It is slightly more precise and avoids the above conflicts.
This change renders the old 'expand-size' property invalid, so add an
error check for that.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
This allows to prefill fdt and config nodes with hash and signature
subnodes. It's just important to place the child nodes last so that
hashes do not come before the data - would be disliked by mkimage.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present we only support expanding out FDT nodes. Make the operation
into an @operation property, so that others can be supported.
Re-arrange and tidy up the documentation so that it has separate
headings for each topic.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a file that has two text sections at different addresses, so we can
test this behaviour in binman, once added.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add an entry for OP-TEE Trusted OS 'BL32' payload.
This is required by platforms using Cortex-A cores with TrustZone
technology.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add missing-blob-help, renumber the test file, update entry-docs:
Signed-off-by: Simon Glass <sjg@chromium.org>
Binman's FIT entry type can have image subentries with "hash" subnodes
intended to be processed by mkimage, but not binman. However, the Entry
class and any subclass that reuses its implementation tries to process
these unconditionally. This can lead to an error when boards specify
hash algorithms that binman doesn't support, but mkimage supports.
Let entries skip processing these "hash" subnodes based on an instance
variable, and set this instance variable for FIT subsections. Also
re-enable processing of calculated and missing properties of FIT entries
which was disabled to mitigate this issue.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Binman keeps track of binary tools each entry wants to use. The
implementation of this for the FIT entry only adds "mkimage", but not
the tools that would be used by its subentries.
Register the binary tools that FIT subentries will use in addition to
the one FIT itself uses, and check their existence by copying the
appropriate method from Section entry type. Also add tests that check if
these subentries can use and warn about binary tools.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We can and should run the node generator only when creating a new image.
When we read it back, there is no need to generate nodes - they already
exits, and binman does not dive that deep into the image - and there is
no way to provide the required fdt-list. So store the mode in the image
object so that Entry_fit can simply skip generator nodes when reading
them from an fdtmap.
This unbreaks all read-backs of images that contain generator nodes in
their fdtmap. To confirm this, add a corresponding test case.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Add SPDX to dts file:
Signed-off-by: Simon Glass <sjg@chromium.org>
Since this is a list of blobs, each blob should have the ability to be
faked, as with blob-ext. Update the Entry base class to set allow_fake
and use the base class in the section code also, so that this propagagtes
to blob-ext-list, which is not a section.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this does not check that the external data is in the expected
place. Use a non-zero offset for the external data and check it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use a unique number instead of the current 203, which is used by 203_fip
as well. Reformat the code to avoid a long line.
Signed-off-by: Simon Glass <sjg@chromium.org>
While converting to binman for an imx8mq board, it has been found that
building in the u-boot CI fails. This is because an imx8mq requires an
external binary (signed_hdmi_imx8m.bin). If this file cannot be found
mkimage fails.
To be able to build this board in the u-boot CI a binman option
(--fake-ext-blobs) is introduced that can be switched on via the u-boot
makefile option BINMAN_FAKE_EXT_BLOBS. With that the needed dummy files are
created.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This format is used in firmware binaries so we may as well supported it.
With this patch binman supports creating, listing and updating FIPs, as
well as extracting files from one, provided that an FDTMAP is also present
somewhere in the image.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes it is useful to have a list of related external blobs in a
single entry. An example is the DDR binaries used by meson. There are
9 files in total. Add support for this, so we don't have to have a
separate entry for each.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases entries encapsulate other data and it is useful to access
the data within. An example is the fdtmap which consists of a 16-byte
header, followed by a devicetree.
Provide an option to specify an alternative format when extracting files.
In the case of fdtmap, this is 'fdt', which produces an FDT file which can
be viewed with fdtdump.
Signed-off-by: Simon Glass <sjg@chromium.org>
WIth EFI we must embed the devicetree in an ELF image so that it is loaded
as part of the executable file. We want it to include the binman
definition in there also, which in some cases cannot be created until the
ELF (u-boot) is built. Add an option to binman to support writing the
updated dtb to the ELF file u-boot.out
This is useful with the EFI app, which is always packaged as an ELF file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Binman needs to be able to update the contents of an ELF file after it has
been build. To support this, add a function to locate the position of a
symbol's contents within the file.
Fix the comments on bss_data.c and Symbol while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some images may take a while to build, e.g. if they are large and use slow
compression. Support compiling sections in parallel to speed things up.
Signed-off-by: Simon Glass <sjg@chromium.org>
(fixed to use a separate test file to fix flakiness)
Add an entry for RISC-V OpenSBI's 'fw_dynamic' firmware payload.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Rick Chen <rick@andestech.com>
Reviewed-by: Rick Chen <rick@andestech.com>
Currently there are 2 binman test cases using the same 172 number.
It seems that 172_fit_fdt.dts was originally named as 170_, but
commit c0f1ebe9c1 ("binman: Allow selecting default FIT configuration")
changed its name to 172_ for no reason. Let's change it back.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When used with hierarchical images, use the Chromium OS convention of
adding a section before all the subentries it contains.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes it is useful to specify the default alignment for all entries
in a section, such as when word-alignment is necessary, for example. It
is tedious and error-prone to specify this individually for each section.
Add a property to control this for a section.
Signed-off-by: Simon Glass <sjg@chromium.org>
Generally the content of sections is not built until the final assembly
of the image. This is partly to avoid wasting time, since the entries
within sections may change multiple times as binman works through its
various stages. This works quite well since sections exist in a strict
hierarchy, so they can be processed in a depth-first manner.
However the 'collection' entry type does not have this luxury. If it
contains a section within its 'content' list, then it must produce the
section contents, if available. That section is typically a sibling
node, i.e. not part oc the collection's hierarchy.
Add a new 'required' argument to section.GetData() to support this. When
required is True, any referenced sections are immediately built. If this
is not possible (because one of the subentries does not have its data yet)
then an error is produced.
The test for this uses a 'collection' entry type, referencing a section as
its first member. This forces a call to _BuildSectionData() with required
set to False, at first, then True later, when the image is assembled.
Signed-off-by: Simon Glass <sjg@chromium.org>
The vblock entry type includes code to collect the data from a number of
other entries (not necessarily subentries) and concatenating it. This is
a useful feature for other entry types.
Make it a base class, so that vblock can use it, along with other entry
types.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present there is a command-line flag to disable substitution of expanded
entries. Add an option to the entry node as well, so it can be controlled
at the node level.
Add a test to cover this. Fix up the comment to the checkSymbols() function
it uses, while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
When creating an entry, check for an expanded version of that entry, then
use it instead. This allows, for example use of:
u-boot {
};
instead of having to write out in full:
u-boot {
type = "section";
u-boot-nodtb {
};
u-boot-dtb {
};
};
Add an implementaion of this and associated documentation.
Signed-off-by: Simon Glass <sjg@chromium.org>
A few tests declare a type when this can be inferred from the node name.
Drop these lines, since it might cause confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
This entry holds the padding between the end of of TPL binary and the
end of BSS. This region must be left empty so that the devicetree can be
appended correctly and remain accessible without interfering with BSS.
Signed-off-by: Simon Glass <sjg@chromium.org>
Since this is an execuable we should be able insert symbol values into it.
Add support for this.
Use common code for this test and the original testSymbols. Use hex
consistently for the values and add some more comments.
Signed-off-by: Simon Glass <sjg@chromium.org>
The offset of an entry needs to be adjusted by its skip-at-start value.
This is currently missing when reading entry data. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
When packing files it is sometimes useful to align the start of each file,
e.g. if the flash driver can only access 32-bit-aligned data. Provides a
new property to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present if a devicetree blob is included in a vblock it does not deal
with updates. This is because the vblock is created once at the start and
does not have a method to update itself later, after all the entry
contents are finalised.
Fix this by adjusting how the vblock is created.
Also simplify Image.ProcessEntryContents() since it effectively duplicates
the code in Section.ProcessContents().
Signed-off-by: Simon Glass <sjg@chromium.org>
Normally when an entry is created, any entry arguments it has are required
to be provided, so it can actually generate its contents correctly.
However when an existing image is read, Entry objects are created for each
of the entries in the image. This happens as part of the process of
reading the image into binman.
In this case we don't need the entry arguments, since we do not intend to
regenerate the entries, or at least not unless requested. So there is no
sense in reporting an error for missing entry arguments.
Add a new property for the Image to handle this case. Update the error
reporting to be conditional on this property.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present binman only supports resolving symbols in the same section as
the binary that uses it. This is quite limited because we often need to
group entries into different sections.
Enhance the algorithm to search the entire image for symbols.
Signed-off-by: Simon Glass <sjg@chromium.org>
With the previous changes, it is now possible to compress entire
sections. Add some tests to check that compression works correctly,
including updating the metadata.
Also update the documentation.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present padding of sections is inconsistent with other entry types, in
that different pad bytes are used.
When a normal entry is padded by its parent, the parent's pad byte is
used. But for sections, the section's pad byte is used.
Adjust logic to always do this the same way.
Note there is still a special case in entry_Section.GetPaddedData() where
an image is padded with the pad byte of the top-level section. This is
necessary since otherwise there would be no way to set the pad byte of
the image, without adding a top-level section to every image.
Signed-off-by: Simon Glass <sjg@chromium.org>
Check the contents of each section to make sure it is actually in the
right place.
Also fix a whitespace error in the .dts file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we use 'compress' as the property to set the compression of
a 'files' entry. But this conflicts with the same property for entries,
of which Entry_section is a subclass.
Strictly speaking, since Entry_files is in fact a subclass of
Entry_section, the files can be compressed individually but also the
section (that contains all the files) can itself be compressed. With this
change, it is possible to express that.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this feature is tested view the end-at-4gb feature. Add some
tests of its own, including the operation of padding.
The third test here shows binman's current, inconsistent approach to
padding in the top-level section. Future patches in this series will
address this.
Signed-off-by: Simon Glass <sjg@chromium.org>
