Age | Commit message (Collapse) | Author |
|
support symlinks"
This reverts commit 01831f9e76fd8b111a7ce70defa745e2c0ee151e.
|
|
symlinks
Some filesystems don't support symlink, then you will get failure when
you install or update the kernel rpm package. Now we use a copy of
image for these filesystems instead of symlink.
Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Suggested-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
the files of linux-modules should be same permissions with rootfs.tar.bz2,
because it is a part of rootfs when used to install.
Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If CONFIG_IKHEADERS is set to =m, then reproducibility issues creep
into the modules build, since the variables we are setting for the
main kernel build are not present.
Since the source code must be available for a possibly git query
on the timestamp, there didn't seem to be an easy way to move the
environment variable setting to a common routine. As such, we
duplicate the block of code that exports the required variables for
reproducible builds. There is a maintenance risk to this, but any
issues should be easy enough to catch.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If reproducible binaries are requested, generate the kernel modules
tarball in a reproducible way. Namely, sort the tarball contents, clamp
the mtime to the source date epoch, compress the archive with a
consistent compression level (9), and don't include the name and
timestamp in the compressed file.
[YOCTO #12719]
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The source directory is not always a git repository, so when querying
git for data to set SOURCE_DATE_EPOCH, specify ${S}/.git as the git
directory to prevent retrieving incorrect data from any parent directory.
Fixes the following errors with the prior logic when building a kernel
that is not obtained from a git repository:
1. With TMPDIR set to a directory outside any git repository on a
mounted filesystem, reproducible builds fail in do_compile with this git
error:
fatal: not a git repository (or any parent up to mount point <abspath>)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
aborting before the error handling logic.
2. With TMPDIR located within a subdirectory of a git repository, the
SOURCE_DATE_EPOCH timestamp would be that of said repository rather than
that of the kernel.
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
legitimize_package_name wants the actual value of KERNEL_REVISION, so
use d.getVar() to fetch it as is done elsewhere in the file. Failing to
do so can result it weird errors at parsing time.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
is enabled
* with 5.4 kernel the do_configure fails when gold is enabled (with ld-is-gold in DISTRO_FEATURES)
* bfd is already being set in KERNEL_LD:
kernel-arch.bbclass:KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
but KERNEL_LD is currently respected only by do_compile and do_compile_kernel modules
and new kernel which contains a check for gold in Kbuild:
https://lore.kernel.org/lkml/alpine.DEB.2.21.1907161434260.1767@nanos.tec.linutronix.de/
more details:
https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com
will fail during the configuration even when gold wouldn't be used to
build it in the end, add LD setting to KERNEL_CONFIG_COMMAND to prevent
premature error when configuring
scripts/kconfig/conf --olddefconfig Kconfig
scripts/Kconfig.include:39: gold linker 'x86_64-oe-linux-ld' not supported
make[2]: *** [/OE/build/oe-core/tmp-glibc/work-shared/qemux86-64/kernel-source/scripts/kconfig/Makefile:73: olddefconfig] Error 1
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Some mips 64 bit platforms use vmlinux.64 image name
Make a symbol link to vmlinux.64 in arch/mips/boot/
Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This reverts commit 6676411fccff2d331878e4ca1f9411aafb056a80.
This revert restores the original code and adds a comment. The commit
that was reverted broke a number of wic templates and tools which rely
on the initramfs creation dependency and the case where the
INITRAMFS_IMAGE_BUNDLE is not set.
If an end user does not want the INITRAMFS_IMAGE generated, it should
be set to "".
[ Issue: LIN1019-1791 ]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If one has provided external key/certificate for modules signing, Kbuild
will skip creating signing_key.pem and will write only signing_key.x509
certificate. Thus we have to check for .x509 file existence rather than
.pem one.
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin-solenikov@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The package 'make-mod-scripts' creates files in 'kernel-build-artifacts/include/config'
which are removed by 'cleanall/cleansstate' of 'virtual/kernel'. And this causes the
below error while building out of tree kernel module:
ERROR: Kernel configuration is invalid.
include/generated/autoconf.h or include/config/auto.conf are missing.
Run 'make oldconfig && make prepare' on kernel src to fix it.
Suggested-by: Jun Nie <jun.nie@linaro.org>
Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As of commit 898490c010b [moduleparam: Save information about built-in
modules in separate file] (kernels v5.2-rc1+), modules.builtin.modinfo
is generated as part of the kernel build process.
We package it along with the other module artifacts, so it can be used
by scripts/other build steps.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
do_bundle_initramfs does not have to depend on
${INITRAMFS_IMAGE}:do_image_complete if INITRAMFS_IMAGE_BUNDLE is not
set.
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
<pre>
when externalsrc is enabled and the 'do_unpack' task is deleted,
building kernel module fail
Signed-off-by: Steven Hung (洪于玉) <Steven.Hung@mediatek.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Based on: https://patchwork.openembedded.org/patch/148047/
When x86_64 enables CONFIG_UNWINDER_ORC [ORC (Oops Rewind Capability)
unwinder for unwinding kernel stack traces], objtool is required to
generate the required information.
If we don't copy objtool to the shared workdir, out-of-tree modules
cannot generate object files.
For instance, meta-skeleton/hello-mod fails with:
| make[3]: *** No rule to make target 'tools/objtool/objtool', needed by ...
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.cpio does not exist,
nor any of the compressed variants, nothing is copied to kernel build's
./usr directory.
The code does not fail, but silently proceeds without a bundled initramfs.
Change to fail and tell the user something is wrong.
Also, if an initramfs is found, contrary to the comments, it does not stop
at the first uncompressed/compressed cpio image found. Instead it keeps
processing all so the last is used. Fix this to behave as per the comments.
[YOCTO #12909]
(Patch by Leon Woestenberg)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fix handling of escape characters in regexs and hence fix python
Deprecation warnings which will be problematic in python 3.8.
Note that some show up as:
"""
meta/classes/package.bbclass:1293: DeprecationWarning: invalid escape sequence \.
"""
where the problem isn't on 1293 in package.bbclass but in some _prepend to a
package.bbclass function in a different file like mesa.inc, often from
do_package_split() calls.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When kernel-fitimage and initramfs is enabled using
INITRAMFS_IMAGE_BUNDLE = "1", kernel do_deploy tries to deploy
fitImage.initramfs with following error
| install: cannot stat 'arch/arm64/boot/fitImage.initramfs': No such
file or directory
Skip deploying fitimage.initramfs, since fitimage does not
create fitimage.initramfs
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The KBUILD_BUILD_USER and KBUILD_BUILD_HOST variables were
assigned at the kernel class level, which made it impossible
to override them in the local configuration.
By setting only the default values of those variables in the
kernel class, it is now possible to override them as expected.
Signed-off-by: Federico Sauter <federico.sauter@ableton.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As was warned by commit 312ee68752fa [kconfig: announce removal of
oldnoconfig if used], oldnoconfig has been removed from the 4.20 kernel.
So we switch our default mode to olddefconfig.
commit fb16d8912 [kconfig: replace 'oldnoconfig' with 'olddefconfig',
and keep the old name as an alias] introduced olddefconfig in the 3.10
kernel, we shuffle oldnoconfig to the fallback target.
The fallback mode allows kernels between 3.10 and the currently listed
oldest kernel of 3.2 to continue to configure.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Some distros want to install the kernel in a custom location other
than /boot and have it properly packaged, so it's useful to use a
weaker assignment.
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
During deploy we iterate over KERNEL_IMAGETYPES twice, with no consumer
of our changes in the interim. Collapse these two loops into one.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
When usrmerge is enabled the kernel modules aren't under /lib, but /usr/lib;
ensure we fetch the modules from the correct location so we don't have a
tarball which consists of a single symlink.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
that."
This reverts commit 65cded55fa96b1ba72149a31689c081ac27af7f7.
The fitImage deployed here is the one generated in kernel-fitimage.bbclass,
whereas the one deployed by kernel-fitimage.bbclass is a raw image, so we
need the one deployed here keeping.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
kernel-fitimage.bbclass replaces an occurance of "fitImage" in
KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
architecture (such as zImage). The kernel-fitimage.bbclass packs that
image as sub-image in a flattened image tree image (fitImage) and
deploys this fitImage along with the image tree source file (.its).
kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
also contains "fitImage", which kernel.bbclass will also deploy
redundantly with different naming.
The result is a dual deployment with slightly different naming,
each with a set of symlinks.
The solution chosen is to have fitImage deployment be handled by
kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
types during deployment.
Signed-off-by: Leon Woestenberg <leon@sidebranch.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* to avoid confusion with "type" command in shell
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
from MODULE_TARBALL_* variables
* for consistency with other artifacts variables, include only the version string, not the actual name or extension
* changing .tgz to something else in the MODULE_TARBALL_NAME variable only wouldn't make much sense
because then kernel.bbclass still calls "tar -cvzf" to create it
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
*_BASE_NAME to *_NAME
* for consistency with IMAGE_NAME and IMAGE_LINK_NAME
and to avoid confusion with IMAGE_BASENAME (which is the
actual name of the artifact, e.g. PN while KERNEL_IMAGE_BASE_NAME
was only the version suffix)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* this makes it easier to access these variables from some other bbclass
e.g. sdcard_image-rpi.bbclass in meta-raspberry where we need to know
how some files in deploy are named, but we cannot inherit kernel.bbclass
as it's used in image recipe not kernel recipe
* alternatively we can move these to bitbake.conf like similar image variables are:
meta/conf/bitbake.conf:IMAGE_BASENAME = "${PN}"
meta/conf/bitbake.conf:IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
meta/conf/bitbake.conf:IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* use INITRAMFS_BASE_NAME and INITRAMFS_SYMLINK_NAME variables, like
other kernel artifacts are using
* use "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" instead of
"${PV}-${PR}-${MACHINE}-${DATETIME}" to be consistent with other files
* allow to modify default symlink name with INITRAMFS_SYMLINK_NAME
instead of currently used:
initramfs_symlink_name=${type}-initramfs-${MACHINE}
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* add 2 new variables:
KERNEL_DTB_BASE_NAME
KERNEL_DTB_SYMLINK_NAME
instead of reusing KERNEL_IMAGE_SYMLINK_NAME and than expecting that
default value ${MACHINE} was being used in e.g.:
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"`
* install normal DTB files only once even if there is multiple entries
in KERNEL_IMAGETYPE_FOR_MAKE and don't prefix them with the type of
the kernel image, use the KERNEL_IMAGETYPE_FOR_MAKE as a prefix only
when installing them bundled with kernel or initramfs image.
* deploy the files from ${D}/${KERNEL_IMAGEDEST}/ instead of kernel
build directory, so that we don't need to call
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
again in do_deploy
* create all links in do_deploy task, because default KERNEL_DTB_BASE_NAME
like KERNEL_IMAGE_BASE_NAME contains PKGR and PKGR is different in
do_install and do_deploy, because kernel.bbclass calls
meta/classes/kernel.bbclass:do_install[prefuncs] += "package_get_auto_pr"
meta/classes/kernel.bbclass:do_deploy[prefuncs] += "package_get_auto_pr"
* the filenames are a bit different, but with separate variable it
should be easier for other bbclasses which use these DTB files to
find them correctly, just use either the cannonical name
$dtb_base_name.$dtb_ext or $dtb_base_name-${KERNEL_DTB_SYMLINK_NAME}.$dtb_ext
because PKGR (and other PKG* variables) might be different in your
task and kernel.do_deploy task.
* fix DTB files being deployed with incorrect filenames when
KERNEL_IMAGE_SYMLINK_NAME isn't set to ${MACHINE}, e.g. instead of
the default:
-rw-r--r-- 2 bitbake bitbake 1.4K Nov 20 07:41 deploy/images/raspberrypi3-64/Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo
lrwxrwxrwx 2 bitbake bitbake 64 Nov 20 07:41 deploy/images/raspberrypi3-64/Image-lirc-rpi.dtbo -> Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo
lrwxrwxrwx 2 bitbake bitbake 64 Nov 20 07:41 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo
I was getting:
-rw-r--r-- 2 bitbake bitbake 1348 Nov 20 10:28 deploy/images/raspberrypi3-64/Image-linux-raspberrypi-lirc-rpi.dtbo
lrwxrwxrwx 2 bitbake bitbake 37 Nov 20 10:28 deploy/images/raspberrypi3-64/Image-linux-raspberrypi-lirc-rpi-master-20171120102653.dtbo -> Image-linux-raspberrypi-lirc-rpi.dtbo
lrwxrwxrwx 2 bitbake bitbake 37 Nov 20 10:28 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> Image-linux-raspberrypi-lirc-rpi.dtbo
and e.g. sdcard_image-rpi.bbclass from meta-raspberrypi:
https://github.com/agherzan/meta-raspberrypi/blob/37e4e18f4a745ce8dc11f7e40a29da0859ff13c6/classes/sdcard_image-rpi.bbclass
was failing in:
mcopy -i ${WORKDIR}/boot.img -s ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${DTB_BASE_NAME}.dtb ::${DTB_BASE_NAME}.dtb
because ${KERNEL_IMAGETYPE}-${DTB_BASE_NAME}.dtb doesn't exist in my
build, due to
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"`
not replacing whole "${KERNEL_IMAGE_SYMLINK_NAME}" (read ${MACHINE})
with just ${DTB_BASE_NAME}
* with this change applied the deploy dir looks like this:
-rw-r--r-- 2 bitbake bitbake 1.4K Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo
lrwxrwxrwx 2 bitbake bitbake 74 Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo
lrwxrwxrwx 2 bitbake bitbake 74 Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi-raspberrypi3-64.dtbo -> lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo
and works correctly even with DISTRO using different naming scheme
* the sdcard_image-rpi.bbclass still needs to be modified, I've provided
updated version here:
https://github.com/agherzan/meta-raspberrypi/pull/159
* mpc8315e-rdb.conf MACHINE in meta-yocto-bsp also needs small fix:
https://lists.yoctoproject.org/pipermail/poky/2018-July/011436.html
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If SOURCE_DATE_EPOCH is unset (in addition to the existing "0" behaviour)
parse out the top most commit timestamp from the kernel tree to use as the
timestamp.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
With recent kernels (i.e. 4.17+) the configuration phase of the kernel
will check for capabilities/options of the compiler for CVE and other
mitigation support.
For a general kernel, we want to ensure that CC is fully defined when
the config targets are invoked (so the proper compiler will be checked).
For linux-yocto, we also need to specify the compiler/tools dependencies
for the configme task since it executes before configure and hence the
main kernel build DEPENDS will not always be in the sysroot before it
executes. Without those dependencies the kernel will be incorrectly
configured (i.e. bison is missing) or the configuration will fail the
mitigation tests.
[YOCTO #12757]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently if KERNEL_IMAGETYPES contains both vmlinux and vmlinux.gz,
KERNEL_IMAGETYPE_FOR_MAKE will end up containing two copies of
vmlinux, which will result in two calls to "make vmlinux" from
kernel_do_compile().
Avoid duplicating vmlinux in KERNEL_IMAGETYPE_FOR_MAKE plus some
minor non-functional updates to formatting and comments.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Commit a1690131691507bbf5853540229b3ad775b836bf removed the ability of
recipes to set KERNEL_IMAGETYPE_FOR_MAKE. Fix that by letting recipes
continue to set their own KERNEL_IMAGETYPE_FOR_MAKE if they so wish.
They may have been doing so for a while, and don't want to have their
carefully-selected value trampled on by kernel.bbclass.
This may be required if the recipe itself wants to build one type of
kernel, but post-process it into a different type, rather like the
vmlinux->vmlinux.gz support provided by kernel.bbclass.
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Set KBUILD_BUILD_VERSION=1 to avoid build version being incremented on
every build. It is visible in the output of "cat /proc/version" after
the hash character.
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Kernel v4.14 and newer contain the following in their Makefile:
HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS)
HOSTLDFLAGS := $(HOST_LFS_LDFLAGS)
This breaks our menuconfig, because it can no longer find ncurses if its
not on the host machine. This can be seen in linux-yocto-dev, for
example:
[clsulliv@clsulliv build]$ bitbake virtual/kernel -c menuconfig
GEN ./Makefile
HOSTLD scripts/kconfig/mconf
/home/clsulliv/yocto/poky/build/tmp/hosttools/ld: cannot find -lncurses
/home/clsulliv/yocto/poky/build/tmp/hosttools/ld: cannot find -ltinfo
collect2: error: ld returned 1 exit status
make[3]: *** [scripts/Makefile.host:99: scripts/kconfig/mconf] Error 1
make[2]: *** [/home/clsulliv/yocto/poky/build/tmp/work-shared/intel-corei7-64/kernel-source/Makefile:504: menuconfig] Error 2
make[1]: *** [Makefile:146: sub-make] Error 2
make: *** [Makefile:24: __sub-make] Error 2
Command failed.
Press any key to continue...
Fix this by setting HOSTLDFLAGS to ${BUILD_LDFLAGS} in our
'make menuconfig' command.
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Replace the occurences of BUILD_REPRODUCIBLE_BINARIES with expanded
values ${BUILD_REPRODUCIBLE_BINARIES} so the variable does not need to be
exported.
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As of the 4.13 kernel, there are configuration + linker combinations
that do not need (or build) crtsavres.o for ppc64 targets. The commit
of interest is:
commit efe0160cfd40a99c052a00e174787c1f4158a9cd
Author: Nicholas Piggin <npiggin@gmail.com>
Date: Fri May 12 01:56:52 2017 +1000
powerpc/64: Linker on-demand sfpr functions for modules
For final link, the powerpc64 linker generates fpr save/restore
functions on-demand, placing them in the .sfpr section. Starting with
binutils 2.25, these can be provided for non-final links with
--save-restore-funcs. Use that where possible for module links.
This saves about 200 bytes per module (~60kB) on powernv defconfig
build.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
As such, our arch test for crtsavres.o is not enough, we add a secondary
existence check before trying the copy.
[YOCTO #12576]
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>
|
|
Explicitly depend on bison-native for deterministic builds, as it is required
for the build:
| HOSTCC scripts/basic/fixdep
| GEN ./Makefile
| HOSTCC scripts/kconfig/conf.o
| YACC scripts/kconfig/zconf.tab.c
| /bin/sh: bison: command not found
| scripts/Makefile.lib:217: recipe for target 'scripts/kconfig/zconf.tab.c' failed
In most cases, this dependency comes indirectly via toolchain dependencies,
specifically binutils-cross, which pulls bison-native. Different setups,
such as with external toolchain, would expose this problem, since correct
dependency is not marked explicitly.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
These functions were moved to meta/lib/oe in 2010 and the base_* functions in
utils.bbclass were intended to be a short-term compatibility layer. They're
still used in a few places, so update the callers to use the new functions.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In the case of a fitImage the this step should be done on the
image use to assemble the fitImage.
Signed-off-by: Thomas Perrot <thomas.perrot@tupi.fr>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The older style calls (plus a bashism in kernel.bbclass, fixed
separately) were introduced via the recent change to add support for
multiple kernel packages:
http://git.openembedded.org/openembedded-core/commit/?id=6c8c899849d101fd1b86aad0b8eed05c7c785924
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The "oldnoconfig" target has been supported since Linux 2.6.36.
According to OLDEST_KERNEL, the oldest kernel currently supported by
OE is 3.2.0, so the fallback to yes '' | make oldconfig is no longer
required.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
possible bashism in run.do_install line 163 (should be 'b = a'):
if [ "kernel" == "kernel" ]; then
Fixes "[: kernel: unexpected operator" when not using bash by default,
which causes the default kernel image link to not be created.
Signed-off-by: Ricardo Salveti <ricardo@opensourcefoundries.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Some distros may want to provide alternate kernel "flavors" via feeds or
within bootable images. For example, readily available builds which
provide certain diagnostic features can enable developers and testers to
more quickly resolve issues by avoiding lengthy kernel builds.
This change allows for building multiple flavors of the kernel and
module packages by templatizing kernel package names via a new
KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the old
name of "kernel", but can be overridden by certain recipes providing
alternate kernel flavors.
To maintain compatibility, recipes providing alternate kernel flavors
cannot be the "preferred provider" for virtual/kernel. This is because
OE puts the preferred provider's build and source at
"tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
"tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
"tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using the
default KERNEL_PACKAGE_NAME="kernel" follows the old semantics -- build
in the old location and may be preferred provider -- while recipes using
all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and don't
provide "virtual/kernel".
Testing:
1. Add `KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux"`
to local.conf so that linux-yocto-tiny may build alongside
the main kernel (linux-yocto).
2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel flavors.
3. Verified image and modules IPKs exist for both:
tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
4. Verified linux-yocto is the "preferred provider", and was built in
shared directory: tmp-glibc/work-shared/qemux86/kernel-*
5. Add `CORE_IMAGE_BASE_INSTALL_append_pn-core-image-base = "tiny-linux"`
to local.conf to install both kernel flavors in core-image-base.
6. `bitbake core-image-base` to build an image.
7. Verified image contains two bzImage's under /boot/, with
"yocto-standard" (linux-yocto recipe) selected to boot via symlink.
Discussion threads:
http://lists.openembedded.org/pipermail/openembedded-core/2015-December/thread.html#114122
http://lists.openembedded.org/pipermail/openembedded-core/2017-July/thread.html#139130
[YOCTO #11363]
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
Coauthored-by: Gratian Crisan <gratian.crisan@ni.com>
Coauthored-by: Haris Okanovic <haris.okanovic@ni.com>
Coauthored-by: Josh Hernstrom <josh.hernstrom@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
During the introduction of support for multiple kernel image types in
849b67b2e4820564b5e5c9bd4bb293c44351c5f3, do_sizecheck was changed to only
warn if any kernel was bigger than ${KERNEL_IMAGE_MAXSIZE}. (Well, it tried
to warn - it turns out that there's no function called "warn", it should be
"bbwarn".) The previous behaviour had been to fail the build if the single
kernel image did not fit.
It seems possible that people might be generating both compressed and
uncompressed kernels and only really care whether the compressed one fits.
This means that we shouldn't just always fail if any of the images are too
large. So, let's warn (correctly this time) on every image that is too
large, but only ultimately fail if no image will fit. The build will also
fail if ${KERNEL_IMAGETYPES} is empty, but I hope that no-one needs to do
that.
While we're here correct a typo in the KERNEL_IMAGE_MAXSIZE validity check.
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
We add the kernel-build-artifacts to the cleandirs list to ensure
that there are no remaining artificats in the kernel-build-artifacts
directory which is STAGING_KERNEL_BUILDDIR. Without this change
multiple System.map files are visiable in the STAGING_KERNEL_BUILDDIR,
which could cause problems for some tools.
[YOCTO #11880]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Allow to search header files and libs from native sysroots.
For example, an expanded BUILD_CFLAGS includes:
'-isystem/builddir/to/linux-yocto/recipe-sysroot-native/usr/include'
And an expanded BUILD_LDFLAGS includes:
'-L/builddir/to/linux-yocto/recipe-sysroot-native/usr/lib
-Wl,-rpath-link,/builddir/to/linux-yocto/recipe-sysroot-native/usr/lib
-Wl,-rpath,/builddir/to/linux-yocto/recipe-sysroot-native/usr/lib'
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|