linux/poky.git/meta/classes/kernel.bbclass, branch hardknott

kernel: Fix interaction when packaging disabled

2021-07-06T12:02:30+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: 8068eaccf89779d374791837215895432e45e85d) Signed-off-by: Richard Purdie (cherry picked from commit 2522daf22e2c27dd9c7926feda0345978217c6c3) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

kernel.bbclass: fix do_sizecheck() comparison

2021-06-26T14:24:08+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: 61feebd88960eb4e074a80a0e45b36a7a1db869c) Signed-off-by: Andrea Adami Signed-off-by: Richard Purdie (cherry picked from commit 254ca956d63b4ce6aa294213b60bb943f9f3a9e6) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

kernel.bbclass: fix deployment for initramfs images

2021-01-30T10:41:04+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: 526bdd88ccd758204452579333ba188e29270bde) Signed-off-by: Awais Belal Signed-off-by: Richard Purdie

kernel: skip installing fitImage when using Initramfs bundles

2021-01-20T00:45:05+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: 1b67fd9ac74935fa41e960478c54e45422339138) Signed-off-by: Abdellatif El Khlifi Signed-off-by: Richard Purdie

kernel: set COMPATIBLE_HOST to *-linux

2020-12-24T08:25:14+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: b1eeeab21a81990321468ddbdd1745ea24d1828d) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

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

2020-11-18T13:59:27+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: 7d94f9209ebaaf59ea001239a889dd7f928a0e7c) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel: Set proper LD in KERNEL_KCONFIG_COMMAND

2020-11-17T21:53:13+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: 1faf66ce0b1f8f5165277161e07e25e672370c3f) Signed-off-by: Wonmin Jung Signed-off-by: Richard Purdie

kernel: provide module.lds for out of tree builds in v5.10+

2020-11-16T14:27:46+00:00

The upstream commit 596b0474d3d [kbuild: preprocess module linker script], adds a dependency on module.lds for external module building. Since module.lds is generated as part of 'modules_prepare', we must make it available with the other kernel artifacts in the kernel shared workdir, otherwise out of tree builds fail. This fixes errors like: | make[4]: *** No rule to make target 'scripts/module.lds', needed by 'build/tmp/work/qemuarm64-poky-linux/cryptodev-module/1.11-r0/git/cryptodev.ko'. Stop. | make[4]: *** Waiting for unfinished jobs.... We also ensure that kernel-devsrc has a copy to support on target module builds that are often prepared with 'make scripts prepare'. Those targets won't regenerate it, so the build fails. If 'make modules_prepare' is used, the file will be regenerated and overwrite our copy (as expected). (From OE-Core rev: 0fc66a0b64953aae38d0124b57615fffaec8de52) Signed-off-by: Pan, Kris Signed-off-by: Lili Li Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel.bbclass: ensure symlink_kernsrc task gets run even with externalsrc

2020-09-28T13:15:48+00:00

Commit c5dfc2586b41 (kernel.bbclass: run do_symlink_kernsrc before do_patch) fixed a race between do_symlink_kernsrc and do_populate_lic. However, I missed the fact that when externalsrc.bbclass is in use, the do_patch task doesn't exist, meaning that do_symlink_kernsrc now doesn't get run at all, breaking the build. We need this task to run regardless of whether do_patch exists or not, so reinstate the configure->symlink_kernsrc dependency explicitly. Fixes: c5dfc2586b41 (kernel.bbclass: run do_symlink_kernsrc before do_patch) Reported-by: Chanho Park (From OE-Core rev: a2b50b74d609ce079ab36b82d4c7c3539fb56485) Signed-off-by: Rasmus Villemoes Signed-off-by: Richard Purdie

kernel.bbclass: use camelCase notation for bash variables in do_deploy

2020-09-17T08:47:45+00:00

* to match other variables there like deployDir imageType [YOCTO #12937] (From OE-Core rev: 13c5d1b686255d385d200cbd06b7000080809fc7) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie