If the initramfs image is type lzo, then a native lzop is needed.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

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>

Signed-off-by: Ross Burton <ross.burton@intel.com>

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.

Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

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].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

KERNEL_VERISON -> KERNEL_VERSION (in a comment)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

"/usr/src/kernel" is being hard-coded in multiple recipes so far, move its
definition to bitbake.conf.

Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>