This ensures the dependencies match across musl and glibc
(From OE-Core rev: ad0b81bffc18f9bd60daac12dd00c56a6ef022f9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add 0001-contrib-spec-filters-obs-usr-bin-sh-bin-sh.patch to fix:
ERROR: quilt-0.69-r0 do_package_qa: QA Issue: /usr/share/quilt/spec-filters/obs contained in package quilt requires /usr/bin/sh, but no providers found in RDEPENDS:quilt? [file-rdeps]
(From OE-Core rev: 05665175f7f9ed75be226034434753ee9e0af3be)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Rebased Makefile-ptest.patch for 6.15
* License-Update: Update copyright year from 2024 to 2025
(From OE-Core rev: 3cb2541fa48118fb545545670dae1cd39a9e7ee3)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
This function creates an emptysrc recipe, but S points to a directory
that doesn't exist and bitbake warns about this.
As it is under the temporary working directory which will be deleted
later, create it to silence the warning.
(From OE-Core rev: 103cc8fa8a09b8e1fadeb0c8dde5f99eb9c24243)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If there are multiple source trees in a project (incredibly common with
go-mod, for example) then the relative path of the LICENSE file from
the source tree could just be "LICENSE", which is not useful when there
are tens of files across the recipe with that name.
Show the parent directory name too, to clarify which file is unknown.
(From OE-Core rev: 9679f4055ad5a077c6b06aa6125cee4e8fa93471)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will be used in bitbake-setup official configurations and
it will be awesome.
(From OE-Core rev: ee80c4f013052950ebc4107a2aa4f9ffc1b28975)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As far as I can tell, we don't have anything using lz4 in our key
build dependencies. It isn't in ASSUME_PROVIDED and our code automatically
adds lz4-native dependencies where needed. Even then, it is very rarely
needed, mainly for some kinds of SRC_URI (none in OE-Core) and some
filesystems/images.
As such, drop this from HOSTTOOLS and rely on lz4-native, which is what
was already happening anyway. This simplies host setup slightly.
(From OE-Core rev: b13654a4fc2fe6397f1802c14b2c6ad44b59a45b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are reports this class has been broken since mickledore which suggests
there are limited numbers of users. It doesn't have any automated testing
and it would be hard to setup and maintain a testing environment for it. The
original users/manintainers aren't using it now.
For those reasons, drop from OE-Core as we're not in a good position to
maintain it. I'd suggest anyone wanting to use it creates a dedicated layer
with maintainers who are in a position to test/develop it appropriately since
it is standalone code.
(From OE-Core rev: ecf8c386cf83ea235bdc4ee0da6671a395a4c358)
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>
qemu USB devices under KVM currently cause reset loop
in u-boot. If u-boot USB support is disabled then
u-boot just ignores the qemu USB devices which
then work with Linux kernel as before.
Issue has been reported to u-boot upstream in:
https://lists.denx.de/pipermail/u-boot/2025-June/591233.html
(From OE-Core rev: ade1069ece5f964edaa7115681d8dbc484ff2c81)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Booting u-boot on qemu with kvm is currently hanging on aarch64
build host. Root cause is in u-boot and CONFIG_BLOBLIST can be
disabled as a workaround.
To reproduce, build on kvm enabled host where "kvm-ok"
succeeds. For example genericarm64 machine and core-image-base
should then boot with:
$ runqemu slirp nographic novga snapshot kvm
On qemuarm64, default kvm setup will boot directly to kernel
and is not affected by this. If build enables u-boot as bios
then the same issue happens.
Without this config workaround, the boot hangs without
any messages in qemu output but ctrl-a-c to qemu console
can shutdown the emulated machine.
This seems to have regressed after u-boot 2025.04 update.
KVM boot can be detected from speed, for example genericarm64
boots in 550 ms with KVM and without in over 5 seconds.
Fixes: [YOCTO #15872]
Upstream u-boot discussion:
https://lists.denx.de/pipermail/u-boot/2025-May/590101.html
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
(From OE-Core rev: c5fa4320e666a0606b18be8f0a08e659170568f2)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes using this class are designed to be pulled in by dependencies and
the recipe doesn't build unless the kernel is appropriately configured. Mark
as not suitable for world builds as a result to avoid world build failures.
(From OE-Core rev: fc4834a8deae27579897d86d82c6f2335636a092)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The integration of the FIT image-related build steps into the kernel
recipe has proven to be not very good. The new implementation with
kernel-fit-image.bbclass fixes some design issues:
* sstate does not work well when a fitImage contains an initramfs. The
kernel is rebuilt from scratch if the build runs from an empty TMPDIR.
* A fitImage kernel is not available as a package, but all other kernel
image types are.
* The task dependencies in the kernel are very complex and difficult to
debug if something goes wrong. As a separate, downstream recipe, this
is now much easier.
The long storry about this issue is here:
[YOCTO #12912]
(From OE-Core rev: deb6bc3bea30dadabdb580a7a58a3b2e277af400)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel.bbclass is no longer involved in FIT image creation. Whether a
FIT image is built now depends entirely on whether the linux-yocto-fitimage
recipe (or any other recipe capable of producing a FIT image) is selected
for the build.
As a result, specifying the kernel image type "fitImage" in
KERNEL_IMAGETYPE or KERNEL_IMAGETYPES is no longer necessary and gets
removed.
(From OE-Core rev: ec606ef2879ddba750e275dae4dc8ab1e943b259)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove the test cases for the kernel-fitimage.bbclass.
(From OE-Core rev: c699dc66fd30cdfc5a3d53997107b870b9e4af65)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rewrite the kernel-fitimage.bbclass file in Python. This allows the
reuse of the new fitimage Python library and a clear alignment of the
two implementations.
Actually, the motivation for an implementation in Python was different.
During the transition from the kernel-fitimage.bbclass to the new
linux-yocto-fitimage.bb, the existing shell code was rewritten in Python
so that the fitimage.py library could be extracted. The new
kernel-fit-image.bbclass and linux-yocto-fitimage.bb were then developed
on this basis.
This approach makes it possible to run the same tests for all different
implementations:
- kernel-fitimage.bbclass in Shell
- kernel-fitimage.bbclass in Python
- linux-yocto-fitimage.bb
Changing the commit order now enables a smooth transition. The two
implementations can coexist. Maintenance and testing should be feasible
for a few months with reasonable effort as they share most of the code.
But of course, the goal is to remove the kernel-fitimage.bbclass as soon
as possible.
This commit opens the path for different strategies going forward:
- Just replace the old implementations with the new one and ignoring
this commit.
- Add the new implementation and keep the old implementation without any
change.
- Add the new implementation and this commit and support the old
architecture sharing most of the code with the new architecture and
implementatiion.
(From OE-Core rev: 6b513a530fcc6d99463fd824bb7208043f59414b)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
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>
