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

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

kernel.bbclass: Use KERNEL_STRIP instead of STRIP

2023-08-16T06:54:38+00:00

Kernel uses its own variables KERNEL_* instead of general toolchain env variables, therefore use KERNEL_STRIP here explicitly, Problems happen when using llvm-strip as default STRIP in distro settings, since kernel defaults to using gcc, system does not stage llvm/clang toolchain into kernel's staging sysroot and this function ends up with FileNotFoundError: [Errno 2] No such file or directory: 'riscv64-yoe-linux-llvm-strip' (From OE-Core rev: 2db0ef8fe6381c893791ad645748f6e7c8134e5f) Signed-off-by: Khem Raj Cc: Bruce Ashfield Signed-off-by: Richard Purdie

kernel: don't fail if Modules.symvers doesn't exist

2023-08-10T08:18:54+00:00

Kernels that do not use modules do not have the Modules.symvers file, which causes the previous one-liner to fail. Invert the logic so that the absence of the Modules.symvers is a passing situation but we still get failure checking on the install operation. (From OE-Core rev: 856c916ffbf3438d8cf5d8bed344473bde03b56e) Signed-off-by: Joel Stanley Signed-off-by: Patrick Williams Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie