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

kernel.bbclass: move variables for kernel artifacts names to separate bbclass

2018-07-10T16:33:00+00:00

* this makes it easier to access these variables from some other bbclass e.g. sdcard_image-rpi.bbclass in meta-raspberry where we need to know how some files in deploy are named, but we cannot inherit kernel.bbclass as it's used in image recipe not kernel recipe * alternatively we can move these to bitbake.conf like similar image variables are: meta/conf/bitbake.conf:IMAGE_BASENAME = "${PN}" meta/conf/bitbake.conf:IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}" meta/conf/bitbake.conf:IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}" (From OE-Core rev: 7d0ef0eaa1bfe97015a774c26f5791622e7e8b12) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

kernel.bbclass: use the consistent naming schema for initramfs

2018-07-10T16:33:00+00:00

* use INITRAMFS_BASE_NAME and INITRAMFS_SYMLINK_NAME variables, like other kernel artifacts are using * use "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" instead of "${PV}-${PR}-${MACHINE}-${DATETIME}" to be consistent with other files * allow to modify default symlink name with INITRAMFS_SYMLINK_NAME instead of currently used: initramfs_symlink_name=${type}-initramfs-${MACHINE} (From OE-Core rev: 935b9d5a2bd12effad65f69a631ecff96b8bb553) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

kernel-devicetree.bbclass: Fix and simplify instalation of DTB files

2018-07-10T16:32:59+00:00

* add 2 new variables: KERNEL_DTB_BASE_NAME KERNEL_DTB_SYMLINK_NAME instead of reusing KERNEL_IMAGE_SYMLINK_NAME and than expecting that default value ${MACHINE} was being used in e.g.: DTB_SYMLINK_NAME=`echo ${symlink_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"` * install normal DTB files only once even if there is multiple entries in KERNEL_IMAGETYPE_FOR_MAKE and don't prefix them with the type of the kernel image, use the KERNEL_IMAGETYPE_FOR_MAKE as a prefix only when installing them bundled with kernel or initramfs image. * deploy the files from ${D}/${KERNEL_IMAGEDEST}/ instead of kernel build directory, so that we don't need to call DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"` again in do_deploy * create all links in do_deploy task, because default KERNEL_DTB_BASE_NAME like KERNEL_IMAGE_BASE_NAME contains PKGR and PKGR is different in do_install and do_deploy, because kernel.bbclass calls meta/classes/kernel.bbclass:do_install[prefuncs] += "package_get_auto_pr" meta/classes/kernel.bbclass:do_deploy[prefuncs] += "package_get_auto_pr" * the filenames are a bit different, but with separate variable it should be easier for other bbclasses which use these DTB files to find them correctly, just use either the cannonical name $dtb_base_name.$dtb_ext or $dtb_base_name-${KERNEL_DTB_SYMLINK_NAME}.$dtb_ext because PKGR (and other PKG* variables) might be different in your task and kernel.do_deploy task. * fix DTB files being deployed with incorrect filenames when KERNEL_IMAGE_SYMLINK_NAME isn't set to ${MACHINE}, e.g. instead of the default: -rw-r--r-- 2 bitbake bitbake 1.4K Nov 20 07:41 deploy/images/raspberrypi3-64/Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo lrwxrwxrwx 2 bitbake bitbake 64 Nov 20 07:41 deploy/images/raspberrypi3-64/Image-lirc-rpi.dtbo -> Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo lrwxrwxrwx 2 bitbake bitbake 64 Nov 20 07:41 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo I was getting: -rw-r--r-- 2 bitbake bitbake 1348 Nov 20 10:28 deploy/images/raspberrypi3-64/Image-linux-raspberrypi-lirc-rpi.dtbo lrwxrwxrwx 2 bitbake bitbake 37 Nov 20 10:28 deploy/images/raspberrypi3-64/Image-linux-raspberrypi-lirc-rpi-master-20171120102653.dtbo -> Image-linux-raspberrypi-lirc-rpi.dtbo lrwxrwxrwx 2 bitbake bitbake 37 Nov 20 10:28 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> Image-linux-raspberrypi-lirc-rpi.dtbo and e.g. sdcard_image-rpi.bbclass from meta-raspberrypi: https://github.com/agherzan/meta-raspberrypi/blob/37e4e18f4a745ce8dc11f7e40a29da0859ff13c6/classes/sdcard_image-rpi.bbclass was failing in: mcopy -i ${WORKDIR}/boot.img -s ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${DTB_BASE_NAME}.dtb ::${DTB_BASE_NAME}.dtb because ${KERNEL_IMAGETYPE}-${DTB_BASE_NAME}.dtb doesn't exist in my build, due to DTB_SYMLINK_NAME=`echo ${symlink_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"` not replacing whole "${KERNEL_IMAGE_SYMLINK_NAME}" (read ${MACHINE}) with just ${DTB_BASE_NAME} * with this change applied the deploy dir looks like this: -rw-r--r-- 2 bitbake bitbake 1.4K Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo lrwxrwxrwx 2 bitbake bitbake 74 Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo lrwxrwxrwx 2 bitbake bitbake 74 Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi-raspberrypi3-64.dtbo -> lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo and works correctly even with DISTRO using different naming scheme * the sdcard_image-rpi.bbclass still needs to be modified, I've provided updated version here: https://github.com/agherzan/meta-raspberrypi/pull/159 * mpc8315e-rdb.conf MACHINE in meta-yocto-bsp also needs small fix: https://lists.yoctoproject.org/pipermail/poky/2018-July/011436.html (From OE-Core rev: 1860d9d3c62e2e94cd68a809385873ffd8270b6d) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

kernel: Set SOURCE_DATE_EPOCH to kernel git timestamp if not set

2018-06-28T08:22:35+00:00

If SOURCE_DATE_EPOCH is unset (in addition to the existing "0" behaviour) parse out the top most commit timestamp from the kernel tree to use as the timestamp. (From OE-Core rev: 2f0dd67a5a8d4269f5155004d532d8fa972b3223) Signed-off-by: Alex Kiernan Signed-off-by: Richard Purdie

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