Call super().__str__ to get the bulk of the string representation, and
we don't need to guard on output/strerr existing as they always set.
(From OE-Core rev: 2adcac16dd26fd054ea779cc4e7aa32282d9bdde)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a test case to boot target system via u-boot
using qemu with KVM. This was broken recently
and workaround proposed to u-boot. Test case
works with genericarm64 and qemuarm64 target machines
compiled and tested on aarch64 build host with KVM
support.
Test execution time with full sstate cache is
around 170 seconds. qemu boot itself takes just
a few seconds to full userspace.
(From OE-Core rev: dce900b029607d12ad55de35741f245beb409b47)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To limit tests to specific build host architectures.
For example KVM testing will only work if target and
build architectures are the same.
(From OE-Core rev: c59b74b8bfd3b351a31204f33e00351ad5e5b657)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the new KernelFitImageRecipeTests class the one that contains the
code, and keep the KernelFitImageTests class as the one that just adds
back the same tests. This will make it easier to delete the tests later,
which will hopefully become obsolete when the kernel-fitimage.bbclass
class is no longer needed.
(From OE-Core rev: 622c446c7c6139ed12c2fa2d9cffa108a85f4390)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Run all existing tests for kernel-fitimage.bbclass also with the new
linux-yocto-fitimage recipe.
Executing each test for both implementations helps ensure functional
compatibility and consistency between them.
This change will naturally double the test duration for FIT image-related
tests, as each test now runs against both implementations. However, the
goal is to eventually deprecate kernel-fitimage.bbclass, at which point
the duplicate tests can be removed.
Additionally, since the new implementation makes significantly more
efficient use of the sstate cache compared to the old one, the overall
test execution time may still be improved.
(From OE-Core rev: d966939e1758cb1a978f486219f642bf67c8ad48)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable all existing tests to be compatible with FIT images generated
either by the new linux-yocto-fitimage recipe or the legacy
kernel-fitimage.bbclass approach.
- Make the following configurations optional:
- KERNEL_IMAGETYPES += "fitImage"
- KERNEL_CLASSES = "kernel-fitimage"
- Allow the tests to specify which kernel recipe should be used for the
build (e.g., linux-yocto, linux-yocto-fitimage, etc.)
(From OE-Core rev: 20cbb095f8685848aa5e31d04006b9842b387912)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having the FIT image generator code as a separate class, which is
essentially independent of BitBake, also allows testing the code
separately from BitBake. Take advantage of this enables testing more
use cases with significantly faster tests.
(From OE-Core rev: f990d95007a616bdafbe80c30877d3bdfd954c05)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the ITS file is created, the mandatory properties are written first
before the optional properties are written.
This is not really useful for the current implementation. But it is a
preparation for a new Python-based implementation that will expect
mandatory properties first. This change makes it possible to run the
tests with both the old and the new implementation.
(From OE-Core rev: 1044366a32d544af53307a03d7d3b0aaf4519990)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is closer to practice to use static and predictable keys to sign the
FIT images. In addition, the new kernel-signing-keys-native is only
reliable if the temporary directory is not deleted. However, depending
on how this test suite is started, this can happen.
There will therefore only be one test that uses the recipe to generate
the keys, which ensures that the recipe works in principle.
It is also ensured that no keys are present before the test and that the
recipe runs safely and is not skipped by Bitbake.
(From OE-Core rev: 97e58d7c2bc1943f0696fc72984788f459f7f7c4)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add some test coverage for non default FIT_CONF_DEFAULT_DTB.
(From OE-Core rev: d9ae846307b640f6c85a67dee405cbaa6258efd4)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a test which does not use the default FIT_CONF_PREFIX configuration.
(From OE-Core rev: 12f20ddefe0393eea8d1c3534058596f3407b5f5)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are several ways to insert external devicetrees and devicetree
overlays into the kernel and thus at least to some extent into the FIT
image.
So far there is no test coverage. Let's improve this as much as possible
without fully understanding all use cases.
This first test adds a devicetree overlay to a build configuration
without signing, since signing is apparently not yet meaningful when
PREFERRED_PROVIDER_virtual/dtb = “bborg-relay-00a2” is used. It is also
not entirely clear how these external devicetree overlays are used by
the configuration nodes of the FIT image. Currently, one configuration
is created per dtb dtbo node, which is not really useful for dtbo nodes.
Before this test can be extended to test devicetree overlays and
signing, the code that creates the configuration nodes in its file
probably needs some improvements in terms of more flexibility in
defining the references from configuration nodes to image nodes.
(From OE-Core rev: 3442d9297dcab400dfe8db93790e049778e0abdb)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Cargo.toml lock for guessing-game, used to test maturin has a minor security
advisory which keeps tripping up github's automated security analysis, "PyO3
Risk of buffer overflow in `PyString::from_object`".
Bump the minimum version requirement for pyo3 to avoid this warning even if it
isn't anything critical and just automated tests.
(From OE-Core rev: 2e817e6e4d53543766b935479b148a1950cc37c8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The project is switching the way handle our CDN provision of sstate objects,
update the URL accordingly.
(From OE-Core rev: fea96974f1ee6ae6dceb39e3ca8157797d81586c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When working on large diffs (eg in meta-oe's repro test) diffoscope may
use a huge amount of memory and trigger OOM kills on parallel builds.
Use the max_diff_block_lines_saved option to limit to 1024 the number of
diff lines saved in a block. Also, limit the number of line in the
report to generate a report even when the limit is reached.
The chosen default 1024 comes from diffoscope default for a diff block.
For a random 10MB binary (packaged in ipk, deb and rpm), this does
decrease the "Maximum resident set size" of diffoscope from 1.3GB to
400MB.
As an added bonus, this also make diffoscope bail out earlier, on the
same example: execution time goes from 30 minutes down to 7.
Fixes [YOCTO #15876]
(From OE-Core rev: 04cbcfc7e09d19b0ba50e7940fc82d10e222fdbe)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was one failure occurring in rust testing for qemuriscv64. Exclude
that test so we can enable in automated testing.
(From OE-Core rev: a7f6ea5b20aa91e4a1b00dbea7a6447effb9220d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, pseudo tracks all files referenced within its presence unless
they're listed in an exclusion list. The exclusion list has grown to be
fairly unwieldy.
This patch swaps PSEUDO_IGNORE_PATHS for PSEUDO_INCLUDE_PATHS which in
theory should be easier and more explicit to maintain.
This change does drop many directories from pseudo coverage including
/home and /tmp. There may be adapatations needed for recipes/classes
using pseudo in specific ways.
(From OE-Core rev: 2502da81709f25de499277b28d33c915638c45f6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Search config.log for the correct host_alias assignment to verify that
configure has correctly identified the host system.
(From OE-Core rev: ade66073a1c89918f849eb2932c05342e8f3ab4f)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need to copy files inside setUpClass() when there's only one
test function that uses it. Just do all of the test inside the test.
(From OE-Core rev: 5474677b21f2f4069f355abdc600483c42d0b0b3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test assumed that maturin would only find a single Python binary, in
/usr/bin/python3*.
However in eSDKs with buildtools a Python is shipped with the SDK, so
the test failed.
Generalise the test so that it runs python3 and obtains its path and
version, and then verifies that path and and version are found by
Maturin. This means we're not assuming a single Python, or the paths, or
that the Python is CPython.
(From OE-Core rev: ae9b5dae77ef140422fcf71d239ca028c9208447)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use 'meson introspect' to dump JSON describing the build configuration
and validate that the target architectures and cross-compiler is
correctly set.
(From OE-Core rev: 1c84361829921e91d782b189e2bde818a2d1491c)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
galculator hasn't been touched for a decade now[1] and fails to compile
under GCC 15.
Switch to building libhandy, which is the GTK+3 precursor to libadwaita
in the Gnome stack. Whilst this is in low-maintainence mode, will be
updated if it breaks.
[1] https://github.com/galculator/galculator/
(From OE-Core rev: ff6fa71eb0511d8594c4416a37d75a85470ff9c6)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refactor this test case so the generic "build a meson project" code is
separated out and can be reused.
Also currently meson inside eSDKs only works with fully populated eSDKs,
but our testing uses minimal eSDKS, so skip the test if the eSDK is a
minimal build. A bug has been filed to resolve this.
(From OE-Core rev: 575e0bf52db0467d88af4b5fe467b682f10ca62a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
At the moment we can't run this test inside an eSDK as it needs the
kernel-devsrc recipe to be present. Skip the test until this has been
resolved.
(From OE-Core rev: f83beee6e63d25ef2b17618a85f9ad6ca0898600)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Clean up lots of dependency checking code by using the new helpers.
This means that a lot of tests that were previously skipped inside the
eSDK testing on the autobuilder are now executed, and fail.
(From OE-Core rev: 11277efd057685558a744e98082b5709e849dd2a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The existing tests simply look at the manifest to determine if a test
should be ran or not based on dependencies. Whilst this works for
Traditional SDKs, it fails for Extensible SDKs if they've been built in
minimal mode, where the manifest will be empty. However, minimal eSDKs
might well have available sstate to install the missing dependencies.
Add a pair of helper functions to ensure that a package is available, or
skip the test. This handles nativesdk- vs -native (SDK vs eSDK) and
will try to sdk-install missing dependencies into an eSDK if they're not
already installed.
(From OE-Core rev: d0e8b83d05957b1f22d08582e364afa4b522801e)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a test that builds a SDK with specific packages in the host and
target sections, and verifies that they're listed in the manifest.
(From OE-Core rev: a1556c801feb56b79243ba2947b74b84f674072b)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Simple test to sanity check that the generated SDK manifest was parsed
correctly and isn't empty.
This test is complicated by the fact that minimal eSDKs without a
toolchain do in fact have an empty manifest, so also check for that.
(From OE-Core rev: 43288b19e93f0c07b347d6e5d6f7f10e96219f96)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This subclass overrides hasHostPackage() but back in 2018[1] the parent
class's method gained a regex argument.
[1] oe-core 595e9922cdb ("oeqa/sdk: fixes related to hasPackage semantics")
(From OE-Core rev: cfd1e0a8c8d294510fca1a800ab27e4f1e2292bf)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
hasTargetPackage has some logic to automatically multilibify package
names if needed (for example, so that gtk+3 becomes lib32-gtk+3).
Due to a logic bug if multilib was True but there were no multilibs
configured then this prepended "-" to the package name, which won't
exist. This resulted in tests being skipped as the dependent packages
are not installed.
Solve this by only prepending to the package name if requested and if a
multilib environment has been detected.
(From OE-Core rev: 2abb146dd81f677176923ebb3188f5b7c034ed68)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Following the usage of TEST_SUITES in testimage, add TESTSDK_SUITES to
specify the list of tests to execute. By default the variable is empty,
which means to run all discovered tests.
This makes it easier to work on a single test without having to run all
of the tests.
(From OE-Core rev: 28d437c52c77889b2ede0fc2f2d6777c5b0a553d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Test recipe git repo URL is checked for newer commits and
mtd-utils-selftest check is sometimes failing due to server
errors. Use pseudo which uses Yocto Project in git servers
which should be reliable.
Fixes: [YOCTO #15855]
build/build-st-17692/tmp/hosttools"; export HOME="/srv/pokybuild"; git -c gc.autoDetach=false -c core.pager=cat -c safe.bareRepository=all -c clone.defaultRemoteName=origin ls-remote git://git.infradead.org/mtd-utils.git failed with exit code 128, output:
fatal: read error: Connection reset by peer
(From meta-yocto rev: a82be5486058c2e5a1e286dba17c33444889c982)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All qemu machines have ext4 in IMAGE_FSTYPES which makes
native mkfs.ext4 available at wic image build time.
genericarm64 defaults to only wic in IMAGE_FSTYPES
and this test was failing:
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing python function set_image_size
| DEBUG: 148548.400000 = 114268 * 1.300000
| DEBUG: 652644.400000 = max(148548.400000, 8192)[148548.400000] + 504096
| DEBUG: 652645.000000 = int(652644.400000)
| DEBUG: 652645 = aligned(652645)
| DEBUG: returning 652645
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_wic
| INFO: Creating image(s)...
|
| ERROR: A native program mkfs.ext4 required to build the image was not found (see details above).
|
| Please make sure wic-tools have e2fsprogs-native in its DEPENDS, build it with 'bitbake wic-tools' and try again.
|
| WARNING: exit code 1 from a shell command.
NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
(From OE-Core rev: 59b5ec3d53058237dc6f3e85385851d1a8a97f97)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This test is failing on genericarm64 which includes all kernel
modules on rootfs by default. Recently added kernel modules
triggered the size limits to be exceeded. Fixes:
ERROR: Actual rootfs size (112884 kB) is larger than allowed size 102400 kB
Doubling the size to avoid issues like this on machines which
may include a lot of packages on default images. Size of the
rootfs does not matter for the test, only that the offsets are
correct in various usecases.
(From OE-Core rev: 1ff542318ea66514ef550d4817ba9b2ef688134c)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The wic test_exclude_path_with_extra_space does not succeed on debian-based
AB workers since they, by default, do not install the 'parted' utility. This
test installs the 'wic-tools' package, which includes the 'parted' utility,
but it is not being found/used for some unknown reason.
In the previous patch it was believed that doing some extra PATH handling
(as performed by some other tests with a python try...finally block) would
solve the issue. That turned out to not be the case. This patch starts by
reverting that change, since it has no benefit.
In order to use the native tools from the 'wic-tools' package, wic's
'--native-sysroot' can be used (as demonstrated in other tests). In fact
the wic help message explaining the purpose of this flag states that it is
for passing "...the path to the native sysroot containing the tools(parted
and mtools) to use"[sic].
Removing the host's 'parted' utility better simulates the situation found
on the debian workers for testing. This patch is seen to make this test pass
with no host 'parted' utility in place.
(From OE-Core rev: 306e4831f07d4a8db6ab880487813a6abd0ffa08)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Older versions do not compile with GCC 15. We had different versions to test
GPLv3 exclusion.
1.21 compiles with gcc 15 and 1.20.2 has a CFLAGS tweak to allow it to work
with gcc 15 too.
1.21 is licensed under GPL-2.0 so we need to rework some of the tests.
Tweak the gplv3 test by adding a special override of LICENSE to then test
the license exclusion code.
Modify the archiver selftests to use the new version.
Based on a patch from Khem Raj <raj.khem@gmail.com>
(From OE-Core rev: 3b17355ad1ecad17d12c5eb0e6403a59ef11f7d7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The wic test_exclude_path_with_extra_space test succeeds on non-debian AB
workers. Add PATH handling so parted from the wic-tools can be found on
debian-based AB workers.
Fixes [YOCTO #15838]
(From OE-Core rev: 3994e727f10c5a0143d52bdd6e1d9ca037296d59)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the test whitespace to avoid bitbake warnings.
(From OE-Core rev: 8a324aa2111872138715bde7fbc86bcfc2d8b20e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the *.wks file contains a "--source rootfs" then
lib/wic/plugins/source/rootfs.py will be invoked to generate (what is assumed
to be) the rootfs partition. If the rootfs partition needs to be tweaked or
modified, the "rootfs.py" plugin will make a copy of the filesystem and then
perform the changes on that copy. In other words, if the "--source rootfs"
line of the *.wks file also contains any of:
--exclude-path
--include-path
--change-directory
--use-label (i.e. modify etc/fstab)
then the rootfs will be copied first, then the copy is modified.
If, for example, the unmodified IMAGE_ROOTFS is:
.../tmp/work/qemuarm64_secureboot-oe-linux/core-image-base/1.0/rootfs
then the copy would be made at:
.../tmp/work/qemuarm64_secureboot-oe-linux/core-image-base/1.0/tmp-wic/rootfs${LINENO}
where ${LINENO} is the line number where this "--source rootfs" line appears
in the *wks file.
When it comes time to make an actual partition of a specific filesystem type,
lib/wic/partition.py::prepare_rootfs() is called. It is in this function that
wic figures out if any extra size needs to be added. The bitbake variable used
to specify the ultimate rootfs size is ROOTFS_SIZE, and since this variable is
only valid for the rootfs (and not any other partitions), the code also
verifies that the partition being created is ${IMAGE_ROOTFS}:
rsize_bb = get_bitbake_var('ROOTFS_SIZE')
rdir = get_bitbake_var('IMAGE_ROOTFS')
if rsize_bb and rdir == rootfs_dir:
<use rsize_bb>
else:
<calculate the partition size using "du -ks $p">
As noted above, if lib/wic/plugins/source/rootfs.py has made a copy, then the
"rdir == rootfs_dir" clause will fail and the code will assume this partition
is not a rootfs since the strings do not compare equal.
Therefore, in order to determine if this is a rootfs, retain the existing
"rdir == rootfs_dir" comparison, but also add another one to check whether or
not this is a wic-generated copy of the rootfs.
STEPS TO REPRODUCE:
- start with the following *wks file:
bootloader --ptable gpt
part /boot --size=100M --active --fstype=ext4 --label boot
part / --source rootfs --fstype=ext4 --label root
- and the following extra variable in conf/local.conf:
IMAGE_ROOTFS_EXTRA_SPACE = "500000"
- build an image
- run it in qemu
$ runqemu slirp nographic serial
- verify the root partition has extra space:
root@qemuarm64-secureboot:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 721.5M 67.4M 600.6M 10% /
devtmpfs 477.7M 0 477.7M 0% /dev
tmpfs 40.0K 0 40.0K 0% /mnt
tmpfs 489.3M 92.0K 489.2M 0% /run
tmpfs 489.3M 68.0K 489.2M 0% /var/volatile
/dev/vda1 120.4M 19.9M 91.4M 18% /boot
- modify the "/" line of the *wks file to be:
part / --source rootfs --fstype=ext4 --label root --exclude-path boot/
- build image
when it fails:
root@qemuarm64-secureboot:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 73.4M 41.9M 25.8M 62% /
devtmpfs 477.7M 0 477.7M 0% /dev
tmpfs 40.0K 0 40.0K 0% /mnt
tmpfs 489.3M 92.0K 489.2M 0% /run
tmpfs 489.3M 68.0K 489.2M 0% /var/volatile
/dev/vda1 120.4M 19.9M 91.4M 18% /boot
after this fix:
root@qemuarm64-secureboot:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 721.5M 47.4M 620.6M 7% /
devtmpfs 477.7M 0 477.7M 0% /dev
tmpfs 40.0K 0 40.0K 0% /mnt
tmpfs 489.3M 92.0K 489.2M 0% /run
tmpfs 489.3M 68.0K 489.2M 0% /var/volatile
/dev/vda1 120.4M 19.9M 91.4M 18% /boot
Doing the math we see that the /boot partition is ~20MB and in the first image
the / partition contains this ~20MB in addition to the rest of the rootfs.
This ~20MB is completely wasted since it is used in the / partition, but then
the /boot partition is mounted on top of it, making the /boot directory of /
inaccessible. After the fix the / partition has an additional ~20MB since the
/boot portion is excluded.
Fixes [YOCTO #15555]
(From OE-Core rev: 1c690aa046ebca13d7b29de50d42b5d8a4a8486c)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream has released a new version (4.4) but not the tarball for it.
Adjust one of the devtool selftests, as it requires that the recipe
under test is using a tarball. Another selftest also needs to be
tweaked to correctly clean up its modifications to that same recipe on
test completion.
(From OE-Core rev: de635a9bc0392689ff36b50e7f91572d3fbaac09)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The base-files test for SPDX 2.2 did not give good coverage, since
base-files doesn't have any dependencies. Add building tar as another
test which more fully exercises the code
(From OE-Core rev: d678e25419c89e09c1c438363bf3a940ce903d43)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cpio is not yet buildable with C23 standard which is default with
GCC 15, therefore ensure to apply needed bandage to keep it compiling
in C17 mode even with GCC 15
(From OE-Core rev: 0c637099887f1be421c8e1203f99631a1e040150)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running, e.g., `devtool reset sdbus-c++` would result in the following
error:
re.error: multiple repeat at position 35
This was due to the ++ in the recipe name, which would be treated as an
incorrect regular expression in _reset().
Use re.escape() to make sure all characters in the recipe name are
treated literally.
(From OE-Core rev: 6e73bd9b3e6d529752db93879f2c0ed53873dd1a)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a new test function which checks that the device-tree of U-Boot
contains the public keys which are required for checking the signature
of the kernel FIT image at run-time.
Use this new _check_kernel_dtb function in the existing
test_sign_cascaded_uboot_fit_image test case which already creates a
build configuration with UBOOT_SIGN_ENABLE = "1" and keys for the kernel.
But so far there was no check that the keys for the kernel verification
got added to U-Boot's DTB.
This test case checks the configuration where only the configuration
nodes of the kernel FIT image are signed.
A new test case test_sign_uboot_kernel_individual checks the
configuration with two keys and signed image and signed configuration
nodes.
This test case covers the use case which recently broke with commit:
OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e
u-boot: kernel-fitimage: Fix dependency loop if
UBOOT_SIGN_ENABLE and UBOOT_ENV enabled
and got fixed with commit
OE-Core rev: 0106e5efab99c8016836a2ab71e2327ce58a9a9d
u-boot: kernel-fitimage: Restore FIT_SIGN_INDIVIDUAL="1"
behavior
This patch also fixes a few more details:
- Simplify the code by moving all the U-Boot related variables to the
_fit_get_bb_vars function.
- Do not set FIT_GENERATE_KEYS = "1" without inheriting the
kernel-fitimage.bbclass which handles this variable.
(From OE-Core rev: dda1fcbc85c26d1851dda6ed235238b15939998e)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the code slightly more robust by using e.g.
bb_vars.get('UBOOT_SIGN_ENABLE') instead of bb_vars['UBOOT_SIGN_ENABLE']
for variables which are potentially undefined.
This is a general cleanup but also a preparation for additional test
cases.
Log bb_vars in verbose mode.
Drop one no longer used log message.
(From OE-Core rev: 22a554e1d5a2449c4c1b34f4d5cfe1572a72a142)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
