If not set the system will use an empty string which will result in
download errors for 'linux-.tar.gz' packages.
This patch makes it obvious to the user that the variable needs to be
set.
Signed-off-by: Christian Kellermann <christian.kellermann@solectrix.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fix kernel reproducible build if a non-C locale is used on the host
system.
When building the Linux kernel, scripts/gen_initramfs_list.sh does 'date
-d"$KBUILD_BUILD_TIMESTAMP" +%s'. In linux.mk, Buildroot sets
KBUILD_BUILD_TIMESTAMP to "$(shell date -d @$(SOURCE_DATE_EPOCH))".
For example, if LANG=fr_FR.UTF-8 is defined in the host system, it does
not work:
- LC_ALL=C date -d"$(LC_ALL=C date)" : ok
- LC_ALL=C date -d"$(LC_ALL=fr_FR.UTF-8 date)" : error
LANG/LC_ALL variables exported in the main Makefiles are not passed in
the $(shell ...) sub-shells.
Signed-off-by: Jean-Baptiste Trédez <jean-baptiste.tredez@basystemes.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Linux kernel include a few information about build environment in its binary.
This feature is incompatible with BR2_REPRODUCIBLE. This patch overload build
information when BR2_REPRODUCIBLE is enabled.
Note that usage of KBUILD_BUILD_TIMESTAMP is not mandatory since Buildroot
use `fakedate'. However, native solution is prefered when upstream
provide one.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The kernel source tree also contains the sources for various userland
tools, of which cpupower, perf or selftests.
Currently, we have support for building those tools as part of the
kernel build procedure. This looked the correct thing to do so far,
because, well, they *are* part of the kernel source tree and some
really have to be the same version as the kernel that will run.
However, this is causing quite a non-trivial-to-break circular
dependency in some configurations. For example, this defconfig fails to
build (similar to the one reported by Paul):
BR2_arm=y
BR2_cortex_a7=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_SYSTEMD=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y
BR2_PACKAGE_CRYPTODEV=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_LIBCURL=y
This causes a circular dependency, as explained by Thomas:
- When libcurl is enabled, systemd depends on it
- When OpenSSL is enabled, obviously, will use it for SSL support
- When cryptodev-linux is enabled, OpenSSL will depend on it to use
crypto accelerators supported in the kernel via cryptodev-linux.
- cryptodev-linux being a kernel module, it depends on linux
- linux by itself (the kernel) does not depend on pciutils, but the
linux tool "cpupower" (managed in linux-tool-cpupower) depends on
pciutils
- pciutils depends on udev when available
- udev is provided by systemd.
And indeed, during the build, we can see that make warns (it's only
reported as a *warning*, not as an actual error):
[...]
make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured
<- cryptodev-linux dependency dropped.
>>> openssl 1.0.2h Downloading
[...]
So the build fails later on, when openssl is actually built:
eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory
compilation terminated.
<builtin>: recipe for target 'eng_cryptodev.o' failed
Furthermore, graph-depends also detects the circular dependency, but
treats it as a hard-error:
Recursion detected for : cryptodev-linux
which is a dependency of: openssl
which is a dependency of: libcurl
which is a dependency of: systemd
which is a dependency of: udev
which is a dependency of: pciutils
which is a dependency of: linux
which is a dependency of: cryptodev-linux
Makefile:738: recipe for target 'graph-depends' failed
Of course, there is no way to break the loop without losing
functionality in either one of the involved packages *and* keep
our infrastructure and packages as-is.
The only solution is to break the loop at the linux-tools level, by
moving them away into their own package, so that the linux package will
no longer have the opportunity to depend on another package via a
dependency of one the tools.
All three linux tools are thus moved away to their own package.
The package infrastructure only knows of three types of packages: those
in package/ , in boot/ , in toolchain/ and the one in linux/ . So we
create that new linux-tools package in package/ so that we don't have to
fiddle with yet another special case in the infra. Still, we want its
configure options to appear in the kernel's sub-menu.
So, we make it a prompt-less package, with only the tools visible as
options of that package, but without the usual dependency on their
master symbol; they only depend on the Linux kernel.
Furthermore, because the kernel is such a huge pile of code, we would
not be very happy to extract it a second time just for the sake of a few
tools. We can't extract only the tools/ sub-directory from the kernel
source either, because some tools have hard-coded path to includes from
the kernel (arch and stuff).
Instead, we just use the linux source tree as our own build tree, and
ensure the linux tree is extracted and patched before linux-tools is
configured and built.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We used to do a special handling of Linux kernel modules when stripping
target binaries because there's some special precious data in modules
that we must keep for them to properly operate. This is for example true
for stack unwinding data etc.
It turned out there're cases when our existing "strip --strip-unneeded"
doesn't work well. For example this removes .debug_frame section used by
Linux on ARC for stack unwinding, refer to [1] and [2] for more details.
Now Linux kernel may strip modules as a part of "modules_install" target
if INSTALL_MOD_STRIP=1 is passed in command line. And so we'll do
allowing kernel decide how to strip modules in the best way.
Still note as of today Linux kernel strips modules uniformly for all
arches with "strip" command, so this commit alone doesn't solve
mentioned problem but it opens a possibility to add later a patch to the
kernel which will strip modules for ARC differently - and that's our
plan for mainline kernel.
[1] https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/86
[2] http://lists.busybox.net/pipermail/buildroot/2016-September/172161.html
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Daniel Mentz <danielmentz@google.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 73da2ff6f7.
The reason for adding support for a local location was to be able to do
development on the Linux kernel source tree on a local directory rather
than have to clone it for every build.
We already have a mechanism for that, it's called override-srcdir. It's
been available since September 2011, more than a year before this patch
was committed.
Otherwise, we're going to be adding support for local sources in other
packages. First was U-Boot as submitted by Adam. But what next? We can't
have such support for all packages, especially since override-srcdir
does the job.
Besides, using a local source tree makes the build non-reproducible, so
we don't really want to have this in a .config (or defconfig).
We only handle the boolean option in legacy, as there is nothing we can
do with the directory path.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Rafal Fabich <rafal.fabich@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To configure the Linux kernel, we currently provide two options:
1. Passing a defconfig name (for example "multi_v7"), to which we append
"_defconfig" to run "make multi_v7_defconfig".
2. Passing a path to a custom configuration file.
Unfortunately, those two possibilities do not allow to configure the
kernel when you want to use the default configuration built into the
kernel for a given architecture. For example, on ARM64, there is a
single defconfig simply called "defconfig", which you can load by
running "make defconfig".
Using the mechanism (1) above doesn't work because we append
"_defconfig" automatically.
One solution would be to change (1) and require the user to enter the
full defconfig named (i.e "multi_v7_defconfig" instead of "multi_v7"),
but we would break all existing Buildroot configurations.
So instead, we add a third option, which simply tells Buildroot to use
the default configuration for the selected architecture. In this case,
Buildroot will configure the kernel by running "make defconfig".
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The endianess of the Linux kernel should be based on BR2_ENDIAN, so that
it is automatically built for the right endianness.
Signed-off-by: Ofer Heifetz <oferh@marvell.com>
[Thomas: tweak commit message, add comment in .mk file.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: don't use the helper.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit ab74e09eb4 renamed the dtc host tool
provided by linux to linux-dtc to avoid clashes with the dtc host tool
provided by host-dtc.
However, external scripting may well rely on the existence of a device tree
compiler as $(HOST_DIR)/usr/bin/dtc, regardless of its source. Changing
these external scripts to use linux-dtc means that the scripts need to be
aware of the buildroot release they are working with, which is not very
nice.
Add a symlink dtc->linux-dtc when no $(HOST_DIR)/usr/bin/dtc is present.
When host-dtc is not enabled, the end result will be dtc and
linux-dtc representing the same thing.
When host-dtc is enabled, either it is build before linux and no symlink
is created at any time, or it is build after linux, and the 'install'
command in host-dtc will overwrite the symlink with a proper dtc. In both
cases, the end result will be dtc and linux-dtc representing a different
thing.
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The target "$(LINUX_DIR)/.stamp_initramfs_rebuilt" uses its own
'cp' command, instead of LINUX_INSTALL_IMAGE/LINUX_INSTALL_IMAGES_CMDS
provided by (or updated with) commit 055e6162bb ("linux: don't build
appended DTB image in place and support multiple images") and thus is
not operating properly when APPENDED_DTB is used.
Indeed, it copies a single image, and does not copy the one with the DTB
appended.
This patch replaces the 'cp' command with LINUX_INSTALL_IMAGE which
handles APPENDED_DTB.
Fixes: 055e6162bb ("linux: don't build appended DTB image in place and
support multiple images")
Signed-off-by: Sebastian Frias <sf84@laposte.net>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Kernels older than 3.9 (not counting stable releases) used the
timeconst.pl perl script for their build process.
The problem with this script is that it used deprecated perl features,
namely defined(@array) which was removed for the perl 5.22 release,
causing build failure of older kernels on newer distributions.
To fix this instead of going the hard way (moving to the new
timeconst.bc script) use the easy way by patching timeconst.pl with an
upstream patch used for stable releases.
First try a dry-run on the patch to see if it applies, if it does then
call a proper APPLY_PATCHES to it.
Tested against an arbitrary 2.6.30 kernel (applies and builds), against
4.4.1 for a missing timeconst.pl (does not apply since it's missing) and
3.8.13 (does not apply since it's fixed already).
Known broken distributions: fedora 23, debian testing (stretch) and unstable
(sid).
Signed-off-by: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
It is no longer meaningful, now that we have the option to use the
kernel version for the linux headers, as it is more logical and more
versatile.
Add it to legacy.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is the Vivante kernel driver split from the kernel source code in
order to make it possible to be used in any kernel source since 3.10.53.
The driver source code provided by Freescale needs fixes so the
community forked the code to allow faster development and easier
integration of fixes from the community.
This patch is based on the Yocto equivalent:
https://github.com/Freescale/meta-fsl-arm/commit/32cf391https://github.com/Freescale/meta-fsl-arm/commit/4249193
This package has been tested with the following commands:
# modprobe galcore
# cd /usr/share/examples/viv_samples/vdk/
# ./tutorial7
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some fine version control systems make all files read-only. The custom DTS file
may therefore be read-only, and that permission is preserved when copying into
the Linux build directory. A subsequent rebuild tries to 'cp' again, which
fails with a "Permission denied" error unless the -f option is used.
Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
Acked-by: Nikolay Dimitrov <picmaster@mail.bg>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, packages that need the kernel to have support for laodable
modules have two ways to require it:
- either the use the kernel-module infra, which does it automatically,
- or they do not use it, and they need to require it manually by
setting the corresponding Makefile variable; however, they must only
set it when they are actually enabled, which makes for a slightly
cumbersome and ugly code, like:
ifeq ($(BR2_PACKAGE_FOO),y)
LINUX_NEEDS_MODULES = y
endif
Introduce a new blind Kconfig option that packages can select to signify
they need kernel modules. That Kconfig option is then used to set the
Makefile variable.
It makes it cleaner:
- code is simpler (one Kconfig line instead of a Makefile if-block,
- this is handled at the Kconfig level, which is where we usually
handle such dependencies.
Packages will be updated in follow-up commits.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix improper use of qstrip; use correct variables.
Fixes#8546.
Reported-by: craigswank@gmail.com
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
[yann.morin.1998@free.fr: move the kconfig-package hunk to the
corresponding patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, the linux.mk logic for appended DTB image does the
appending of the DTB in place, directly at the end of the zImage using
a >> sign. This is incorrect because if you run "make linux-rebuild"
multiple times, you get the DTB appended over and over again to the
image.
Since keeping the 'zImage' or 'uImage' name for the appended DTB image
is not very clear, this commit moves to using the 'zImage.<dtb>' and
'uImage.<dtb>' format. This way, we can clearly distinguish the
original image from the appended one.
In addition, this naming scheme easily allows to generate *multiple*
appended DTB images: from one zImage, you can generate multiple
zImage.<dtb> for several DTBs, and then generate (if requested) the
corresponding uImage.<dtb>.
To achieve this, this commit:
- Changes the definition of LINUX_APPENDED_DTB to iterate over
$(KERNEL_DTS_NAME), and generate a zImage.<dtb> image for each of
them.
- Changes the addition of LINUX_APPENDED_DTB for appended uImage to
also iterate over $(KERNEL_DTS_NAME).
- Provide a different implementation of LINUX_INSTALL_IMAGE which
installs all the appended DTB images (but not the bare image)
- Remove the checks that verified that only one DT name is passed
when appended DTB is used, since we now support generating multiple
DT images.
Some of the tested configuration:
- Normal uImage with several DTBs
BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7"
BR2_LINUX_KERNEL_UIMAGE=y
BR2_LINUX_KERNEL_UIMAGE_LOADADDR="0x200000"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-xp-matrix armada-xp-gp armada-370-mirabox"
Contents of output/images/:
armada-370-mirabox.dtb armada-xp-gp.dtb armada-xp-matrix.dtb uImage
- Normal zImage with several DTBs
BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7"
BR2_LINUX_KERNEL_ZIMAGE=y
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-xp-matrix armada-xp-gp armada-370-mirabox"
Contents of output/images:
armada-370-mirabox.dtb armada-xp-gp.dtb armada-xp-matrix.dtb zImage
- Appended uImage with several DTBs:
BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7"
BR2_LINUX_KERNEL_APPENDED_UIMAGE=y
BR2_LINUX_KERNEL_UIMAGE_LOADADDR="0x200000"
BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-xp-matrix armada-xp-gp armada-370-mirabox"
Contents of output/images:
uImage.armada-370-mirabox uImage.armada-xp-gp uImage.armada-xp-matrix
- Appended zImage with several DTBs:
BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7"
BR2_LINUX_KERNEL_APPENDED_ZIMAGE=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-xp-matrix armada-xp-gp armada-370-mirabox"
Contents of output/images:
zImage.armada-370-mirabox zImage.armada-xp-gp zImage.armada-xp-matrix
In all configurations, the contents of output/target/boot/ was the
same if BR2_LINUX_KERNEL_INSTALL_TARGET=y.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When you're using the "appended DTB" mode, the Device Tree blob gets
appended to your kernel image, so there is no point in installing both
the DTB and the kernel image to the images or target directories,
installing the kernel image itself is sufficient.
Therefore, this commit disables the definition of LINUX_INSTALL_DTB
when appended DTB is used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, the LINUX_INSTALL_DTB and LINUX_INSTALL_DTB_TARGET macros
are exactly the same, except for the target directory.
Similarly, LINUX_INSTALL_KERNEL_IMAGE_TO_TARGET and
LINUX_INSTALL_IMAGES_CMDS are copying the kernel image, just to a
different place (and with a different strategy).
As a preparation for future additions, this commit de-duplicate this
code:
- LINUX_INSTALL_DTB becomes a make macro that takes one argument: the
destination directory.
- LINUX_INSTALL_IMAGE is a new make macro that also takes on
argument: the destination directory.
Both macros are used by LINUX_INSTALL_KERNEL_IMAGE_TO_TARGET and
LINUX_INSTALL_IMAGES_CMDS to respectively install to the target
directory and the images directory.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Linux for MIPS supports raw binary zboot image (vmlinuz.bin).
Add it to the "Kernel binary format" list.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This selection will ensure that the correct host tools
will be build used for the kernel compression method used.
[Maxime: Select the compression opts in the kernel config too ]
Signed-off-by: Sagaert Johan <sagaert.johan@proximus.be>
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998 at free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
On aarch64, the image name is always Image, so let's add support for
that.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
So it doesn't conflict with host-dtc. The Linux kernel version may be a
patched version supporting E.G. overlays.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When a package wants to build a kernel module, we should ensure that the
kernel does support modules.
This patch does it automatically for packages using the kernel-module
infrastructure.
Packages that do not use it will have to set it manually (to be done in
a followup patch).
Suggested-by: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Noé Rubinstein <noe.rubinstein@gmail.com>
Cc: Jan Viktorin <viktorin@rehivetech.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Both of CONFIG_NF_CONNTRACK and CONFIG_NF_CONNTRACK_MARK are needed by
xtables-addons.
Although the current code does enable them in the linux' .config file,
the former is protected behind CONFIG_NETFILTER_ADVANCED, which may be
missing from a user-supplied (def)config file, and is missing from some
of the bundled defconfigs as well.
For example, the following defconfig fails to build:
BR2_TOOLCHAIN_EXTERNAL=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_DEFCONFIG="i386"
BR2_PACKAGE_XTABLES_ADDONS=y
So, also force-enable CONFIG_NETFILTER_ADVANCED.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Linux buildsystem tries to run the compiler even just for
'kernelrelease' (which we store in LINUX_VERSION_PROBED) and we
sometimes need to use it before the toolchain is available; thus
we get spurious errors on stderr.
Consign stderr to oblivion when computing the 'kernelrelease'.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Verified that LINUX_VERSION_PROBED is only used in "-quoted commands
(actually, usually it's not quoted).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit add an infrastructure to build linux kernel
tools available in the kernel sources.
Currently, the only linux kernel tool packaged in Buildroot
is perf and it's packaged as a separate generic package.
This is a problem for licence information raised in this
thread [1].
Since these tools require to build a Linux kernel, we can
use some hooks in linux package like we did for linux
extensions [2] and remove the perf package.
[1] http://lists.busybox.net/pipermail/buildroot/2015-May/128783.html
[2] http://lists.busybox.net/pipermail/buildroot/2015-March/121835.html
[Thomas: fix minor typos in comments.]
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
If we check that the user provides a config file after we call to the
kconfig-package infra, the error message we get is the one for the
kconfig-package infra, not the custom error message we want to show to
the user.
So, only call kconfig-package after we do the check. Move the check with
the existing checks for the DTS, for consistency.
[Thomas: put the checks together, but right before the kconfig-package
call, rather than in the middle of the code, were the DTS related
tests were located.]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, this is triggering the error message:
make randconfig
make source
Limit the checks that enforce a DTS is set and at most one DTB is
appended to when we are actually building, like is done for the
configuration-file variables.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The ktap package requires some parts of the kernel tracing
infrastructure to be enabled, especially
CONFIG_EVENT_TRACING. However, this option is a blind option in the
kernel, so enabling it in linux.mk has no effect: we need to enable a
non-blind option that selects CONFIG_EVENT_TRACING. We've chosen to
select CONFIG_ENABLE_DEFAULT_TRACERS.
This fixes the build of ktap.
[Thomas: use CONFIG_ENABLE_DEFAULT_TRACERS as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This one is a bit tricky, as the version can come from the linux-headers
package, so we must also account for that.
We currently have no hash file for linux, but better do the change now,
which allows us to later add a hash file.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of manually testing MAKECMDGOALS, use the newly introduced
BR_BUILDING variable to know if we're building or not.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Curently, all three linux extensions follow the same layout:
- test if the extension is enabled
- add itself to linux' patch-dependencies
- declare a macro, added as the pre-patch hook
Except for the macro, all can be commonalised.
Add a simple infrastructure for that:
- extensions declare themselves in the list of extensions
- extensions define their macro
- the infra adds them to the patch-dependencies and pre-patch
hooks as appropriate
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Several packages have some logic to apply custom patches that existed
before the BR2_GLOBAL_PATCH_DIR mechanism: at91bootstrap,
at91bootstrap3, barebox, uboot and linux. Currently, the logic of
those packages to apply custom patches is to match
<package-name>-*.patch, which is not consistent with what we've done
for patches stored in the package directory, and for patches stored in
BR2_GLOBAL_PATCH_DIR: in such cases, we simply apply *.patch.
Therefore, for consistency reasons, this commit changes these packages
to also apply *.patch.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This commit doesn't touch infra packages.
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The linux package has a special handling of patches, with quite a bit
of legacy in it. A problem caused by this special handling is that the
linux package calls directly the DOWNLOAD_WGET macro, which means that
the package infrastructure isn't aware of which patches get
downloaded, and it prevents doing changes inside the package download
infrastructure.
This commit changes the handling of patches in the linux package in
the following way:
* The LINUX_PATCHES variable is kept as is: it lists all the patches
mentioned in the Config.in option BR2_LINUX_KERNEL_PATCH. This
option can contain http://, ftp://, https:// URLs, path to local
files or local directories.
This variable is *not* used by the generic package infrastructure,
so it is purely internal to the Linux package.
* The LINUX_PATCH variable is now filled in with the list of patches
that should be downloaded. It is derived from LINUX_PATCHES by
filtering the patches that have http://, ftp:// or https:// in
their path. Since <pkg>_PATCH is handled by the package
infrastructure, it means that those patches are now automatically
downloaded and applied by the package infrastructure.
* The LINUX_APPLY_PATCHES hook is renamed to
LINUX_APPLY_LOCAL_PATCHES, because it is now only responsible of
applying local patches: remote patches are handled by
LINUX_PATCH. The implementation of the hook is changed to filter
out the patches that have already taken care of by LINUX_PATCH, so
that we only iterate through the list of local patches or local
patch directories.
[Thomas: adjust comment in the code according to Yann comments.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
If you have several linux patches directories, Buildroot does not stop
if one patches of the first directories don't apply. This patch fixes
this.
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The recommended form is without the trailing slash. Buildroot will add a slash
between FOO_SITE and FOO_SOURCE as appropriate.
Reported-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When building device tree blobs from custom *.dts files, buildroot
initializes KERNEL_DTS_NAME variable from all given file names.
This causes that user can't provide one *.dts file and some other
*.dtsi files as dependencies.
Problem is fixed by adding filter for initializing KERNEL_DTS_NAME
variable with *.dts files only. All user provided files are copied
into kernel source tree, but only file names suffixed with *.dts
are used for building appropriate *.dtb files.
[Thomas: add comment into the code to explain why we are filtering
.dts files only.]
Signed-off-by: Ivo Slanina <ivo.slanina@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
