linux/poky.git/meta/classes-recipe/kernel.bbclass, branch scarthgap

cml1.bbclass: use consistent make flags for menuconfig

2025-12-31T15:49:31+00:00

The class called 'make menuconfig' without any of the make variables and options set in EXTRA_OEMAKE, resulting in a quite different build environment than actually intended. For the kernel.bbclass this was fixed in commit 8c616bc0 ("kernel: Use consistent make flags for menuconfig") by appending ${EXTRA_OEMAKE} to KCONFIG_CONFIG_COMMAND. Instead of fixing this individually for additional recipes, we simply include ${EXTRA_OEMAKE} in KCONFIG_CONFIG_COMMAND by default. For most class users, this change is directly visible in the generated .config file: * For barebox and u-boot, the CONFIG_GCC_VERSION erroneously reflected the host GCC version before where it now correctly reflects the target toolchain's GCC. * For u-boot, also the "Compiler: " line at the beginning of the .config now prints the target toolchain instead of the host ones. * The kernel had this already set. * busybox did not produce any difference. Note that these projects might base some compile-time decisions on e.g. the actual compiler version used. Having the wrong one in the menuconfig-generated .config affects at least the visibility and consistency. Reported-by: Ulrich Ölmann (From OE-Core rev: a7dd1c221e42fd8df1d6f1c76c6a5ab7a3e19542) Signed-off-by: Enrico Jörns Signed-off-by: Richard Purdie (cherry picked from commit 1b6ddd452837e67b500a84455a234f5edc8250a9) Signed-off-by: Enrico Jörns Signed-off-by: Steve Sakoman

kernel.bbclass: Add task to export kernel configuration to SPDX

2025-12-31T15:49:31+00:00

Introduce a new bitbake task do_create_kernel_config_spdx that extracts the kernel configuration from ${B}/.config and exports it into the recipe's SPDX document as a separate build_Build object. The kernel config parameters are stored as SPDX DictionaryEntry objects and linked to the main kernel build using an ancestorOf relationship. This enables the kernel build's configuration to be explicitly captured in the SPDX document for compliance, auditing, and reproducibility. The task is gated by SPDX_INCLUDE_KERNEL_CONFIG (default = "0"). Reviewed-by: Joshua Watt (From OE-Core rev: 1fff29a0428778929ffa530482ebf7db95f1e0ae) Signed-off-by: Kamel Bouhara (Schneider Electric) Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie (cherry picked from commit 228a968e7c47d811c06143279bdb0f9c5f374bef) Signed-off-by: Steve Sakoman

classes/kernel: No symlink in postinst without KERNEL_IMAGETYPE_SYMLINK

2024-08-01T13:08:09+00:00

The commit “Use a copy of image for kernel*.rpm if fs doesn't support symlinks” [1] added postinst and postrm scripts to the kernel package which create a symlink after package installation. This should not happen if `KERNEL_IMAGETYPE_SYMLINK` is not `1`. Background: The u-boot implementation of jffs2 does not support symlinks. Using a hardlink or removing `${KERNEL_VERSION}` from the file name fails, because the current postinst script replaces the file with the symlink. [1] 8b6b95106a5d4f1f6d34209ec5c475c900270ecd Cc: Bruce Ashfield Cc: Richard Purdie Cc: Yanfei Xu (From OE-Core rev: 6916c19c8a09d8d0334c957ae541aafcbbcf92df) Signed-off-by: Jörg Sommer Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 6a763401862d9ee96749ad18378b6344778c2c66) Signed-off-by: Steve Sakoman

kernel.bbclass: check, if directory exists before removing empty module directory

2024-06-19T15:34:58+00:00

If the kernel folder does not exist, find will result in an error. This can occur if the kernel has no modules but, for example, custom modules are created. Add check before deleting. (From OE-Core rev: 63856721cab409ae0598cfbff4fcf55c90bfd7e7) Signed-off-by: Heiko Thole Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 7ef767d84d56b25498e45db83bb8f9d9caebeaf9) Signed-off-by: Steve Sakoman

kernel: Fix check_oldest_kernel

2024-03-18T12:21:45+00:00

The check_oldest_kernel() function requires utsrelease.h to be generated. This file is generated during do_compile, so we need to delay calling check_oldest_kernel() until after this. With this change in place, I now see the expected warning when building Linux 5.10.y. (From OE-Core rev: 525019b30e83ea65021ca4874605589ccd2daf80) Signed-off-by: Paul Barker Signed-off-by: Richard Purdie

kernel.bbclass: Set pkg-config variables for building modules

2024-02-24T16:10:23+00:00

