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>
When setting BR2_LINUX_KERNEL_LATEST_VERSION, it is hard for the user to
know that this version is subject to change in the future.
Explicit this in the Kconfig entry text.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since quite some time, the kernel and bootloader communities consider
zImage as the default format for kernel images on ARM, replacing
uImage. The load address information in uImage is no longer needed,
since the kernel is position-independent in terms of physical address,
except on a few old platforms. For most people, using zImage is simply
better/simpler, so let's switch to zImage as the default image format
on ARM.
All defconfigs are updated: 46 defconfigs no longer need to select
explicitly zImage because it's the default, and 16 defconfigs now need
to explicitly select uImage because that's no longer the default.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Matt Weber <matt@thewebers.ws>
Acked-by: Julien Boibessot <julien.boibessot@armadeus.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch adds the ability to compile and install the kernel
selftests into the target at /usr/lib/kselftests. The rationale behind
/usr/lib is that the selftests have subdirectories where they are
installed which makes them unsuitable to be placed in /usr/sbin as
this would result in /usr/sbin/kselftests/x/y/z. While the selftests
aren't libraries either, they don't achieve much as a standalone
binary so they can be considered to be a 'library of tests' making
/usr/lib sensible.
The selftests require that the kernel headers be installed into the
kernel build tree as some of the selftests have a hardcoded CFLAGS to
include kernel headers (CFLAGS += -I../../../../usr/include/). This is
most easily achieved by using the make ... headers_install inside the
kernel build dir.
This is likely to be a rarely used debugging/performance feature for
development and unlikely to be used in a production configuration.
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas:
- remove bash as a build dependency, it is only a runtime dependency.
- fix typo in the Config.in help text, and rewrap
- add missing 'depends on BR2_USE_MMU' dependency for the comment.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Forcefully disable the features that have optional dependencies that are
not enabled in Buildroot.
Disable support for bionic since, well, we're not Android.
Slightly re-order the variables to have semantically-related variables
together, with features last.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
perf does not honour the -j flags we pass to make; it yet again tries to
reinvent the wheel and by default uses the number of CPUs as the number
of parallel jobs.
Fortunately, in their infinite wisdom, the insane developpers of the
perf buildsystem were kind enough to provide us with a variable we can
set to specify the number of parallel jobs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The perf buildsystem, inside the kernel, is not really amenable to be
easily used...
Regarding the documentation, it will forcefully try to detect asciidoc
and, with the latest versions, xmlto, completely disregarding what the
user may provide.
We currently pass ASCIIDOC= (the empty string) on the make command line,
as an attempt to disable building the documentation, but that has no
effect whatsoever on perf: that variable is not passed down to the
sub-sub-make (yes, a two-level depth) that is responsible for building
the documentation.
We really do not want to build any of the documentation (the user can
refer to the documentation on his own development machine), so we use a
little dirty trick: we provide a GNUmakefile beside the existing
Makefile for the documentation; GNUmakefile always takes precedence over
a Makefile when both are present. We only provide a catch-all-no-recipe
rule in that GNUmakefile, so it really does nothing useful, except avoid
building the documentation.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We need to pass an argument to ld for setting the endianness when
building it for MIPS architecture, otherwise the default one will always
be used (which is big endian) and the compilation for little endian will
always fail showing an error like this one:
LD foo.o
mips-linux-gnu-ld: foo.o: compiled for a little endian system and target
is big endian
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.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 heavily (and most often improperly) modified Linux kernels may export
new APIs to userland, so as to speak to custom hardware or custom kernel
facilities.
However, we currently have no easy way to use such kernels as a source
for the linux-headers package, which precludes having those userland
headers intalled for userland applications to use them.
We do have a way for the kernel to use the same version as for the
headers, but that is definitely not enough, as the linux-headers package
has a version choice that is far less versatile and capable than that of
the linux package.
Add a new option for the linux-headers package, for the user to specify
that the version (really, the sources) of the kernel be used to install
the headers from.
We do that by making linux-headers patch-depend on the linux package.
We can't have linux-header simply depend on linux, because the simple
dependency means the the dependee will be configured, built and installed
before the dependent is configured. And since linux is a target package,
it depends on the toolchain, which internally dependes on linux-headers,
which would depend on linux, and we'd get a circular dependency.
Using patch-depend will ensure that linux is extracted and patched
before linux-headers is extracted, which is really all we need.
Then, we install the headers from the linux source tree, rather than
from linux-headers' source tree (as there's nothing in there!).
Since we need to install a private set for uClibc (see cde947f, uclibc:
prevent rebuilding after installation to staging), we explicitly set
INSTALL_HDR_PATH when calling the kernel' install-headers rule in
LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in
linux-headers' $(@D) instead of linux' $(@D).
Finally, as there is no way to know the kernel version in this case, we
must still prompt the user for the kernel series the headers are from
(like we do for a custom version) and check for consistency at build
time.
Note however that this still leaves users that want to built their
such-kernel outside of Buildroot out in the cold.
[Peter: drop comment as suggested by Thomas]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Karoly Kasza <kaszak@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.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>
The perf tool installed test files in
output/target/usr/libexec/perf-core/tests/
which amounted to about 30+K.
Since they are not needed for normal perf operation, remove them.
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>
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>
Since v4.0 the fbtft drivers are included in the linux kernel
staging area.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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>
Remove the perf package and add legacy handling.
[Thomas:
- improve the Config.in.legacy help text
- improve the comment explaining why we pass O= when building perf]
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>
This patch is based on the patch send by James Knight:
http://lists.busybox.net/pipermail/buildroot/2015-May/128754.html
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: James Knight <james.knight@rockwellcollins.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
This commit removes BR2_LINUX_KERNEL_EXT_RTAI_PATCH because this
option never worked. It was added in commit
8797a9cd1f, which added package/rtai/
and RTAI as a Linux extension.
The option prompt says "Path for RTAI patch file", so let's say you
specify /home/foo/bar/myrtai.patch as the value for
BR2_LINUX_KERNEL_EXT_RTAI_PATCH.
Then the code does:
RTAI_PATCH = $(call qstrip,$(BR2_LINUX_KERNEL_EXT_RTAI_PATCH))
and we have a package called 'rtai', so the normal logic of
<pkg>_PATCH applies. Since the <pkg>_PATCH value does not contain
ftp://, http:// or https://, the package infrastructure will try to
download $(RTAI_SITE)/$(RTAI_PATCH), i.e:
https://www.rtai.org/userfiles/downloads/RTAI/home/foo/bar/myrtai.patch
Pretty clear that it has no chance of working.
Now, let's assume an URL is used as the value of
BR2_LINUX_KERNEL_EXT_RTAI_PATCH, such as
http://foo.com/bar/myrtai.patch. In this case, it will be properly
downloaded by the package infrastructure. But then, the following code
kicks in:
define RTAI_PREPARE_KERNEL
$(APPLY_PATCHES) \
$(LINUX_DIR) \
$(dir $(RTAI_PATCH)) \
$(notdir $(RTAI_PATCH))
endef
The value of $(dir $(RTAI_PATCH)) will be http://foo.com/bar/. How
can $(APPLY_PATCHES) make use of such a stupid patch location?
[Thomas: add Config.in.legacy handling, as suggested by Arnout, even
if we believe that no-one could have ever used this option.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
linux has uImage generation support for powerpc64 as well as powerpc,
since 2.6.15.
Signed-off-by: Erico Nunes <erico.nunes@datacom.ind.br>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes fbtft kernel extension bug reported by Richard Fergusson ([1]):
drivers/video/Kconfig:2525: can't open file
"drivers/video/fbdev/fbtft/Kconfig"
Fix: write the right fbtft/KConfig path to video/Kconfig or
video/fbdev/Kconfig (instead of hard coded one)
[1] http://lists.busybox.net/pipermail/buildroot/2015-January/117057.html
Reported-by: Richard Fergusson <fergie4000@gmail.com>
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
Since the move to the kconfig-package infra, linux extensions are
broken.
In our linux package, extensions are applied as pre-patch hooks.
Before the kconfig-package infra, we had custom rules for the
linux-*config targets, which were of the form:
linux-menuconfig: linux-configure
$(MAKE) -C $(LINUX_DIR) menuconfig
This caused the linux tree to be fully configured before running the
configurators, and thus linux dependencies were entirely fullfilled, and
extensions were properly applied.
Since we migrated (in dff25ea), the kconfig-package infra introduces a
(hidden, internal) intermediate step 'kconfig-fixup' and decorelates the
kconfig-part of the configuration from the actual package-part of the
configuration:
linux-configure -------> kconfig-fixup --> .config --> $(LINUX_CONFIG_FILE)
/
linux-menuconfig --'
As thus, this (very useful!) use-case breaks (starting from a clean
Buildroot tree):
make menuconfig
-> enable a kernel and at least one extension
-> save and exit
make linux-menuconfig
-> extensions are not available
Fix that by using the newly-introduced patch-dependencies, so that
extensions are available before we try to patch the linux kernel.
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>
[Thomas: fix issues noticed by Arnout:
- Rewrap the linux/Config.in paragraph
- Revert the "is a toolchain dependency" -> "has a toolchain
dependency" change from pkg-generic.mk, as the original was
correct.]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.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>
Reword the help text and get ride of the supported kernel
version list which is outdated since Xenomai version bump.
[Thomas: rewrap text to the appropriate length, fix some typos.]
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
Since BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE can either be a complete
.config file or a defconfig file, it can be confusing to the user
whether to choose BR2_LINUX_KERNEL_USE_DEFCONFIG or
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG.
To avoid that confusion, clarify Kconfig entry messages for in-tree
defconfig and custom (def)config files.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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>
When Buildroot is configured to append the root filesystem to the Linux
kernel as initramfs, Buildroot sets the path to the initramfs source
dynamically in the Linux configuration file.
As this path is specified as an absolute path, typically being different
for different users of the same project (e.g. containing a username),
saving the configuration to a version control system (for example using
'make linux-update-defconfig') would result in a difference for this
path at every invocation by a different user.
Although this is technically not an issue, it is confusing that this
generates a difference.
Address this issue by using a not-yet-expanded make variable to specify
the path to the initramfs source. That variable will be expanded by the
Linux build system, which uses it both as a Makefile variable and a
shell variable; thus, it needs to be specified in LINUX_MAKE_ENV (so
it is exported and available in sub-processes of make). Any saved
configuration file would simply contain the reference to the
not-yet-expanded variable.
As in the Linux build system, the config variables are both read from
make as from a shell script, we cannot use $() syntax as this would be
interpreted as a command invocation by the shell. Instead, use ${}
syntax which is interpreted as variable reference both by the shell as
by make.
[Thomas:
- Really make the patch work by using $(LINUX_MAKE_ENV) instead of
$(TARGET_MAKE_ENV). Otherwise, the new BR2_BINARIES_DIR variable is
not passed at all stages of the build process, which makes the
build fail when an initramfs is used.]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Migrate the linux package to the kconfig infrastructure.
A notable change compared to the original behavior:
- the targets linux-update-(def)config are now always saving the config
file, even for a defconfig bundled in the linux sources. This is done
to keep the kconfig infrastructure simple.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Even though this is not strictly necessary with the current version of
linux.mk, it becomes necessary when migrating linux.mk to the kconfig
infrastructure.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
