linux/poky.git/meta/classes/kernel.bbclass, branch dunfell-23.0.29

kernel.bbclass: Add force flag to rm calls

2023-10-20T15:35:31+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) (From OE-Core rev: 844faa7c51ae8ec0966e9c5c3f70a1dbf2222c21) Signed-off-by: Ryan Eatmon Signed-off-by: Richard Purdie Signed-off-by: Alexander Sverdlin Signed-off-by: Steve Sakoman Backported from kirkstone commit 7e177848f97e. Signed-off-by: Paul Barker Signed-off-by: Steve Sakoman

kernel: Fix path comparison in kernel staging dir symlinking

2023-09-15T13:47:11+00:00

Due to an oversight in the do_symlink_kernsrc function, the path comparison between "S" and "STAGING_KERNEL_DIR" is broken. The code obtains both variables, but modifies the local copy of "S" before comparing them, causing the comparison to always return false. This can cause the build to fail when the EXTERNALSRC flag is enabled, since the code will try to create a symlink even if one already exists. This patch resolves the issue by comparing the variables before they are modified. (From OE-Core rev: 27a982807caa7ffbdf2d4ef02bc0b037150b1b3b) Signed-off-by: Staffan Rydén Signed-off-by: Alexandre Belloni (cherry picked from commit afd2038ef8a66a5e6433be31a14e1eb0d9f9a1d3) Signed-off-by: Steve Sakoman

kernel: skip installing fitImage when using Initramfs bundles

2023-08-16T13:55:13+00:00

When including an initramfs bundle inside a FIT image, the fitImage is created after the install task by do_assemble_fitimage_initramfs. This happens after the generation of the initramfs bundle (done by do_bundle_initramfs). So, at the level of the install task we should not try to install the fitImage. The fitImage is still not generated yet. After the generation of the fitImage, the deploy task copies the fitImage from the build directory to the deploy folder. Change-Id: I3eaa6bba1412f388f710fa0f389f66631c1c4826 (From OE-Core rev: b70a8333a7467162b9d148b99f5970c0af2a531f) Signed-off-by: Abdellatif El Khlifi Signed-off-by: Richard Purdie (cherry picked from commit 1b67fd9ac74935fa41e960478c54e45422339138) Signed-off-by: Frederic Martinsons Signed-off-by: Steve Sakoman

linux: inherit pkgconfig in kernel.bbclass

2023-03-15T23:09:24+00:00

pkgconfig is being required to find dependencies for building kernel native tools, move "inherit pkgconfig" to kernel.bbclass so BSP kernel recipes can also benefit from it. (From OE-Core rev: a5e62888768be641d5da00fd847e0cac96820c75) Signed-off-by: Ming Liu Signed-off-by: Alexandre Belloni (cherry picked from commit 8a84bd98e3fbc16c782f83064801e469d086911e) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel.bbclass: make KERNEL_DEBUG_TIMESTAMPS work at rebuild

2022-12-07T15:06:37+00:00

Currently, the KERNEL_DEBUG_TIMESTAMPS is not working as expected at rebuild. That is, even if we set it to "1", the kernel build time is not changed. The problem could be reproduced by the following steps. 1. bitbake core-image-minimal; start image and check `uname -a` output. 2. set in local.conf: KERNEL_DEBUG_TIMESTAMPS = "1" 3. bitbake core-image-minimal; start image and check `uname -a` output. It's expected that after enabling KERNEL_DEBUG_TIMESTAMPS, the kernel build time will be set to current date. But it's not. This is because the compile.h was not re-generated when do_compile task was re-executed. In mkcompile_h, we have: """ # Only replace the real compile.h if the new one is different, # in order to preserve the timestamp and avoid unnecessary # recompilations. # We don't consider the file changed if only the date/time changed, # unless KBUILD_BUILD_TIMESTAMP was explicitly set (e.g. for # reproducible builds with that value referring to a commit timestamp). # A kernel config change will increase the generation number, thus # causing compile.h to be updated (including date/time) due to the # changed comment in the # first line. """ It has made it very clear that it will not be re-generated unless we have KBUILD_BUILD_TIMESTAMP set explicitly. So we set this variable explicitly in do_compile to fix this issue. (From OE-Core rev: e44f0cda8176186d42a752631810c1cb5f1971eb) Signed-off-by: Chen Qi Signed-off-by: Alexandre Belloni (cherry picked from commit 1b68c2d2d385013a1c535ef81172494302a36d74) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel: improve transformation from KERNEL_IMAGETYPE_FOR_MAKE

2022-12-07T15:06:37+00:00

