summaryrefslogtreecommitdiffstats
path: root/meta/classes/kernel.bbclass
AgeCommit message (Collapse)Author
2015-09-02kernel.bbclass: add the runtime dependency on kernel-vmlinux for kernel-imageKevin Hao
When a BSP uses vmlinux for boot, the kernel-image package is just empty. But by default the kernel-vmlinux is not installed. Then the pkg_postinst_kernel-image() would create a symlink to a non-existent file. Fix this by adding the runtime dependency on kernel-vmlinux for kernel-image if the KERNEL_IMAGETYPE is "vmlinux". Signed-off-by: Kevin Hao <kexin.hao@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-08-11kernel.bbclass: dont assume ${B}/include/generated existsAndre McCurdy
Older kernels (e.g. 2.6.32) don't create an include/generated directory, so check that the directory exists before trying to copy files from it in do_shared_workdir(). Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-07-16kernel: fix path assumptions in tasksRoss Burton
Several of the kernel class tasks were making assumptions about what directory they were executed in. Clarify the code by making paths absolute or passing -C to oe_runmake. Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-05-26kernel: Pull uImage generation into separate classMarek Vasut
Pull the uImage image format generation from kernel.bbclass into a separate kernel-uimage.bbclass. Introduce new KERNEL_CLASSES variable, which allows registration of additional classes which implement new kernel image types. The default value of is to register kernel-uimage to preserve the original behavior. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Richard Purdie <richard.purdie@linuxfoundation.org> Cc: Koen Kooi <koen@dominion.thruhere.net> Cc: Paul Eggleton <paul.eggleton@linux.intel.com> Cc: Ross Burton <ross.burton@intel.com> Cc: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-26kernel: Pull out the linux.bin generationMarek Vasut
Pull the generation of linux.bin image, which is then packed into uImage, into a separate function. No functional change. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Richard Purdie <richard.purdie@linuxfoundation.org> Cc: Koen Kooi <koen@dominion.thruhere.net> Cc: Paul Eggleton <paul.eggleton@linux.intel.com> Cc: Ross Burton <ross.burton@intel.com> Cc: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-26kernel: Rework do_uboot_mkimageMarek Vasut
Rework the function so part it's internals can be re-used by fitImage image type. The name of the temporary file , linux.bin , is recycled a little more as it's now used for both the case where it is gzip compressed and where it is not. This should be fine, since the file is temporary and removed after the uImage was created anyway. There is no functional change here. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Richard Purdie <richard.purdie@linuxfoundation.org> Cc: Koen Kooi <koen@dominion.thruhere.net> Cc: Paul Eggleton <paul.eggleton@linux.intel.com> Cc: Ross Burton <ross.burton@intel.com> Cc: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-26kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKEMarek Vasut
Remove the lambda function setting KERNEL_IMAGETYPE_FOR_MAKE and instead set it in the anonymous python function. This also allows us to handle image types which are not supported directly by kernel, but require some other kernel target to be built. This is the case for example with the fitImage, which is the uImage successor. There is no functional change. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Richard Purdie <richard.purdie@linuxfoundation.org> Cc: Koen Kooi <koen@dominion.thruhere.net> Cc: Paul Eggleton <paul.eggleton@linux.intel.com> Cc: Ross Burton <ross.burton@intel.com> Cc: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-15kernel/rm_work: Improve interactionRichard Purdie
The do_shared_workdir task does leave behind the necessary information in shared-work after it completes. We don't make this a "full" sstate task however since that means tarring up and copying what is usually a large amount of data which would be better extracted straight from the original SCM. The issue with rm_work occurs since it removes the do_shared_workdir stamp meaning subsequent builds will add it back if they need to touch any kernel modules for example. This ends up triggering a near enough complete kernerl rebuild since if configure reruns, populate_sysroot has to rerun. This change promotes the task to have a "setscene" variant but it doesn't use any of the sstate class lifting to generate the sstate file. The sstate function will therefore never get called since the sstate object will never exist. We can add the task to the list of tasks rm_work promotes to a setscene variant and unwanted rebuilds of the kernel should be avoided. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-07kernel.bbclass: Fix race conditionEd Bartosh
Race condition between do_compile_kernelmodules and do_shared_workdir tasks occurs when do_compile_kernelmodules changes files in include/generated/* while do_shared_workdir tries to copy them to shared working directory. Fixed race by moving do_shared_workdir after do_compile but before do_compile_kernelmodules. [YOCTO #7321] Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-29kernel: Fix depmod for multilibRichard Purdie
Using populate_sysroot for this data was a nice idea but flawed as it doesn't work in multilib builds. Instead we can use PKGDATA_DIR since this is consistent over multilib builds. It also turns out to be slightly neater code too. Hopefully this resolves the problem once and for all. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-23kernel/image/depmodwrapper: Fixups for depmodRichard Purdie
With the rpm package backend enabled, running: bitbake <image> bitbake virtual/kernel -c clean bitbake <image> -c rootfs -f results in an image with incorrect kernel module dependency information. The problem is that the System.map and kernel-abiversion files are needed for depmod and after the recent kernel changes, these are no longer in sstate. Its reasonable to require the kernel to unpack/build if you're about to build a module against it. It is not reasonable to require this just to build a rootfs. Therefore stash the needed files specifically for depmod. Also fix some STAGING_KERNEL_DIR references which were incorrect, found whilst sorting through his change. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-23fix '[[: not found' error message using dashVincent Génieux
Remove bash specific syntax '[[ test ]]' replaced with '[ test ]'. Fixes [YOCTO #7112] Signed-off-by: Vincent Génieux <vincent2014@startigen.fr> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-01-16kernel.bbclass: Update cleandirs to remove new kernel staging dirsDarren Hart
Fixes [YOCTO 6818] Update do_unpack[cleandirs] to include the STAGING_KERNEL_BUILDDIR, and add the same set of updated cleandirs for do_clean. Signed-off-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-16kernel: move source and build output to work-sharedBruce Ashfield
commit 3b3f7e785e279 [kernel: Rearrange for 1.8] began the process of moving the kernel source and build artefacts out of sstate control and into a shared location. This changed triggered some workflow issues, as well as bugs related to the kernel source containing build output, and hence being dirty and breaking kernel rebuilds. To solve these issues, and to make it clear that the kernel is not under sstate control, we move the source and build outputs to: work-shared/MACHINE/kernel-source work-shared/MACHINE/kernel-build-artifacts Where kernel-build-artifacts is the kernel build output and kernel-source is kept "pristine". The build-artifacts contain everything that is required to build external modules against the kernel source, and includes the defconfig, the kernel-abiversion, System.map files and output from "make scripts". External module builds should either pass O= on the command line, or set KBUILD_OUTPUT to point to the build-artifacts. module-base.bbclass takes care of setting KBUILD_OUTPUT, so most existing external module recipes are transparently adapted to the new source/build layout. recipes that depend on the kernel source must have a depedency on the do_shared_workdir task: do_configure[depends] += "virtual/kernel:do_shared_workdir" With this dependency added, the STAGING_KERNEL_DIR will be populated and available to the rest of the build. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-16kernel.bbclass: When linux/version.h exists, copy itOtavio Salvador
Old Linux kernel versions rely on linux/version.h for modules; this needs to be published for external modules to use. Copy it when available. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-07kernel.bbclass: fix do_unpack function when S ends with slashMartin Jansa
* slash at the end causes os.symlink(kernsrc, s) to use s as directory name and fails with: ERROR: Error executing a python function in /OE/build/owpb/webos-ports/meta-smartphone/meta-samsung/recipes-kernel/linux/linux-samsung-tuna_git.bb: The stack trace of python calls that resulted in this exception/failure was: File: 'base_do_unpack', lineno: 26, function: <module> 0022: subprocess.call(d.expand("mv /OE/build/owpb/webos-ports/tmp-glibc/work/maguro-webos-linux-gnueabi/linux-samsung-tuna/3_3.0.72+gitrAUTOINC+f8ed73f94a-r12/git/ /OE/build/owpb/webos-ports/tmp-glibc/sysroots/maguro/usr/src/kernel"), shell=True) 0023: os.symlink(kernsrc, s) 0024: 0025: *** 0026:base_do_unpack(d) 0027: File: 'base_do_unpack', lineno: 23, function: base_do_unpack 0019: bb.utils.mkdirhier(kernsrc) 0020: bb.utils.remove(kernsrc, recurse=True) 0021: import subprocess 0022: subprocess.call(d.expand("mv /OE/build/owpb/webos-ports/tmp-glibc/work/maguro-webos-linux-gnueabi/linux-samsung-tuna/3_3.0.72+gitrAUTOINC+f8ed73f94a-r12/git/ /OE/build/owpb/webos-ports/tmp-glibc/sysroots/maguro/usr/src/kernel"), shell=True) *** 0023: os.symlink(kernsrc, s) 0024: 0025: 0026:base_do_unpack(d) 0027: Exception: OSError: [Errno 2] No such file or directory ERROR: Function failed: base_do_unpack ERROR: Logfile of failure stored in: /OE/build/owpb/webos-ports/tmp-glibc/work/maguro-webos-linux-gnueabi/linux-samsung-tuna/3_3.0.72+gitrAUTOINC+f8ed73f94a-r12/temp/log.do_unpack.17042 ERROR: Task 0 (/OE/build/owpb/webos-ports/meta-smartphone/meta-samsung/recipes-kernel/linux/linux-samsung-tuna_git.bb, do_unpack) failed with exit code '1' Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-21kernel: Fix non linux-yocto buildsRichard Purdie
After the recent kernel changes, non linux-yocto builds stopped working properly for two reasons: a) ${S} was being reset to ${WORKDIR}/git for example and STAGING_KERNEL_DIR did not contain the source b) Most builds were using ${B} == ${S} This patch adds a fixup to the unpack function to handle the case where ${S} != ${STAGING_KERNEL_DIR} and also set up the infrastrcture so that B != S for kernel builds from now on. The kernel build system is one of the best for supporting this and there is no good reason not to take advantage of it. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-20kernel: Clean ${S} before unpackRichard Purdie
Currently unpack just forces sources over the current files. This change ensures ${S} is cleaned out before sources are unpacked. This resolves issues seen when upgrading to the new kernel class changes. Ultimately, this should probably move to base.bbclass but one step at a time, this solves an immediate problem blocking the other patches from merging. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-20kernel: fix out of tree module buildsBruce Ashfield
With the kernel build optimizations, we no longer copy the source from the built kernel into the staging dir, since the kernel is unpacked and built directly from the staging dir. This means that a few build artifacts need to be restored to allow out of tree modules to once again build. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-20kernel: Rearrange for 1.8Richard Purdie
In 1.8 we want to streamline the kernel build process. Basically we currently have multiple copies of the kernel source floating around and the copying/compression/decompression is painful. Lets assume we have a kernel source per machine since in most cases this is true (and we have a sysroot per machine anyway). Basically, instead of extracting a source into WORKDIR, then copying to a sysroot, we now set S to point straight at STAGING_DIR_KERNEL. Anything using kernel source can then just point at it and use: do_configure[depends] += "virtual/kernel:do_patch" to depend on the kernel source being present. Note this is different behaviour to DEPENDS += "virtual/kernel" which equates to do_configure[depends] += "virtual/kernel:do_populate_sysroot". Once we do this, we no longer need the copy operation in do_populate_sysroot, in fact there is nothing to do there (yay). The remaining part of the challenge is to kill off the horrible do_install. This patch splits it off to a different class, the idea here is to have a separate recipe which depends on the virtual/kernel:do_patch and just installs and packages the source needed to build modules on target into a specific package. Right now this code is proof of concept. It builds kernels and kernel modules. perf blows up in do_package with issues on finding the kernel version which can probably be fixed by adding back the right bit of do_install, and adding a dependency of do_package[depends] += "virtual/kernel:do_install" to perf. The whole thing needs a good write up, the corner cases testing and probably a good dose of cleanup to the remaining code. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-19kernel.bbclass: Remove bashismKhem Raj
Fixes build on systems using dash for default shell e.g. errors like run.do_strip.25842: [[: not found | readelf: Error: Unable to read in 0x37 bytes of section headers | readelf: Error: Not an ELF file - it has the wrong magic bytes at the start Change-Id: I29cac15be44a02d75a3d6889b6ae9b2e19bf46af Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-10-24kernel.bbclass: Create modules directory even if there is no modules installedHe Zhe
During kernel_do_install it needs to make symbol link at ${D}/lib/modules/${KERNEL_VERSION}/build, but there will not be ${D}/lib/modules/${KERNEL_VERSION} if there is no modules installed for current image, which will result in a build failure. Add "mkdir -p ${D}/lib/modules/${KERNEL_VERSION}" here to avoid this failure and the need of similar changes in other scripts that also expect it to exist. Signed-off-by: He Zhe <zhe.he@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-10-06kernel.bbclass: enable a link for external module buildingNitin A Kamble
Even though the kernel-dev package provides the required support for building external kernel modules on the target, some commonly used scripts and utilities fail as they are not finding the kernel module build support files at the desired location. Create the /lib/modules/<kernel-version>/build link on target pointing to the sources provided by the kernel-dev package, to fix the issue. Fixes Bug: [YOCTO #2968] Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-04kernel: Added bc-native as DEPENDSAlejandro Hernandez
The makefile checks for bc during for compilation [YOCTO #6781] Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-22kernel.bbclass: use one package split for all firmware filename extensionsCarlos Rafael Giani
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
2014-09-10kernel.bbclass: handle .dsp firmwareCarlos Rafael Giani
A few firmware files use this filename extension, like korg/k1212.dsp . Create respective packages. Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-08-23sanity.bbclass/kernel.bbclass: minor fixesRobert Yang
Fixed: - Remove an unused line - Remove unneeded code after d.getVar(), we don't need the "or ''" after d.getVar() unless we need a string. - typo: PREMIRROS -> PREMIRRORS. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-23kernel: Prevent from installing so files into source dirYang Shi
vdso build could generate so files, avoid installing such so files into kernel source dir, otherwise the below package QA error might be hit: ERROR: QA Issue: File '/usr/src/kernel/arch/x86/vdso/vdso64.so' from linux-yocto was already stripped, this will prevent future debugging! [already-stripped] Signed-off-by: Yang Shi <yang.shi@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25kernel: don't copy .so.dbg files into kernel source installBruce Ashfield
In 3.16+ x86-64 kernel builds produce a vdso64.so.dbg file. If this file is copied into the kernel source install multiple QA failures are triggered. Specifically, this file triggers a debug package split that results in files installed but not shipped, and invalid .debug file errors. By ensuring that .so files are not copied, we avoid this incorrect split with no impact on future build phases. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
2014-07-10kernel.bbclass: update KERNEL_IMAGE_MAXSIZERobert Yang
* Make KERNEL_IMAGE_MAXSIZE and IMAGE_ROOTFS_SIZE have the same algorithm: - Use Kbytes as the unit since we use this in other codes. - Use "du" rather than "ls" to figure out the size since we use this in image.py. [YOCTO #2610] Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2014-06-29classes/kernel: Use full path for symlink in update-alternatives.Drew Moseley
Use a fully qualified path for the <path> parameter in calls to update-alternatives. The chkconfig-alternatives version requires a full path and without it, the symlink is not properly created. Signed-off-by: Drew Moseley <drew_moseley@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-25kernel: don't populate source symbolic linkMing Liu
/usr/src/kernel/source deployed by kernel-dev package is symbolically linking to a build-time kernel source folder, which make no sense when cross-compiling. Fixed by not populating it at install stage. Signed-off-by: Ming Liu <ming.liu@windriver.com> Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-21classes/kernel: move module postinst commands to kernel-basePaul Eggleton
Since kernel-base is the package that contains the files that depmod needs to run, we should be running depmod from the kernel-base postinstall rather than kernel-image. Fixes [YOCTO #5392]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-02-13kernel.bbclass, base.bbclass: Fix support for old kernel configurationOtavio Salvador
This solves a regression introduced by OE-Core:9b75f6a (kernel: use oldnoconfig before yes '' | make oldconfig). The original oe_runmake explicitly calls 'die' command in case of failure so the fallback code never runs. The fallback code needs to handle the oe_runmake return code to call the backward compatible callback so we introduced a new command called oe_runmake_call which is used by oe_runmake. This does not change the functional behaviour of oe_runmake so it avoids any change except for the code which does need to handle the oe_runmake exit code. Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-02-11kernel: use oldnoconfig before yes '' | make oldconfigAlexandre Belloni
When using a defconfig, using yes '' | make oldconfig may not result in the correct configuration being set. For example: $ ARCH=mips make qi_lb60_defconfig # # configuration written to .config # $ grep USB_ETH .config CONFIG_USB_ETH=y # CONFIG_USB_ETH_RNDIS is not set # CONFIG_USB_ETH_EEM is not set $ cp arch/mips/configs/qi_lb60_defconfig .config $ yes '' | make ARCH=mips oldconfig [...] $ grep USB_ETH .config CONFIG_USB_ETH=m # CONFIG_USB_ETH_RNDIS is not set # CONFIG_USB_ETH_EEM is not set Using make olddefconfig solves that but we'll use the oldnoconfig alias for backward compatibility with older kernels. $ cp arch/mips/configs/qi_lb60_defconfig .config $ make ARCH=mips oldnoconfig scripts/kconfig/conf --olddefconfig Kconfig # # configuration written to .config # $ grep USB_ETH .config CONFIG_USB_ETH=y # CONFIG_USB_ETH_RNDIS is not set # CONFIG_USB_ETH_EEM is not set Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-02-11kernel: stop using -exec rm for deleting filesBruce Ashfield
Removing files from the source tree via find, exec and rm is not the most efficient operation, due to (among other things) the many forked processes. If we use -delete, it saves a significant amount of time. But -delete does not work with -prune (since it forces -depth). To maintain the lib, tools and scripts source files, we can hide them temporarily, skip their hidden directories and then finally restore them. Time for install before this change: real 2m48.563s user 0m35.220s sys 0m33.036s Time for install after this change: real 1m21.301s user 0m33.160s sys 0m28.388s We could further speed this up by using inline perl to delete the files, but that complexity is avoided for now. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-02-02kernel.bbclass: Fix empty modules directory QA issueNathan Rossi
If a kernel is built without any external modules (aka no CONFIG_*=m), then during a modules_install of the kernel an empty directory is created at /lib/modules/${KERNEL_VERIONS}/kernel. This is behaviour of the kernel infrastructure, the directory would normally be populated with the modules that were built. However because of the expectations of kernel-modules-split, no packages are created when there are no modules and an empty directory lingers. This raises QA issues as warning or errors (depending on the distro). The following patch changes the kernel_do_install task to check if the directory is empty and if so removes it. Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2014-01-14kernel.bbclass: add support for LZ4 initramfs filesKoen Kooi
Signed-off-by: Koen Kooi <koen.kooi@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-12-12classes/module_strip: removePaul Eggleton
This class has been empty since 2010, so we shouldn't need it anymore. A check of common layers suggests there shouldn't be any references to it outside of OE-Core. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-27Revert "kernel: restore scripts in the sysroot"Richard Purdie
This reverts commit 6a6735cb98d529c8c5376aedb5c951339f54fe96. The module class already ensures the scripts are rebuilt correctly. Running this at sstate installation time is problematic since it can require the cross compiler. Adding such a dependency would cause issues of its own. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-22kernel.bbclass: Stop bundle_initramfs thwarting sstate cache and fix raceMike Crowe
The new do_bundle_initramfs task introduced in 609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a defeats using the sstate cache. The kernel is resurrected from the sstate cache but ends up being built again since do_bundle_initramfs depends on do_compile. The task is no longer nostamp to avoid causing unnecessary rebuilds. The sstate checksum stamps should know when to rebuild. The task now runs before do_deploy and part of the work has been moved to do_deploy where it now writes to ${DEPLOYDIR} rather than ${DEPLOY_DIR_IMAGE} so that the files end up in sstate. The task can also race against do_install since both call into the kernel build system. This is fixed by making do_bundle_initramfs run after do_install (which therefore also fixes the problem that 3baa63b4d588c3262254528b406ede265dd117bf was addressing.) Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-22Revert "kernel.bbclass: move bundle_initramfs after kernel_link_vmlinux"Mike Crowe
This reverts commit 3baa63b4d588c3262254528b406ede265dd117bf. It broke builds that aren't using kernel-yocto. Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-20kernel.bbclass: move bundle_initramfs after kernel_link_vmlinuxMing Liu
${KERNEL_OUTPUT} is being renamed/restored in bundle_initramfs task, so we must ensure bundle_initramfs run after kernel_link_vmlinux where the link of vmlinux is created as the bootable image. Signed-off-by: Ming Liu <ming.liu@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-11-20kernel.bbclass: Use lzma not lzmash for decompressingPhil Blundell
If kernel_do_compile() encounters a .lzma image for the initramfs, it attempts to decompress it using the little-known "lzmash" utility. This may not be present, which will cause the build to fail. Fortunately, it appears that the more mainstream "lzma" tool is compatible so we can use that one instead. Signed-off-by: Phil Blundell <philb@gnu.org> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-11-16kernel.bbclass: fix hardlink testBruce Ashfield
The commit [kernel.bbclass: test for hardlinks before installing] doesn't work on all build machines without a space between the ! and the test for hardlink equivalance. The build continues, while the test fails and no copy is made into the sysroot. Eventually tasks like build_hdimg will fail with the missing kernel with the root cause being less than obvious. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-15kernel.bbclass: test for hardlinks before installingBruce Ashfield
commit df564c4 [kernel: Use hardlinks for do_populate_sysroot for speed] does indeed speed up the build, but it also means that the KERNEL_OUPUT and KERNEL_IMAGETYPE may be hardlinks. If they are hardlinks, install complains that they are actually the same file and stops the build. We can easily test and avoid the copy if the file is already in place. [YOCTO #5527] Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-12kernel: Use hardlinks for do_populate_sysroot for speedRichard Purdie
The kernel tree is large and doesn't need to be copied. Override the default sysroot handling function to use a hardlink copying function in python. This commit also drops the copying of the /lib directory which just contains the kernel modules. We never use those in the sysroot so there is little point in carrying those around. For linux-yocto this takes the do_populate_sysroot time 24s -> 14s. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-12kernel: Use hardlinks during do_install for speedRichard Purdie
Whilst the comment says we can't do this, its incorrect, install operates on WORKDIR and its hard for different parts of WORKDIR to be on different filesystems. Hardlinking instead of copying is therefore a nice performance gain. Also, completely skip the Documentation directory (adding a dummy Makefile to keep make happy) and tweak the other cp commands to link since if we don't we'd get "this is the same file" type errors from cp for some kernel versions. For do_install on linux-yocto, this takes it from 227s -> 84s. (From OE-Core rev: 0727e510f8533216518563b1533e804a1dc44402) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-11-04kernel.bbclass: Delay rm_work to run after do_bundle_initramfsXufeng Zhang
Since kernel will build twice when we are trying to bundle kernel and initramfs together after commit 609d5a9ab("kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling"), thus, the second building for kernel would fail if rm_work is done previously. To fix this problem, we need to make do_bundle_initramfs task run before do_rm_work task. [YOCTO #5416] Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2013-10-14kernel: restore scripts in the sysrootBruce Ashfield
When building against the sysroot, out of tree modules can require modpost and other utilities normally found in the kernel's scripts directory. For the kernel source in the staging dir, these scripts have been removed to avoid mixing archiectures when packaging kernel-dev (among other things). Rather than further complicate the kernel's install rule, or its packaging, we can restore the scripts by building them in the kernel staging directory after the sstate is installed, making them available to packages that need them. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>