| Age | Commit message (Collapse) | Author |
|---|
|
This consistency reads a bit nicer.
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
|
|
It was "... doing the same build ... will not trigger a rebuild".
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
|
|
Reads better.
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
|
|
It might not be clear what is meant with "to make sure the shell leaves it alone".
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
|
|
It reads a bit nicer.
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
|
|
riscv was missing from the list.
To some, the architecture's name may not be obvious from the code name.
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
|
|
Strictly speaking, "has" doesn't make sense.
"supports" seems like a better word and it probably was what the original author meant.
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
|
|
Otherwise, the two dashes are rendered as just one.
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
|
|
These are fixes to what looks like obvious typos.
Some minor improvments are also included, such as:
- Write "symbolic link" instead of symlink
- Correct capitalization for LLVM (all caps)
- Remove dead link and surrounding sentence
Signed-off-by: Adriano Carvalho <adrianocarvalho.pt@gmail.com>
|
|
Free the allocated buffer in case of an error.
Fixes: 9e63786e2b4b ("tools: mkeficapsule: rework the code a little bit")
Addresses-Coverity-ID: 345917 Resource leak
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Jerome Forissier <jerome.forissier@linaro.org> says:
Two small fixes for binman (bintool). The first patch avoids a warning,
the second one makes sure the APT package list is up-to-date when
running apt_install(). That one fixes a CI issue I encountered.
Link: https://lore.kernel.org/r/20250724091342.59902-1-jerome.forissier@linaro.org
|
|
'apt-get update -y' may be required to make sure that the list of
packages is up-to-date and that the subsequent 'apt-get install'
operations can find the requested packages.
Fixes the following CI error:
Fetch: zstd
- trying method: binary download
- sudo apt-get install -y zstd
Exception: Error 100 running 'sudo apt-get install -y zstd': E: Unable to locate package zstd
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
The 'apt' command is not meant to be used in scripts or tools. Please
see the man page [1] for details. Therefore, use 'apt-get' instead.
This avoids the following warning:
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
[1] https://manpages.debian.org/bookworm/apt/apt.8.en.html#SCRIPT_USAGE_AND_DIFFERENCES_FROM_OTHER_APT_TOOLS
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
The statement that prints the ELF object type value assumes that "%lx"
(long unsigned int, hexadecimal) is suitable for printing a uint64_t
typed value. While this may seem to work for some machines, ie. amd64,
it isn't ideal on a 32-bit system, such as x86 where uint64_t is likely
to be equivalent to a long long unsigned int, as indicated by:
../tools/mips-relocs.c:275:34:
warning: format '%lx' expects argument of type 'long unsigned int',
but argument 2 has type 'uint64_t'
{aka 'long long unsigned int'} [-Wformat=]
275 | printf("type 0x%lx\n", ehdr_field(e_type));
| ~~^
| |
| long unsigned int
| %llx
As the ehdr_field function-like macro expands to a uint64_t value,
it is better to use the PRIx64 macro in place of "%lx" to ensure that
the correct format string introducer is specified for the actual type
hiding behind uint64_t.
A similar issue is also present in the report of .rel section overflow,
where "%lx" is used to print a few size_t typed values, and would be
better served by "%zx" instead.
Signed-off-by: Justin Swartz <justin.swartz@risingedge.co.za>
Fixes: 963014641117 ("MIPS: make size of relocation table fixed but configurable")
Fixes: 703ec9ddf965 ("MIPS: Stop building position independent code")
Cc: Paul Burton <paulburton@kernel.org>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
|
|
- Update to Ubuntu "Jammy" 20250714 tag
- Update to current Dockerfile which brings us QEMU 10.0.2 and newer
coreboot and pulls in lz4 via the non-legacy package name.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This series from myself brings CI up to using QEMU 10.0.2 for platforms.
We need to disable one test for now while a report to upstream QEMU is
resolved and also need to now update coreboot in order to be able to
build a version of it non-interactively (source locations have changed).
Link: https://lore.kernel.org/r/20250716001539.2483390-1-trini@konsulko.com
|
|
At this point there's problems rebuilding coreboot-24.08 without manual
intervention. Let us upgrade to a newer version.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
As QEMU 10.0.2 is the current release, update to that so that we can
update other features within CI.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This test was failing due to matching on Anatolij's old email address.
Switch to the new one.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Aristo Chen <jj251510319013@gmail.com> says:
This patch series introduces a validation step in `mkimage` to ensure that
the `default` property under the `/configurations` node in a FIT image
references a valid subnode. If the referenced node does not exist, mkimage
now prints an error and fails early. This helps prevent runtime failures
when U-Boot attempts to boot using an undefined configuration.
The first patch implements the validation logic in `fit_image.c`. The second
patch fixes an invalid default configuration reference exposed by this new
check in the `k3-am65-iot2050-boot-image.dtsi`. The final patch adds a test
case to verify that mkimage correctly fails when an invalid default
configuration is present in the ITS file.
This series improves the robustness of FIT image generation and helps
catch malformed image trees during build time.
Link: https://lore.kernel.org/r/20250715130317.3886-1-aristo.chen@canonical.com
|
|
When a FIT image declares a default configuration via the
'configurations/default' property, it must reference a valid subnode
under the /configurations node. If the named default does not exist,
U-Boot will fail to boot the image when no explicit configuration is
provided.
This patch adds a validation step in mkimage to check that the
referenced default configuration node is present. If not, mkimage will
print an error and abort.
This helps catch malformed or outdated ITS files early at build time
instead of deferring failure to runtime.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
|
|
To get the [] annotation working with python 3.7 and 3.8, import
annotations.
Reported-by: Tim Harvey <tharvey@gateworks.com>
Fixes: 21bc3433a43d ("binman: rework dropping absent entries from packaged image")
Reviewed-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Tested-by: Tim Harvey <tharvey@gateworks.com>
|
|
The GitHub dependabot tool has reported a number of issues recently with
some modules that we use. While unlikely to be exploitable in the way we
use them, update various libraries to the latest.
Reported-by: GitHub dependabot
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
i.MX95 B0 uses image container format v2, and `one container header
occupies 0x4000, so that CMD_CNTR_VERSION needs to be added.
The purpose of CMD_DUMMY_DDR is to create a dummy image entry in boot
container prior the DDR OEI image entry. ROM reads the address of DUMMY
DDR image entry and passes it to DDR OEI in OEI entry function as
parameter value, in order to indicate the offset of training data with
the boot container.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
|
|
In the Fixes commit, I initialized size_inc from the return value of
the new fit_estimate_hash_sig_size() helper. That helper may fail and
report that by returning a negative value, but I overlooked that
size_inc had type size_t, and hence the error check doesn't work.
Change size_inc to have type int so the error check works. Inside the
loop, it is passed to another function as a size_t parameter, but
that's fine, because we know it is non-negative, and its value may be
incremented in steps of 1024 and is capped at ~64K, so it will
certainly never overflow an int.
Fixes: 7d4eacb0e68 ("mkimage: do a rough estimate for the size needed for hashes/signatures")
Addresses-Coverity-ID: 569495: Integer handling issues (NEGATIVE_RETURNS)
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
|
|
These functions are only used locally. Enabling -Wmissing-prototypes
triggers a warning. Mark them as static.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
This functions is only used locally and triggers a warning when
compiling with -Wmissing-prototypes. Mark it as static.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
This function is only used locally. Enabling -Wmissing-prototypes triggers
a warning. Mark it as static.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
These functions are only used locally. Enabling -Wmissing-prototypes triggers
a warning. Mark them as static.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Add new etype which generates the Renesas R-Car Gen4 SA0 header.
This header is placed at the beginning of SPI NOR and describes
where should data from SPI NOR offset 0x40000 be loaded to, and
how much data should be loaded there. In case of U-Boot, this is
used to load SPL and possibly other payload(s) into RT-VRAM.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
pkg_resources is deprecated, use migration guide in [1] to migrate to
importlib.resources.
Keep the Python 3.6 backwards compatibility.
This also fixes the binman version test which failed for setuptools
versions that print the deprecation warning.
Change from __name__ to __package__ as with the transition from
pkg_resources to importlib_resources using __name__ results in
TypeErrors [2].
[1] https://importlib-resources.readthedocs.io/en/latest/migration.html
[2] https://github.com/python/importlib_resources/issues/60
Reviewed-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Yannic Moog <y.moog@phytec.de>
|
|
Commit 93b55636b09f ("tools: kwboot: Allow any baudrate on Linux") added a
tcgetattr() function to be used, instead of the libc's termios functions.
This was done to allow using the raw TCGETS2/TCSETS2 ioctls that allow to
support arbitrary baud rates.
This breaks the build for PowerPC, because that architecture does not have
a struct termios2 defined because the termios and ktermios are the same.
On PowerPC, the termios ioctl() emulates the TCGETS2/TCSETS*2 ioctls with
tcgetattr/tcsetattr using just the struct termios (that's as mentioned the
same than what is defined as struct termios2 in other architectures).
So there is no need to use the TCGETS2/TCSETS2 ioctls on that architecture
and just TCGETS/TCSETS ioctls with termios as defined by PowerPC is enough.
Fixes: 93b55636b09f ("tools: kwboot: Allow any baudrate on Linux")
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
This series from Ilias Apalodimas <ilias.apalodimas@linaro.org> largely
finishes the re-sync with the Linux Kernel v5.1 kbuild system.
Link: https://lore.kernel.org/r/20250627185723.342553-1-ilias.apalodimas@linaro.org
|
|
Our last sync with the kernel was 5.1. Even that was a partial one
as some patches from 4.x kernels were already missing making the
transition to a modern kbuild infeasible.
We are so out of sync now, that tracking the patches and backporting
them one by one makes little sense and it's going to take ages.
This is an attempt to sync up Makefile[.lib/.kbuild].
Unfortunately due to sheer amount of patches this is not easy to review,
but that's what we decided during a community call.
One of the biggest changes is get rid of partial linking entirely and
build .a archives isntead of .o.
We diaviate from the kernel on that. Instead of calling a custom script
to create the archive symbol table, we call ar with rcTP (isntead of
rcSTP) since we want a resulting archive that's sauble with the linker.
The only affected platforms are PPC ones. Unfortunately I don't have any
of them around to test, but the objdump of the resulting files --
arch/powerpc/lib/built-in.[oa] looks identical.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
|
|
key-name-hint in signature nodes"
Quentin Schulz <foss+uboot@0leil.net> says:
I misunderstood the documentation and put the signing key in a keys/
directory while setting key-name-hint property in the signature node and
u-boot-spl-pubkey-dtb to a path.
mkimage doesn't fail if it cannot find the public key when signing a
FIT but returns something on stderr to notify the user it couldn't find
the key. The issue is that bintool currently discards stderr if the
command successfully returns, so the FIT is not signed AND the user
isn't made aware of it unless the image is manually inspected.
mkimage does fail when trying to insert a public key in a DTB if it
isn't found but we can have a better error message.
Link: https://lore.kernel.org/r/20250418-binman-pubkey-dir-v2-0-b6b90a765ffe@cherry.de
|
|
key-name-hint with path
key-name-hint property in u-boot-spl-pubkey-dtb binman entry may contain
a path instead of a filename due to user mistake.
Because we currently assume it is a filename instead of a path, binman
will find the full path to the key based on that path, and return the
dirname of the full path but keeps the path in key-name-hint instead of
stripping the directories from it.
This means mkimage will fail with the following error message if we have
key-name-hint set to keys/dev:
binman: Error 1 running 'fdt_add_pubkey -a sha256,rsa2048 -k /home/qschulz/work/upstream/u-boot/keys -n keys/dev -r conf /home/qschulz/work/upstream/u-boot/build/ringneck/u-boot-spl-dtbdhsfx3mf': Couldn't open RSA certificate: '/home/qschulz/work/upstream/u-boot/keys/keys/dev.crt': No such file or directory
Let's make it a bit more obvious what the error is by erroring out in
binman if a path is provided in key-name-hint (it is named key-name-hint
and not key-path-hint after all).
Fixes: 5609843b57a4 ("binman: etype: Add u-boot-spl-pubkey-dtb etype")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
mkimage doesn't fail if it cannot find the public key but it prints to
stderr. Considering that btool.run() discards stderr, it means binman
happily returns an unsigned FIT and doesn't tell you something went
wrong.
Binman will actually find the file if there's a path in the
key-name-hint property but the current logic expects key-name-hint to be
a filename and thus returns the dirname of the found path for the key,
but with the original key-name-hint appended. This means we can have the
following:
- key-name-hint = "keys/dev"
- name = "/home/qschulz/work/upstream/u-boot/keys/"
so we pass /home/qschulz/work/upstream/u-boot/keys/ to the -k option of
mkimage but the FIT still contains "keys/dev" in key-name-hint which
means mkimage will try to find the key at
/home/qschulz/work/upstream/u-boot/keys/keys/, which doesn't exist.
Let's assume paths are simply not supported (it is named key-name-hint
and not key-path-hint after all) and raise an error if the property
contains a path so that the build fails and not quietly.
Fixes: 133c000ca334 ("binman: implement signing FIT images during image build")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Allow -w to be used with -i to do a build without a separate output
directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This option doesn't work as expected since it sets the cwd to the work
directory, which does not necessarily hold the source code.
It should be left unset, so that the current directory is the source
directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
When this utility was converted from run_pipe and to the new output
helper, two problems were introduced. First, the conversion for calling
"git rm -f" wasn't correct. Change this to match the other conversions.
Second, the final call we do we need to construct the list because we
print that command for the user to use to inspect remaining references.
Fixes: 3d094ce28a22 ("u_boot_pylib: Add a function to run a single command")
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Background:
I have several customers that will be using a certain remote signing
service for signing their images, in order that the private keys are
never exposed outside that company's secure servers. This is done via
a pkcs#11 interface that talks to the remote signing server, and all
of that works quite well.
However, the way this particular signing service works is that one
must upfront create a "signing session", where one indicates which
keys one will use and, importantly, how many times each key will (may)
be used. Then, depending on the keys requested and the customer's
configuration, one or more humans must authorize that signing session
So for example, if official release keys are to be used, maybe two
different people from upper management must authorize, while if
development keys are requested, the developer himself can authorize
the session.
Once authorized, the requester receives a token that must then be used
for signing via one of the keys associated to that session.
I have that integrated in Yocto in a way that when a CI starts a BSP
build, it automatically works out which keys will be needed (e.g. one
for signing U-Boot, another for signing a kernel FIT image) based on
bitbake metadata, requests an appropriate signing session, and the
appropriate people are then notified and can then look at the details
of that CI pipeline and confirm that it is legitimate.
The problem:
The way mkimage does FIT image signing means that the remote server
can be asked to perform a signature an unbounded number of times, or
at least a number of times that cannot be determined upfront. This
means that currently, I need to artificially say that a kernel key
will be used, say, 10 times, even when only a single FIT image with
just one configuration node is created.
Part of the security model is that once the number of signings using a
given key has been depleted, the authorization token becomes useless
even if somehow leaked from the CI - and _if_ it is leaked/compromised
and abused before the CI has gotten around to do its signings, the
build will then fail with a clear indication of the
compromise. Clearly, having to specify a "high enough" expected use
count is counter to that part of the security model, because it will
inevitably leave some allowed uses behind.
While not perfect, we can give a reasonable estimate of an upper bound
on the necessary extra size by simply counting the number of hash and
signature nodes in the FIT image.
As indicated in the comments, one could probably make it even more
precise, and if there would ever be signatures larger than 512 bytes,
probably one would have to do that. But this works well enough in
practice for now, and is in fact an improvement in the normal case:
Currently, starting with size_inc of 0 is guaranteed to fail, so we
always enter the loop at least twice, even when not doing any signing
but merely filling hash values.
Just in case I've missed anything, keep the loop incrementing 1024
bytes at a time, and also, in case the estimate turns out to be over
64K, ensure that we do at least one attempt by changing to a do-while
loop.
With a little debug printf, creating a FIT image with three
configuration nodes previously resulted in
Trying size_inc=0
Trying size_inc=1024
Trying size_inc=2048
Trying size_inc=3072
Succeeded at size_inc=3072
and dumping info from the signing session (where I've artifically
asked for 10 uses of the kernel key) shows
"keyid": "kernel-dev-20250218",
"usagecount": 9,
"maxusagecount": 10
corresponding to 1+2+3+3 signatures requested (so while the loop count
is roughly linear in the number of config nodes, the number of
signings is quadratic).
With this, I instead get
Trying size_inc=3456
Succeeded at size_inc=3456
and the expected
"keyid": "kernel-dev-20250218",
"usagecount": 3,
"maxusagecount": 10
thus allowing me to set maxusagecount correctly.
Update a binman test case accordingly: With the previous behaviour,
mkimage would try size_inc=0 and then size_inc=1024 and then
succeed. With this patch, we first try, and succeed, with 4*128=512
due to the four hash nodes (and no signature nodes) in 161_fit.dts, so
the image ends up 512 bytes smaller.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
|
|
supernodes"
Moteen Shah <m-shah@ti.com> says:
In the U-Boot pre-relocation stage, if the parent node lacks
bootph-all/bootph-some-ram property and the driver lacks a pre-reloc
flag, all of its subsequent subnodes gets skipped over from driver
binding—even if they have a bootph* property.
This series addresses the issue by scanning through all the nodes during
build time and propagating the applicable property to all of its supernode.
Link: https://lore.kernel.org/r/20250516114148.3862114-1-m-shah@ti.com
|
|
Add a testcase to ensure that scan_and_prop_bootph() actually
propagates bootph-* properties to supernodes.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
to supernodes
As per bootph schema, bootph-* property in child node should be
implied in their parent, but this feature is not implemented in
the U-Boot proper stage (before relocation) resulting in devices
not being bound because of the missing bootph-all or bootph-some-ram
property in the parent node.
To mitigate this issue, add a function to scan through all the nodes
in the device-tree for bootph-all and bootph-some-ram properties. If
found, propagate it to all of its parent nodes up the hierarchy.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
|
|
Yannic Moog <y.moog@phytec.de> says:
This series solves a contradiction regarding ext blobs packaged in
binman. When they are marked as optional, by default they are faked, two
messages are emitted. One says the image is not functional the other
says the image is still functional. Both concern the same binman
entry/blob.
Binman is set up to have fake external blobs in case they are missing.
This is regardless on whether they are optional or not.
The implementation does not allow different types of entries to override
the faking decision; at least there wouldn't be much sense in doing so.
Here is an example build output of a phycore-imx8mp:
BINMAN .binman_stamp
Image 'image' is missing optional external blobs but is still functional: tee-os
/binman/section/fit/images/tee/tee-os (tee.bin):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
Image 'image' has faked optional external blobs and is still functional: tee.bin
OFCHK .config
The output stays to inform/warn the user, but in this case the tee-os
entry will not be present in the final image.
Link: https://lore.kernel.org/r/20250613-binman_faked_optional-v3-0-1e23dd7c41a2@phytec.de
|
|
When external blobs are marked optional, they should not cause a
build to fail. Extend the test cases for FitTeeOsOptional and
ExtblobOptional.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
Some test cases don't use _DoTestFile directly which accepts
allow_fake_blobs. However, they specifically test functionality that
requires external blobs not to be faked. Extend the _DoReadFileDtb
signature to allow passing that option to _DoTestFile.
Also fix tests that require non-faked ext blobs.
By default, external blobs are faked. Some tests care only about more
basic functionality. In those cases no external blobs should be faked.
That would trigger a different (binman) case which is not in scope for
those particular tests.
Thus, disable faked blobs for those test cases.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
When having an entry that is marked as optional and is missing in the
final image, the following output is observed:
CFGS spl/u-boot-spl.cfgout
BINMAN .binman_stamp
Image 'image' has faked external blobs and is non-functional: tee.bin
Image 'image' is missing optional external blobs but is still functional: tee-os
/binman/section/fit/images/tee/tee-os (tee.bin):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
Some images are invalid
make: *** [Makefile:1135: .binman_stamp] Error 103
To solve this contradictory messaging, when checking the faked blob
list, remove entries that are allowed to be missing. Instead add an
info message for faked optional blobs. Also reduce verbosity of the
optional image warning to an info message.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
|
When blobs are absent and are marked as optional, they can be safely
dropped from the binman tree. Use the drop_absent function for that.
Rename drop_absent to drop_absent_optional as we do not want to drop any
entries that are absent; they should be reported by binman as errors
when they are missing.
We also reorder the processing of the image the following:
- We call the CheckForProblems function before the image is built.
- We drop entries after we checked for problems with the image.
This is okay because CheckForProblems does not look at the file we have
written but rather queries the data structure (image) built with binman.
This also allows us to get all error and warning messages that we want
to report while avoiding putting missing optional entries in the final
image.
As only the blobs are dropped, the sections still remain in the
assembled image. Thus add them to the expected test case checks where
necessary.
In addition, a rework of testPackTeeOsOptional test case is necessary.
The test did not really do what it was supposed to. The description said
that optional binary is tested, but the binary is not marked as
optional. Further, the tee.elf file, when included in the image
properly, also shows up in the image data. This must be added as well.
As there is no global variable for the elf data, set the pathname to the
elf file that was created when setting up the test suite.
For the test case get the filename and read the contents, comparing them
to the contents of the created binman image.
Signed-off-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Bryan Brattlof <bb@ti.com>
|
