linux/poky.git/meta/classes/kernel.bbclass, branch 1.9_M2

kernel: fix path assumptions in tasks

2015-07-16T14:09:21+00:00

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. (From OE-Core rev: d596286bc4cf19774447b136a27acf3c61aad2ff) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel: Pull uImage generation into separate class

2015-05-26T09:57:51+00:00

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. (From OE-Core rev: 086536ac84fcc9350802c09166f600becd52a1f8) Signed-off-by: Marek Vasut Cc: Richard Purdie Cc: Koen Kooi Cc: Paul Eggleton Cc: Ross Burton Cc: Bruce Ashfield Signed-off-by: Richard Purdie

kernel: Pull out the linux.bin generation

2015-05-26T09:57:51+00:00

Pull the generation of linux.bin image, which is then packed into uImage, into a separate function. No functional change. (From OE-Core rev: 2879e5423aff8df5731712b853d71a73047a2fd7) Signed-off-by: Marek Vasut Cc: Richard Purdie Cc: Koen Kooi Cc: Paul Eggleton Cc: Ross Burton Cc: Bruce Ashfield Signed-off-by: Richard Purdie

kernel: Rework do_uboot_mkimage

2015-05-26T09:57:51+00:00

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. (From OE-Core rev: 63e3816b161f8659850d6123a53bdf128780e13d) Signed-off-by: Marek Vasut Cc: Richard Purdie Cc: Koen Kooi Cc: Paul Eggleton Cc: Ross Burton Cc: Bruce Ashfield Signed-off-by: Richard Purdie

kernel: Clean up KERNEL_IMAGETYPE_FOR_MAKE

2015-05-26T09:57:51+00:00

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. (From OE-Core rev: a1690131691507bbf5853540229b3ad775b836bf) Signed-off-by: Marek Vasut Cc: Richard Purdie Cc: Koen Kooi Cc: Paul Eggleton Cc: Ross Burton Cc: Bruce Ashfield Signed-off-by: Richard Purdie

kernel/rm_work: Improve interaction

2015-05-15T16:44:59+00:00

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. (From OE-Core rev: 55b4f7fd217f0c65d457c731150340c18fb3fa19) Signed-off-by: Richard Purdie

kernel.bbclass: Fix race condition

2015-05-07T12:40:36+00:00

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] (From OE-Core rev: b4ec689f71fe9504559c1921c893f5e096d6b744) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie

kernel: Fix depmod for multilib

2015-01-29T15:36:52+00:00

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. (From OE-Core rev: 6cccae3ca54c1177a1d91d23c3e151d74e735ee9) Signed-off-by: Richard Purdie

kernel/image/depmodwrapper: Fixups for depmod

2015-01-23T14:32:02+00:00

With the rpm package backend enabled, running: bitbake bitbake virtual/kernel -c clean bitbake -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. (From OE-Core rev: b851504dcf5e147c9efb1c7b6a4d22c1a1a87cd7) Signed-off-by: Richard Purdie

fix '[[: not found' error message using dash

2015-01-23T11:36:29+00:00

Remove bash specific syntax '[[ test ]]' replaced with '[ test ]'. Fixes [YOCTO #7112] (From OE-Core rev: f2ff849d5936d3dc5e24301e0620da265df50fea) Signed-off-by: Vincent Génieux Signed-off-by: Ross Burton Signed-off-by: Richard Purdie