linux/poky.git/meta/classes/kernel.bbclass, branch uninative-2.1

kernel: specify dependencies for compilation for config tasks

2018-06-12T22:34:24+00:00

With recent kernels (i.e. 4.17+) the configuration phase of the kernel will check for capabilities/options of the compiler for CVE and other mitigation support. For a general kernel, we want to ensure that CC is fully defined when the config targets are invoked (so the proper compiler will be checked). For linux-yocto, we also need to specify the compiler/tools dependencies for the configme task since it executes before configure and hence the main kernel build DEPENDS will not always be in the sysroot before it executes. Without those dependencies the kernel will be incorrectly configured (i.e. bison is missing) or the configuration will fail the mitigation tests. [YOCTO #12757] (From OE-Core rev: ff1bdd75d50f0ebac3d599e461685ace29559a82) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel.bbclass: avoid duplicates in KERNEL_IMAGETYPE_FOR_MAKE

2018-05-22T12:13:33+00:00

Currently if KERNEL_IMAGETYPES contains both vmlinux and vmlinux.gz, KERNEL_IMAGETYPE_FOR_MAKE will end up containing two copies of vmlinux, which will result in two calls to "make vmlinux" from kernel_do_compile(). Avoid duplicating vmlinux in KERNEL_IMAGETYPE_FOR_MAKE plus some minor non-functional updates to formatting and comments. (From OE-Core rev: 80455a0b6cce6d12a5b32194d0cad2e4c7f71599) Signed-off-by: Andre McCurdy Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel: Permit overriding of KERNEL_IMAGETYPE_FOR_MAKE

2018-05-11T06:49:37+00:00

Commit a1690131691507bbf5853540229b3ad775b836bf removed the ability of recipes to set KERNEL_IMAGETYPE_FOR_MAKE. Fix that by letting recipes continue to set their own KERNEL_IMAGETYPE_FOR_MAKE if they so wish. They may have been doing so for a while, and don't want to have their carefully-selected value trampled on by kernel.bbclass. This may be required if the recipe itself wants to build one type of kernel, but post-process it into a different type, rather like the vmlinux->vmlinux.gz support provided by kernel.bbclass. (From OE-Core rev: 38abd26fe7de321e0f1fc4895f754f34dee90f6c) Signed-off-by: Mike Crowe Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel.bbclass: improve reproducibility

2018-04-03T22:53:19+00:00

Set KBUILD_BUILD_VERSION=1 to avoid build version being incremented on every build. It is visible in the output of "cat /proc/version" after the hash character. (From OE-Core rev: 7fa32ee42c3320e9e2b24ef747e43484b719f617) Signed-off-by: Jonathan Liu Signed-off-by: Richard Purdie

kernel.bbclass: set HOSTLDFLAGS in KCONFIG_CONFIG_COMMAND

2018-03-20T09:59:32+00:00

Kernel v4.14 and newer contain the following in their Makefile: HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS) HOSTLDFLAGS := $(HOST_LFS_LDFLAGS) This breaks our menuconfig, because it can no longer find ncurses if its not on the host machine. This can be seen in linux-yocto-dev, for example: [clsulliv@clsulliv build]$ bitbake virtual/kernel -c menuconfig GEN ./Makefile HOSTLD scripts/kconfig/mconf /home/clsulliv/yocto/poky/build/tmp/hosttools/ld: cannot find -lncurses /home/clsulliv/yocto/poky/build/tmp/hosttools/ld: cannot find -ltinfo collect2: error: ld returned 1 exit status make[3]: *** [scripts/Makefile.host:99: scripts/kconfig/mconf] Error 1 make[2]: *** [/home/clsulliv/yocto/poky/build/tmp/work-shared/intel-corei7-64/kernel-source/Makefile:504: menuconfig] Error 2 make[1]: *** [Makefile:146: sub-make] Error 2 make: *** [Makefile:24: __sub-make] Error 2 Command failed. Press any key to continue... Fix this by setting HOSTLDFLAGS to ${BUILD_LDFLAGS} in our 'make menuconfig' command. (From OE-Core rev: 6afe8e211bfb3deb359194488f34a2c56f4b5ef6) Signed-off-by: California Sullivan Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/recipes: Use expanded BUILD_REPRODUCIBLE_BINARIES value

2018-03-12T22:06:32+00:00

Replace the occurences of BUILD_REPRODUCIBLE_BINARIES with expanded values ${BUILD_REPRODUCIBLE_BINARIES} so the variable does not need to be exported. (From OE-Core rev: 27f87bbc8395a2481ef808465a62d213a6b678ac) Signed-off-by: Juro Bystricky Signed-off-by: Richard Purdie

kernel: make copying of crtsavres.o conditional

2018-03-08T23:28:04+00:00

As of the 4.13 kernel, there are configuration + linker combinations that do not need (or build) crtsavres.o for ppc64 targets. The commit of interest is: commit efe0160cfd40a99c052a00e174787c1f4158a9cd Author: Nicholas Piggin Date: Fri May 12 01:56:52 2017 +1000 powerpc/64: Linker on-demand sfpr functions for modules For final link, the powerpc64 linker generates fpr save/restore functions on-demand, placing them in the .sfpr section. Starting with binutils 2.25, these can be provided for non-final links with --save-restore-funcs. Use that where possible for module links. This saves about 200 bytes per module (~60kB) on powernv defconfig build. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman As such, our arch test for crtsavres.o is not enough, we add a secondary existence check before trying the copy. [YOCTO #12576] (From OE-Core rev: af58819253a2d4526dc8871a17e1492bd1d92951) Signed-off-by: Bruce Ashfield Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel.bbclass: explicitly depend on bison-native for deterministic builds

2018-02-24T10:31:47+00:00

Explicitly depend on bison-native for deterministic builds, as it is required for the build: | HOSTCC scripts/basic/fixdep | GEN ./Makefile | HOSTCC scripts/kconfig/conf.o | YACC scripts/kconfig/zconf.tab.c | /bin/sh: bison: command not found | scripts/Makefile.lib:217: recipe for target 'scripts/kconfig/zconf.tab.c' failed In most cases, this dependency comes indirectly via toolchain dependencies, specifically binutils-cross, which pulls bison-native. Different setups, such as with external toolchain, would expose this problem, since correct dependency is not marked explicitly. (From OE-Core rev: d26b700553fe8fa21c2e42b04e11bb380d94ef36) Signed-off-by: Denys Dmytriyenko Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta: don't use deprecated functions from utils.bbclass

2018-01-30T11:50:11+00:00

These functions were moved to meta/lib/oe in 2010 and the base_* functions in utils.bbclass were intended to be a short-term compatibility layer. They're still used in a few places, so update the callers to use the new functions. (From OE-Core rev: c97acbd034532895ce57c6717ed1b3ccc7900b0d) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel: Use KERNEL_IMAGETYPE_FOR_MAKE in do_bundle_initramfs

2018-01-19T12:37:13+00:00

In the case of a fitImage the this step should be done on the image use to assemble the fitImage. (From OE-Core rev: a061c6bfd3a049a2c8d14bcfafd6e1837afb95e5) Signed-off-by: Thomas Perrot Signed-off-by: Ross Burton Signed-off-by: Richard Purdie