linux/poky.git/meta/classes, branch kirkstone-4.0.18

u-boot: Move UBOOT_INITIAL_ENV back to u-boot.inc

2024-03-12T14:06:19+00:00

Commit cc6c3e31526d ("u-boot: Move definitions to common locations") moved UBOOT_INITIAL_ENV to uboot-config.bbclass, but it should be kept at u-boot.inc because it encodes ${PN} in it, which should be set by the U-Boot recipe. Currently, whatever inherits uboot-config bbclass will fill-in its own PN, which would change the content of UBOOT_INITIAL_ENV per-package. Cc: Klaus Heinrich Kiwi Cc: Marek Vasut Fixes: cc6c3e31526d ("u-boot: Move definitions to common locations") (From OE-Core rev: 18b76259d27dc045f621cd512582c37e8bbab45c) Signed-off-by: Fabio Estevam Backported from master: 0b0c4b37d318b86f100512476ffd861e0ce1f47e Signed-off-by: Fabio Estevam Signed-off-by: Steve Sakoman

kernel.bbclass: Set pkg-config variables for building modules

2024-03-07T18:32:54+00:00

[Backport cd2072e5d953 from the master without HOSTPKG_CONFIG setting] 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: d63af11e92094487d6e358f27283e5385937e7a8) Signed-off-by: Munehisa Kamata Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

kernel: make LOCALVERSION consistent between recipes

2024-03-01T15:19:54+00:00

The initial fix for localversion setting in 6.3+ broke older recipes and also broke recipes setting localversion in a kernel recipe, as make-mod-scripts (and other locations) can trigger a regeneration of files and don't have access to the variable. Moving the setting of this variable to the global namespace doesn't make sense, so we follow the example of the kernel-abiversion and save a kernel-localversion to the build artifacts. Recipes that may regenerate scripts/dynamic files, must depend on the do_shared_workedir of the kernel and use the helper function to read the file storing the localversion. (From OE-Core rev: cca0971a7d92d823cc0c2b16cf14a7b2ed8ecb61) Signed-off-by: Bruce Ashfield Signed-off-by: Alexandre Belloni cherry-picked from master b378eec156998eea55ba61e59103cb34fab0d07c Signed-off-by: Andreas Helbech Kleist Acked-by: Ryan Eatmon Signed-off-by: Steve Sakoman

kernel: fix localversion in v6.3+

2024-03-01T15:19:54+00:00

During testing of the v6.4 reference kernel, it was noticed that on-target modules no longer matched the magic value of the running kernel. This was due to a different localversion in the cross built kernel and the scripts / resources created on target. This was due to changes in the setlocalversion script introduced in the v6.3 series. The .scmversion file is no longer used (or packaged) to inhibit the addition of a "+" (through querying of the git status of the kernel) or the setting of a local version. We recently introduced the KERNEL_LOCALVERSION variable to allow recipes to place a value in .scmversion, so we extend the use of that variable to kernel-arch.bbclass and use it to set the exported variable LOCALVERSION. We must do it at the kernel-arch level, as the variable must be exported in any kernel build to ensure that setlocalversion always correctly sets the localversion. (From OE-Core rev: 74897e505db19a23a5b864a48a4fa97d657605c8) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691 Signed-off-by: Andreas Helbech Kleist Signed-off-by: Steve Sakoman

kernel.bbclass: introduce KERNEL_LOCALVERSION

2024-03-01T15:19:54+00:00

Just like UBOOT_LOCALVERSION, an end user can set KERNEL_LOCALVERSION to append a string to the name of the local version of the kernel image. (From OE-Core rev: 29a0d2a49df8e24f3948a2ddf03743f0cb5d09dd) Signed-off-by: Ming Liu Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie cherry-picked from master 229435a52f36ddec5f85fb6d5ccd42044b688397 Signed-off-by: Andreas Helbech Kleist Signed-off-by: Steve Sakoman

populate_sdk_ext: use ConfigParser instead of SafeConfigParser

2024-03-01T15:19:53+00:00

SafeConfigParser was renamed to ConfigParser in 3.2, and the SafeConfigParser alias will be removed in 3.12. (From OE-Core rev: 50815c328e677ac079d38dc8555a909f049cf5be) Signed-off-by: Ross Burton Signed-off-by: Alexandre Belloni Cherry-picked from master: 71b3e7f71727137b4b996cc4160c9cc1581824b8 Signed-off-by: Adrian Freihofer Signed-off-by: Steve Sakoman

Revert "kernel: fix localversion in v6.3+"

2024-02-16T01:49:52+00:00

This reverts commit d9273edae80978c34f8426f34f991b9598828aa9. This commit is causing breakage for some vendor kernel builds. (From OE-Core rev: 59cc2e75c15f8c6371a4c4a3b7bd2e6c3f145fbc) Signed-off-by: Steve Sakoman

kernel: fix localversion in v6.3+

2024-02-15T13:51:57+00:00

During testing of the v6.4 reference kernel, it was noticed that on-target modules no longer matched the magic value of the running kernel. This was due to a different localversion in the cross built kernel and the scripts / resources created on target. This was due to changes in the setlocalversion script introduced in the v6.3 series. The .scmversion file is no longer used (or packaged) to inhibit the addition of a "+" (through querying of the git status of the kernel) or the setting of a local version. We recently introduced the KERNEL_LOCALVERSION variable to allow recipes to place a value in .scmversion, so we extend the use of that variable to kernel-arch.bbclass and use it to set the exported variable LOCALVERSION. We must do it at the kernel-arch level, as the variable must be exported in any kernel build to ensure that setlocalversion always correctly sets the localversion. (From OE-Core rev: d9273edae80978c34f8426f34f991b9598828aa9) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie Cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691 Signed-off-by: Andreas Helbech Kleist Signed-off-by: Steve Sakoman

image-live.bbclass: LIVE_ROOTFS_TYPE support compression

2024-02-07T13:30:05+00:00

The task for fstypes with compression is the same as the task for the uncompressed fstypes, e.g. when adding tar.xz to `IMAGE_FSTYPES`, it will be included into the do_image_tar task and not creating a separate do_image_tar.xz task. This commit fixes `LIVE_ROOTFS_TYPE` with compressed fstypes by depending on the actual task instead of the non-existent do_image_. task. Fixes [YOCTO #15331] (From OE-Core rev: 60d88989698968c13f8e641f0ba1a82fcf700fb7) Signed-off-by: Ludovic Jozeau Reviewed-by: Yoann Congal Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 67c507e3d42e52a6d452c4a453eeaf7f2e2d68d6) Signed-off-by: Steve Sakoman

testimage: drop target_dumper, host_dumper, and monitor_dumper

2024-01-04T15:00:13+00:00

The target_dumper code is basically broken. It has been reading binary files over the text base serial communication and runs at every command failure which makes no sense. Each run might overwrite files from the previous run and the output appears corrupted due to confusion from the binary data. It isn't possible to cherry-pick "testimage: Drop target_dumper and most of monitor_dumper" from master, so just make target_dumper, host_dumper, and monitor_dumper empty functions. For further details see: https://lists.openembedded.org/g/openembedded-architecture/message/1888 (From OE-Core rev: 960e7e3dffa22c2142cb672c68cd9a8f0e3998a3) Signed-off-by: Steve Sakoman