In 526bdd88ccd758204452579333ba188e29270bde the imageType loop in kernel_do_deploy was changed to use KERNEL_IMAGETYPE_FOR_MAKE rather than KERNEL_IMAGETYPES. This broke the special handling for fitImage immediately below because KERNEL_IMAGETYPE_FOR_MAKE never contains fitImage. It has always been my understanding that KERNEL_IMAGETYPE_FOR_MAKE controlled what was passed to make, but KERNEL_IMAGETYPE controlled what was installed/deployed. When the two are different then it's the responsibility of whoever set KERNEL_IMAGETYPE_FOR_MAKE to ensure that whatever comes out of the kernel build system has been transformed in to the requested form by the time of installation. This is what happens for kernel.bbclass's own support for vmlinux.gz. I think this means that for KERNEL_IMAGETYPE vmlinux.gz, kernel.bbclass is responsible for generating vmlinux.gz.initramfs[1] so that kernel_do_deploy can deploy it. This means that the change in 526bdd88ccd758204452579333ba188e29270bde can be reverted, fixing KERNEL_IMAGETYPE = "fitImage". In addition, it ought to be possible for recipes and other classes that use kernel.bbclass to hook into this mechanism by setting KERNEL_IMAGETYPE_FOR_MAKE and performing their own transformations. do_bundle_initramfs calls kernel_do_compile and we don't want it to transform vmlinux to vmlinux.gz at that point, since it will fight against the careful renaming and preserving that do_bundle_initramfs does. Let's separate the transformation out of kernel_do_compile to a new do_transform_kernel task that can be run at the right time. This means that it's also logical to perform the equivalent translation for the kernel with the initramfs in a separate do_transform_bundled_initramfs task too. This leaves two clear customisation points for recipes and other classes to hook into the process and perform their transformations: do_transform_kernel and do_transform_bundled_initramfs. (I care about this because our recipes that use kernel.bbclass also set KERNEL_IMAGETYPE_FOR_MAKE and transform vmlinux into a form suitable for our bootloader after do_compile and do_bundle_initramfs into the format matching KERNEL_IMAGETYPE. I'm unable to successfully bundle an initramfs after 526bdd88ccd758204452579333ba188e29270bde, but I didn't want to just revert that change to reintroduce the bug that it was fixing.) I can't say that I'm entirely happy with this change, but I'm unsure what to do to improve it. I find the way that both the bare kernel and the one with the initramfs both get deployed to be confusing, and a waste of build time. I would like to not actually generate a publishable kernel image at all during do_compile when an initramfs is in use, but I suspect that this would affect valid use cases that I'm not aware of. (From OE-Core rev: d9e9653616638f2b187d5e04540071ac34d99f56) Signed-off-by: Mike Crowe [1] It could be argued that this should be vmlinux.initramfs.gz, but that would require another special case in kernel_do_deploy and the filename is only visible within this class and the recipes that use it anyway. Signed-off-by: Alexandre Belloni (cherry picked from commit 10a4a132e87e835726bf5da81a60f6f509b90765) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel: Fix interaction when packaging disabled

2021-07-10T21:46:19+00:00

When packaging is disabled using the nopackages class, ensure we don't add to PACKAGES. This fixes builds where we have an unpackaged kernel alongside a packaged kernel. (From OE-Core rev: 6683b784d3258672c8d56c945db02ba37379cbf6) Signed-off-by: Richard Purdie (cherry picked from commit 2522daf22e2c27dd9c7926feda0345978217c6c3) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel.bbclass: fix do_sizecheck() comparison

2021-06-19T15:59:29+00:00

The routine do_sizecheck() was historically needed by legacy devices with limited flash memory. The lowest extreme is probably with Zaurus collie having exactly 1024*1024 = 1048576 bytes for the kernel partition. In the years the KERNEL_IMAGE_MAXSIZE has been converted to kilobytes thus rounded so we have now KERNEL_IMAGE_MAXSIZE_collie = "1024". The effect is that now the check fails because we hit curiously this | WARNING: This kernel zImage (size=1024(K) > 1024(K)) is too big for... even though zImage is 1047288 bytes (kernel + kexecboot-klibc-initramfs). Fix this case using test -gt (greater) instead of -ge (greater or equal). (From OE-Core rev: f5fc716d744745d5c2ea83f0b1d63907cfe04c06) Signed-off-by: Andrea Adami Signed-off-by: Richard Purdie (cherry picked from commit 254ca956d63b4ce6aa294213b60bb943f9f3a9e6) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel.bbclass: Remove do_install[prefunc] no longer needed

2021-05-13T21:10:06+00:00

Prior work has refactored the do_install task multiple times, and any references to PKGV and PKGR (even indirect ones) have been removed. (From OE-Core rev: d2fe8c5861283ff4a4bd18239a61eb6745b7f696) Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie (cherry picked from commit 36fe4db8ae827a93abe9fce6740459d215411965) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel.bbclass: Configuration for environment with HOSTCXX

2021-05-04T21:57:55+00:00

When compiling xilinx-zynq board linux-kernel-dev(v5.8) if "GCC_PLUGINS=y", The following error will appear: "HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o fatal error: gmp.h: No such file or directory" the GCC_PLUGINS depend on return result of gcc-plugin.sh execution however in gcc-plugin.sh use HOSTCC to detect the feature of GNU extension of gcc, this will result that HOSTCC can compile the file successfully, but HOSTCXX is used in the actual compilation process. (From OE-Core rev: 9a14fb4aefb3a0bad1d1a98f44eaa10177737e04) Signed-off-by: Zhang Qiang Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie Cc: Armin Kuster Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie