buildroot/linux/linux.mk, branch 2016.11

linux/tools: make it a real, separate package

2016-09-22T10:32:34+00:00

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. : 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" Cc: Thomas Petazzoni Cc: Paul Ashford [Thomas: - fix typo #(@D) -> $(@D) - fix the inclusion of the per-tool .mk files.] Signed-off-by: Thomas Petazzoni

linux: use INSTALL_MOD_STRIP=1 to strip modules

2016-09-19T17:29:02+00:00

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 Cc: Vineet Gupta Cc: Peter Korsgaard Cc: Thomas Petazzoni Cc: Daniel Mentz Signed-off-by: Thomas Petazzoni

Revert "Added local directory as source of kernel code"

2016-08-28T21:55:30+00:00

This reverts commit 73da2ff6f718f2889e3c5024d899f8d58f502863. 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" Cc: Rafal Fabich Cc: Peter Korsgaard Cc: Arnout Vandecappelle Cc: Thomas Petazzoni Cc: Adam Duskett Signed-off-by: Peter Korsgaard

linux: allow the selection of the architecture's default configuration

2016-06-18T13:05:15+00:00

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 Signed-off-by: Thomas Petazzoni Acked-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

linux: align endianess based on the Buildroot configuration

2016-06-11T14:19:30+00:00

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 [Thomas: tweak commit message, add comment in .mk file.] Signed-off-by: Thomas Petazzoni

linux: use the generic help rules

2016-06-07T20:10:20+00:00

Signed-off-by: "Yann E. MORIN" Cc: Arnout Vandecappelle Cc: Thomas Petazzoni [Thomas: don't use the helper.] Signed-off-by: Thomas Petazzoni

linux: provide symlink dtc->linux-dtc is there is no dtc yet

2016-05-31T20:40:34+00:00

Commit ab74e09eb4e28dab8bed8d783c5f0464d39a32e7 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 Signed-off-by: Thomas De Schampheleire Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

linux: properly install all images in the initramfs case

2016-04-25T19:40:47+00:00

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 055e6162bba7 ("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: 055e6162bba7 ("linux: don't build appended DTB image in place and support multiple images") Signed-off-by: Sebastian Frias Tested-by: Thomas Petazzoni Signed-off-by: Thomas Petazzoni

linux: Add custom Subversion repository support for the package

2016-04-05T20:28:09+00:00

Signed-off-by: Pauli Sundberg Signed-off-by: Peter Korsgaard

linux: add conditional patch for timeconst.pl

2016-02-10T07:12:57+00:00

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 Signed-off-by: Peter Korsgaard