The pkg-config workaround has been applied for kernel image building, but not for module building. So pkg-config variables are different between do_compile and do_compile_kernelmodules tasks. It may unnecessary trigger rebuilding of a few host tools at the later task. Especially when CONFIG_DEBUG_INFO_BTF is enabled in the kernel, it may even trigger rebuilding vmlinux at do_compile_kernelmodules due to the rebuilt host tools such as certs/extract-cert or objtool (on x86). This eventually creates an inconsistent set of kernel binaries. Here is the repro steps: - Check out nanbield on x86 - The unexpected rebuild happens on kirkstone or possibly earlier - Ensure that pahole is available (e.g. via meta-oe) - Set KERNEL_DEBUG to "True" to properly set up PAHOLE e.g. $ export KERNEL_DEBUG="True" $ export BB_ENV_PASSTHROUGH_ADDITIONS="${BB_ENV_PASSTHROUGH_ADDITIONS} KERNEL_DEBUG" - Enable CONFIG_DEBUG_INFO_BTF=y e.g. $ bitbake -c menuconfig virtual/kernel -> Kernel hacking -> Compile-time checks and compiler options -> Generate BTF typeinfo - Build the kernel e.g. $ bitbake virtual/kernel The BTF information in the resulting bzImage and kernel modules are inconsistent, because the module's BTF information is generated using the "second" vmlinux that doesn't have the identical BTF to the "first" vmlinux. These modules can't be loaded at runtime due to the BTF mismatch. This also leads to a build-id mismatch between the installed bzImage and vmlinux since the bzImage is created from the first vmlinux, but the installed vmlinux is the second one. $ eu-readelf -n tmp/work/qemux86_64-poky-linux/linux-yocto/6.5.13+git/image/boot/{bzImage*,vmlinux*} | grep "Build ID" Build ID: 4a0d62ee7fef0244950f0f604253729875bea493 Build ID: fb99b3d91399dbe42bf67ddee59e0f5a0c7f74d9 To avoid the unexpected rebuilding that results in such inconsistency, set the same pkg-config variables when building kernel and modules. For kernel 5.19 and above, simply set the HOSTPKG_CONFIG in the make command line. (From OE-Core rev: cd2072e5d953af981339427028e19083257e6a92) Signed-off-by: Munehisa Kamata Signed-off-by: Richard Purdie

classes/recipes: Switch to use inherit_defer

2024-01-18T10:15:58+00:00

Now that bitbake supports the use of inherit_defer, switch all conditional (variable based) inherits to use this instead. This leads to more a more deterministic user experience since there is no longer an immediate expansion and later changes to the variables in question (e.g. a bbappend) are accounted for. This patch tries to ensure the behaviour before/after remains as unchanged as it reasonably can, e.g. by always inherting populate_sdk_base. native and nativesdk continue to need to be inherited last, hence being used with inherit_defer in a handful of very specific cases. (From OE-Core rev: 451363438d38bd4552d5bcec4a92332f5819a5d4) Signed-off-by: Richard Purdie

kernel.bbclass: add preceding space in appendVar setting

2023-10-30T17:12:19+00:00

The appendVar setting should have a preceding space, otherwise, when KERNEL_MODULE_SPLIT is set to "0", we'll sometimes get dependency error due to lacking of space. (From OE-Core rev: 266cd948d4aa68de34075e8ed6299f7d80d19346) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

kernel.bbclass: Use strip utility used for kernel build in do_package

2023-10-27T07:28:38+00:00

os.environ does not pass this down to runstrip() function and in strip_execs() its using STRIP bitbake variable to find the strip utility to use. Since there might be a trailing whitespace in KERNEL_STRIP remove that otherwise python is not able to launch it. e.g. FileNotFoundError: [Errno 2] No such file or directory: 'riscv64-yoe-linux-strip ' This is more evident when STRIP and KERNEL_STRIP are different utilities e.g. when using clang as default toolchain but using gcc+binutils only for kernel build. (From OE-Core rev: 77497dbdca92ab4d6386a071bc281c42a7e8a14b) Signed-off-by: Khem Raj Cc: Bruce Ashfield Signed-off-by: Luca Ceresoli Signed-off-by: Richard Purdie

kernel.bbclass: Add force flag to rm calls

2023-09-02T10:47:50+00:00

The latest 6.5 kernels do not appear to create the source file in ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the recipe errors out when trying to remove it. Simple fix is to add the -f (force) flag to the call. (From OE-Core rev: 2e669bf797b15d803e7d6a700e449bdc467a4bcc) Signed-off-by: Ryan Eatmon Signed-off-by: Richard Purdie