linux/poky.git/meta/classes/kernel.bbclass, branch 3.5_M1

kernel: improve transformation from KERNEL_IMAGETYPE_FOR_MAKE

2021-12-09T13:49:51+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: 10a4a132e87e835726bf5da81a60f6f509b90765) 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 Signed-off-by: Richard Purdie

kernel: export native PKGCONFIG variables

2021-11-26T17:01:08+00:00

In a similar manner to cml1.bbclass, we export the pkg-config variables to allow a direct call to pkg-config access to the native sysroot versus the target sysroot. The kernel doesn't use pkg-config for target configuration, and has many explicit calls to pkg-config, without the possibility of easy override to pkg-config-native. The calls to pkg-config could be made cross friendly via replacement with make variables, but until that effort is undertaken upstream, we need a bridge approach. In particular, this is required for dtschema validation, which is a requirement in kernel 5.16+ (From OE-Core rev: 9172d61c57e23682c3d2c25701cbd53c84d01a27) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel: provide virtual/kernel for all kernels

2021-11-10T19:27:29+00:00

Since we allow the kernel package name to be varied, we should allow those packages to provide virtua/kernel, which allows them to be used as primary kernels. This change drops the use of regex, since any regex would enforce naming (and limit what can be a provider) and add complexity./ There are currently no recipes that I found, that inherit kernel that are not kernel recipes (kernel-base, etc, provide other facilities), so making this provides simpler shouldn't cause problems. Multiple kernel providers can be dealt with in the same way as any multiple provider. [YOCTO: #13172] (From OE-Core rev: 365dc1471a1b67c45de58aadf29844a9ff83d30f) Signed-off-by: Bruce Ashfield squash with provider Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel: Rework kernel make flag to variable mappings

2021-10-16T16:41:59+00:00

In 2017 we added changes to pass the BUILD_CFLAGS into the kernel via BUILD_CC. This isn't really correct and the upstream kernel now has places to pass build cflags, ldflags and more. Update our kernel make flags to correctly use the kernel's variables. This addresses concerns raised by kernel developers. If this breaks some usecase please report it so we can work out how to fix it properly. (From OE-Core rev: 7fd06a57a1d91d8534721923f6e3951ec8220cec) Signed-off-by: Richard Purdie

kernel: Add KERNEL_DEBUG_TIMESTAMPS variable

2021-10-16T16:41:59+00:00

Change the "binary reproducibility" configuration within the kernel to work off a separate variable, defaulting to reproducible builds. This allows kernel developers wanting timestamps in their images to enable it easily and clearly without changing the rest of the reproduciblity code which they likely don't need to change anyway. (From OE-Core rev: 0725ca18af7a2835aeb9616592a45ead2ee87987) Signed-off-by: Richard Purdie

kernel.bbclass: remove unnecessary dead code

2021-09-28T16:55:04+00:00

The grep pattern seems to have been wrong ever since we stopped adding the -ffile-prefix-map via a patch in commit 20aea61385e, because the actual upstream gcc produces -ffile-prefix-map== and not -ffile-prefix-map= Besides, these *-prefix-map options are already used when building the kernel due to the setting of KERNEL_CC, and the kernel build system itself also probes for and uses at least -fmacro-prefix-map (hence taking care of __FILE__ etc., but not necessarily things that go in .debug_info sections). (From OE-Core rev: 5d56de8cd653d2a3a7f4c104d50c14e22d412f66) Signed-off-by: Rasmus Villemoes Signed-off-by: Richard Purdie

base/kernel: Support zstd-compressed squashfs and cpio initramfs

2021-09-01T13:06:17+00:00

Enable zstd PACKAGECONFIG knob for squashfs-tools and add support for zstd compressed initramfs and squashfs. (From OE-Core rev: fa146049eec5f9730781830270cc9dc55a2146f7) Signed-off-by: Zoltán Böszörményi Signed-off-by: Richard Purdie

kernel: Use unexpanded EXTENDPKGV

2021-09-01T11:07:38+00:00

EXTENDPKGV can contain AUTOINC so use an expanded form in the variables allowing for later expansion during packaging to avoid race issues over the variable and the build failures that can result. (From OE-Core rev: 1f93d2426d22c74893e8daec9bb939133c5737c2) Signed-off-by: Richard Purdie

kernel.bbclass: Use full versions for inter-package dependencies

2021-08-27T10:54:34+00:00

If the kernel configuration enables module signing but no key is provided, then the kernel generates one during the kernel build. The current runtime-dependency references (with only package names without full versions) allow mixed package installations from different rebuilds of the same kernel version. This creates an issue because then the modules either don't work or taint the kernel. Tighten RDEPENDS with the full package version, i.e. use (= ${EXTENDPKGV}) markers for inter-package dependencies. The kernel will pull in the kernel-modules subpackage of the same exact version automatically if KERNEL_SPLIT_MODULES="0" is set. Otherwise the situation is the same as with the old default with one subpackage per kernel module where they have to be upgraded manually. (From OE-Core rev: 56428d15803733e14d6f1faf5f77eb933ef966f3) Signed-off-by: Zoltán Böszörményi Signed-off-by: Richard Purdie

Allow opt-out of split kernel modules

2021-08-27T10:54:33+00:00

For some use cases, a monolithic kernel-modules package containing all modules built from the kernel sources may be preferred. For one, download time is shorter and installation time is faster. Set KERNEL_SPLIT_MODULES="0" for this in. The default is one subpackage per module. Also, adapt kernel.bbclass to KERNEL_SPLIT_MODULES != "1" case Extra RDEPENDS and other inter-package references are needed in this case. (From OE-Core rev: 4b13409d82e9d576e32b978f7a42a143127ab894) Signed-off-by: Zoltán Böszörményi Signed-off-by: Richard Purdie