KERNEL_MODULE_AUTOLOAD defines the list of the kernel modules to be autoloaded
on boot. kernel-module-split.bbclass generates the required modules.load.d and
conf files for each kernel module. This conf files inturn read by system service
to perform module loading and configuration. When a kernel module is added to
KERNEL_MODULE_AUTOLOAD the conf files must be generated in all cases.
When KERNEL_SPLIT_MODULES=0 modprobe and autoload conf files are not
getting generated for the kernel modules.
To fix that enhanced the class implementation by separating out conf
file handling mechanism in two functions, generate_conf_files() and
frob_metadata(). generate_conf_files() handles no-split case where as
frob_metadata() keeps handling the existing case for spliting the modules.
Splitted common handling/generation of conf files stuff in to handle_conf_files()
function which gets invoked by both frob_metadata() and generate_conf_files()
on top of the scenario specific handling done in respective functions.
This implementation covers generation of the conf files for in-tree kernel
modules as well as standalone kernel module built as seperate package/recipe.
[YOCTO #15145]
(From OE-Core rev: cf998576ccfd20a61a9afa6df27fb73d93c8ed9a)
Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These exports are made in bitbake.conf, we don't need to duplicate these
here. Clean up as was done in native/nativesdk.
(From OE-Core rev: 2ddf340be2c4f4b4424d137ba1e87269c2c36357)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When looking at bitbake parsing speed issues, I noticed a lot of weird looking
variables from the update-alternatives class. It is possible this was written
before variable dependencies could handle flags. It can handle flags now so
simplfy the code to take advantage of that and avoid the indirection variables.
The win here is a significant reduction in the number of variables, which
in turn significantly reduces the looping bitbake's taskhash calculation code
needs to do.
(From OE-Core rev: bd8fc4c59a137a37bd7a54f398949617982d447e)
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>
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>
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>
The new recipe linux-yocto-fitimage.bb and the new
kernel-fit-image.bbclass are intended to become successors of the
kernel-fitimage.bbclass.
Instead of injecting the FIT image related build steps into the kernel
recipe, the new recipe takes the kernel artifacts from the kernel recipe
and creates the FIT image as an independent task.
This solves some basic problems:
* 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 recipe takes the kernel artifacts from the deploy folder. There was
also a test implementation passing the kernel artifacts via sysroot
directory. This requires changes on the kernel.bbclass to make it
copying the artifacts also to the sysroot directory while the same
artifacts are already in the sstate-cached deploy directory.
The new class kernel-fit-extra-artifacts.bbclass generates and deploys
the kernel binary intended for inclusion in a FIT image.
Note that the kernel used in a FIT image is a stripped (and optionally
compressed) vmlinux ELF binary - not a self-extracting format like
zImage, which is already available in the deploy directory if needed
separately.
The kernel-fit-extra-artifacts.bbclass can be used like this:
KERNEL_CLASSES += "kernel-fit-extra-artifacts"
(if uImage support is not needed, or with :append otherwise)
The long story about this issue is here:
[YOCTO #12912]
(From OE-Core rev: 05d0c7342d7638dbe8a9f2fd3d1c709ee87d6579)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The function must be executed in CWD. Make it more flexible by
specifying the kernel build folder as a parameter.
This is a refactoring without functional change. But later this change
will allow to use this function also with a kernel from the sstate-cache
instead of requiring the full kernel build folder structure.
Another preparation for using a kernel from sstate-cache is to persist
the linux_comp variable in a file next to the linux.bin file rather than
using a global shell variable.
This change also requires to adapt the kernel-uimage.bbclass
accordingly. This change also fixes a minor detail:
the kernel-uimage.bbclass used ${ instead of $ for evaluatiing a local
shell variable.
(From OE-Core rev: 8ea95cd419ee4efac5f54124e2ce98304262e8c1)
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>
The do_kernel_generate_rsa_keys function from kernel-fitimage.bbclass
is moved to a new recipe, kernel-signing-keys-native.bb. This
refactoring introduces no functional changes.
Intention this change:
- Remove the dependency of uboot-sign.bbclass on kernel-fitimage.bbclass.
- Simplify the use of custom key generation implementations by
isolating the functionality into a separate recipe.
Known limitations of this (and also the previous) implementation:
- When generating from an existing TMPDIR, the existing key is reused.
However, when generating from an empty TMPDIR or an SDK using the
sstate-cache, a new key is generated, which may lead to
inconsistencies.
- The use of random keys (via FIT_GENERATE_KEYS) is convenient for
experiments but unsuitable for production environments requiring
deterministic and secure key management.
Future improvements to consider:
- Ensure reproducibility, even when using the sstate-cache. However,
simply storing the private key in a potentially shared sstate artifact
may not always be ideal from a security perspective.
- Support encrypted keys via `SRC_URI` for reliable key updates.
- Enable signing with an HSM (Hardware Security Module) through
mechanisms like PKCS#11 or post-processing scripts.
(From OE-Core rev: 88736bb53fd2f0ffa1d249fc1a37897d10c8be18)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Do not use the ${} bitbake syntax for shell internal variables
- Fix shellcheck SC2045 warning:
Iterating over ls output is fragile. Use globs.
- Improve error handling for dtc. Print the output, not only the exit
value.
(From OE-Core rev: f33ee0cfb3c664c4857c18271dd55981bc369cc1)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a regression introduced by the change to use
systemd-systemctl-native rather than a python fake implementation,
which caused template units to not be properly enabled when set in
the SYSTEMD_SERVICE variable. Through investigation, it seems that
the best way to re-enable template instances is to handle them
explicitly in the systemd.bbclass and enable them with `preset`, like
most units are handled[1,2].
Per the systemd.preset manpage, the format for template units is
different than for regular units[3]. We need to coalesce all the
template instances onto a single line and emit them as an additional
space-deliminated argument.
Ran this against openbmc's phosphor-ipmi-net recipe and generated
the following preset file:
```
$ cat packages-split/phosphor-ipmi-net/usr/lib/systemd/system-preset/98-phosphor-ipmi-net.preset
enable phosphor-ipmi-net@.service eth0
enable phosphor-ipmi-net@.socket eth0
```
[1]: https://lore.kernel.org/openembedded-core/Z2ch.1747051947055246176.oktf@lists.openembedded.org/
[2]: https://lore.kernel.org/openembedded-core/aDdoTVtCmElpURYD@heinlein/
[3]: https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html
Fixes: 7a580800db39 ("systemd: Build the systemctl executable")
(From OE-Core rev: f33d9b1f434e40a459614d8dc21ce45e11581008)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was removed by me without good reasons in commit
2f0ef8cd0e61c34e67ad9c7508094da3c23f5fce
"wic bootimg-efi.py: change UKI support from wic plugin to uki.bbclass"
and results in grub-efi binaries missing from
genereted ESP partition on qemux86-64.
Fixes oeqa selftest
overlayfs.OverlayFSEtcRunTimeTests.test_image_feature_is_missing
after wic detects missing EFI loader files on ESP partition.
Test case was passing due qemu syslinux boot using kernel directly
from /boot and not using UEFI firmware to boot.
Fixes: 2f0ef8cd0e61 ("wic bootimg-efi.py: change UKI support from wic plugin to uki.bbclass")
WKS_FILE_DEPENDS_BOOTLOADERS needs to list all EFI loaders because
it's used in DEPENDS and thus can't use conditional python macros
to select which loader is actually needed in sysroot when
wic builds the images and ESP partition.
(From OE-Core rev: c6eb09f45900367df01958ee7012e9de974b401f)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Call wic with --debug to capture logs from wic internals
so that it's clear which partitions get created and which
files get copied where. wic plugins contain for example
race conditions which don't install files at all and thus
images fail to boot and it's not possible to debug these without
something in wic task logs.
As an example core-image-initramfs-boot do_image_wic
log is now 576 lines which is not excessive but very
important when debugging problems, especially race
conditions which are only hit in some builds in CI.
With all issues I have to deal within wic, I always
need to apply this change before I get to see any
details what wic and its plugins are doing. Thus I
strongly believe this verbose outuput should be the
default.
(From OE-Core rev: de2187cc4cb8de0a8308708951ada36fa34da263)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
os-release was needed with UKI generation when this was done
using wic plugin but now with separate uki.bbclass wic does
not need it anymore.
(From OE-Core rev: 1b51677bff4f6cff6450010f6e5edd4f47693d82)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On x86 family builds, grub and systemd-boot are always included and thus
get built and deployed before wic image builds. On aarch64 builds
that was not the case. Result is that some builds added systemd-boot binaries
to the wic image ESP partition and some not, though bugs in wic plugins
contributed here too since missing files were silently ignored.
Boot of such images fails since firmware is not able to load the
default EFI binaries.
Adding EFI_PROVIDER to WKS_FILE_DEPENDS_BOOTLOADERS is not possible
because of parsing order so adding grub-efi and systemd-boot
to aarch64 and systemd-boot to arm depends
which makes sure their do_deploy is always executed
before wic image is generated. Thus systemd-boot and grub
binaries will get copied from deploy directory to the wic
image ESP partition, and boot of the images succeeds.
(From OE-Core rev: 9975b72291cd2e1ad79635e903e6a744251d91bf)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We aren't checking for this variable anymore, so remove it from the
setuptools3 and setuptools3_legacy classes.
(From OE-Core rev: d6ef6c50dd344a8cfc873c18216ba497735d8200)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the ability to set the "firmware" property in the FIT configuration node
by introducing the UBOOT_FIT_CONF_FIRMWARE variable.
This property defines the primary image to be executed during boot. If it is
set, its value will be written into the FIT configuration under the "firmware"
field. If not set, the bootloader will fall back to using the first entry in
the "loadables" list.
Using this property improves control over the boot sequence, especially in
multi-binary boot scenarios.
(From OE-Core rev: 82e1d7cbc855dbe4bec93f9b049851cbe376ea5e)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An unintended "-e" string may be written into the generated ITS file when users
set the UBOOT_FIT_USER_SETTINGS variable to include custom binaries in the U-Boot
image.
This issue is caused by the use of 'echo -e', which behaves inconsistently across
different shells. While bash interprets '-e' as enabling escape sequences
(e.g., \n, \t), dash—the default /bin/sh on many systems—does not recognize
'-e' and treats it as a literal string. As a result, "-e" can be mistakenly
injected into the ITS file under certain build environments.
To ensure consistent and shell-agnostic behavior, replace 'echo -e' with
'printf', which is well-defined by POSIX and behaves reliably across all common
shells.
This change improves portability and prevents malformed ITS files caused by unintended
string injection.
Fixes: c12e013 ("uboot-sign: support to add users specific image tree source")
(From OE-Core rev: 1d5d22a38188f2c879e289a9732b620b0a6f7a6e)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some recipes might provide conf files produced during build phase or
simply tracked in the VCS instead of generating them with Yocto.
In such cases those conf files wouldn't be assigned to correct packages.
With this change, if user wants to generate a conf file they still can,
but not generating them won't prevent assigning the file to proper
package given the file exists.
(From OE-Core rev: c7faf141592d1e2a5cab32a83f7e1498ee498d65)
Signed-off-by: Michal Sieron <michalwsieron@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
/etc/os-release is a symlink to /usr/lib.
Symlink is retrieved as a dead link which points to nowhere if also the
original file is not accompanying it.
Fetch the real file in addition to this link.
Alternative could be to use "tar -h" (supported also by busybox tar),
however that could lose some important information if links are relevant
for failure analysis.
(From OE-Core rev: ed43f9ccb3c08845259e24440912631afd780d12)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the task dependency:
do_uboot_assemble_fitimage -> virtual/kernel:do_kernel_generate_rsa_keys
to ensure the kernel FIT image signing keys are available when creating
the U-Boot DTB. This is done only if the signing of the kernel FIT image
is enabled (UBOOT_SIGN_ENABLE="1").
The lack of the dependency causes build errors when executing a build
with no kernel FIT keys initially present in the keys directory. In such
cases one would see an output like this in the Bitbake logs:
Log data follows:
| DEBUG: Executing shell function do_uboot_assemble_fitimage
| Couldn't open RSA private key: '/workdir/build/keys/fit/dev.key': No such file or directory
| Failed to sign 'signature' signature node in 'conf-1' conf node
| FIT description: Kernel Image image with one or more FDT blobs
| ...
This issue was introduced by commit 259bfa86f384 where the dependency
between U-Boot and the kernel was removed (for good reasons). Before
that commit the dependency was set via DEPENDS so that, in terms of
tasks, one had:
u-boot:do_configure -> virtual/kernel:do_populate_sysroot
and the chain leading to the key generation was:
virtual/kernel:do_populate_sysroot -> virtual/kernel:do_install
virtual/kernel:do_install -> virtual/kernel:do_assemble_fitimage
virtual/kernel:do_assemble_fitimage -> virtual/kernel:do_kernel_generate_rsa_keys
With the removal of the first dependency, no more guarantees exist that
the keys would be present when assembling the U-Boot FIT image. That's
the situation we are solving with the present commit.
Fixes: 259bfa86f384 ("u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enabled")
(From OE-Core rev: 036f20156b3c7d0a8b912e90aa29a9b986106d5a)
Signed-off-by: Rogerio Guerra Borin <rogerio.borin@toradex.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Sean Anderson <sean.anderson@seco.com>
Cc: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In testimage, the ptest-runner output parser expects test results to follow
a specific format,with lines beginning with PASS:, FAIL:, or SKIP:. ptest-cargo,
currently, does not emit any of those lines and the parser treats the test
section as having no results, causing a test failure with :
AssertionError:
ptests which had no test results:
['<package>']
This patch ensures that the recipes using ptest-cargo class explicitly emits
PASS: or FAIL: lines, making the results compatible with the test parser and
preventing test failures.
(From OE-Core rev: 6a9356346f13556a06d4a99bd7924992c7e29d66)
Signed-off-by: Ines KCHELFI <ines.kchelfi@smile.fr>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
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>
Create a new set of exports for the Meson `host_machine` cross settings.
This allows the target cross file to be created correctly from
meson.cross.template and aligns with meson.bbclass.
Note, one might think that HOST_OS and HOST_ARCH would be appropriate as
inputs here, aligning nicely with the Meson naming. That turns out to be
incorrect since the script is generated in a native/nativesdk build with
HOST_OS and HOST_ARCH set for the "build machine", not the "host
machine", using the Meson terminology. See
https://mesonbuild.com/Cross-compilation.html.
Fixes: [YOCTO #15485]
(From OE-Core rev: 9e742a0a9078f4a19a5edbfa51f22f7b71992188)
(From OE-Core rev: f2f898e36feb3bd489edda451e71b11bf69940b9)
Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Meson settings for the standalone SDK also need to be available for
the Yocto build SDK, a.k.a. meta-ide-support.
(From OE-Core rev: 6287114bf10718fe49f7c1ed211f3d99f0933bc4)
(From OE-Core rev: d69d049e9a7114323a1e1b8da4999e9e3f08ad03)
Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.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>
Bumping the kern-tools SRCREV to pickup the following commits:
tools: allow fixups to conditionally change options
Sometimes we have options that should either be =y or =m depending
on the use case.
Rather than force the options into multiple parallel and very similar
fragments (which is error prone and labour intensive), we can allow
an annotation in the configuration fragment that allows the default
value to be overriden by a variable.
The variable in question comes from a -D<var>=<value> on the scc
or spp command line. If the define evaluates to a non-zero value
a fixup is created that will modify the value when scc finishes
gathering meta-data.
An example of a notation would be:
CONFIG_INET_TUNNEL=y # OVERRIDE:$MODULE_OR_Y
CONFIG_INET_TUNNEL will be =y when standard tools (like merge-config)
are used. But when scc/spp see this notation, they check the value
of the variable MODULE_OR_Y, if that variable evalutes to a non-zero
value, a fixup is created that will change CONFIG_INET_TUNNEL to
that value before the kernel is configured.
To use the annotations, scc needs to be passed a value that is used
in the override expression. This has always been possible with defines
(-Dx=y), so we leverage that to control these conditional overrides.
In kernel-yocto, we now have a variable: KMETA_CONFIG_FEATURES
KMETA_CONFIG_FEATURES ?= ""
Which defaults to empty, the only feature that is currently
implemented is "prefer-modules". When prefer-modules is detected
in the kmeta config features, the following define is passed to
scc:
-DMODULE_OR_Y=m
Which as you can see from the above INET_TUNNEL example, will
evaluate to "m" and will override the default of "y".
(From OE-Core rev: 4eb24e85e815cee0e310e98ce4384d4cdeeba69f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Follow the changes in Clang search paths and specify sysroot via the
TOOLCHAIN_OPTIONS, otherwise clang will fail to find system headers when
executed by bindgen.
For SDK packages TOOLCHAIN_OPTIONS don't contain full sysroot path, so
specify the correct directory explicitly.
(From OE-Core rev: a647a0ff4c4eb7a7c1f6ec84a574f7d7796b6178)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
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>
Move the functions in qemu.bbclass to meta/lib/oe/qemu.py as they are
generally useful.
The qemu.bbclass is still kept, and recipes can continue to use functions
from it, though they have become wrapper functions on qemu.py functions.
Note that the QEMU_OPTIONS settings are still kept in qemu.bbclass.
This sets a clear barrier for people to use qemu user mode.
(From OE-Core rev: 7b3563b3b3901c96c3e498799a83ab8cabcf84b4)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a distro sets TOOLCHAIN with ?= or = then it overrides this
too, however, we demand GCC to be in there due to KERNEL_CC etal
Make it hard assignment, it can still be overturned via a bbappend
in that case it is intentional to use non-gcc compiler for kernel
(From OE-Core rev: 307902aa05c4537cb34fffe768df1547fb6a12d8)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some components e.g. clang and its runtime needs the native toolchain
defines especially when doing nativesdk builds it uses
CROSS_TOOLCHAIN_FLAGS_NATIVE to pass native toolchain file, which is
then used to build native llvm tools needed during nativesdk builds
Moreover this would enable using OE built native toolchain e.g.
clang-native to build cmake based packages. e.g. libcxx and other llvm
runtime plus it can be used for build native packages which require clang
(From OE-Core rev: 79dc6a23234a34403157dec10d0cdd839ca76b3e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using the ptest-cargo class with multiple Rust test binaries, ptest-runner
may report FAIL: 0 even if one of the tests fails, as long as the last test passes.
This happens because the run-ptest script, as generated by the class, does not
track failures and simply returns the exit code of the last test.
To fix this, each test binary is checked individually for failure. If any test fails,
a non-zero exit code is returned.
This ensures that test failures are not silently ignored and are properly reported
by ptest-runner in multi-test scenarios.
(From OE-Core rev: 039708d2aa578da755d5b6eadd6f549121a93186)
Signed-off-by: Ines KCHELFI <ines.kchelfi@smile.fr>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Align cargo options between ptest-cargo and cargo classes.
After oe-core commit 16745b20452de60ae2474433cc1a2fb1ed9f6a64 there is
a discrepancy between cargo arguments in compile and compile-ptest-cargo
steps when packageconfig is used for cargo based recipes.
Currently we have to do something like following code to build ptest
enabled cargo based recipe:
CARGO_BUILD_FLAGS:append:task-compile-ptest-cargo = " ${PACKAGECONFIG_CONFARGS}"
Otherwise the options are either doubled in compile step or completely
missing in compile-ptest-cargo step.
(From OE-Core rev: 98d03d31de4010534b1a00d29409d3486a0ab0b9)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For packages that need qemuwrapper-cross, they should have it
in PAKAGE_WRITE_DEPS.
Now that we've used 'qemuwrapper-cross' to replace 'qemu-native'
for recipes that need qemu-native for their postinsts, and we've
now mapped PACKAGE_WRITE_DEPS for nativesdk recipes, these
qemuwrapper-cross dependencies can be dropped from image.bbclass
and populate_sdk.bbclass.
(From OE-Core rev: fbac8d025585fe704f79ccdf00f376f677e3a89d)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to properly generate Rust bindings for the target systems, we
need to pass '-taget foo-linux-gnueabi' flags and a correct include
target include path (${STAGING_INCDIR}) to the bindgen. Add those
flags to the generated meson target file.
(From OE-Core rev: 40008d55c01681c60088e5b7defb0b8513a4ed1c)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-ffile-prefix map is more comprehensive when it comes to reproducible
builds and its superset of all prefix-mapping options in compilers
This makes is cleaner and workable across gcc and clang, clang does not
support -fcanon-prefix-map and it has to be explicitly omitted when using
clang.
There are lambdas generated in templates by clang which still get the
absolute paths despite -fdebug-prefix-map, this helps with that as well.
nasm is an outlier and we have fixed it by adding -fdebug-prefix-map option
luckily we do not pass DEBUG_PREFIX_MAP to nasm, in all recipes which use
nasm either pass -fdebug-prefix-map explicitly to nasm or they rewrite it
to use nasm flags syntax.
We have discussed this in past [1]
[1] https://patchwork.yoctoproject.org/project/oe-core/patch/20230428032030.2047920-1-raj.khem@gmail.com/#10281
(From OE-Core rev: ff73fa7ef7666a6dbe34f15515bc3ab6e574c5b0)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Jacob Kroon <jacob.kroon@gmail.com>
Cc: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want nativesdk packages to depend on correct recipes introduced
by PACKAGE_WRITE_DEPS, so do the same mapping just as we do for DEPENDS.
Before this change:
nativesdk-glib-2.0 -> qemuwrapper-cross
After this change:
nativesdk-glib-2.0 -> nativesdk-qemuwrapper-cross
This can fix do_populate_sdk failure complaining missing of
nativesdk-qemuwrapper. Error message is like below:
NOTE: > Executing update_gio_module_cache-nativesdk intercept ...
NOTE: Exit code 127. Output:
/xxx/lib32-core-image-sato/1.0/intercept_scripts-xxxx/
update_gio_module_cache-nativesdk: 13: nativesdk-qemuwrapper: not found
(From OE-Core rev: 89ac78e68c4be6e6163223c99e140e7530a61e8e)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These classes/recipes inherit qemu.bbclass but do not use anything from it.
What they use is qemuwrapper-cross, which is needed at do_rootfs time and
needs to be pulled-in by PACKAGE_WRITE_DEPS.
Also, in meta/conf/layer.conf, exclude qemuwrapper-cross deps for all arch
recipes that depend on it. This it ensure allarch recipes have the same
signature across different machines.
(From OE-Core rev: 6f3ce94f4c03e7b26f1fcdf78ea969f57717ec56)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel will continue using console from firmware which is
much better on HW when we may not know at build time which
console HW and drivers are available, e.g. like on
genericarm64 machine.
(From OE-Core rev: cf2ed52a94f5fa57cc6d93418dfb49b30e2240cc)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than emitting:
Exception: KeyError: 'packages'
and a stack trace, let's fail immediately if lockfileVersion implies
that the npm-shrinkwrap.json file isn't compatible.
The documentation[1] doesn't make it clear which lockfileVersions are
guaranteed to contain "packages". I have lockfileVersion 1 files
without. Running npm 7.5.2 generates npm-shrinkwrap.json files with
lockfileVersion 2 and "packages", so I've set the minimum to be 2.
[1] https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json
(From OE-Core rev: 4d3cbd11bc9cc0bf5a8571ecd3ce6e5e5c6ef6eb)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rust stable version updated to 1.85.0
https://blog.rust-lang.org/2025/02/20/Rust-1.85.0.html
Some of the major updates:
- Update LIC_FILES_CHKSUM in libstd-rs and rust recipes.
License-Update: Unicode license text is updated to Unicode-3.0 License.
6d2a3e9786
[RP: Update LICENSE to reference Unicode-3.0]
- Pass '-Zforce-unstable-if-unmarked' to RUSTFLAGS in libstd-rs.bb
Fix: https://github.com/rust-lang/rust/issues/133857#issuecomment-2526341227
- Downgrade bootstrap cc version causing bootstrap to fail on custom targets. (Backported from v1.85.1)
Fix: e4ca11f87f
- Explicitly set float ABI for all ARM 32 bits targets.
Fix: a51fefcaab
- Rust v1.85.0 tarball doesn't ship gcc tree.
Drop "remove_gcc_directory" postfunc which removed it and prevented the bloat.
Fix: 13c3f9b949
Adapted the patch changes with v1.85.0:
repro-issue-fix-with-cc-crate-hashmap.patch
revert-link-std-statically-in-rustc_driver-feature.patch
rust-oe-selftest.patch
rv32-cargo-rustix-0.38.40-fix.patch
Dropped patches:
fix-tidy-check-failure.patch since it's merged with v1.85.0.
(From OE-Core rev: 3130069fdebb92f20b962fa8074564a27c3fb6b9)
Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* PACKAGECONFIG_CONFARGS was added in:
https://git.openembedded.org/openembedded-core/commit/?id=16745b20452de60ae2474433cc1a2fb1ed9f6a64
but it wasn't added in bbnote above which might lead to confusing errors like I got now:
NOTE: cargo build -v --frozen --target aarch64-webos-linux-gnu --release --manifest-path=.../git//Cargo.toml
error: unexpected argument '--cfg' found
Usage: cargo build --verbose... --frozen --target [<TRIPLE>] --release --manifest-path <PATH>
and was wondering where --cfg came from.
* it was from recipe where we already use:
RUSTFLAGS:append = " ${PACKAGECONFIG_CONFARGS}"
it will be difficult to use PACKAGECONFIG for RUSTFLAGS and prevent
them to be used here for cargo as well, what about the recipes which
need them to explicitly append them to CARGO_BUILD_FLAGS ?
(From OE-Core rev: 38d953b2ffd4e0cee9e77f97988e44be105023c6)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to allow rust packages to define PACKAGECONFIG options, append
the contents of PACKAGECONFIG_CONFARGS to the build command.
This patch was already submitted by Bartosz Golaszewski on older
version but was never merged. It will be really usefull for Rust recipes.
(From OE-Core rev: 16745b20452de60ae2474433cc1a2fb1ed9f6a64)
Signed-off-by: Jean-Pierre Geslin <jarsoper@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
