linux/poky.git/meta/classes-recipe/kernel.bbclass, branch master

The poky repository master branch is no longer being updated.

2025-11-07T13:31:53+00:00

You can either: a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs b) use the new bitbake-setup You can find information about either approach in our documentation: https://docs.yoctoproject.org/ Note that "poky" the distro setting is still available in meta-yocto as before and we continue to use and maintain that. Long live Poky! Some further information on the background of this change can be found in: https://lists.openembedded.org/g/openembedded-architecture/message/2179 Signed-off-by: Richard Purdie

kernel.bbclass: add lz4-native dependency for Image.lz4

2025-09-22T21:09:48+00:00

The pixel6 kernel build fails with "lz4: command not found" when KERNEL_IMAGETYPE is set to `Image.lz4`. Upstream commit 0c7dc5bae1 ("bitbake.conf: Drop lz4 from HOSTTOOLS") dropped lz4 from the global `HOSTTOOLS` variable. This meant that the lz4 binary was no longer automatically provided to build tasks, causing the compilation to fail. Add a conditional dependency on `lz4-native` directly to `kernel.bbclass`. It ties the dependency directly to the image type that requires it, making the build more robust. Suggested-by: André Draszik (From OE-Core rev: 42b85e1532d5448dc88dcb0d068e746f0220ee84) Signed-off-by: Tudor Ambarus Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

kernel.bbclass: State riscv required tune_features for Linux

2025-07-07T21:12:50+00:00

Required: rv32ima_zicsr_zifencei rv64ima_zicsr_zifencei See the arch/riscv/Makefile: riscv-march-$(CONFIG_ARCH_RV32I) := rv32ima riscv-march-$(CONFIG_ARCH_RV64I) := rv64ima riscv-march-$(CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI) := $(riscv-march-y)_zicsr_zifencei (From OE-Core rev: 6fd37774eda090951c48a3d9ad482e53f98b0529) Signed-off-by: Mark Hatle Signed-off-by: Antonin Godard Signed-off-by: Richard Purdie

kernel.bbclass: remove support for type fitImage

2025-06-05T10:02:22+00:00

kernel.bbclass is no longer involved in FIT image creation. Whether a FIT image is built now depends entirely on whether the linux-yocto-fitimage recipe (or any other recipe capable of producing a FIT image) is selected for the build. As a result, specifying the kernel image type "fitImage" in KERNEL_IMAGETYPE or KERNEL_IMAGETYPES is no longer necessary and gets removed. (From OE-Core rev: ec606ef2879ddba750e275dae4dc8ab1e943b259) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

uboot, kernel: use hex address for UBOOT_ENTRYPOINT

2025-03-11T11:20:34+00:00

Compiling a FIT image with this default values and dump it with dumpimage shows decimal converted values. For example the default value 20008000 looks like this: Image 0 (kernel-1) ... Load Address: 0x01314c40 Entry Point: 0x01314c40 With this change the expected value is printed by dumpimage. (From OE-Core rev: e6f2ca9135ef7da8f8b5925957532734c06e55cc) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

cml1.bbclass: use consistent make flags for menuconfig

2025-03-03T18:01:29+00:00

The class called 'make menuconfig' without any of the make variables and options set in EXTRA_OEMAKE, resulting in a quite different build environment than actually intended. For the kernel.bbclass this was fixed in commit 8c616bc0 ("kernel: Use consistent make flags for menuconfig") by appending ${EXTRA_OEMAKE} to KCONFIG_CONFIG_COMMAND. Instead of fixing this individually for additional recipes, we simply include ${EXTRA_OEMAKE} in KCONFIG_CONFIG_COMMAND by default. For most class users, this change is directly visible in the generated .config file: * For barebox and u-boot, the CONFIG_GCC_VERSION erroneously reflected the host GCC version before where it now correctly reflects the target toolchain's GCC. * For u-boot, also the "Compiler: " line at the beginning of the .config now prints the target toolchain instead of the host ones. * The kernel had this already set. * busybox did not produce any difference. Note that these projects might base some compile-time decisions on e.g. the actual compiler version used. Having the wrong one in the menuconfig-generated .config affects at least the visibility and consistency. Reported-by: Ulrich Ölmann (From OE-Core rev: 1b6ddd452837e67b500a84455a234f5edc8250a9) Signed-off-by: Enrico Jörns Signed-off-by: Richard Purdie

kernel.bbclass: Handle possible multiconfig.

2025-02-25T12:17:22+00:00

When specifying the dependencies of do_bundle_initramfs the current multiconfig might not be the default. This fixes the dependencies between the multiconfigs if the current differs to default. (From OE-Core rev: 2e40466af83a3c66aef878e3f08a891405199ebe) Signed-off-by: Mueller, Daniel Signed-off-by: Richard Purdie

meta/meta-selftest: Fix variable assignment whitespace

2025-02-01T13:42:34+00:00

Recipes are much more readable with whitespace around the assignment operators. Fix various assignments in OE-Core to show this is definitely the preferred formatting. (From OE-Core rev: 30ea609d3357fb3de911f2f6a5e6856c151b976a) Signed-off-by: Richard Purdie

classes/recipes: Switch virtual/XXX-gcc to virtual/cross-cc (and c++/binutils)

2025-01-21T23:09:33+00:00

The idea of the base class dependency is to say "yes, I need a C cross compiler" and this was never meant to be gcc specific. Looking at the codebase, whilst we code triplets into this, it does overcomplicate things as there are only ever limited, "target", "sdk" and the class extended versions like mutlilib. After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc. This lets us remove the "gcc" specific element as well as removing the over complicated triplet usage. At the same time, change the much less widely used "g++" variant to "c++" for similar reasons and remove the triplet from virtual/XXX-binutils too. Backwards compatibility mappings could be left but are just going to confuse things in future so we'll just require users to update. This simplification, whilst disruptive for any toolchain focused layers, will make improved toolchain selection in the future much easier. Since we no longer have overlapping variables, some code for that can just be removed. The class extension code does need to start remapping some variables but not the crosssdk target recipe names. This patch is in two pieces, this one handles the renaming with the functional changes separate in a second for easier review even if this breaks bisection. (From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0) Signed-off-by: Richard Purdie

cml1: add do_savedefconfig

2024-09-05T20:48:47+00:00

Move the do_savedefconfig task definition from u-boot and kernel to cml1.bbclass. There are more recipes which use the kbuild framework and benefit from a do_savedefconfig task. (From OE-Core rev: 2b2ed48903e09196ee20da7f66b1d3689e4a4473) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie