Having no opt-out method and adding the task to linux-yocto.inc was
causing issues. For example, linux-yocto-dev would often fail because
it uses AUTOREV with no way to dynamically change the PV.
Add a variable to turn off the sanity check, allowing an easy opt out,
and set the opt-out variable in linux-yocto-dev, fixing the issue with
AUTOREV.
(From OE-Core rev: 1b6a3c17874ead7ee0957e67329aa3bd019fa129)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It isn't clear that the README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
file in the deploy directory warrants the complexity it brings elsewhere.
Let's just remove it entirely.
In particular, if two do_image_complete tasks run in parallel they risk
both trying to put their image into ${DEPLOY_DIR_IMAGE} at the same time.
Both will contain a README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
file. In theory this should be safe because "cp -alf" will just cause one
to overwrite the other. Unfortunately, coreutils cp also has a race[1]
which means that if one copy creates the file at just the wrong point the
other will fail with:
cp: cannot create hard link ‘..../tmp-glibc/deploy/images/pantera/README_-_DO_NOT_DELETE_FILES_IN_THIS_D.txt’ to
+‘..../tmp-glibc/work/rage_against-oe-linux-gnueabi/my-own-image/1.0-r0/deploy-my-own-image-complete/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt’: File exists
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25680
(From OE-Core rev: 71e9e88847d7000781642ea6187ebd8f40dfdcfe)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
run.do_deploy.27809: line 155: depmodwrapper: command not found
(From OE-Core rev: 96b7eceefb3e99848d1c16d7c5da123056dcdc24)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The changes committed with 6e58f54be103814b6b8a85b236510633c49e6832 did only
consider the vmlinuz ELF kernel but some devices do reqire a raw vmlinuz.bin
(as for example gcw0 in meta-handheld booted by ubiboot).
Expand the above mentioned patch to consider this case.
(From OE-Core rev: 413a5faf99280f4e083358e4134aebbcfa47bb4c)
Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The depmodwrapper dependency is not actually used by the class but
anyone using pkg_postinst_kernel-base() will need it.
(From OE-Core rev: e3f5290d8deba9b7cead73b52ac45a37228fece9)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 0ccb2efe9837e2915c093341a662dffc1df00866.
The OVS fails to function and the kernel modules cannot be found by
any of the kernel tools such as depmod because they are installed
into the wrong directory in multilib 64bit/32bit bulids.
(From OE-Core rev: 85cec1e3df68e932c7b210956ef5f17b85f3616f)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When installing a kernel package, the symlinks created by
update-alternatives should point to a path relative to KERNEL_IMAGEDEST
and not an absolute path to '/boot'.
Failing to do so causes problems when resolving the symlink inside some
bootloaders which mount the boot partition elsewhere.
(From OE-Core rev: c7bc46b9bc29dd0953ab8d63b50fa105bb66892e)
Signed-off-by: David Vincent <freesilicon@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
(From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These files cause warnings because they don't get packaged, now that they
don't land in kernel-vmlinux anymore.
(From OE-Core rev: a49569e3a7534779bbe3f01a0647fd076c95798d)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With multiple kernel images enabled starting with 'vmlinux', e.g.
vmlinux.gz and vmlinux.bin, all files landed inside the
kernel-vmlinux package.
On top of that, even initramfs images were included, e.g.
vmlinux.gz-initramfs-*.
(From OE-Core rev: b7f4133b44b740e8ac8e758b0d4a3ee32d326332)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When iterating over kernel image types to set up their packaging
variables, don't use make targets but the real names.
It was surprising if both vmlinux.bin and vmlinux.gz were enabled
and only the latter had its filename extension removed from the
package name.
(From OE-Core rev: aa189f183e10588f7e8d642f351bd9b8d69f3ea9)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code failed to copy the initramfs in case it was a plain
cpio archive.
(From OE-Core rev: 7dbdb4ea91aa027866da2bd46c65fe65a25c848f)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The do_deploy runs depmodwrapper which requires
pkgdata/kernel-depmod/kernel-abiversion, which is generated by
PACKAGEFUNCS. So we need let do_deploy depend on do_packagedata.
This can fix the errors which happens sometimes when kernel upgrades:
DEBUG: Executing shell function do_deploy
Error: Kernel version 4.8.8-WR9.0.0.1_standard does not match kernel-abiversion (4.8.8-WR9.0.0.0_standard)
And we only see this error when kernel upgrades and rebuild, but doesn't
see it in a normal build, this is becuase depmodwrapper doesn't exit
error when kernel-depmod/kernel-abiversion doesn't exit, it just prints
an error which should go into log.do_deploy:
if [ ! -r /path/to/sysroots/qemux86-64/pkgdata/kernel-depmod/kernel-abiversion ]; then
echo "Unable to read: /path/to/sysroots/qemux86-64/pkgdata/kernel-depmod/kernel-abiversion" >&2
else
[foo]
fi
We can see that there is no "exit 1", I guess it was designed to let it
can run without kernel-abiversion
(From OE-Core rev: 64148a30397b8c92414262c0d414d103d2b97ddd)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel being built should match what the recipe claims it is
building. This function ensures that happens by comparing the version
information in the kernel's Makefile to the PV the recipe is using.
v2 changes:
* Match against PV instead of LINUX_VERSION
* Match against EXTRAVERSION as well (e.g., -rc4)
* Cleaned up version string building
Fixes [YOCTO #6767].
(From OE-Core rev: ec467cfaea5c8cf22c61daa8845c2e4e96449512)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Default values for KERNEL_IMAGE_BASE_NAME and MODULE_IMAGE_BASE_NAME
are already assigned using ?= and anyone wanting to over-ride one is
likely to want to over-ride them all. Make the three consistent with
each other.
(From OE-Core rev: e30c6c93bb70d17244c90c2be12229148f8f6314)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 79fe476be233015c1c90e9c3fb4572267b5551d1)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The KConfig infrastructure needs to build HOST binaries in order to
provide its infratstructure. Yocto needs to force the HOSTCC and HOSTCPP
variables to BUILD_CC and BUILD_CPP to make sure that the proper compiler
is used when compiling host binaries
(From OE-Core rev: c710401a2af6488b38565e8ef32b48ed1cd0aa69)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The absence of signing_key.* in $kerneldir made signing of
out-of-tree kernel modules fail (silently). Add copying of these
files during the shared_workdir task.
(From OE-Core rev: 7aadc91b5ef86a89a827d59bd19e7b8272a5dd66)
Signed-off-by: Mattias Waldo <mattias.waldo@saabgroup.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In a similar manner to diffconfig, tell the bitbake user where the
defconfig will be saved to.
(From OE-Core rev: 8e4cefb093e0df9660e2a6215cfe21c6c779c23f)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default of EXTRA_OEMAKE is already empty since commit:
OE-Core rev: aeb653861a0ec39ea7a014c0622980edcbf653fa
bitbake.conf: Remove unhelpful default value for EXTRA_OEMAKE
(From OE-Core rev: de720a8b10de17e613a8fb20d8df2af0b84507d7)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the initramfs image is type lzo, then a native lzop is needed.
(From OE-Core rev: ee0640cb0c32b959ffaaac6752d582ed1d76e313)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake rev 67a7b8b02 "build: don't use $B as the default cwd for
functions" (included in current bitbake master) breaks the assumption
that do_bundle_initramfs runs inside the build directory.
This causes kernel_do_compile() as called from within
do_bundle_initramfs() to fail, as the former is not being executed
from the correct directory anymore. (Note that kernel_do_compile()
as called from bitbake directly doesn't suffer from that problem,
as it inherits the workdir from base_do_compile() in that case.)
Set workdir explicitly.
(From OE-Core rev: 4455da22a151c2ac006af63cbd39779b21b12580)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If linkpath points to the a file in KERNEL_OUTPUT_DIR, rather than
outside, then symlink creation for the bundled initramfs image files
fails.
This is because in that case $linkpath.initramfs and $realpath.initramfs
are in the same directory, KERNEL_OUTPUT_DIR, and hence are the same.
Since we just created $realpath.initramfs, creating a symlink with the
same name will fail.
Given that $linkpath is not necessarily the same as the kernel image type,
just removing this symlink creation is not the right thing to do, as
in that case kernel_do_deploy() wouldn't find the bundled file.
What we really want is a symlink from the name of the initramfs-bundled
kernel image type to the real initramfs-bundled kernel image, as that is
what is actually used later in do_deploy().
This brings the code path for when $KERNEL_OUTPUT_DIR/$type is a symlink
in line with when it is not.
(From OE-Core rev: 7585ebbbe4e95870ab7475737ed5b94255351c72)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If multiple kernel image types have been specified, only the very first
one would receive a symlink in DEPLOYDIR.
The reason is that we're looping over the list of image types and check
if a bundled initramfs images exists using a relative path. As part of
the loop we're changing the current directory, hence all additional
iterations fail to see the files we're looking for, and hence no symlinks
are being created.
Fix by not changing the directory and adjusting the ln invocation instead.
(From OE-Core rev: 2a6ac8ca71b669b8653eb19417faf58575385a21)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_compile_kernelmodules was assuming that the current directory was ${B} but
didn't make that explicit, so use an absolute path to ensure this always works.
(From OE-Core rev: a26ec548aabda74acfdd1e2893b98b47bc513b15)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rename do_kernel_link_vmlinux to do_kernel_link_images and make a
symbol link to vmlinuz(if exists) for reference in arch/$arch/boot
directory.
Signen-off-by: He Zhe <zhe.he@windriver.com>
(From OE-Core rev: 6e58f54be103814b6b8a85b236510633c49e6832)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add KERNEL_IMAGETYPES to support building packaging and installing
multi types of kernel images, such as zImage uImage, at one time.
KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE work as before.
(From OE-Core rev: 849b67b2e4820564b5e5c9bd4bb293c44351c5f3)
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the kernel being built is older than OLDEST_KERNEL and we're building
with glibc, then the C library we're building is probably not going to
be compatible with the kernel and we should warn the user. (This is
easier to do here rather than when building glibc, because we don't
necessarily have the information we need to determine the kernel version
there, whereas we do here.)
Fixes [YOCTO #8653].
(From OE-Core rev: 2e66f57febe85a63ce2ab98eaf6318d47eb60939)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KERNEL_VERISON -> KERNEL_VERSION (in a comment)
(From OE-Core rev: 3f1d813e7183750b5189ae1ee99fd2f0bdeacac7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"/usr/src/kernel" is being hard-coded in multiple recipes so far, move its
definition to bitbake.conf.
(From OE-Core rev: eb9f900527e02ca08a1de14b4ac773f513bb1ee4)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes kernels which package sb16 firmware e.g.
directories were installed but not shipped in any package:
/lib/firmware/sb16
/lib/firmware/sb16/ima_adpcm_playback.csp
/lib/firmware/sb16/ima_adpcm_init.csp
/lib/firmware/sb16/mulaw_main.csp
/lib/firmware/sb16/ima_adpcm_capture.csp
/lib/firmware/sb16/alaw_main.csp
(From OE-Core rev: 826bc56e77bd9a53f6bc19548549f6d92de09911)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 8d310b24927d0f348fb431895f0583733db2aad0.
That commit completely breaks KBUILD_DEFCONFIG because it relies on
$ARCH to match between the target OE arch and the kernel subdirectory
containing the defconfigs. In the kernel all defconfigs for everything
x86-based (including x86_64) is stored in dir arch/x86/configs/
kernel-yocto.bbclass correctly searches for all the defconfigs inside
${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}
Commit 8d310b249 makes it search in wrong places and _only_ if you
define TARGET_ARCH = "athlon" will it search x86 which is nonsensical.
The commit further adds an if clause to hack the mungled kernel arches
back to their original values (ugh) in do_shared_workdir which is run
after do compile, but of course the build breaks before that in
do_kernel_metadata because of the KBUILD_DEFCONFIG mentioned above (so
that hack is useless).
Please fix that corner case bug in another way which does not completely
screw up the kernel arch mapping & defconfig logic. If 64bit configs are
generated in the kernel for 32bit machines because the host is asked,
then it it a bug in the kernel, it is of no use to hack around it in OE.
(From OE-Core rev: bc02a478a5d4a5de7b3943ed809d5c22711f5b1f)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we don't do this, the deploy sstate object contains an every
increasing number of modules tarballs and kernel images, one per
execution of "-c deploy -f".
Cleaning the directory before we start makes things much tidier.
(From OE-Core rev: 3ac195bbd4ced24e6a132cfbe5e175b95fc4664b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move do_kernel_link_vmlinux() from kernel-yocto.bbclass into
kernel.bbclass so that it's available to any kernel recipe.
Note that the task is not enabled by default in kernel-yocto.bbclass,
so don't enable by default in kernel.bbclass either. To enable, see
the example in linux-yocto.inc, ie:
addtask kernel_link_vmlinux after do_compile before do_install
(From OE-Core rev: a29371848deda618a42f9a30f9856a44c2342fe6)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For a bare-bone kernel recipe which specifies 32 bit x86 target,
a 64 bit .config will be generated from do_configure task when
building 32-bit qemux86, once all of these conditions are true:
* arch of host is x86_64
* kernel source tree used in build has commit ffee0de41 which
actually chooses i386 or x86_64 defconfig by asking host when
ARCH is "x86" (arch/x86/Makefile)
* bare-bone kernel recipe inherits directly from kernel without
other special treatments.
Build will fail because of the mismatched kernel architecture.
The patch sets ARCH i386 or x86_64 explicitly to configure
task to avoid this host contamination. Kernel artifact is also
changed so that it can map i386 and x64 back to arch/x86 when
needed.
(From OE-Core rev: 8d310b24927d0f348fb431895f0583733db2aad0)
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After the separation of do_rootfs, some rootfs references need changing
to image_complete.
(From OE-Core rev: 59a5f596ca29b1eb8283706e3c60fbb39f9c2c23)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KERNEL_CONFIG_COMMAND will be expanded by bitbake, so can be
used directly in kernel_do_configure()
(From OE-Core rev: f8a35d8e312df908c73724465035921856d30781)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes https://bugzilla.yoctoproject.org/show_bug.cgi?id=8127 which causes
[ 1225.089323] 8189es: Unknown symbol cfg80211_scan_done (err -22)
[ 1225.095916] 8189es: no symbol version for cfg80211_remain_on_channel_expired
when loading external compiled 8189es module.
(From OE-Core rev: afcea61e8eb39234d336c706fdfd4680dea7c060)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross reported the following waring when building edgerouter BSP:
WARNING: Section not found: .comment
The reason is that the testing of the existing sections in do_strip()
returned the wrong value. Please see the following code in do_strip():
for str in ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}; do {
if [ "$headers" != *"$str"* ]; then
bbwarn "Section not found: $str";
fi
"$CROSS_COMPILE"strip -s -R $str ${KERNEL_OUTPUT}
}; done
The "*" doesn't have special meaning in the if string test, so it will
return true even the $str is a substring of $headers. Fix this issue
by replacing it with "! (echo "$headers" | grep -q "^$str$")".
Reported-by: Ross Burton <ross.burton@intel.com>
(From OE-Core rev: 4965f122ca67c0ff60dc60f7885db1ed9db909b4)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If externalsrc is enabled the 'do_unpack' task is run if the recipe has
some local source files. In the case of kernel recipe this caused the
(externalsrc) source tree to be moved/symlinked. This patch prevents the
behaviour, making sure the source tree is not moved around when
externalsrc is enabled. Instead of moving the source tree,
STAGING_KERNEL_DIR will be a symlink to it.
[YOCTO #6658]
(From OE-Core rev: 8f6c564661a3801012eb2d9a98cdc99c91712367)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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".
(From OE-Core rev: bd8b9bc716774a8f8b4b97ece5c7b2eb58aa2330)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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().
(From OE-Core rev: 5bebaf37429c28134aeb6fd261e282e9a0397771)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <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>
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 <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>
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 <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>
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 <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>
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 <richard.purdie@linuxfoundation.org>
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 <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: b851504dcf5e147c9efb1c7b6a4d22c1a1a87cd7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove bash specific syntax '[[ test ]]' replaced with '[ test ]'.
Fixes [YOCTO #7112]
(From OE-Core rev: f2ff849d5936d3dc5e24301e0620da265df50fea)
Signed-off-by: Vincent Génieux <vincent2014@startigen.fr>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO 6818]
Update do_unpack[cleandirs] to include the STAGING_KERNEL_BUILDDIR, and
add the same set of updated cleandirs for do_clean.
(From OE-Core rev: 0726f8099c1407eea9e53a62be94defbab32265e)
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>
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.
(From OE-Core rev: 6a1ff0e7eacef595738f2fed086986fd622ec32a)
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>
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.
(From OE-Core rev: 78226efe72c8221206594c70fa1d8742d4097af1)
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>
* 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'
(From OE-Core rev: dba30c2395792b553b69ce0b44cc75ff2dbdb317)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 106dab2fd0321e6b4e77b40111e59a3a31d329d4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 7deb1f670c188c24744b7888a2d2f73c2a8ddff7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 4b981e4fd5a4744d0d83053219274296e7785e77)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 3b3f7e785e27990ba21bc7cd97289c826a9a95d1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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
(From OE-Core rev: 6956ffdc6e9879e32360b6ee3a3d286618807485)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: f2f72f8ff623d24fffbb1b0ad40bc08f05ff31dd)
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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]
(From OE-Core rev: aafa4bc896eb944aa4fc406807dd7e02f4b9b7ba)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The makefile checks for bc during for compilation
[YOCTO #6781]
(From OE-Core rev: c067e52cffe002de3b39aa1bced308dd532859c1)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: dd5313228879487ca2b11fc5d38fb821a2a810a5)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A few firmware files use this filename extension, like korg/k1212.dsp .
Create respective packages.
(From OE-Core rev: 4a4877c2e7cdcb8a1d0a54add600c0cd4e92e647)
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 7849e50107a27b0ff2aaac47480ac1a0a79533dc)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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]
(From OE-Core rev: daff14bf44c59542c8b8f1a455dcc59586be7e59)
Signed-off-by: Yang Shi <yang.shi@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: f1f6d153de9dc675b4bf4020799b2365b1b62ec7)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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]
(From OE-Core rev: 7384d2831c713ac5999aca83c312154dc15cec56)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 78ee4d8b1782445caecce8331e68efe83fc32044)
Signed-off-by: Drew Moseley <drew_moseley@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
/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.
(From OE-Core rev: edb85a9589be54a1e9c980aa669a380222a76cf4)
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>
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].
(From OE-Core rev: f7d2cb383281ec8dfa90950ba04d87dd29ffc676)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 51707282fc2c5a74588b2d79b2229513a883924f)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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
(From OE-Core rev: 9b75f6a5786ff7b2e6219d78b38f0032f100c660)
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 01932d6bbc71e86fd903097b5339e91f76846388)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 63d3070b7e1207164891b154a5b9017731e75872)
Signed-off-by: Nathan Rossi <nathan.rossi@xilinx.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 3c4557df95e3c60ef938c53f00bb1d7f765fe0ef)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 6a6735cb98.
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.
(From OE-Core rev: b2c948d56241ff7cdea2e9e68b740f305c72f5ca)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.)
(From OE-Core rev: 55989cb509340bd265d0ce0d8bfe849681be4616)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 3baa63b4d588c3262254528b406ede265dd117bf. It broke
builds that aren't using kernel-yocto.
(From OE-Core rev: 81831db1c32afa3346f3ed9f4325ad280e5bb005)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
${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.
(From OE-Core rev: 3baa63b4d588c3262254528b406ede265dd117bf)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: f7a04cbdee67675ff6a8787709f3a312dc25bfec)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 0704648e9dfd2897f6f54773a0e7d2762117970c)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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]
(From OE-Core rev: 6a3b3e501c66733216ac43d3f020cfdb512dd640)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 13259459e200a237ca486cbe1123a0b0a4d1eebf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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)
(From OE-Core rev: f6e98af6b9f6729bb61f17e3b4203c3c79829205)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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]
(From OE-Core rev: 8308e22a44a2dea7d1bbfb429b9df9c63714a649)
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>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 5bcd65807aa634060f98928db6011856934dabe4)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When user runs devshell in kernel recipe and compiles kernel,
this will fail by unrecognized option of LD.
----
$ make
...
arm-poky-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
arm-poky-linux-gnueabi-ld: use the --help option for usage information
----
This set to empty LDFLAGS when user runs the devshell, and solve this problem.
(From OE-Core rev: e36ac3ab3a7fe02c7eeb3998ff33c001ab795841)
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Activating the INITRAMFS_TASK can cause circular dependencies, but
that is up to the end user to resolve in recipes. The INITRAMFS_TASK
should also trigger immediate linking of the cpio task in the first
compile pass. This was a subtle regression introduced by: 609d5a9ab
(kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency
and bundling).
This patch restores the previous behavior and only affects the
INITRAMFS_TASK which is not set by any of the default build profiles
in oe-core.
Reviewed-by: Andrea Adami <andrea.adami@gmail.com>
(From OE-Core rev: 36faac868e086e9c23537b107cdd973d7fd980bd)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch aims to fix the following two cases for the INITRAMFS generation.
1) Allow an image recipe to specify a paired INITRAMFS recipe such
as core-image-minimal-initramfs. This allows building a base
image which always generates the needed initramfs image in one step
2) Allow building a single binary which contains a kernel and
the initramfs.
A key requirement of the initramfs is to be able to add kernel
modules. The current implementation of the INITRAMFS_IMAGE variable
has a circular dependency when using kernel modules in the initramfs
image.bb file that is caused by kernel.bbclass trying to build the
initramfs before the kernel's do_install rule.
The solution for this problem is to have the kernel's
do_bundle_initramfs_image task depend on the do_rootfs from the
INITRAMFS_IMAGE and not some intermediate point. The image.bbclass
will also sets up dependencies to make the initramfs creation task run
last.
The code to bundle the kernel and initramfs together has been added.
At a high level, all it is doing is invoking a second compilation of
the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
to the generated initramfs from the image recipe.
[YOCTO #4072]
(From OE-Core rev: 609d5a9ab9e58bb1c2bcc2145399fbc8b701b85a)
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #4991]
The kernel image is installed as part of the kernel-image package, but
the symlink creation/removal via alternatives is being done in
pkg_post(inst|rm)_kernel-base.
Move the postinst alternatives logic into the kernel-image functions.
(From OE-Core rev: 35f538b117e3387354d2dab1f22c3de28ab1322b)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The modules-${MACHINE}.tgz should link to ${MODULE_TARBALL_BASE_NAME}.
But now it links to an invalid file ${MODULE_TARBALL_BASE_NAME}.bin.
Remove the extra .bin suffix.
[YOCTO #4595]
(From OE-Core rev: ef9fad8fff1c413bc0eab15625f051d4e2d0a201)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* DEPLOYDIR is used as target for every other file deployed by do_deploy,
this was just unnecessary switching CWD to create relative symlink and I
have no idea why rm -f was used together with ln -sf.
(From OE-Core rev: 8375782a295c6294ea4ab889c309bebf873f3489)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Compiling the Linux kernel requires binutils; kernel.bbclass uses
INHIBIT_DEFAULT_DEPS so it had better depend on binutils explicitly.
(The lack of this dependency isn't always a problem because binutils
is required to build gcc-cross but if gcc-cross is reconstructed from
the sstate cache then gcc-cross's dependency on binutils-cross is
ignored due to being in the safe dependency list in
setscene_depvalid.)
(From OE-Core rev: 37beb7bdab78de5253a894f35afafa34c13a00f5)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Acked-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
