Recipes are much more readable with whitespace around the assignment operators.
Fix various assignments in OE-Core to show this is definitely the preferred
formatting.
(From OE-Core rev: 30ea609d3357fb3de911f2f6a5e6856c151b976a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The idea of the base class dependency is to say "yes, I need a C cross compiler"
and this was never meant to be gcc specific. Looking at the codebase, whilst we
code triplets into this, it does overcomplicate things as there are only ever
limited, "target", "sdk" and the class extended versions like mutlilib.
After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc.
This lets us remove the "gcc" specific element as well as removing the over
complicated triplet usage.
At the same time, change the much less widely used "g++" variant to "c++" for
similar reasons and remove the triplet from virtual/XXX-binutils too.
Backwards compatibility mappings could be left but are just going to confuse
things in future so we'll just require users to update.
This simplification, whilst disruptive for any toolchain focused layers, will
make improved toolchain selection in the future much easier.
Since we no longer have overlapping variables, some code for that can just
be removed. The class extension code does need to start remapping some variables
but not the crosssdk target recipe names.
This patch is in two pieces, this one handles the renaming with the functional
changes separate in a second for easier review even if this breaks bisection.
(From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the do_savedefconfig task definition from u-boot and kernel to
cml1.bbclass. There are more recipes which use the kbuild framework and
benefit from a do_savedefconfig task.
(From OE-Core rev: 2b2ed48903e09196ee20da7f66b1d3689e4a4473)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CMDLINE_CONSOLE appears to be a legacy variable that is unused anywhere,
and has not been modified the creation of the git tree. Remove it and
make life simpler.
(From OE-Core rev: d075b7c8f15488d98f0cda7b59de9dbed2a4f2d1)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* -image and -base change PKG to:
PKG:${KERNEL_PACKAGE_NAME}-image = "${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar(KERNEL_VERSION))}"
PKG:${KERNEL_PACKAGE_NAME}-base = "${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar(KERNEL_VERSION))}"
* but only when debian.bbclass is inheritted they add the original package name into RPROVIDES by:
https://git.openembedded.org/openembedded-core/commit/?id=3409c4379559afbb1d1d29045582995147a33bbc
* fixes the build if some packagegroup or something RDEPENDS on kernel-image or kernel-base
and the DISTRO doesn't inherit debian.bbclass
* as shown in pkgdata:
linux-raspberrypi $ egrep "^(PKG:)|(RPRO)" 6.6.36+git-*/pkgdata/runtime/kernel-image
6.6.36+git-debian/pkgdata/runtime/kernel-image:RPROVIDES:kernel-image: kernel-image (=6.6.36+git@PRSERV_PV_AUTOINC@+733366844f_769634f344)
6.6.36+git-debian/pkgdata/runtime/kernel-image:PKG:kernel-image: kernel-image-6.6.36-v8
6.6.36+git-without-debian/pkgdata/runtime/kernel-image:PKG:kernel-image: kernel-image-6.6.36-v8
linux-raspberrypi $ egrep "^(PKG:)|(RPRO)" 6.6.36+git-*/pkgdata/runtime/kernel-image-image
6.6.36+git-debian/pkgdata/runtime/kernel-image-image:RPROVIDES:kernel-image-image: kernel-image-image (=6.6.36+git@PRSERV_PV_AUTOINC@+733366844f_769634f344)
6.6.36+git-debian/pkgdata/runtime/kernel-image-image:PKG:kernel-image-image: kernel-image-image-6.6.36-v8
6.6.36+git-without-debian/pkgdata/runtime/kernel-image-image:PKG:kernel-image-image: kernel-image-image-6.6.36-v8
(From OE-Core rev: 05498781657a3f8b38b000f91594ecd78850ce47)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add linux:linux to CVE_PRODUCT. linux:linux is used by the kernel CNA
in raw CVE entries. We can't use just linux, because of conflicts with
CPE entries of multiple distributions.
(From OE-Core rev: 27404c4ef815f41aac994e9f390776a8bf4f9553)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The commit “Use a copy of image for kernel*.rpm if fs doesn't support
symlinks” [1] added postinst and postrm scripts to the kernel package which
create a symlink after package installation. This should not happen if
`KERNEL_IMAGETYPE_SYMLINK` is not `1`.
Background: The u-boot implementation of jffs2 does not support symlinks.
Using a hardlink or removing `${KERNEL_VERSION}` from the file name fails,
because the current postinst script replaces the file with the symlink.
[1] 8b6b95106a
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Yanfei Xu <yanfei.xu@windriver.com>
(From OE-Core rev: 6a763401862d9ee96749ad18378b6344778c2c66)
Signed-off-by: Jörg Sommer <joerg.sommer@navimatix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Work through the initial issues I found where we need to change WORKDIR
to UNPACKDIR.
(From OE-Core rev: 86fec41b1e809d1a2fa2feadc26d29020df53d39)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the kernel folder does not exist, find will result in an error.
This can occur if the kernel has no modules but, for example, custom modules are created.
Add check before deleting.
(From OE-Core rev: 7ef767d84d56b25498e45db83bb8f9d9caebeaf9)
Signed-off-by: Heiko Thole <heiko.thole@entwicklung.eq-3.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The check_oldest_kernel() function requires utsrelease.h to be
generated. This file is generated during do_compile, so we need to delay
calling check_oldest_kernel() until after this.
With this change in place, I now see the expected warning when building
Linux 5.10.y.
(From OE-Core rev: 525019b30e83ea65021ca4874605589ccd2daf80)
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The pkg-config workaround has been applied for kernel image building, but
not for module building. So pkg-config variables are different between
do_compile and do_compile_kernelmodules tasks. It may unnecessary trigger
rebuilding of a few host tools at the later task.
Especially when CONFIG_DEBUG_INFO_BTF is enabled in the kernel, it may even
trigger rebuilding vmlinux at do_compile_kernelmodules due to the rebuilt
host tools such as certs/extract-cert or objtool (on x86). This eventually
creates an inconsistent set of kernel binaries.
Here is the repro steps:
- Check out nanbield on x86
- The unexpected rebuild happens on kirkstone or possibly earlier
- Ensure that pahole is available (e.g. via meta-oe)
- Set KERNEL_DEBUG to "True" to properly set up PAHOLE
e.g.
$ export KERNEL_DEBUG="True"
$ export BB_ENV_PASSTHROUGH_ADDITIONS="${BB_ENV_PASSTHROUGH_ADDITIONS} KERNEL_DEBUG"
- Enable CONFIG_DEBUG_INFO_BTF=y
e.g.
$ bitbake -c menuconfig virtual/kernel
-> Kernel hacking
-> Compile-time checks and compiler options
-> Generate BTF typeinfo
- Build the kernel
e.g.
$ bitbake virtual/kernel
The BTF information in the resulting bzImage and kernel modules are
inconsistent, because the module's BTF information is generated using the
"second" vmlinux that doesn't have the identical BTF to the "first" vmlinux.
These modules can't be loaded at runtime due to the BTF mismatch.
This also leads to a build-id mismatch between the installed bzImage and
vmlinux since the bzImage is created from the first vmlinux, but the
installed vmlinux is the second one.
$ eu-readelf -n tmp/work/qemux86_64-poky-linux/linux-yocto/6.5.13+git/image/boot/{bzImage*,vmlinux*} | grep "Build ID"
Build ID: 4a0d62ee7fef0244950f0f604253729875bea493
Build ID: fb99b3d91399dbe42bf67ddee59e0f5a0c7f74d9
To avoid the unexpected rebuilding that results in such inconsistency, set
the same pkg-config variables when building kernel and modules. For kernel
5.19 and above, simply set the HOSTPKG_CONFIG in the make command line.
(From OE-Core rev: cd2072e5d953af981339427028e19083257e6a92)
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that bitbake supports the use of inherit_defer, switch all conditional
(variable based) inherits to use this instead. This leads to more a more
deterministic user experience since there is no longer an immediate expansion
and later changes to the variables in question (e.g. a bbappend) are
accounted for.
This patch tries to ensure the behaviour before/after remains as unchanged
as it reasonably can, e.g. by always inherting populate_sdk_base. native
and nativesdk continue to need to be inherited last, hence being used
with inherit_defer in a handful of very specific cases.
(From OE-Core rev: 451363438d38bd4552d5bcec4a92332f5819a5d4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The appendVar setting should have a preceding space, otherwise, when
KERNEL_MODULE_SPLIT is set to "0", we'll sometimes get dependency error
due to lacking of space.
(From OE-Core rev: 266cd948d4aa68de34075e8ed6299f7d80d19346)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
os.environ does not pass this down to runstrip() function and in
strip_execs() its using STRIP bitbake variable to find the strip utility
to use. Since there might be a trailing whitespace in KERNEL_STRIP
remove that otherwise python is not able to launch it.
e.g.
FileNotFoundError: [Errno 2] No such file or directory: 'riscv64-yoe-linux-strip '
This is more evident when STRIP and KERNEL_STRIP are different utilities
e.g. when using clang as default toolchain but using gcc+binutils only for
kernel build.
(From OE-Core rev: 77497dbdca92ab4d6386a071bc281c42a7e8a14b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it. Simple fix is to add the
-f (force) flag to the call.
(From OE-Core rev: 2e669bf797b15d803e7d6a700e449bdc467a4bcc)
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Kernel uses its own variables KERNEL_* instead of general toolchain env
variables, therefore use KERNEL_STRIP here explicitly, Problems happen
when using llvm-strip as default STRIP in distro settings, since kernel
defaults to using gcc, system does not stage llvm/clang toolchain into
kernel's staging sysroot and this function ends up with
FileNotFoundError: [Errno 2] No such file or directory: 'riscv64-yoe-linux-llvm-strip'
(From OE-Core rev: 2db0ef8fe6381c893791ad645748f6e7c8134e5f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Kernels that do not use modules do not have the Modules.symvers file,
which causes the previous one-liner to fail. Invert the logic so that
the absence of the Modules.symvers is a passing situation but we still
get failure checking on the install operation.
(From OE-Core rev: 856c916ffbf3438d8cf5d8bed344473bde03b56e)
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The initial fix for localversion setting in 6.3+ broke older
recipes and also broke recipes setting localversion in a kernel
recipe, as make-mod-scripts (and other locations) can trigger
a regeneration of files and don't have access to the variable.
Moving the setting of this variable to the global namespace
doesn't make sense, so we follow the example of the kernel-abiversion
and save a kernel-localversion to the build artifacts.
Recipes that may regenerate scripts/dynamic files, must
depend on the do_shared_workedir of the kernel and use the helper
function to read the file storing the localversion.
(From OE-Core rev: b378eec156998eea55ba61e59103cb34fab0d07c)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to an oversight in the do_symlink_kernsrc function, the path
comparison between "S" and "STAGING_KERNEL_DIR" is broken. The code
obtains both variables, but modifies the local copy of "S" before
comparing them, causing the comparison to always return false.
This can cause the build to fail when the EXTERNALSRC flag is enabled,
since the code will try to create a symlink even if one already exists.
This patch resolves the issue by comparing the variables before they are
modified.
(From OE-Core rev: afd2038ef8a66a5e6433be31a14e1eb0d9f9a1d3)
Signed-off-by: Staffan Rydén <staffan.ryden@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 5.19 kernel introduced a variable to specify the pkg-config
command to use for host tools.
Previously to this being introduced, we needed to overrride the
standard PKG_CONFIG* variables to avoid calls to pkg-config using
the target configuration.
While we can't completely drop the PKG_CONFIG workaround, we
should introduce the new variable, and prepare to only use it
once all supported kernels are 5.19+
(From OE-Core rev: d4b5ea28078cbbf417d95e1b77c6b8c3e9f9e4c0)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During testing of the v6.4 reference kernel, it was noticed that
on-target modules no longer matched the magic value of the running
kernel.
This was due to a different localversion in the cross built kernel
and the scripts / resources created on target.
This was due to changes in the setlocalversion script introduced
in the v6.3 series.
The .scmversion file is no longer used (or packaged) to inhibit
the addition of a "+" (through querying of the git status of the
kernel) or the setting of a local version.
We recently introduced the KERNEL_LOCALVERSION variable to allow
recipes to place a value in .scmversion, so we extend the use of
that variable to kernel-arch.bbclass and use it to set the
exported variable LOCALVERSION.
We must do it at the kernel-arch level, as the variable must be
exported in any kernel build to ensure that setlocalversion always
correctly sets the localversion.
(From OE-Core rev: 765b13b7305c8d2f222cfc66d77c02e6a088c691)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
strip can be coming from binutils or from llvm
in some cases llvm-strip can fail on kernel
Subprocess output:aarch64-yoe-linux-llvm-strip: error: Link field value 28 in section .rela.dyn is not a symbol table
This helps in selecting which strip is used when building kernel
(From OE-Core rev: 03973c8c1c93ddb1c8e05b773bfcc45aed73a99f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a specific kernel provider or configuration wants to enable BTF
and pahole analysis, it isn't currently possible due to the explicit
definition to false in the base kernel build arguments.
pahole is now detected by the kernel built itself, so unless
pahole-native is enabled, the result is the same.
If a kernel does require an explicit disable of pahole, it is better
to carry PAHOLE=false in those specific recipes.
(From OE-Core rev: b1e4851a36ed47ce6ba880a49264b9a57c78cf4f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Just like UBOOT_LOCALVERSION, an end user can set KERNEL_LOCALVERSION
to append a string to the name of the local version of the kernel
image.
(From OE-Core rev: 229435a52f36ddec5f85fb6d5ccd42044b688397)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the notation suggested by Martin Jansa to avoid a bashism. Also
switch KERNEL_DTBVENDORED to the more common 0/1 notation instead of
true/false.
Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb
directory, 2023-05-02)
(From OE-Core rev: dd5a5abc9d88c3bc8ff2c52b042600f00f054015)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fedora/Redhat and Arch are somewhat standardized on their dtb directory
structure. Let's add some flags to configure yocto to mimic that
behavior.
Add the following variables to the kernel class:
- KERNEL_DTBDEST (controls the destination directory for dtbs)
- KERNEL_DTBVENDORED (controls if vendor subdirectories are to
be respected)
Currently KERNEL_DTBDEST is expected to be a subdir of KERNEL_IMAGEDEST
and KERNEL_DTBVENDORED is expected to be "true"/"false". This only
applies to the package directory structure. The deploydir structure is
purposely left untouched for compatibility with existing recipes.
By default this is configured to behave the same as the current recipe
and produce a flat dtb directory at KERNEL_IMAGEDEST.
(From OE-Core rev: 04ab57d20009d85eb566e83ae6fe1dcea4db7300)
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a partial fix for bugzilla 15059 [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15059]
It has been noted by several people that when an initramfs is bundled:
- a lot of the kernel is rebuilt
- it takes a really long time
When looking at the logs, the second kernel compilation (that performs
the bundle) is not using the parallel make settings, and builds with
-j1.
We are already explicitly passing PARALLEL_MAKE when building kernel
modules, and by extending that explicit use to the main kernel
compilation, we ensure that we always get a parallel build.
Build times chnaged from more than 30 minutes for the bundle, to
3 minutes in local testing.
The question of whether or not too much is rebuilding during the
bundle step is still an open question, but with this tweak, at least
the build time is back in the realm of acceptable.
(From OE-Core rev: 88fd394ecf0f2174b792075d409d87046896426b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* move it from kernel.bbclass, because it needs to stay in sync with
IMAGE_LINK_NAME structure
* image-artifact-names.bbclass is also inheritted from kernel-artifact-names.bbclass
so every recipe which needs this variable probably already inherits one of these
* fixes kernel-fitimage.bbclass with modified IMAGE_LINK_NAME
[YOCTO #12937]
(From OE-Core rev: 432d0df0d771c8f0bef1e855ac6b0011b2c3cad2)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pkgconfig is being required to find dependencies for building kernel
native tools, move "inherit pkgconfig" to kernel.bbclass so BSP kernel
recipes can also benefit from it.
(From OE-Core rev: 8a84bd98e3fbc16c782f83064801e469d086911e)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in switching toolchains cleanly for kernel build
between gcc and clang
Currently, some kernels allow building with clang but not all
the distro might use clang as default system compiler but kernel
may demand gcc which is provided via KERNEL_* variables, however
kernel does use OBJCOPY at places during build and it maybe set
to use llvm objcopy when using clang. That should be a deliberate
setting when clang is used for kernel as well, otherwise it should
use binutils provided objcopy
(From OE-Core rev: 17b409f2fd97894e0943d13c2cb0d52abde647e3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the 6.1 kernel we've seen reproducibility/determinism issues where the kernel
seems to rebuild headers referencing the hostname or local user. kernel-devsrc
building after the kernel seemed to trigger it in some cases.
Moving the definitions to the bbclass used by all the kernel recipe code including
kernel-devsrc seems to be the best way to ensure this doesn't happen.
(From OE-Core rev: 60681baa97daf4f3856453c34d6be08b6771a81b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a follow-up to commit 846ff49465 to remove the extra whitespace
that is no longer needed after converting :append and :prepend to += and
=+.
(From OE-Core rev: 5a38be49e451c9f9d973b10a33c3972507f7b18a)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As far as I can tell, none of these uses of PACKAGESPLITFUNCS need append/prepend
operators, the standard += and =+ can work just fine. Since OE-Core is copied a lot,
use the preferred syntax which is also simpler to parse and change.
(From OE-Core rev: 846ff49465337dddd75a83161f41f48117f6571c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, allyesconfig test runs for x86_64 fail with:
ERROR: linux-yocto-5.19.17+gitAUTOINC+0cba9aa404_aaf4490d18-r0 do_package:
QA Issue: linux-yocto: Files/directories were installed but not shipped in any
package:
/lib/modules/5.19.17/kernel/drivers/nvdimm
With CONFIG_NVDIMM_TEST_BUILD=m, an empty nvdimm directory is created during
modules_install, which triggers the QA issue.
Extend kernel_do_install() to also remove inner empty directories that might
get created by modules_install.
(From OE-Core rev: 7120b09a33af4c9a18063c0f2e51fb598697e39c)
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, the KERNEL_DEBUG_TIMESTAMPS is not working as expected
at rebuild. That is, even if we set it to "1", the kernel build time
is not changed. The problem could be reproduced by the following steps.
1. bitbake core-image-minimal; start image and check `uname -a` output.
2. set in local.conf: KERNEL_DEBUG_TIMESTAMPS = "1"
3. bitbake core-image-minimal; start image and check `uname -a` output.
It's expected that after enabling KERNEL_DEBUG_TIMESTAMPS, the kernel
build time will be set to current date. But it's not. This is because
the compile.h was not re-generated when do_compile task was re-executed.
In mkcompile_h, we have:
"""
# Only replace the real compile.h if the new one is different,
# in order to preserve the timestamp and avoid unnecessary
# recompilations.
# We don't consider the file changed if only the date/time changed,
# unless KBUILD_BUILD_TIMESTAMP was explicitly set (e.g. for
# reproducible builds with that value referring to a commit timestamp).
# A kernel config change will increase the generation number, thus
# causing compile.h to be updated (including date/time) due to the
# changed comment in the
# first line.
"""
It has made it very clear that it will not be re-generated unless
we have KBUILD_BUILD_TIMESTAMP set explicitly. So we set this variable
explicitly in do_compile to fix this issue.
(From OE-Core rev: 1b68c2d2d385013a1c535ef81172494302a36d74)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building with CONFIG_MODVERSIONS=y and CONFIG_RANDSTRUCT=y we need
to copy the build assets generated for the randstrutc seed to
STAGING_KERNEL_BUILDDIR, otherwise the out-of-tree modules build will
generate those assets which will result in a different
RANDSTRUCT_HASHED_SEED.
(From OE-Core rev: b36303158b2e0273ff415bdedefb379f680b30fc)
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replacing sysroot_stage_all by a no-op recipe makes it difficult for
bbappends to stage files intentionally. Instead, just clear
SYSROOT_DIRS, allowing other bbappends to easily add new directories.
(From OE-Core rev: 849791e7086463a4c7c53c2c1ed9603a6c3a080d)
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes sure that the postinstall script it using the right kernel
paths.
(From OE-Core rev: 5105820df4800673c188366a76c1a3bd387a7148)
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're currently only passing in a subset of the kernel make flags to
menuconfig. Fix this to be consistent with all the other kernel
operations since these are becomming increasingly reliant on host
compilers and flags and target toolchains as well.
(From OE-Core rev: 8c616bc090d1834a21073a33209323220c05d2e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It as been bothering me a bit that we don't set CC and LD consistently
for the kernel make calls and this can lead to interesting bugs as the
kernel increases in complexity. Add them to EXTRA_OEMAKE so they're
always passed in. This makes everything slightly more consistent and
less likely to break in future.
(From OE-Core rev: afe8c318843e4033dcc07e4f10198df241d8e4f6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
