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

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

kernel.bbclass: fix deployment for initramfs images

2021-02-10T23:55:53+00:00

The do_bundle_initramfs() only processes kernel image types that are found in KERNEL_IMAGETYPE_FOR_MAKE whereas the build system can generate other types that are not directly supported by the kernel build system. In which case when we come to the deploy phase not all the images mentioned in KERNEL_IMAGETYPES would have a respective initramfs bundled image. An example is using vmlinux.gz in KERNEL_IMAGETYPES and enabling initramfs and then we see install: cannot stat 'arch/arm64/boot/vmlinux.gz.initramfs': No such file or directory So we align the deploy phase with bundle initramfs phase and pick up relevant initramfs bundled images using KERNEL_IMAGETYPE_FOR_MAKE instead of KERNEL_IMAGETYPES. (From OE-Core rev: 352cecca98a0a845e1dacd10e399e26cdf8c7a93) Signed-off-by: Awais Belal Signed-off-by: Richard Purdie (cherry picked from commit 526bdd88ccd758204452579333ba188e29270bde) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel: set COMPATIBLE_HOST to *-linux

2021-01-01T11:55:35+00:00

The target system triple contains whether the target is Linux or not, so use it to avoid situations where you can attempt to build a kernel for systems which don't support Linux. (From OE-Core rev: 3f08f5b7068ecd3a59fc30dd90515df314a94f84) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie (cherry picked from commit b1eeeab21a81990321468ddbdd1745ea24d1828d) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel: Set proper LD in KERNEL_KCONFIG_COMMAND

2020-12-09T23:49:01+00:00

With 'ld-is-gold' and linux kernel 5.4 or later, menuconfig task for kernel recipes will fail with: $ bitbake -c menuconfig virtual/kernel ... scripts/kconfig/mconf Kconfig scripts/Kconfig.include:43: gold linker 'x86_64-poky-linux-ld' not supported /OE/build/tmp/work-shared/qemux86-64/kernel-source/scripts/kconfig/Makefile:29: recipe for target 'menuconfig' failed make[2]: *** [menuconfig] Error 1 /OE/build/tmp/work-shared/qemux86-64/kernel-source/Makefile:606: recipe for target 'menuconfig' failed make[1]: *** [menuconfig] Error 2 /OE/build/tmp/work-shared/qemux86-64/kernel-source/Makefile:185: recipe for target '__sub-make' failed make: *** [__sub-make] Error 2 Command failed. This is because that the KERNEL_LD variable already set in kernel-arch.bbclass isn't used by do_menuconfig function of cml1.bbclass. To fix this issue specify LD variable while calling the kernel menuconfig command through KERNEL_KCONFIG_COMMAND. (From OE-Core rev: 5f85104363cf496d76c3d29a05ba4406701d2878) Signed-off-by: Wonmin Jung Signed-off-by: Richard Purdie (cherry picked from commit 1faf66ce0b1f8f5165277161e07e25e672370c3f) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel: relocate copy of module.lds to module compilation task

2020-12-09T23:49:00+00:00

There were two copies of this patch floating around, and the merged variant has the copy in the wrong place. module.lds is only created during modules_prepare, and that target is not invoked during our main build of the kernel. We aren't about to change the kernel build (there's no need), so we move the copy into the compile_kernelmodules task. After that runs, we have module.lds availble to copy. This has been tested against clean kernel + out of tree module builds, and the dependencies are correct that the file is copied before the out of tree module build starts. (From OE-Core rev: 38c6c6f4a460e9c0593e2530ffeaf20b24fd83a9) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie (cherry picked from commit 7d94f9209ebaaf59ea001239a889dd7f928a0e7c) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie