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

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

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

2020-12-09T23:49:00+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: 46bc7719ea5ddf4342921c1b2721c73c1a3694a6) Signed-off-by: Pan, Kris Signed-off-by: Lili Li Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie (cherry picked from commit 0fc66a0b64953aae38d0124b57615fffaec8de52) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

Revert "kernel.bbclass: run do_symlink_kernsrc before do_patch"

2020-09-22T22:34:40+00:00

This reverts commit 914d8a00e34a8edf75a349da6f5978e4ed60e6d5. Due to bug introduced for externalsrc https://bugzilla.yoctoproject.org/show_bug.cgi?id=14044 (From OE-Core rev: a6a9913575aab96f4347bdf979e26115aa0fd716) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel.bbclass: run do_symlink_kernsrc before do_patch

2020-09-02T15:04:37+00:00

There's a race between do_symlink_kernsrc and do_populate_lic, since the latter is ordered "after do_patch"; so the two may run in parallel. In some cases, that actually causes do_populate_lic to fail if it happens to look for a license file somewhere under ${S} in the short window after shutil.move and before the symlink has been created. Fix that by simply ordering symlink_kernsrc before do_patch. Any task that pokes around in ${S} looking for files should be ordered after do_patch, so this should also fix similar latent races with other ad hoc tasks. (From OE-Core rev: 914d8a00e34a8edf75a349da6f5978e4ed60e6d5) Signed-off-by: Rasmus Villemoes Signed-off-by: Richard Purdie (cherry picked from commit c5dfc2586b4135cc86e91bb04fed837daf505676) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel.bbclass: add lz4 dependency and fix the call to lz4

2020-07-16T21:28:40+00:00

If the initramfs image is type lz4, then a native lz4 is needed. Additionally an output filename needs to be specified when calling lz4, otherwise STDOUT will be used implicitly. (From OE-Core rev: 589b2d7e902125199377d5f1550597bcb38a1bf6) Signed-off-by: Timon Ulrich Signed-off-by: Richard Purdie (cherry picked from commit c83a7aec59defbbc049d44ba34a7a409ada4fa19) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel.bbclass: Fix Module.symvers support

2020-07-02T15:12:37+00:00

Starting from v5.8-rc1 commit 269a535ca931 (modpost: generate vmlinux.symvers and reuse it for the second modpost"), kernel will generate new vmlinux.symvers instead of dumping all the vmlinux symbols into Module.symvers in the first pass. Error log: 'run.do_shared_workdir.16614' failed with exit code 1: DEBUG: cp: cannot stat 'Module.symvers': No such file or directory This change will check the file Module.symvers existence before copying it. (From OE-Core rev: e96d99824f085644162fe0599988a3408eab90f8) Signed-off-by: Lili Li Signed-off-by: Richard Purdie (cherry picked from commit cd2d62a08a1dfcd890a03ee55132b6d6c65f5ab7) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel/reproducibility: kernel modules need SOURCE_DATE_EPOCH export

2020-06-05T20:36:31+00:00

If CONFIG_IKHEADERS is set to =m, then reproducibility issues creep into the modules build, since the variables we are setting for the main kernel build are not present. Since the source code must be available for a possibly git query on the timestamp, there didn't seem to be an easy way to move the environment variable setting to a common routine. As such, we duplicate the block of code that exports the required variables for reproducible builds. There is a maintenance risk to this, but any issues should be easy enough to catch. (From OE-Core rev: f511d78164581f80e7b8c592fe88ffbf38738150) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie (cherry picked from commit 82cdfcdccfedd320ebc0cdc778c7d4966198b96f) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel.bbclass: fix SOURCE_DATE_EPOCH for non-git kernel builds

2020-03-10T23:20:33+00:00

The source directory is not always a git repository, so when querying git for data to set SOURCE_DATE_EPOCH, specify ${S}/.git as the git directory to prevent retrieving incorrect data from any parent directory. Fixes the following errors with the prior logic when building a kernel that is not obtained from a git repository: 1. With TMPDIR set to a directory outside any git repository on a mounted filesystem, reproducible builds fail in do_compile with this git error: fatal: not a git repository (or any parent up to mount point ) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). aborting before the error handling logic. 2. With TMPDIR located within a subdirectory of a git repository, the SOURCE_DATE_EPOCH timestamp would be that of said repository rather than that of the kernel. (From OE-Core rev: 270ae94fe345b9ce98d822034cbfad7e24c5f393) Signed-off-by: Christopher Clark Signed-off-by: Richard Purdie