With of-platdata-inst we want to set up a reference to each devices'
parent device, if there is one. If we find that the device has a parent
(i.e. is not a root node) but it is not in the list of devices being
written, then we cannot create the reference.
Report an error in this case, since it indicates that the parent node
is either missing a compatible string, is disabled, or perhaps does not
have any properties because it was not tagged for SPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
The return value '-ENOSPC' of fit_set_timestamp function does not match
the caller fit_image_write_sig's expection which is '-FDT_ERR_NOSPACE'.
Fix it by not calling fit_set_timestamp, but call fdt_setprop instead.
This fixes a following mkimage error:
| Can't write signature for 'signature@1' signature node in
| 'conf@imx6ull-colibri-wifi-eval-v3.dtb' conf node: <unknown error>
| mkimage Can't add hashes to FIT blob: -1
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Tested-by: Igor Opaniuk <igor.opaniuk@foundries.io>
When "mkimage -l" was run on a block device it would fail with
erroneous message, because fstat reports a size of zero for those:
mkimage: Bad size: "/dev/sdb4" is not valid image
This patch identifies the "is a block device" case and reports it as
such, and if it knows how to determine the size of a block device on
the current OS, proceeds.
As shown in
http://www.mit.edu/afs.new/sipb/user/tytso/e2fsprogs/lib/blkid/getsize.c
this is no portable task, and I only handled the case of a modern
Linux kernel, which is what I can test.
Signed-off-by: Yann Dirson <yann@blade-group.com>
- Move to gcc-11.1.0 builds from kernel.org for supported platforms and
LLVM-11 for those tests.
- As Heinrich has noted, the RISC-V platform specification has a profile
OS-A for running rich operating systems like Linux and BSD. This profile
requires 64bit and UEFI conforming to the EBBR. Only the 'embedded'
profile may use 32bit. Given this, drop grub for 32bit RISC-V as it no
longer compiles with gcc-11.1 and upstream is unlikely to fix it:
https://www.mail-archive.com/grub-devel@gnu.org/msg30736.html
- Update to grub-2.06 release to address other issues of building with
gcc-11.1.
- Update to newer Xtensa (gcc-9.2.0) and ARC (gcc-10.2) toolchains
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Rick Chen <rick@andestech.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
In commit 1e4687aa47 ("binman: Use target-specific tools when
cross-compiling"), a utility function was implemented to get preferred
compilation tools using environment variables like CC and CROSS_COMPILE.
Although it intended to provide custom default tools (same as those in
the global Makefile) when no relevant variables were set (for example
using "gcc" for "cc"), it is only doing so when CROSS_COMPILE is set and
returning the literal name of the tool otherwise.
Remove the check for an empty CROSS_COMPILE, which makes the function
use it as an empty prefix to the custom defaults and return the intended
executables.
Fixes: 1e4687aa47 ("binman: Use target-specific tools when cross-compiling")
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Move us up to being based on Ubuntu 20.04 "focal" and the latest tag
from Ubuntu for this release. For this, we make sure that "python" is
now python3 but still include python2.7 for the rx51 qemu build as that
is very old and does not support python3.
Signed-off-by: Tom Rini <trini@konsulko.com>
The filesystem and EFI (capsule and secure boot) test setups try to use
guestmount and virt-make-fs respectively to prepare disk images to run
tests on. However, these libguestfs tools need a kernel image and fail
with the following message (revealed in debug/trace mode) if it can't
find one:
supermin: failed to find a suitable kernel (host_cpu=x86_64).
I looked for kernels in /boot and modules in /lib/modules.
If this is a Xen guest, and you only have Xen domU kernels
installed, try installing a fullvirt kernel (only for
supermin use, you shouldn't boot the Xen guest with it).
This failure then causes these tests to be skipped in CIs. Install a
kernel package in the Docker containers so the CIs can run these
tests with libguestfs tools again (assuming the container is run with
necessary host devices and privileges). As this kernel would be only
used for virtualization, we can use the kernel package specialized for
that. On Ubuntu systems kernel images are not readable by non-root
users, so explicitly add read permissions with chmod as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add DM (device manager) firmware image to the fit image that is loaded by
R5 SPL. This is needed with the HSM rearch where the firmware allocation
has been changed slightly.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
Add support for providing ATF load address with a Kconfig symbol.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-2-a-govindraju@ti.com
For scenarios like OF_BOARD or OF_PRIOR_STAGE, no device tree blob is
provided in the U-Boot build phase hence the binman node information
is not available. In order to support such use case, a new Kconfig
option BINMAN_STANDALONE_FDT is introduced, to tell the build system
that a device tree blob containing binman node is explicitly required
when using binman to package U-Boot.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
It needs a space around '-a'.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Rick Chen <rick@andestech.com>
At present we sometimes see problems in gitlab where the environment has
0x80 characters or sequences which are not valid UTF-8.
Avoid this by using bytes for the environment, both internal to buildman
and when writing out the 'env' file. Add a test to make sure this works
as expected.
Reported-by: Marek Vasut <marex@denx.de>
Fixes: e5fc79ea71 ("buildman: Write the environment out to an 'env' file")
Signed-off-by: Simon Glass <sjg@chromium.org>
There have been at least a few cases where an exception has occurred in a
thread and resulted in buildman hanging: running out of disk space and
getting a unicode error.
Handle these by collecting a list of exceptions, printing them out and
reporting failure if any are found. Add a test for this.
Signed-off-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>
Use an interator in two of the fmap tests so it is easier to add new
items. Also check the name first since that is the first indication
that something is wrong. Use a variable for the expected size of the
fmap to avoid repeating the code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Parse each empty-line-delimited message separately. This saves having to
deal with all the different line content styles, we only care about the
header ERROR | WARNING | NOTE...
Also make checkpatch print line information for a uboot specific
warning.
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Given that we have tests that require pygit2 and it can be installed
like any other python module, fail much more loudly if it is missing.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
At present each invocation of run_steps() updates OUTPUT_FILES_COMMON,
since it does not make a copy of the dict. This is fine for a single
invocation, but for tests, run_steps() is invoked many times.
As a result it may include unwanted items from the previous run, if it
happens that a test runs twice on the same CPU. The problem has not been
noticied previously, as there are few enough tests and enough CPUs that
is is rare for the 'wrong' combination of tests to run together.
Fix this by making a copy of the dict, before updating it. Update the
tests to suit, taking account of the files that are no-longer generated.
With this fix, we no-longer generate files which are not needed for a
particular state of OF_PLATDATA_INST, so the check_instantiate() function
is not needed anymore. It has become dead code and so fails the
code-coverage test (dtoc -T). Remove it.
Signed-off-by: Simon Glass <sjg@chromium.org>
These two tests require an ELF image so that symbol information can be
written into the SPL/TPL binary. At present they rely on other tests
having set it up first, but every test must run independently. This can
cause occasional errors in CI.
Fix this by setting up the required files, as other tests do.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
It's not always desirable to use 'keydir' and some ad-hoc heuristics
to get the filename of the signing key. More often, just passing the
filename is the simpler, easier, and logical thing to do.
Since mkimage doesn't use long options, we're slowly running out of
letters. I've chosen '-G' because it was available.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
mkimage supports rsa2048, and rsa4096 signatures. With newer silicon
now supporting hardware-accelerated ECDSA, it makes sense to expand
signing support to elliptic curves.
Implement host-side ECDSA signing and verification with libcrypto.
Device-side implementation of signature verification is beyond the
scope of this patch.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
fdt_add_bignum() is useful for algorithms other than just RSA. To
allow its use for ECDSA, move it to a common file under lib/.
The new file is suffixed with '-libcrypto' because it has a direct
dependency on openssl. This is due to the use of the "BIGNUM *" type.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
rsa-checksum.c sontains the hash_calculate() implementations. Despite
the "rsa-" file prefix, this function is useful for other algorithms.
To prevent confusion, move this file to lib/, and rename it to
hash-checksum.c, to give it a more "generic" feel.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Skip the processing of *.aml and *.dat files while iterating through the
source in order to process header files.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
strn(cat|cpy) has a bad habit of not nul-terminating the destination,
resulting in constructions like
strncpy(foo, bar, sizeof(foo) - 1);
foo[sizeof(foo) - 1] = '\0';
However, it is very easy to forget about this behavior and accidentally
leave a string unterminated. This has shown up in some recent coverity
scans [1, 2] (including code recently touched by yours truly).
Fortunately, the guys at OpenBSD came up with strl(cat|cpy), which always
nul-terminate strings. These functions are already in U-Boot, so we should
encourage new code to use them instead of strn(cat|cpy).
[1] https://lists.denx.de/pipermail/u-boot/2021-March/442888.html
[2] https://lists.denx.de/pipermail/u-boot/2021-January/438073.html
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Show short arguments along with long arguments in online help:
$ tools/mkeficapsule -h
Usage: mkeficapsule [options] <output file>
Options:
-f, --fit <fit image> new FIT image file
-r, --raw <raw image> new raw image file
-i, --index <index> update image index
-I, --instance <instance> update hardware instance
-K, --public-key <key file> public key esl file
-D, --dtb <dtb file> dtb file
-O, --overlay the dtb file is an overlay
-h, --help print a help message
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Bitmap files should not be executable.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Fix the warning by set the variable zero to uint64_t
"warning: ‘write’ reading 5 bytes from a region of size 4"
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Integrate the Dockerfile from
https://source.denx.de/u-boot/gitlab-ci-runner.git as of
commit bc6130d572f1 ("Dockerfile: Remove high UID/GID") and introduce a
short rST on how to build the container.
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
This existing code assumes that a reg property is larger than one cell,
but this is not always the case. Fix this assumption.
Also if a node's parent is missing the #address-cells and #size-cells
properties we use 2 as a default for each. But this should not happen in
practice. More likely the properties were removed for SPL due to there
being no 'u-boot,dm-pre-reloc' property, or similar. Add a warning for
this as the failure can be very confusing.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present an empty size is considered to be a 64-bit value. This does not
seem useful and wastes space. Limit the 64-bit detection to where one or
both of the addr/size is two cells or more.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present warnings are shown as soon as they are discovered in the
source scannner. But the function that detects them may be called multiple
times.
Collect all the warnings and show them at the end.
Signed-off-by: Simon Glass <sjg@chromium.org>
The environment may contain some unicode characters. At least that is what
seemed to happen on one commit:
Building current source for 1 boards (0 threads, 64 jobs per thread)
0 0 0 /1 -1 (starting)
Traceback (most recent call last):
File ".../tools/buildman/buildman", line 64, in <module>
ret_code = control.DoBuildman(options, args)
File "tools/buildman/control.py", line 372, in DoBuildman
options.keep_outputs, options.verbose)
File ".../tools/buildman/builder.py", line 1704, in BuildBoards
results = self._single_builder.RunJob(job)
File ".../tools/buildman/builderthread.py", line 526, in RunJob
self._WriteResult(result, job.keep_outputs, job.work_in_output)
File ".../tools//buildman/builderthread.py", line 349, in _WriteResult
print('%s="%s"' % (var, env[var]), file=fd)
UnicodeEncodeError: 'ascii' codec can't encode characters in position
311-312: ordinal not in range(128)
The problem defies repetition with any change at all to buildman. But
let's set an encoding in any case.
Signed-off-by: Simon Glass <sjg@chromium.org>
While we cannot know which commit the warning relates to, this should not
be fatal. Print the warning and carry on.
Signed-off-by: Simon Glass <sjg@chromium.org>
On Arm-based Macs, -no_pie is ignored and gives a linker warning.
Moreover, the build falls over with:
ld: Absolute addressing not allowed in arm64 code but used in '_image_type_ptr_aisimage' referencing '_image_type_aisimage'
for dumpimage and mkimage, since we put data structs in text sections
not data sections and so cannot have dynamic relocations. Instead, move
the sections to __DATA and drop disabling PIE.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add a few more internal checks to make sure offsets are correct, before
updating the dtb.
To make this easier, update the functions which add a property to return
that property,.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far we have only needed to add subnodes to empty notds, so have not
had to deal with ordering. However this feature is needed for binman's
expanded nodes, since there may be another node in the same section.
While libfdt adds new properties after existing properties, it adds new
subnodes before existing subnodes. This means that we must reorder the
nodes in the cached version, so that the ordering remains consistent.
Update the sync implementation to sync existing subnodes first, then
add new ones, then tidy up the ordering in the cached version. Update the
test to cover this behaviour.
Also improve the comment about property syncing while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new test that adds a subnode alongside an existing one, as well as
adding properties to a subnode. This will expand to adding multiple
subnodes in future patches. Put a node after the one we are adding to so
we can check that things sync correctly.
The testAddNode() test should be in the TestNode class since it is a node
test, so move it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Once the tree has been synced, thus potentially moving things around in the
fdt, we set _cached_offsets to False so that a refresh will happen next
time a property is accessed.
This 'lazy' refresh doesn't really save much time, since refresh is a very
fast operation, just a single walk of the tree. Also, having the refresh
happen in the bowels of property access it makes it harder to figure out
what is going on.
Simplify the code by always doing a refresh before and after a sync. Set
_cached_offsets to True immediately after this, in the Refresh() function,
since this makes more sense than doing it in the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
If a property does not yet have an offset, then that means it exists in
the cache'd fdt but has not yet been synced back to the flat tree. Use
the dirty flag for this so we don't need to check the offset too. Improve
the comments for Prop and Node to make it clear what an offset of None
means.
Also clear the dirty flag after the property is synced.
Signed-off-by: Simon Glass <sjg@chromium.org>
