summaryrefslogtreecommitdiffstats
path: root/meta/classes/kernel.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* kernel.bbclass: fix deployment for initramfs imagesAwais Belal2021-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The do_bundle_initramfs() only processes kernel image types that are found in KERNEL_IMAGETYPE_FOR_MAKE whereas the build system can generate other types that are not directly supported by the kernel build system. In which case when we come to the deploy phase not all the images mentioned in KERNEL_IMAGETYPES would have a respective initramfs bundled image. An example is using vmlinux.gz in KERNEL_IMAGETYPES and enabling initramfs and then we see install: cannot stat 'arch/arm64/boot/vmlinux.gz.initramfs': No such file or directory So we align the deploy phase with bundle initramfs phase and pick up relevant initramfs bundled images using KERNEL_IMAGETYPE_FOR_MAKE instead of KERNEL_IMAGETYPES. (From OE-Core rev: 526bdd88ccd758204452579333ba188e29270bde) Signed-off-by: Awais Belal <awais_belal@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: skip installing fitImage when using Initramfs bundlesAbdellatif El Khlifi2021-01-201-1/+15
| | | | | | | | | | | | | | | | | | | | When including an initramfs bundle inside a FIT image, the fitImage is created after the install task by do_assemble_fitimage_initramfs. This happens after the generation of the initramfs bundle (done by do_bundle_initramfs). So, at the level of the install task we should not try to install the fitImage. The fitImage is still not generated yet. After the generation of the fitImage, the deploy task copies the fitImage from the build directory to the deploy folder. Change-Id: I3eaa6bba1412f388f710fa0f389f66631c1c4826 (From OE-Core rev: 1b67fd9ac74935fa41e960478c54e45422339138) Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: set COMPATIBLE_HOST to *-linuxRoss Burton2020-12-241-0/+2
| | | | | | | | | | | The target system triple contains whether the target is Linux or not, so use it to avoid situations where you can attempt to build a kernel for systems which don't support Linux. (From OE-Core rev: b1eeeab21a81990321468ddbdd1745ea24d1828d) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: relocate copy of module.lds to module compilation taskBruce Ashfield2020-11-181-1/+4
| | | | | | | | | | | | | | | | | | | | There were two copies of this patch floating around, and the merged variant has the copy in the wrong place. module.lds is only created during modules_prepare, and that target is not invoked during our main build of the kernel. We aren't about to change the kernel build (there's no need), so we move the copy into the compile_kernelmodules task. After that runs, we have module.lds availble to copy. This has been tested against clean kernel + out of tree module builds, and the dependencies are correct that the file is copied before the out of tree module build starts. (From OE-Core rev: 7d94f9209ebaaf59ea001239a889dd7f928a0e7c) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: Set proper LD in KERNEL_KCONFIG_COMMANDWonmin Jung2020-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With 'ld-is-gold' and linux kernel 5.4 or later, menuconfig task for kernel recipes will fail with: $ bitbake -c menuconfig virtual/kernel ... scripts/kconfig/mconf Kconfig scripts/Kconfig.include:43: gold linker 'x86_64-poky-linux-ld' not supported /OE/build/tmp/work-shared/qemux86-64/kernel-source/scripts/kconfig/Makefile:29: recipe for target 'menuconfig' failed make[2]: *** [menuconfig] Error 1 /OE/build/tmp/work-shared/qemux86-64/kernel-source/Makefile:606: recipe for target 'menuconfig' failed make[1]: *** [menuconfig] Error 2 /OE/build/tmp/work-shared/qemux86-64/kernel-source/Makefile:185: recipe for target '__sub-make' failed make: *** [__sub-make] Error 2 Command failed. This is because that the KERNEL_LD variable already set in kernel-arch.bbclass isn't used by do_menuconfig function of cml1.bbclass. To fix this issue specify LD variable while calling the kernel menuconfig command through KERNEL_KCONFIG_COMMAND. (From OE-Core rev: 1faf66ce0b1f8f5165277161e07e25e672370c3f) Signed-off-by: Wonmin Jung <wonmin82@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: provide module.lds for out of tree builds in v5.10+Bruce Ashfield2020-11-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The upstream commit 596b0474d3d [kbuild: preprocess module linker script], adds a dependency on module.lds for external module building. Since module.lds is generated as part of 'modules_prepare', we must make it available with the other kernel artifacts in the kernel shared workdir, otherwise out of tree builds fail. This fixes errors like: | make[4]: *** No rule to make target 'scripts/module.lds', needed by 'build/tmp/work/qemuarm64-poky-linux/cryptodev-module/1.11-r0/git/cryptodev.ko'. Stop. | make[4]: *** Waiting for unfinished jobs.... We also ensure that kernel-devsrc has a copy to support on target module builds that are often prepared with 'make scripts prepare'. Those targets won't regenerate it, so the build fails. If 'make modules_prepare' is used, the file will be regenerated and overwrite our copy (as expected). (From OE-Core rev: 0fc66a0b64953aae38d0124b57615fffaec8de52) Signed-off-by: Pan, Kris <kris.pan@intel.com> Signed-off-by: Lili Li <lili.li@intel.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: ensure symlink_kernsrc task gets run even with externalsrcRasmus Villemoes2020-09-281-1/+4
| | | | | | | | | | | | | | | | | | | | | Commit c5dfc2586b41 (kernel.bbclass: run do_symlink_kernsrc before do_patch) fixed a race between do_symlink_kernsrc and do_populate_lic. However, I missed the fact that when externalsrc.bbclass is in use, the do_patch task doesn't exist, meaning that do_symlink_kernsrc now doesn't get run at all, breaking the build. We need this task to run regardless of whether do_patch exists or not, so reinstate the configure->symlink_kernsrc dependency explicitly. Fixes: c5dfc2586b41 (kernel.bbclass: run do_symlink_kernsrc before do_patch) Reported-by: Chanho Park <parkch98@gmail.com> (From OE-Core rev: a2b50b74d609ce079ab36b82d4c7c3539fb56485) Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: use camelCase notation for bash variables in do_deployMartin Jansa2020-09-171-7/+7
| | | | | | | | | | | * to match other variables there like deployDir imageType [YOCTO #12937] (From OE-Core rev: 13c5d1b686255d385d200cbd06b7000080809fc7) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: eliminate (initramfs_)symlink_name variablesMartin Jansa2020-09-171-4/+2
| | | | | | | | | | | | * they are used only once, we can use the value directly * notice that .bin extension isn't part of the variable values [YOCTO #12937] (From OE-Core rev: 22874b43de45e86418f683eb9d4394d7a8a08033) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: use bash variables like imageType, base_name without {}Martin Jansa2020-09-171-10/+10
| | | | | | | | | | | | * just to make sure it looks like bash variable not bitbake variable in run.do_* scripts [YOCTO #12937] (From OE-Core rev: 9a16dc2ac3d5e8ea95a575c377d3ad1602c1db12) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: Move away from calling package_get_auto_prMark Hatle2020-08-281-1/+4
| | | | | | | | | | | | | | | | | | | ...instead we call read_subpackage_metadata. Calling package_get_auto_pr *should* result in the same PKGV AUTOINC replacement. However, it will also end up changing PKGR differently then do_package as the BB_TASKHASH used will be for the wrong task. Generally this won't cause any real-world issue, but it could cause problems. Moving to read_subpackage_metadata ensures that the values used in do_package will be read in and used for kernel deployment. (From OE-Core rev: 86142dad13935a0d9af4a4177e05ff5c39003db7) Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: Remove do_install[prefunc] no longer neededMark Hatle2020-08-261-1/+0
| | | | | | | | | | Prior work has refactored the do_install task multiple times, and any references to PKGV and PKGR (even indirect ones) have been removed. (From OE-Core rev: 36fe4db8ae827a93abe9fce6740459d215411965) Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: run do_symlink_kernsrc before do_patchRasmus Villemoes2020-08-261-1/+1
| | | | | | | | | | | | | | | | | | | There's a race between do_symlink_kernsrc and do_populate_lic, since the latter is ordered "after do_patch"; so the two may run in parallel. In some cases, that actually causes do_populate_lic to fail if it happens to look for a license file somewhere under ${S} in the short window after shutil.move and before the symlink has been created. Fix that by simply ordering symlink_kernsrc before do_patch. Any task that pokes around in ${S} looking for files should be ordered after do_patch, so this should also fix similar latent races with other ad hoc tasks. (From OE-Core rev: c5dfc2586b4135cc86e91bb04fed837daf505676) Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: Configuration for environment with HOSTCXXZhang Qiang2020-08-131-0/+2
| | | | | | | | | | | | | | | | | | | When compiling xilinx-zynq board linux-kernel-dev(v5.8) if "GCC_PLUGINS=y", The following error will appear: "HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o fatal error: gmp.h: No such file or directory" the GCC_PLUGINS depend on return result of gcc-plugin.sh execution however in gcc-plugin.sh use HOSTCC to detect the feature of GNU extension of gcc, this will result that HOSTCC can compile the file successfully, but HOSTCXX is used in the actual compilation process. (From OE-Core rev: 740d87766cb87f75c477666d97cb0480c10217f4) Signed-off-by: Zhang Qiang <qiang.zhang@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: make dependency on lzop-native conditionalTimon Ulrich2020-07-081-1/+2
| | | | | | | | | a native lzop is only needed when an lzo compressed initramfs is actually present (From OE-Core rev: 1217ddf070261c5fe523729b2a833bd38f1e4ccd) Signed-off-by: Timon Ulrich <t.ulrich@anapur.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: add gzip-native to do_deploy dependenciesMatt Madison2020-07-081-1/+1
| | | | | | | | | | | | | | | When a modules tarball is created during kernel_do_deploy, the tarball is compressed using gzip, but gzip-native is not a dependency so the build host's gzip is being used for this. Using gzip-native will, by default, use pigz instead of single-threaded gzip, making this task less of a bottleneck for builds with a large modules package. (From OE-Core rev: 1243aad78601e9a5c0a3471c8a105c429536599d) Signed-off-by: Matt Madison <matt@madison.systems> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support ↵Yanfei Xu2020-07-051-3/+19
| | | | | | | | | | | | | | | symlinks Some filesystems don't support symlink, then you will get failure when you install or update the kernel rpm package. Now we use a copy of image for these filesystems instead of symlink. Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> Suggested-by: Richard Purdie <richard.purdie@linuxfoundation.org> (From OE-Core rev: bb946b8cdbd01408bfa0ba8e53f9e09931dfb29d) Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: add lz4 dependency and fix the call to lz4Timon Ulrich2020-07-051-1/+2
| | | | | | | | | | | | If the initramfs image is type lz4, then a native lz4 is needed. Additionally an output filename needs to be specified when calling lz4, otherwise STDOUT will be used implicitly. (From OE-Core rev: c83a7aec59defbbc049d44ba34a7a409ada4fa19) Signed-off-by: Timon Ulrich <t.ulrich@anapur.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* deploy.bbclass: Clean DEPLOYDIR before do_deployDaniel Klauer2020-06-301-2/+0
| | | | | | | | | | | | | | | | | | | | | | do_deploy should clean up ${DEPLOYDIR} before running, just like do_install cleans up ${D} before running. This reduces the risk of DEPLOYDIR being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds. It is convenient to have this in deploy.bbclass, so it doesn't have to be duplicated in every recipe, considering for example meta-freescale, which has 23 affected recipes. All recipes using deploy.bbclass (grep -r 'inherit .*deploy') in poky, meta-openembedded and meta-freescale look like they either benefit from this or are at least not affected negatively by it. The only exception I've noticed was uboot-sign.bbclass, which was however fixed by the previous patch. (From OE-Core rev: 7083a7d56f4d90c81d2e6652ee291d20fd908bbe) Signed-off-by: Daniel Klauer <daniel.klauer@gin.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: Fix Module.symvers supportLili Li2020-06-281-1/+1
| | | | | | | | | | | | | | | | | | Starting from v5.8-rc1 commit 269a535ca931 (modpost: generate vmlinux.symvers and reuse it for the second modpost"), kernel will generate new vmlinux.symvers instead of dumping all the vmlinux symbols into Module.symvers in the first pass. Error log: 'run.do_shared_workdir.16614' failed with exit code 1: DEBUG: cp: cannot stat 'Module.symvers': No such file or directory This change will check the file Module.symvers existence before copying it. (From OE-Core rev: cd2d62a08a1dfcd890a03ee55132b6d6c65f5ab7) Signed-off-by: Lili Li <lili.li@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-modules.tgz: fix file permissions to rootLi Wang2020-05-221-0/+1
| | | | | | | | | | the files of linux-modules should be same permissions with rootfs.tar.bz2, because it is a part of rootfs when used to install. (From OE-Core rev: 71e141906069c6f754199512741f6e3d5b72fee7) Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel/reproducibility: kernel modules need SOURCE_DATE_EPOCH exportBruce Ashfield2020-05-151-0/+15
| | | | | | | | | | | | | | | | | | If CONFIG_IKHEADERS is set to =m, then reproducibility issues creep into the modules build, since the variables we are setting for the main kernel build are not present. Since the source code must be available for a possibly git query on the timestamp, there didn't seem to be an easy way to move the environment variable setting to a common routine. As such, we duplicate the block of code that exports the required variables for reproducible builds. There is a maintenance risk to this, but any issues should be easy enough to catch. (From OE-Core rev: 82cdfcdccfedd320ebc0cdc778c7d4966198b96f) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/kernel: Generate reproducible kernel module tarballJoshua Watt2020-05-141-1/+7
| | | | | | | | | | | | | | | If reproducible binaries are requested, generate the kernel modules tarball in a reproducible way. Namely, sort the tarball contents, clamp the mtime to the source date epoch, compress the archive with a consistent compression level (9), and don't include the name and timestamp in the compressed file. [YOCTO #12719] (From OE-Core rev: 5c6a472c82a9b3c122fc54d3ee7171508c643a8b) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: fix SOURCE_DATE_EPOCH for non-git kernel buildsChristopher Clark2020-03-101-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The source directory is not always a git repository, so when querying git for data to set SOURCE_DATE_EPOCH, specify ${S}/.git as the git directory to prevent retrieving incorrect data from any parent directory. Fixes the following errors with the prior logic when building a kernel that is not obtained from a git repository: 1. With TMPDIR set to a directory outside any git repository on a mounted filesystem, reproducible builds fail in do_compile with this git error: fatal: not a git repository (or any parent up to mount point <abspath>) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). aborting before the error handling logic. 2. With TMPDIR located within a subdirectory of a git repository, the SOURCE_DATE_EPOCH timestamp would be that of said repository rather than that of the kernel. (From OE-Core rev: 270ae94fe345b9ce98d822034cbfad7e24c5f393) Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/kernel.bbclass: Fix parsing errorsJoshua Watt2020-03-061-2/+2
| | | | | | | | | | | legitimize_package_name wants the actual value of KERNEL_REVISION, so use d.getVar() to fetch it as is done elsewhere in the file. Failing to do so can result it weird errors at parsing time. (From OE-Core rev: 9bff4d14693c1890fc181ec68c9f883dc4e4accf) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: set LD in KERNEL_CONFIG_COMMAND to fix 5.4+ builds when gold ↵Martin Jansa2020-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | is enabled * with 5.4 kernel the do_configure fails when gold is enabled (with ld-is-gold in DISTRO_FEATURES) * bfd is already being set in KERNEL_LD: kernel-arch.bbclass:KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}" but KERNEL_LD is currently respected only by do_compile and do_compile_kernel modules and new kernel which contains a check for gold in Kbuild: https://lore.kernel.org/lkml/alpine.DEB.2.21.1907161434260.1767@nanos.tec.linutronix.de/ more details: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com will fail during the configuration even when gold wouldn't be used to build it in the end, add LD setting to KERNEL_CONFIG_COMMAND to prevent premature error when configuring scripts/kconfig/conf --olddefconfig Kconfig scripts/Kconfig.include:39: gold linker 'x86_64-oe-linux-ld' not supported make[2]: *** [/OE/build/oe-core/tmp-glibc/work-shared/qemux86-64/kernel-source/scripts/kconfig/Makefile:73: olddefconfig] Error 1 (From OE-Core rev: 66c1f4b0abd3483759f9e4141a80f982eaf8ccfd) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: Make symbol link to vmlinux.64 in boot directoryVasyl Gomonovych2019-12-301-0/+3
| | | | | | | | | | Some mips 64 bit platforms use vmlinux.64 image name Make a symbol link to vmlinux.64 in arch/mips/boot/ (From OE-Core rev: 70626b52e5e61c80018e9f1f85bc169d0434b986) Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Revert "kernel.bbclass: adjust a condition checking"Jason Wessel2019-09-061-2/+4
| | | | | | | | | | | | | | | | | | | This reverts commit 6676411fccff2d331878e4ca1f9411aafb056a80. This revert restores the original code and adds a comment. The commit that was reverted broke a number of wic templates and tools which rely on the initramfs creation dependency and the case where the INITRAMFS_IMAGE_BUNDLE is not set. If an end user does not want the INITRAMFS_IMAGE generated, it should be set to "". [ Issue: LIN1019-1791 ] (From OE-Core rev: ab61a11623ac0a25ba1c98d686c79815abab573f) Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: fix installation of modules signing certificatesDmitry Eremin-Solenikov2019-07-311-1/+1
| | | | | | | | | | | | If one has provided external key/certificate for modules signing, Kbuild will skip creating signing_key.pem and will write only signing_key.x509 certificate. Thus we have to check for .x509 file existence rather than .pem one. (From OE-Core rev: 2527e731eba43bd36d0ea268aca6b03155376134) Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin-solenikov@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: Make task clean depend on cleaning of make-mod-scriptsHaiqing Bai2019-06-111-0/+1
| | | | | | | | | | | | | | | | The package 'make-mod-scripts' creates files in 'kernel-build-artifacts/include/config' which are removed by 'cleanall/cleansstate' of 'virtual/kernel'. And this causes the below error while building out of tree kernel module: ERROR: Kernel configuration is invalid. include/generated/autoconf.h or include/config/auto.conf are missing. Run 'make oldconfig && make prepare' on kernel src to fix it. Suggested-by: Jun Nie <jun.nie@linaro.org> (From OE-Core rev: f79c95f6a883e999e0c2ecfd60b6b696b7595497) Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: package modules.builtin.modinfoBruce Ashfield2019-05-311-1/+1
| | | | | | | | | | | | | | As of commit 898490c010b [moduleparam: Save information about built-in modules in separate file] (kernels v5.2-rc1+), modules.builtin.modinfo is generated as part of the kernel build process. We package it along with the other module artifacts, so it can be used by scripts/other build steps. (From OE-Core rev: 112a4d3b2b4a829dd5657b6533b1c1bb589d6c8e) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: adjust a condition checkingMing Liu2019-05-161-1/+2
| | | | | | | | | | | do_bundle_initramfs does not have to depend on ${INITRAMFS_IMAGE}:do_image_complete if INITRAMFS_IMAGE_BUNDLE is not set. (From OE-Core rev: 6676411fccff2d331878e4ca1f9411aafb056a80) Signed-off-by: Ming Liu <liu.ming50@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: convert base_do_unpack_append() to a taskSteven Hung (洪于玉)2019-04-231-1/+2
| | | | | | | | | | | <pre> when&#32;externalsrc&#32;is&#32;enabled&#32;and&#32;the&#32;&#39;do_unpack&#39;&#32;task&#32;is&#32;deleted, building&#32;kernel&#32;module&#32;fail (From OE-Core rev: 1ba4728f058b90957741fa016230ffa72e206ff3) Signed-off-by:&#32;Steven&#32;Hung&#32;(&#27946;&#20110;&#29577;)&#32;&lt;Steven.Hung@mediatek.com&gt; Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: add objtool to shared workdir when CONFIG_UNWINDER_ORC is setJustin Bronder2019-03-021-0/+9
| | | | | | | | | | | | | | | | | | | Based on: https://patchwork.openembedded.org/patch/148047/ When x86_64 enables CONFIG_UNWINDER_ORC [ORC (Oops Rewind Capability) unwinder for unwinding kernel stack traces], objtool is required to generate the required information. If we don't copy objtool to the shared workdir, out-of-tree modules cannot generate object files. For instance, meta-skeleton/hello-mod fails with: | make[3]: *** No rule to make target 'tools/objtool/objtool', needed by ... (From OE-Core rev: 7d4fdd3b95c949277f77df90bb2e8120b8d167ae) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: Ensure an initramfs is added if configuredRichard Purdie2019-02-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | If ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.cpio does not exist, nor any of the compressed variants, nothing is copied to kernel build's ./usr directory. The code does not fail, but silently proceeds without a bundled initramfs. Change to fail and tell the user something is wrong. Also, if an initramfs is found, contrary to the comments, it does not stop at the first uncompressed/compressed cpio image found. Instead it keeps processing all so the last is used. Fix this to behave as per the comments. [YOCTO #12909] (Patch by Leon Woestenberg) (From OE-Core rev: 5b5604e288af755eb5553a97d26533445b2cf94b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: Fix Deprecated warnings from regexsRichard Purdie2019-01-161-1/+1
| | | | | | | | | | | | | | | | | | | | Fix handling of escape characters in regexs and hence fix python Deprecation warnings which will be problematic in python 3.8. Note that some show up as: """ meta/classes/package.bbclass:1293: DeprecationWarning: invalid escape sequence \.   """ where the problem isn't on 1293 in package.bbclass but in some _prepend to a package.bbclass function in a different file like mesa.inc, often from do_package_split() calls. (From OE-Core rev: 4b1c0c7d5525fc4cea9e0f02ec54e92a6fbc6199) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: Fix incorrect deploying of fitimage.initramfsManjukumar Matha2019-01-071-0/+3
| | | | | | | | | | | | | | | | | When kernel-fitimage and initramfs is enabled using INITRAMFS_IMAGE_BUNDLE = "1", kernel do_deploy tries to deploy fitImage.initramfs with following error | install: cannot stat 'arch/arm64/boot/fitImage.initramfs': No such file or directory Skip deploying fitimage.initramfs, since fitimage does not create fitimage.initramfs (From OE-Core rev: 0f87f8522a2c1b5a7042738887952b98060fbd9d) Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: don't assign the build user/hostFederico Sauter2018-12-081-2/+2
| | | | | | | | | | | | | | The KBUILD_BUILD_USER and KBUILD_BUILD_HOST variables were assigned at the kernel class level, which made it impossible to override them in the local configuration. By setting only the default values of those variables in the kernel class, it is now possible to override them as expected. (From OE-Core rev: a3e8cdf9c3ba966fa4b5a21235540eb0b00fb487) Signed-off-by: Federico Sauter <federico.sauter@ableton.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: use olddefconfig as the primary target for KERNEL_CONFIG_COMMANDBruce Ashfield2018-11-141-1/+1
| | | | | | | | | | | | | | | | | | | As was warned by commit 312ee68752fa [kconfig: announce removal of oldnoconfig if used], oldnoconfig has been removed from the 4.20 kernel. So we switch our default mode to olddefconfig. commit fb16d8912 [kconfig: replace 'oldnoconfig' with 'olddefconfig', and keep the old name as an alias] introduced olddefconfig in the 3.10 kernel, we shuffle oldnoconfig to the fallback target. The fallback mode allows kernels between 3.10 and the currently listed oldest kernel of 3.2 to continue to configure. (From OE-Core rev: 8593dcb7e8c938530ff00ffedf7f3d02d26c3bad) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: allow custom KERNEL_IMAGEDESTIoan-Adrian Ratiu2018-10-251-1/+1
| | | | | | | | | | | Some distros want to install the kernel in a custom location other than /boot and have it properly packaged, so it's useful to use a weaker assignment. (From OE-Core rev: cadd91655a336eb6d65ca43dc1231bbe5271e1cf) Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: Avoid iterating over KERNEL_IMAGETYPES twiceAlex Kiernan2018-09-221-7/+4
| | | | | | | | | | | During deploy we iterate over KERNEL_IMAGETYPES twice, with no consumer of our changes in the interim. Collapse these two loops into one. (From OE-Core rev: 8d3139640ed4cd4e196dc2d1f6ae02d612fb9564) Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: Fix modules tarball generation with usrmergeAlex Kiernan2018-09-221-2/+2
| | | | | | | | | | | | When usrmerge is enabled the kernel modules aren't under /lib, but /usr/lib; ensure we fetch the modules from the correct location so we don't have a tarball which consists of a single symlink. (From OE-Core rev: 62d2d7d12dda69d6019a1a2d5492450487e41bfd) Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Revert "kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does ↵Alex Kiernan2018-09-221-12/+6
| | | | | | | | | | | | | | | | that." This reverts commit 65cded55fa96b1ba72149a31689c081ac27af7f7. The fitImage deployed here is the one generated in kernel-fitimage.bbclass, whereas the one deployed by kernel-fitimage.bbclass is a raw image, so we need the one deployed here keeping. (From OE-Core rev: 798d2acc0141b13da7ddd18875a417b2df9d57b3) Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.Leon Woestenberg2018-09-131-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | kernel-fitimage.bbclass replaces an occurance of "fitImage" in KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the architecture (such as zImage). The kernel-fitimage.bbclass packs that image as sub-image in a flattened image tree image (fitImage) and deploys this fitImage along with the image tree source file (.its). kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus also contains "fitImage", which kernel.bbclass will also deploy redundantly with different naming. The result is a dual deployment with slightly different naming, each with a set of symlinks. The solution chosen is to have fitImage deployment be handled by kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage types during deployment. (From OE-Core rev: 65cded55fa96b1ba72149a31689c081ac27af7f7) Signed-off-by: Leon Woestenberg <leon@sidebranch.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: rename type variable to imageTypeMartin Jansa2018-08-211-29/+29
| | | | | | | | | * to avoid confusion with "type" command in shell (From OE-Core rev: 8d454ea754c96561257b1cc011fa638ceaa771db) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-artifact-names.bbclass, kernel.bbclass: remove prefix and extension ↵Martin Jansa2018-08-211-2/+2
| | | | | | | | | | | | | from MODULE_TARBALL_* variables * for consistency with other artifacts variables, include only the version string, not the actual name or extension * changing .tgz to something else in the MODULE_TARBALL_NAME variable only wouldn't make much sense because then kernel.bbclass still calls "tar -cvzf" to create it (From OE-Core rev: 43bd7f39157da49f7fb0c2d6d9751059471c8d53) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel*.bbclass: rename *_SYMLINK_NAME variables to *_LINK_NAME and ↵Martin Jansa2018-08-211-7/+7
| | | | | | | | | | | | | | *_BASE_NAME to *_NAME * for consistency with IMAGE_NAME and IMAGE_LINK_NAME and to avoid confusion with IMAGE_BASENAME (which is the actual name of the artifact, e.g. PN while KERNEL_IMAGE_BASE_NAME was only the version suffix) (From OE-Core rev: f952c8e08b4798aa0f8bf764cfd70bda0eae9b8b) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: move variables for kernel artifacts names to separate bbclassMartin Jansa2018-07-101-17/+1
| | | | | | | | | | | | | | | | * 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 <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: use the consistent naming schema for initramfsMartin Jansa2018-07-101-10/+9
| | | | | | | | | | | | | | | * 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 <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-devicetree.bbclass: Fix and simplify instalation of DTB filesMartin Jansa2018-07-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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 <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>