At present binman returns success when told to handle missing/faked blobs
or missing bintools. This is confusing since in fact the resulting image
cannot work.

Use exit code 103 to signal this problem, with a -W option to convert
it to a warning.

Rename the flag to --ignore-missing since it controls bintools also.

Add documentation about exit codes while we are here.

Signed-off-by: Simon Glass <sjg@chromium.org>

Collect and thereby initialize bintools before any usage but after
generation of entries. This is needed to handle bintools for compress
and decompress like other bintools.

Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

At present fake files from a previous build appear to be real files for
a subsequent build, since they sit in the output directory.

This can cause problems, since binman may need to parse the file, e.g.
with the Intel description.bin files.

Fix this by putting them in a 'binman-fake' subdirectory. Keep a track
of the fake filename so we only create it once. Subsequent builds will
still see that the file is missing and mark it as fake.

Update a few tests to check the behaviour.

Signed-off-by: Simon Glass <sjg@chromium.org>

When an image has the 'allow-repack' property, binman includes the
original offset and size properties from the image description in the
fdtmap. These are later used as the packing constraints when replacing
entries in an image, so other unconstrained entries can be freely
positioned.

Replacing an entry in an image without 'allow-repack' (and therefore the
original offsets) follows the same logic and results in entries being
merely concatenated. Instead, skip resetting the calculated offsets and
sizes to the missing originals for these images so that every entry is
constrained to its existing offset/size.

Add tests that replace an entry with smaller or equal-sized data, in an
image that doesn't allow repacking. Attempting to do so with bigger-size
data is already an error that is already being tested.

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>

Leave the 'expand' term for use by entry types which have an expanded
version of themselves. Rename this method to indicate that it generates
subentries.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>

Fix pylint errors that can be fixed and mask those that seem to be
incorrect.

A complication with binman is that it tries to avoid importing libfdt
(or anything that imports it) unless needed, so that things like help
still work if it is missing.

Note that two tests are duplicated in binman and two others have
duplicate names, so both of these issues are fixed also.

Signed-off-by: Simon Glass <sjg@chromium.org>

Convert this file to snake case and update all files which use it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Convert this file to snake case and update all files which use it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Each bintool has some documentation which can be useful for the user.
Add a new command that collects this and writes it into a .rst file.

Signed-off-by: Simon Glass <sjg@chromium.org>