2013-06-07 12:13:46 +02:00
|
|
|
################################################################################
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
#
|
2011-07-11 22:46:07 +02:00
|
|
|
# Linux kernel target
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
#
|
2013-06-07 12:13:46 +02:00
|
|
|
################################################################################
|
2013-06-06 01:53:25 +02:00
|
|
|
|
2013-07-20 08:52:43 +02:00
|
|
|
LINUX_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
|
2017-03-30 15:43:32 +02:00
|
|
|
LINUX_LICENSE = GPL-2.0
|
2012-05-17 19:33:09 +02:00
|
|
|
LINUX_LICENSE_FILES = COPYING
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
|
2016-06-04 18:30:51 +02:00
|
|
|
define LINUX_HELP_CMDS
|
|
|
|
|
@echo ' linux-menuconfig - Run Linux kernel menuconfig'
|
|
|
|
|
@echo ' linux-savedefconfig - Run Linux kernel savedefconfig'
|
|
|
|
|
@echo ' linux-update-defconfig - Save the Linux configuration to the path specified'
|
|
|
|
|
@echo ' by BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE'
|
|
|
|
|
endef
|
|
|
|
|
|
2011-07-11 22:46:07 +02:00
|
|
|
# Compute LINUX_SOURCE and LINUX_SITE from the configuration
|
2013-02-23 19:03:30 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_CUSTOM_TARBALL),y)
|
2011-07-11 22:46:08 +02:00
|
|
|
LINUX_TARBALL = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION))
|
2013-01-09 13:12:44 +01:00
|
|
|
LINUX_SITE = $(patsubst %/,%,$(dir $(LINUX_TARBALL)))
|
2011-07-11 22:46:08 +02:00
|
|
|
LINUX_SOURCE = $(notdir $(LINUX_TARBALL))
|
2011-07-11 22:46:11 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_GIT),y)
|
2013-09-02 22:07:54 +02:00
|
|
|
LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL))
|
2011-07-11 22:46:11 +02:00
|
|
|
LINUX_SITE_METHOD = git
|
2013-09-02 22:07:54 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_HG),y)
|
|
|
|
|
LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL))
|
|
|
|
|
LINUX_SITE_METHOD = hg
|
2016-03-29 19:22:58 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_SVN),y)
|
|
|
|
|
LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL))
|
|
|
|
|
LINUX_SITE_METHOD = svn
|
2017-04-06 18:58:25 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_LATEST_CIP_VERSION),y)
|
|
|
|
|
LINUX_SITE = git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-cip.git
|
2017-08-11 05:50:35 +02:00
|
|
|
else ifneq ($(findstring -rc,$(LINUX_VERSION)),)
|
|
|
|
|
# Since 4.12-rc1, -rc kernels are generated from cgit. This also works for
|
|
|
|
|
# older -rc kernels.
|
|
|
|
|
LINUX_SITE = https://git.kernel.org/torvalds/t
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
else
|
2013-05-11 03:40:36 +02:00
|
|
|
LINUX_SOURCE = linux-$(LINUX_VERSION).tar.xz
|
2011-07-11 22:46:16 +02:00
|
|
|
# In X.Y.Z, get X and Y. We replace dots and dashes by spaces in order
|
2015-02-24 14:40:46 +01:00
|
|
|
# to use the $(word) function. We support versions such as 4.0, 3.1,
|
2011-07-11 22:46:16 +02:00
|
|
|
# 2.6.32, 2.6.32-rc1, 3.0-rc6, etc.
|
2011-10-24 16:54:03 +02:00
|
|
|
ifeq ($(findstring x2.6.,x$(LINUX_VERSION)),x2.6.)
|
2014-07-31 10:46:58 +02:00
|
|
|
LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v2.6
|
2015-02-24 14:40:46 +01:00
|
|
|
else ifeq ($(findstring x3.,x$(LINUX_VERSION)),x3.)
|
2014-07-31 10:46:58 +02:00
|
|
|
LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v3.x
|
2015-02-24 14:40:46 +01:00
|
|
|
else ifeq ($(findstring x4.,x$(LINUX_VERSION)),x4.)
|
|
|
|
|
LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v4.x
|
2011-10-24 16:54:03 +02:00
|
|
|
endif
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
endif
|
|
|
|
|
|
2017-03-21 01:07:05 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL)$(BR2_LINUX_KERNEL_LATEST_VERSION),y)
|
|
|
|
|
BR_NO_CHECK_HASH_FOR += $(LINUX_SOURCE)
|
|
|
|
|
endif
|
|
|
|
|
|
2011-07-11 22:46:08 +02:00
|
|
|
LINUX_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH))
|
|
|
|
|
|
linux: use the package infrastructure to download patches
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>
2015-03-29 19:33:15 +02:00
|
|
|
# We rely on the generic package infrastructure to download and apply
|
|
|
|
|
# remote patches (downloaded from ftp, http or https). For local
|
|
|
|
|
# patches, we can't rely on that infrastructure, because there might
|
|
|
|
|
# be directories in the patch list (unlike for other packages).
|
|
|
|
|
LINUX_PATCH = $(filter ftp://% http://% https://%,$(LINUX_PATCHES))
|
|
|
|
|
|
2011-07-11 22:46:08 +02:00
|
|
|
LINUX_INSTALL_IMAGES = YES
|
2018-08-17 18:06:47 +02:00
|
|
|
LINUX_DEPENDENCIES = host-kmod
|
|
|
|
|
|
2018-08-17 18:06:50 +02:00
|
|
|
# Starting with 4.16, the generated kconfig paser code is no longer
|
|
|
|
|
# shipped with the kernel sources, so we need flex and bison, but
|
|
|
|
|
# only if the host does not have them.
|
|
|
|
|
LINUX_KCONFIG_DEPENDENCIES = \
|
|
|
|
|
$(BR2_BISON_HOST_DEPENDENCY) \
|
|
|
|
|
$(BR2_FLEX_HOST_DEPENDENCY)
|
|
|
|
|
|
2018-08-17 18:06:52 +02:00
|
|
|
# Starting with 4.18, the kconfig in the kernel calls the
|
|
|
|
|
# cross-compiler to check its capabilities. So we need the
|
|
|
|
|
# toolchain before we can call the configurators.
|
|
|
|
|
LINUX_KCONFIG_DEPENDENCIES += toolchain
|
|
|
|
|
|
2015-07-12 13:43:32 +02:00
|
|
|
# host tools needed for kernel compression
|
|
|
|
|
ifeq ($(BR2_LINUX_KERNEL_LZ4),y)
|
|
|
|
|
LINUX_DEPENDENCIES += host-lz4
|
|
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_LZMA),y)
|
|
|
|
|
LINUX_DEPENDENCIES += host-lzma
|
|
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_LZO),y)
|
|
|
|
|
LINUX_DEPENDENCIES += host-lzop
|
|
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_XZ),y)
|
|
|
|
|
LINUX_DEPENDENCIES += host-xz
|
|
|
|
|
endif
|
2017-10-19 12:59:17 +02:00
|
|
|
LINUX_COMPRESSION_OPT_$(BR2_LINUX_KERNEL_GZIP) += CONFIG_KERNEL_GZIP
|
|
|
|
|
LINUX_COMPRESSION_OPT_$(BR2_LINUX_KERNEL_LZ4) += CONFIG_KERNEL_LZ4
|
|
|
|
|
LINUX_COMPRESSION_OPT_$(BR2_LINUX_KERNEL_LZMA) += CONFIG_KERNEL_LZMA
|
|
|
|
|
LINUX_COMPRESSION_OPT_$(BR2_LINUX_KERNEL_LZO) += CONFIG_KERNEL_LZO
|
|
|
|
|
LINUX_COMPRESSION_OPT_$(BR2_LINUX_KERNEL_XZ) += CONFIG_KERNEL_XZ
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
|
2018-03-04 22:31:15 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL),y)
|
|
|
|
|
LINUX_DEPENDENCIES += host-openssl
|
|
|
|
|
endif
|
|
|
|
|
|
2018-03-04 22:31:16 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF),y)
|
|
|
|
|
LINUX_DEPENDENCIES += host-elfutils
|
|
|
|
|
endif
|
|
|
|
|
|
linux: select BR2_PACKAGE_HOST_UBOOT_TOOLS instead of BR2_LINUX_KERNEL_UBOOT_IMAGE
A long time ago, the blind config option BR2_LINUX_KERNEL_UBOOT_IMAGE
was introduced to be able to trigger the linux -> host-uboot-tools
dependency. Back in those days, there was no user-configurable
BR2_PACKAGE_HOST_UBOOT_TOOLS.
Now, however, it is possible to select a custom kernel image name that
needs uboot-tools, and manually enable BR2_PACKAGE_HOST_UBOOT_TOOLS. In
this case, however, the linux -> host-uboot-tools is missed and the
build is not reproducible. An example of such a situation is the
upcoming CI40 defconfig.
As a solution, remove BR2_LINUX_KERNEL_UBOOT_IMAGE entirely. Instead,
just select BR2_PACKAGE_HOST_UBOOT_TOOLS and add the dependency if it
is selected.
Note that this may introduce a redundant dependency in case the user
selected BR2_PACKAGE_HOST_UBOOT_TOOLS for some other reason (e.g. to
be able to generate a U-Boot environment to include in the image, while
the kernel is built as a zImage). However, the redundant dependency
shouldn't hurt much.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Abhimanyu Vishwakarma <abhimanyu.v@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-04-10 18:05:11 +02:00
|
|
|
# If host-uboot-tools is selected by the user, assume it is needed to
|
|
|
|
|
# create a custom image
|
|
|
|
|
ifeq ($(BR2_PACKAGE_HOST_UBOOT_TOOLS),y)
|
2015-03-31 09:21:57 +02:00
|
|
|
LINUX_DEPENDENCIES += host-uboot-tools
|
2012-07-30 14:32:46 +02:00
|
|
|
endif
|
|
|
|
|
|
2017-07-09 14:22:00 +02:00
|
|
|
ifneq ($(ARCH_XTENSA_OVERLAY_FILE),)
|
|
|
|
|
define LINUX_XTENSA_OVERLAY_EXTRACT
|
|
|
|
|
$(call arch-xtensa-overlay-extract,$(@D),linux)
|
|
|
|
|
endef
|
|
|
|
|
LINUX_POST_EXTRACT_HOOKS += LINUX_XTENSA_OVERLAY_EXTRACT
|
|
|
|
|
LINUX_EXTRA_DOWNLOADS += $(ARCH_XTENSA_OVERLAY_URL)
|
|
|
|
|
endif
|
|
|
|
|
|
2011-07-11 22:46:07 +02:00
|
|
|
LINUX_MAKE_FLAGS = \
|
2018-03-04 22:31:17 +01:00
|
|
|
HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" \
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
ARCH=$(KERNEL_ARCH) \
|
|
|
|
|
INSTALL_MOD_PATH=$(TARGET_DIR) \
|
2015-10-04 14:28:48 +02:00
|
|
|
CROSS_COMPILE="$(TARGET_CROSS)" \
|
2013-09-10 21:54:59 +02:00
|
|
|
DEPMOD=$(HOST_DIR)/sbin/depmod
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
|
linux: avoid unnecessary changes in defconfig for INITRAMFS_SOURCE
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>
2015-02-03 15:21:48 +01:00
|
|
|
LINUX_MAKE_ENV = \
|
|
|
|
|
$(TARGET_MAKE_ENV) \
|
|
|
|
|
BR_BINARIES_DIR=$(BINARIES_DIR)
|
2015-02-03 15:21:47 +01:00
|
|
|
|
2016-11-23 13:58:44 +01:00
|
|
|
ifeq ($(BR2_REPRODUCIBLE),y)
|
|
|
|
|
LINUX_MAKE_ENV += \
|
|
|
|
|
KBUILD_BUILD_VERSION=1 \
|
|
|
|
|
KBUILD_BUILD_USER=buildroot \
|
|
|
|
|
KBUILD_BUILD_HOST=buildroot \
|
2016-12-07 16:20:42 +01:00
|
|
|
KBUILD_BUILD_TIMESTAMP="$(shell LC_ALL=C date -d @$(SOURCE_DATE_EPOCH))"
|
2016-11-23 13:58:44 +01:00
|
|
|
endif
|
|
|
|
|
|
2018-06-02 16:34:07 +02:00
|
|
|
# gcc-8 started warning about function aliases that have a
|
|
|
|
|
# non-matching prototype. This seems rather useful in general, but it
|
|
|
|
|
# causes tons of warnings in the Linux kernel, where we rely on
|
|
|
|
|
# abusing those aliases for system call entry points, in order to
|
|
|
|
|
# sanitize the arguments passed from user space in registers.
|
|
|
|
|
# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82435
|
|
|
|
|
ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_8),y)
|
|
|
|
|
LINUX_MAKE_ENV += KCFLAGS=-Wno-attribute-alias
|
|
|
|
|
endif
|
|
|
|
|
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
# Get the real Linux version, which tells us where kernel modules are
|
|
|
|
|
# going to be installed in the target filesystem.
|
2015-07-22 16:58:53 +02:00
|
|
|
LINUX_VERSION_PROBED = `$(MAKE) $(LINUX_MAKE_FLAGS) -C $(LINUX_DIR) --no-print-directory -s kernelrelease 2>/dev/null`
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
|
2018-04-01 07:08:24 +02:00
|
|
|
LINUX_DTS_NAME += $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTS_NAME))
|
2018-02-21 20:53:16 +01:00
|
|
|
|
2015-03-01 15:51:44 +01:00
|
|
|
# We keep only the .dts files, so that the user can specify both .dts
|
|
|
|
|
# and .dtsi files in BR2_LINUX_KERNEL_CUSTOM_DTS_PATH. Both will be
|
|
|
|
|
# copied to arch/<arch>/boot/dts, but only the .dts files will
|
|
|
|
|
# actually be generated as .dtb.
|
2018-04-01 07:08:24 +02:00
|
|
|
LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)))))
|
2012-07-30 14:32:45 +02:00
|
|
|
|
2018-04-01 07:08:24 +02:00
|
|
|
LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME))
|
2012-12-21 08:39:14 +01:00
|
|
|
|
2011-03-21 18:39:43 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM),y)
|
2014-07-11 14:49:22 +02:00
|
|
|
LINUX_IMAGE_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_IMAGE_NAME))
|
|
|
|
|
LINUX_TARGET_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_IMAGE_TARGET_NAME))
|
2014-12-24 14:54:55 +01:00
|
|
|
ifeq ($(LINUX_IMAGE_NAME),)
|
2014-12-15 22:19:10 +01:00
|
|
|
LINUX_IMAGE_NAME = $(LINUX_TARGET_NAME)
|
2014-12-24 14:54:55 +01:00
|
|
|
endif
|
2011-03-21 18:39:43 +01:00
|
|
|
else
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_UIMAGE),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_NAME = uImage
|
2012-07-30 14:32:47 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_APPENDED_UIMAGE),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_NAME = uImage
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_BZIMAGE),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_NAME = bzImage
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_ZIMAGE),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_NAME = zImage
|
2015-10-29 13:52:05 +01:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_ZIMAGE_EPAPR),y)
|
|
|
|
|
LINUX_IMAGE_NAME = zImage.epapr
|
2012-07-30 14:32:47 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_APPENDED_ZIMAGE),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_NAME = zImage
|
2012-07-30 14:32:48 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_CUIMAGE),y)
|
2018-05-06 08:34:18 +02:00
|
|
|
LINUX_IMAGE_NAME = cuImage.$(firstword $(LINUX_DTS_NAME))
|
2012-07-30 14:32:48 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_SIMPLEIMAGE),y)
|
2018-05-06 08:34:18 +02:00
|
|
|
LINUX_IMAGE_NAME = simpleImage.$(firstword $(LINUX_DTS_NAME))
|
2015-10-04 18:28:15 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_IMAGE),y)
|
|
|
|
|
LINUX_IMAGE_NAME = Image
|
2012-07-30 14:32:48 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_LINUX_BIN),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_NAME = linux.bin
|
2010-09-01 15:26:24 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_VMLINUX_BIN),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_NAME = vmlinux.bin
|
2010-12-05 21:53:23 +01:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_VMLINUX),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_NAME = vmlinux
|
2011-09-20 11:01:26 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_VMLINUZ),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_NAME = vmlinuz
|
2015-12-15 08:34:06 +01:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_VMLINUZ_BIN),y)
|
|
|
|
|
LINUX_IMAGE_NAME = vmlinuz.bin
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
endif
|
2014-12-15 22:19:10 +01:00
|
|
|
# The if-else blocks above are all the image types we know of, and all
|
|
|
|
|
# come from a Kconfig choice, so we know we have LINUX_IMAGE_NAME set
|
|
|
|
|
# to something
|
2014-07-17 21:55:08 +02:00
|
|
|
LINUX_TARGET_NAME = $(LINUX_IMAGE_NAME)
|
2011-03-21 18:39:43 +01:00
|
|
|
endif
|
2014-07-17 21:55:08 +02:00
|
|
|
|
.mk files: bulk aligment and whitespace cleanup of assignments
The Buildroot coding style defines one space around make assignments and
does not align the assignment symbols.
This patch does a bulk fix of offending packages. The package
infrastructures (or more in general assignments to calculated variable
names, like $(2)_FOO) are not touched.
Alignment of line continuation characters (\) is kept as-is.
The sed command used to do this replacement is:
find * -name "*.mk" | xargs sed -i \
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*$#\1 \2#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\]\+\)$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\ \t]\+\s*\\\)\s*$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\(\s*\\\)#\1 \2\3#'
Brief explanation of this command:
^\([A-Z0-9a-z_]\+\) a regular variable at the beginning of the line
\([?:+]\?=\) any assignment character =, :=, ?=, +=
\([^\\]\+\) any string not containing a line continuation
\([^\\ \t]\+\s*\\\) string, optional whitespace, followed by a
line continuation character
\(\s*\\\) optional whitespace, followed by a line
continuation character
Hence, the first subexpression handles empty assignments, the second
handles regular assignments, the third handles regular assignments with
line continuation, and the fourth empty assignments with line
continuation.
This expression was tested on following test text: (initial tab not
included)
FOO = spaces before
FOO = spaces before and after
FOO = tab before
FOO = tab and spaces before
FOO = tab after
FOO = tab and spaces after
FOO = spaces and tab after
FOO = \
FOO = bar \
FOO = bar space \
FOO = \
GENIMAGE_DEPENDENCIES = host-pkgconf libconfuse
FOO += spaces before
FOO ?= spaces before and after
FOO :=
FOO =
FOO =
FOO =
FOO =
$(MAKE1) CROSS_COMPILE=$(TARGET_CROSS) -C
AT91BOOTSTRAP3_DEFCONFIG = \
AXEL_DISABLE_I18N=--i18n=0
After this bulk change, following manual fixups were done:
- fix line continuation alignment in cegui06 and spice (the sed
expression leaves the number of whitespace between the value and line
continuation character intact, but the whitespace before that could have
changed, causing misalignment.
- qt5base was reverted, as this package uses extensive alignment which
actually makes the code more readable.
Finally, the end result was manually reviewed.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Yann E. Morin <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-07 09:06:03 +02:00
|
|
|
LINUX_KERNEL_UIMAGE_LOADADDR = $(call qstrip,$(BR2_LINUX_KERNEL_UIMAGE_LOADADDR))
|
2013-03-13 12:13:24 +01:00
|
|
|
ifneq ($(LINUX_KERNEL_UIMAGE_LOADADDR),)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_MAKE_FLAGS += LOADADDR="$(LINUX_KERNEL_UIMAGE_LOADADDR)"
|
2013-03-13 12:13:24 +01:00
|
|
|
endif
|
|
|
|
|
|
2010-12-05 21:53:26 +01:00
|
|
|
# Compute the arch path, since i386 and x86_64 are in arch/x86 and not
|
|
|
|
|
# in arch/$(KERNEL_ARCH). Even if the kernel creates symbolic links
|
|
|
|
|
# for bzImage, arch/i386 and arch/x86_64 do not exist when copying the
|
|
|
|
|
# defconfig file.
|
|
|
|
|
ifeq ($(KERNEL_ARCH),i386)
|
2018-04-01 07:08:24 +02:00
|
|
|
LINUX_ARCH_PATH = $(LINUX_DIR)/arch/x86
|
2010-12-05 21:53:26 +01:00
|
|
|
else ifeq ($(KERNEL_ARCH),x86_64)
|
2018-04-01 07:08:24 +02:00
|
|
|
LINUX_ARCH_PATH = $(LINUX_DIR)/arch/x86
|
2010-12-05 21:53:26 +01:00
|
|
|
else
|
2018-04-01 07:08:24 +02:00
|
|
|
LINUX_ARCH_PATH = $(LINUX_DIR)/arch/$(KERNEL_ARCH)
|
2010-12-05 21:53:26 +01:00
|
|
|
endif
|
|
|
|
|
|
2010-12-05 21:53:23 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_VMLINUX),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_PATH = $(LINUX_DIR)/$(LINUX_IMAGE_NAME)
|
2011-09-20 11:01:26 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_VMLINUZ),y)
|
2014-03-06 10:42:28 +01:00
|
|
|
LINUX_IMAGE_PATH = $(LINUX_DIR)/$(LINUX_IMAGE_NAME)
|
2015-12-15 08:34:06 +01:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_VMLINUZ_BIN),y)
|
|
|
|
|
LINUX_IMAGE_PATH = $(LINUX_DIR)/$(LINUX_IMAGE_NAME)
|
2010-12-05 21:53:23 +01:00
|
|
|
else
|
2018-04-01 07:08:24 +02:00
|
|
|
LINUX_IMAGE_PATH = $(LINUX_ARCH_PATH)/boot/$(LINUX_IMAGE_NAME)
|
2010-12-05 21:53:23 +01:00
|
|
|
endif # BR2_LINUX_KERNEL_VMLINUX
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
|
linux: use the package infrastructure to download patches
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>
2015-03-29 19:33:15 +02:00
|
|
|
define LINUX_APPLY_LOCAL_PATCHES
|
|
|
|
|
for p in $(filter-out ftp://% http://% https://%,$(LINUX_PATCHES)) ; do \
|
|
|
|
|
if test -d $$p ; then \
|
2015-03-29 19:33:22 +02:00
|
|
|
$(APPLY_PATCHES) $(@D) $$p \*.patch || exit 1 ; \
|
2010-12-05 21:53:18 +01:00
|
|
|
else \
|
2015-03-16 10:57:17 +01:00
|
|
|
$(APPLY_PATCHES) $(@D) `dirname $$p` `basename $$p` || exit 1; \
|
2010-12-05 21:53:18 +01:00
|
|
|
fi \
|
|
|
|
|
done
|
2011-07-11 22:46:08 +02:00
|
|
|
endef
|
|
|
|
|
|
linux: use the package infrastructure to download patches
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>
2015-03-29 19:33:15 +02:00
|
|
|
LINUX_POST_PATCH_HOOKS += LINUX_APPLY_LOCAL_PATCHES
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
|
2016-02-07 14:41:48 +01:00
|
|
|
# Older linux kernels use deprecated perl constructs in timeconst.pl
|
|
|
|
|
# that were removed for perl 5.22+ so it breaks on newer distributions
|
|
|
|
|
# Try a dry-run patch to see if this applies, if it does go ahead
|
|
|
|
|
define LINUX_TRY_PATCH_TIMECONST
|
|
|
|
|
@if patch -p1 --dry-run -f -s -d $(@D) <$(LINUX_PKGDIR)/0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional >/dev/null ; then \
|
|
|
|
|
$(APPLY_PATCHES) $(@D) $(LINUX_PKGDIR) 0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional ; \
|
|
|
|
|
fi
|
|
|
|
|
endef
|
|
|
|
|
LINUX_POST_PATCH_HOOKS += LINUX_TRY_PATCH_TIMECONST
|
|
|
|
|
|
2018-08-24 15:44:58 +02:00
|
|
|
LINUX_KERNEL_CUSTOM_LOGO_PATH = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_LOGO_PATH))
|
|
|
|
|
ifneq ($(LINUX_KERNEL_CUSTOM_LOGO_PATH),)
|
|
|
|
|
LINUX_DEPENDENCIES += host-imagemagick
|
|
|
|
|
define LINUX_KERNEL_CUSTOM_LOGO_CONVERT
|
|
|
|
|
$(HOST_DIR)/bin/convert $(LINUX_KERNEL_CUSTOM_LOGO_PATH) \
|
|
|
|
|
-dither None -colors 224 -compress none \
|
|
|
|
|
$(LINUX_DIR)/drivers/video/logo/logo_linux_clut224.ppm
|
|
|
|
|
endef
|
|
|
|
|
LINUX_PRE_BUILD_HOOKS += LINUX_KERNEL_CUSTOM_LOGO_CONVERT
|
|
|
|
|
endif
|
|
|
|
|
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
|
2015-12-22 22:22:02 +01:00
|
|
|
LINUX_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfig
|
linux: allow the selection of the architecture's default configuration
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>
2016-06-14 12:19:58 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG),y)
|
|
|
|
|
LINUX_KCONFIG_DEFCONFIG = defconfig
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG),y)
|
2015-12-22 22:22:02 +01:00
|
|
|
LINUX_KCONFIG_FILE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE))
|
2011-07-11 22:46:08 +02:00
|
|
|
endif
|
2015-04-28 16:34:32 +02:00
|
|
|
LINUX_KCONFIG_FRAGMENT_FILES = $(call qstrip,$(BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES))
|
2015-02-03 15:21:47 +01:00
|
|
|
LINUX_KCONFIG_EDITORS = menuconfig xconfig gconfig nconfig
|
linux: don't override HOSTCC for kconfig
Kconfig uses either pkg-config or hard-coded /usr/include paths to find
the ncurses or ncursesw library. If ncursesw is found, it will include
<ncursesw.h>. Since Buildroot's host-ncurses doesn't install a .pc file,
and linux.mk anyway doesn't pass the pkg-config options to find the host
pkg-config files, Kconfig will always find the system's ncursesw.h.
However, since commit dde090c299 (linux: fix passing of host CFLAGS and
LDFLAGS) HOST_LDFLAGS is passed to the linux build system. Thus, if
host-ncurses was already built before 'make linux-menuconfig' is called,
the build will pick up libncurses from the host directory, which is NOT
widechar. Thus, two different ncurses configurations are mixed into the
final mconf program. This will result in serious breakage in the
rendering of the menus (lots of @ and question mark characters).
As a workaround (suggested by Yann), don't pass HOST_CFLAGS and
HOST_LDFLAGS when running kconfig commands. For kconfig, we should never
need host packages anyway. This way, the kconfig calls will always use
the system's ncurses and never our host-ncurses.
Note that the same problem could pop up for other kconfig packages as
well if we ever pass HOST_CFLAGS/HOST_LDFLAGS to them. We could force
HOSTCC=$(HOSTCC) directly in kconfig-package. However, for now there
are no other packages that exhibit this problem, so this can be
revisited when they do.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: David De Grave <david.degrave@essensium.com>
Cc: Scott Fan <fancp2007@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Tested-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-17 14:39:21 +02:00
|
|
|
|
|
|
|
|
# LINUX_MAKE_FLAGS overrides HOSTCC to allow the kernel build to find our
|
|
|
|
|
# host-openssl and host-libelf. However, this triggers a bug in the kconfig
|
|
|
|
|
# build script that causes it to build with /usr/include/ncurses.h (which is
|
|
|
|
|
# typically wchar) but link with $(HOST_DIR)/lib/libncurses.so (which is not).
|
|
|
|
|
# We don't actually need any host-package for kconfig, so remove the HOSTCC
|
|
|
|
|
# override again.
|
|
|
|
|
LINUX_KCONFIG_OPTS = $(LINUX_MAKE_FLAGS) HOSTCC="$(HOSTCC)"
|
2015-02-03 15:21:47 +01:00
|
|
|
|
linux: add blind kconfig option to require kernel modules
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>
2015-12-10 19:53:13 +01:00
|
|
|
# If no package has yet set it, set it from the Kconfig option
|
|
|
|
|
LINUX_NEEDS_MODULES ?= $(BR2_LINUX_NEEDS_MODULES)
|
|
|
|
|
|
2016-05-19 15:17:03 +02:00
|
|
|
# Make sure the Linux kernel is built with the right endianness. Not
|
|
|
|
|
# all architectures support
|
|
|
|
|
# CONFIG_CPU_BIG_ENDIAN/CONFIG_CPU_LITTLE_ENDIAN in Linux, but the
|
|
|
|
|
# option will be thrown away and ignored if it doesn't exist.
|
|
|
|
|
ifeq ($(BR2_ENDIAN),"BIG")
|
|
|
|
|
define LINUX_FIXUP_CONFIG_ENDIANNESS
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_CPU_BIG_ENDIAN,$(@D)/.config)
|
|
|
|
|
endef
|
|
|
|
|
else
|
|
|
|
|
define LINUX_FIXUP_CONFIG_ENDIANNESS
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_CPU_LITTLE_ENDIAN,$(@D)/.config)
|
|
|
|
|
endef
|
|
|
|
|
endif
|
|
|
|
|
|
2015-02-03 15:21:47 +01:00
|
|
|
define LINUX_KCONFIG_FIXUP_CMDS
|
2015-09-03 14:54:19 +02:00
|
|
|
$(if $(LINUX_NEEDS_MODULES),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_MODULES,$(@D)/.config))
|
2017-10-19 12:59:17 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,$(strip $(LINUX_COMPRESSION_OPT_y)),$(@D)/.config)
|
2015-07-12 13:43:32 +02:00
|
|
|
$(foreach opt, $(LINUX_COMPRESSION_OPT_),
|
|
|
|
|
$(call KCONFIG_DISABLE_OPT,$(opt),$(@D)/.config)
|
|
|
|
|
)
|
2016-05-19 15:17:03 +02:00
|
|
|
$(LINUX_FIXUP_CONFIG_ENDIANNESS)
|
2013-07-14 00:27:30 +02:00
|
|
|
$(if $(BR2_arm)$(BR2_armeb),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_AEABI,$(@D)/.config))
|
2013-12-29 18:33:45 +01:00
|
|
|
$(if $(BR2_TARGET_ROOTFS_CPIO),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_INITRD,$(@D)/.config))
|
linux: add support for initramfs
In Buildroot, the kernel is built and installed *before* the root
filesystems are built. This allows the root filesystem to correctly
contain the kernel modules that have been installed.
However, in the initramfs case, the root filesystem is part of the
kernel. Therefore, the kernel should be built *after* the root
filesystem (which, in the initramfs case simply builds a text file
listing all files/directories/devices/symlinks that should be part of
the initramfs). However, this isn't possible as the initramfs text
file would lack all kernel modules.
So, the solution choosen here is to keep the normal order: kernel is
built before the root filesystem is generated, and to add a little
quirk to retrigger a kernel compilation after the root filesystem
generation.
To do so, we add a ROOTFS_$(FSTYPE)_POST_TARGETS variable to the
fs/common.mk infrastructure. This allows individual filesystems to set
a target name that we should depend on *after* generating the root
filesystem itself (contrary to normal ROOTFS_$(FSTYPE)_DEPENDENCIES,
on which we depend *before* generating the root filesystem).
The initramfs code in fs/initramfs/initramfs.mk uses this to add a
dependency on 'linux26-rebuild-with-initramfs'.
In linux/linux.mk, we do various things :
* If BR2_TARGET_ROOTFS_INITRAMFS is enabled (i.e if initramfs is
enabled as a root filesystem type), then we create an empty
rootfs.initramfs file (remember that at this point, the root
filesystem hasn't been generated) and we adjust the kernel
configuration to include an initramfs. Of course, in the initial
kernel build, this initramfs will be empty.
* In the linux26-rebuild-with-initramfs target, we retrigger a
compilation of the kernel image, after removing the initramfs in
the kernel sources to make sure it gets properly rebuilt (we've
experienced cases were modifying the rootfs.initramfs file wouldn't
retrigger the generation of the initramfs at the kernel level).
This is fairly quirky, but initramfs really is a special case, so in
one way or another, we need a little quirk to solve its specialness.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-06-13 19:19:38 +02:00
|
|
|
# As the kernel gets compiled before root filesystems are
|
2011-09-06 23:16:09 +02:00
|
|
|
# built, we create a fake cpio file. It'll be
|
|
|
|
|
# replaced later by the real cpio archive, and the kernel will be
|
2014-07-24 19:49:34 +02:00
|
|
|
# rebuilt using the linux-rebuild-with-initramfs target.
|
2011-07-11 22:46:08 +02:00
|
|
|
$(if $(BR2_TARGET_ROOTFS_INITRAMFS),
|
linux: ensure images/ exist before creating files there
When using an initramfs, on the first-pass build, we create a dummy cpio
so that the build succeeeds. The real cpio will come later, and we'll do
a second-pass build to use the actual cpio.
However, when we touch that dummy cpio, the images/ directory may not
yet exist, since commit d0f4f95e39 (Makefile: rework main directory
creation logic) removed its creation at the begining of the build, to
only at the moment we need it, i.e. during the *_INSTALL_IMAGES_CMDS
steps.
However, the linux build is not a _INSTALL_IMAGES_CMDS step, so there is
no guarantee that images/ already exist at that time.
Fix that by explicitly creating images/ before touching the dummy cpio.
Reported-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-12-03 20:12:19 +01:00
|
|
|
mkdir -p $(BINARIES_DIR)
|
2011-09-06 23:16:09 +02:00
|
|
|
touch $(BINARIES_DIR)/rootfs.cpio
|
linux: avoid unnecessary changes in defconfig for INITRAMFS_SOURCE
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>
2015-02-03 15:21:48 +01:00
|
|
|
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_SOURCE,"$${BR_BINARIES_DIR}/rootfs.cpio",$(@D)/.config)
|
2011-07-11 22:46:08 +02:00
|
|
|
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_ROOT_UID,0,$(@D)/.config)
|
linux: Do not force GZIP initramfs compression
Initramfs compression does not make much sense for the architectures
that support compressed kernel images because in this case the data
would be compressed twice. This will eventually result in a bigger
kernel image and time overhead when uncompressing it.
The only reason to use compressed initramfs is to reduce memory
usage when the kernel prepares rootfs, and both the unpacked
filesystem and initramfs.cpio are present in the memory.
Buildroot attempts to force GZIP compression for initramfs,
however it doesn't always work because initramfs compression mode
depends on RAM disk compression supported by the kernel.
Thus, CONFIG_INITRAMFS_COMPRESSION_GZIP depends on CONFIG_RD_GZIP.
If CONFIG_RD_GZIP is not set, setting GZIP initramfs compression
will have no effect.
Besides, the kernel also supports other compression methods,
like BZIP2, LZMA, XZ and LZO. Forcing the good old GZIP does not
really make much sense any more.
This removes initramfs compression settings from Buildroot,
so that the default value preset in the kernel config is used,
which is CONFIG_INITRAMFS_COMPRESSION_NONE.
If initramfs compression is still needed, it can be set
in the kernel config (using make linux-menuconfig)
Signed-off-by: Valentine Barshak <gvaxon@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-10-10 01:34:56 +02:00
|
|
|
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_ROOT_GID,0,$(@D)/.config))
|
2011-07-11 22:46:08 +02:00
|
|
|
$(if $(BR2_ROOTFS_DEVICE_CREATION_STATIC),,
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS_MOUNT,$(@D)/.config))
|
2014-02-07 14:21:32 +01:00
|
|
|
$(if $(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_INOTIFY_USER,$(@D)/.config))
|
2018-11-03 17:42:43 +01:00
|
|
|
$(if $(BR2_PACKAGE_AUDIT),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_NET,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_AUDIT,$(@D)/.config))
|
2018-11-04 22:02:38 +01:00
|
|
|
$(if $(BR2_PACKAGE_INTEL_MICROCODE),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_MICROCODE,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_MICROCODE_INTEL,$(@D)/.config))
|
2013-12-16 11:53:20 +01:00
|
|
|
$(if $(BR2_PACKAGE_KTAP),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_DEBUG_FS,$(@D)/.config)
|
2015-02-22 14:39:00 +01:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_ENABLE_DEFAULT_TRACERS,$(@D)/.config)
|
2013-12-16 11:53:20 +01:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_PERF_EVENTS,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_FUNCTION_TRACER,$(@D)/.config))
|
2018-07-04 09:07:35 +02:00
|
|
|
$(if $(BR2_PACKAGE_LINUX_TOOLS_PERF),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_PERF_EVENTS,$(@D)/.config))
|
2012-03-23 16:49:53 +01:00
|
|
|
$(if $(BR2_PACKAGE_SYSTEMD),
|
2014-02-07 14:21:34 +01:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_CGROUPS,$(@D)/.config)
|
2014-02-24 10:25:42 +01:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_INOTIFY_USER,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_FHANDLE,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL,$(@D)/.config)
|
2017-06-04 11:48:39 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_XATTR,$(@D)/.config))
|
2014-04-20 20:54:03 +02:00
|
|
|
$(if $(BR2_PACKAGE_SMACK),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_SMACK,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_NETWORK,$(@D)/.config))
|
2018-02-15 14:57:52 +01:00
|
|
|
$(if $(BR2_PACKAGE_SUNXI_MALI_MAINLINE_DRIVER),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_CMA,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_DMA_CMA,$(@D)/.config))
|
2014-10-21 23:10:51 +02:00
|
|
|
$(if $(BR2_PACKAGE_IPTABLES),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_IP_NF_IPTABLES,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_IP_NF_FILTER,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER_XTABLES,$(@D)/.config))
|
2014-10-21 23:10:52 +02:00
|
|
|
$(if $(BR2_PACKAGE_XTABLES_ADDONS),
|
2015-08-21 23:58:29 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER_ADVANCED,$(@D)/.config)
|
2014-10-21 23:10:52 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_NF_CONNTRACK,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_NF_CONNTRACK_MARK,$(@D)/.config))
|
2017-09-06 22:30:06 +02:00
|
|
|
$(if $(BR2_PACKAGE_WIREGUARD),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_INET,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_NET,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_NET_FOU,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_CRYPTO,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_CRYPTO_MANAGER,$(@D)/.config))
|
2012-07-30 14:32:47 +02:00
|
|
|
$(if $(BR2_LINUX_KERNEL_APPENDED_DTB),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_ARM_APPENDED_DTB,$(@D)/.config))
|
2016-02-02 00:38:11 +01:00
|
|
|
$(if $(BR2_PACKAGE_KERNEL_MODULE_IMX_GPU_VIV),
|
|
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_MXC_GPU_VIV,$(@D)/.config))
|
2018-08-24 15:44:58 +02:00
|
|
|
$(if $(LINUX_KERNEL_CUSTOM_LOGO_PATH),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_FB,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_LOGO,$(@D)/.config)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_LOGO_LINUX_CLUT224,$(@D)/.config))
|
2011-07-11 22:46:08 +02:00
|
|
|
endef
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
|
2012-07-30 14:32:45 +02:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT),y)
|
2018-08-17 18:06:51 +02:00
|
|
|
# Starting with 4.17, the generated dtc parser code is no longer
|
|
|
|
|
# shipped with the kernel sources, so we need flex and bison. For
|
|
|
|
|
# reproducibility, we use our owns rather than the host ones.
|
|
|
|
|
LINUX_DEPENDENCIES += host-bison host-flex
|
|
|
|
|
|
2012-07-30 14:32:47 +02:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT),)
|
2012-07-30 14:32:45 +02:00
|
|
|
define LINUX_BUILD_DTB
|
2018-04-01 07:08:24 +02:00
|
|
|
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(LINUX_DTBS)
|
2012-07-30 14:32:45 +02:00
|
|
|
endef
|
2015-10-18 23:05:01 +02:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_APPENDED_DTB),)
|
2012-07-30 14:32:45 +02:00
|
|
|
define LINUX_INSTALL_DTB
|
2013-04-14 19:31:30 +02:00
|
|
|
# dtbs moved from arch/<ARCH>/boot to arch/<ARCH>/boot/dts since 3.8-rc1
|
2012-12-21 09:07:45 +01:00
|
|
|
cp $(addprefix \
|
2018-04-01 07:08:24 +02:00
|
|
|
$(LINUX_ARCH_PATH)/boot/$(if $(wildcard \
|
|
|
|
|
$(addprefix $(LINUX_ARCH_PATH)/boot/dts/,$(LINUX_DTBS))),dts/),$(LINUX_DTBS)) \
|
2015-10-18 23:05:00 +02:00
|
|
|
$(1)
|
2013-02-14 05:27:54 +01:00
|
|
|
endef
|
2015-10-18 23:05:01 +02:00
|
|
|
endif # BR2_LINUX_KERNEL_APPENDED_DTB
|
|
|
|
|
endif # BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT
|
|
|
|
|
endif # BR2_LINUX_KERNEL_DTS_SUPPORT
|
2012-07-30 14:32:47 +02:00
|
|
|
|
2013-01-08 12:23:56 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_APPENDED_DTB),y)
|
|
|
|
|
# dtbs moved from arch/$ARCH/boot to arch/$ARCH/boot/dts since 3.8-rc1
|
2012-07-30 14:32:47 +02:00
|
|
|
define LINUX_APPEND_DTB
|
2018-04-01 07:08:24 +02:00
|
|
|
(cd $(LINUX_ARCH_PATH)/boot; \
|
|
|
|
|
for dtb in $(LINUX_DTS_NAME); do \
|
linux: don't build appended DTB image in place and support multiple images
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>
2015-10-18 23:05:02 +02:00
|
|
|
if test -e $${dtb}.dtb ; then \
|
|
|
|
|
dtbpath=$${dtb}.dtb ; \
|
|
|
|
|
else \
|
|
|
|
|
dtbpath=dts/$${dtb}.dtb ; \
|
|
|
|
|
fi ; \
|
|
|
|
|
cat zImage $${dtbpath} > zImage.$${dtb} || exit 1; \
|
|
|
|
|
done)
|
2012-07-30 14:32:47 +02:00
|
|
|
endef
|
2013-01-08 12:23:56 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_APPENDED_UIMAGE),y)
|
2013-06-07 15:21:43 +02:00
|
|
|
# We need to generate a new u-boot image that takes into
|
|
|
|
|
# account the extra-size added by the device tree at the end
|
|
|
|
|
# of the image. To do so, we first need to retrieve both load
|
|
|
|
|
# address and entry point for the kernel from the already
|
|
|
|
|
# generate uboot image before using mkimage -l.
|
linux: don't build appended DTB image in place and support multiple images
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>
2015-10-18 23:05:02 +02:00
|
|
|
LINUX_APPEND_DTB += ; \
|
|
|
|
|
MKIMAGE_ARGS=`$(MKIMAGE) -l $(LINUX_IMAGE_PATH) |\
|
2014-10-25 20:29:31 +02:00
|
|
|
sed -n -e 's/Image Name:[ ]*\(.*\)/-n \1/p' -e 's/Load Address:/-a/p' -e 's/Entry Point:/-e/p'`; \
|
2018-04-01 07:08:24 +02:00
|
|
|
for dtb in $(LINUX_DTS_NAME); do \
|
linux: don't build appended DTB image in place and support multiple images
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>
2015-10-18 23:05:02 +02:00
|
|
|
$(MKIMAGE) -A $(MKIMAGE_ARCH) -O linux \
|
|
|
|
|
-T kernel -C none $${MKIMAGE_ARGS} \
|
2018-04-01 07:08:24 +02:00
|
|
|
-d $(LINUX_ARCH_PATH)/boot/zImage.$${dtb} $(LINUX_IMAGE_PATH).$${dtb}; \
|
linux: don't build appended DTB image in place and support multiple images
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>
2015-10-18 23:05:02 +02:00
|
|
|
done
|
2013-01-08 12:23:56 +01:00
|
|
|
endif
|
2012-07-30 14:32:47 +02:00
|
|
|
endif
|
2012-07-30 14:32:45 +02:00
|
|
|
|
2010-06-13 19:18:34 +02:00
|
|
|
# Compilation. We make sure the kernel gets rebuilt when the
|
|
|
|
|
# configuration has changed.
|
2011-07-11 22:46:08 +02:00
|
|
|
define LINUX_BUILD_CMDS
|
2018-08-16 22:45:23 +02:00
|
|
|
$(foreach dts,$(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)), \
|
|
|
|
|
cp -f $(dts) $(LINUX_ARCH_PATH)/boot/dts/
|
|
|
|
|
)
|
linux: avoid unnecessary changes in defconfig for INITRAMFS_SOURCE
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>
2015-02-03 15:21:48 +01:00
|
|
|
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(LINUX_TARGET_NAME)
|
2018-04-01 07:08:23 +02:00
|
|
|
@if grep -q "CONFIG_MODULES=y" $(@D)/.config; then \
|
|
|
|
|
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) modules ; \
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
fi
|
2012-07-30 14:32:45 +02:00
|
|
|
$(LINUX_BUILD_DTB)
|
2012-07-30 14:32:47 +02:00
|
|
|
$(LINUX_APPEND_DTB)
|
2011-07-11 22:46:08 +02:00
|
|
|
endef
|
|
|
|
|
|
linux: don't build appended DTB image in place and support multiple images
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>
2015-10-18 23:05:02 +02:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_APPENDED_DTB),y)
|
|
|
|
|
# When a DTB was appended, install the potential several images with
|
|
|
|
|
# appended DTBs.
|
|
|
|
|
define LINUX_INSTALL_IMAGE
|
|
|
|
|
mkdir -p $(1)
|
2018-04-01 07:08:24 +02:00
|
|
|
cp $(LINUX_ARCH_PATH)/boot/$(LINUX_IMAGE_NAME).* $(1)
|
linux: don't build appended DTB image in place and support multiple images
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>
2015-10-18 23:05:02 +02:00
|
|
|
endef
|
|
|
|
|
else
|
|
|
|
|
# Otherwise, just install the unique image generated by the kernel
|
|
|
|
|
# build process.
|
2015-10-18 23:05:00 +02:00
|
|
|
define LINUX_INSTALL_IMAGE
|
|
|
|
|
$(INSTALL) -m 0644 -D $(LINUX_IMAGE_PATH) $(1)/$(LINUX_IMAGE_NAME)
|
|
|
|
|
endef
|
linux: don't build appended DTB image in place and support multiple images
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>
2015-10-18 23:05:02 +02:00
|
|
|
endif
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
|
2011-07-05 21:53:54 +02:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_INSTALL_TARGET),y)
|
2011-07-11 22:46:08 +02:00
|
|
|
define LINUX_INSTALL_KERNEL_IMAGE_TO_TARGET
|
2015-10-18 23:05:00 +02:00
|
|
|
$(call LINUX_INSTALL_IMAGE,$(TARGET_DIR)/boot)
|
|
|
|
|
$(call LINUX_INSTALL_DTB,$(TARGET_DIR)/boot)
|
2011-07-11 22:46:08 +02:00
|
|
|
endef
|
2011-07-05 21:53:54 +02:00
|
|
|
endif
|
2011-07-11 22:46:08 +02:00
|
|
|
|
2012-05-15 10:18:25 +02:00
|
|
|
define LINUX_INSTALL_HOST_TOOLS
|
|
|
|
|
# Installing dtc (device tree compiler) as host tool, if selected
|
2018-04-01 07:08:23 +02:00
|
|
|
if grep -q "CONFIG_DTC=y" $(@D)/.config; then \
|
|
|
|
|
$(INSTALL) -D -m 0755 $(@D)/scripts/dtc/dtc $(HOST_DIR)/bin/linux-dtc ; \
|
2018-11-13 16:50:16 +01:00
|
|
|
$(if $(BR2_PACKAGE_HOST_DTC),,ln -sf linux-dtc $(HOST_DIR)/bin/dtc;) \
|
2012-05-15 10:18:25 +02:00
|
|
|
fi
|
|
|
|
|
endef
|
|
|
|
|
|
2011-07-11 22:46:08 +02:00
|
|
|
define LINUX_INSTALL_IMAGES_CMDS
|
2015-10-18 23:05:00 +02:00
|
|
|
$(call LINUX_INSTALL_IMAGE,$(BINARIES_DIR))
|
|
|
|
|
$(call LINUX_INSTALL_DTB,$(BINARIES_DIR))
|
2011-07-11 22:46:08 +02:00
|
|
|
endef
|
|
|
|
|
|
2016-09-19 16:12:05 +02:00
|
|
|
ifeq ($(BR2_STRIP_strip),y)
|
|
|
|
|
LINUX_MAKE_FLAGS += INSTALL_MOD_STRIP=1
|
|
|
|
|
endif
|
|
|
|
|
|
2011-07-11 22:46:08 +02:00
|
|
|
define LINUX_INSTALL_TARGET_CMDS
|
|
|
|
|
$(LINUX_INSTALL_KERNEL_IMAGE_TO_TARGET)
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
# Install modules and remove symbolic links pointing to build
|
|
|
|
|
# directories, not relevant on the target
|
2018-04-01 07:08:23 +02:00
|
|
|
@if grep -q "CONFIG_MODULES=y" $(@D)/.config; then \
|
linux: avoid unnecessary changes in defconfig for INITRAMFS_SOURCE
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>
2015-02-03 15:21:48 +01:00
|
|
|
$(LINUX_MAKE_ENV) $(MAKE1) $(LINUX_MAKE_FLAGS) -C $(@D) modules_install; \
|
2018-04-01 07:08:23 +02:00
|
|
|
rm -f $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/build ; \
|
|
|
|
|
rm -f $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/source ; \
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
fi
|
2012-05-15 10:18:25 +02:00
|
|
|
$(LINUX_INSTALL_HOST_TOOLS)
|
2011-07-11 22:46:08 +02:00
|
|
|
endef
|
New, simpler, infrastructure for building the Linux kernel
This patch introduces a single, simple, infrastructure to build the
Linux kernel. The configuration is limited to :
* Kernel version: a fixed recent stable version, same as kernel
headers version (for internal toolchains only), custom stable
version, or custom tarball URL
* Kernel patch: either a local file, directory or an URL
* Kernel configuration: either the name of a defconfig or the
location of a custom configuration file
* Kernel image: either uImage, bzImage, zImage or vmlinux.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-04-03 18:46:46 +02:00
|
|
|
|
linux/tools: make it a real, separate package
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>
2016-09-06 16:29:14 +02:00
|
|
|
# Include all our extensions.
|
2015-07-14 19:35:12 +02:00
|
|
|
#
|
2015-03-13 19:57:28 +01:00
|
|
|
# Note: our package infrastructure uses the full-path of the last-scanned
|
|
|
|
|
# Makefile to determine what package we're currently defining, using the
|
|
|
|
|
# last directory component in the path. As such, including other Makefile,
|
|
|
|
|
# like below, before we call one of the *-package macro is usally not
|
|
|
|
|
# working.
|
|
|
|
|
# However, since the files we include here are in the same directory as
|
|
|
|
|
# the current Makefile, we are OK. But this is a hard requirement: files
|
|
|
|
|
# included here *must* be in the same directory!
|
2013-09-03 10:45:41 +02:00
|
|
|
include $(sort $(wildcard linux/linux-ext-*.mk))
|
2011-09-17 22:22:51 +02:00
|
|
|
|
2015-03-14 15:25:20 +01:00
|
|
|
LINUX_PATCH_DEPENDENCIES += $(foreach ext,$(LINUX_EXTENSIONS),\
|
|
|
|
|
$(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),$(ext)))
|
|
|
|
|
|
|
|
|
|
LINUX_PRE_PATCH_HOOKS += $(foreach ext,$(LINUX_EXTENSIONS),\
|
|
|
|
|
$(if $(BR2_LINUX_KERNEL_EXT_$(call UPPERCASE,$(ext))),\
|
|
|
|
|
$(call UPPERCASE,$(ext))_PREPARE_KERNEL))
|
|
|
|
|
|
2015-07-13 12:32:00 +02:00
|
|
|
# Checks to give errors that the user can understand
|
2016-12-12 12:27:37 +01:00
|
|
|
|
|
|
|
|
# When a custom repository has been set, check for the repository version
|
|
|
|
|
ifeq ($(BR2_LINUX_KERNEL_CUSTOM_SVN)$(BR2_LINUX_KERNEL_CUSTOM_GIT)$(BR2_LINUX_KERNEL_CUSTOM_HG),y)
|
|
|
|
|
ifeq ($(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION)),)
|
|
|
|
|
$(error No custom repository version set. Check your BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION setting)
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL)),)
|
|
|
|
|
$(error No custom repo URL set. Check your BR2_LINUX_KERNEL_CUSTOM_REPO_URL setting)
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
2015-07-13 12:32:00 +02:00
|
|
|
ifeq ($(BR_BUILDING),y)
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
|
2015-12-22 22:22:02 +01:00
|
|
|
# We must use the user-supplied kconfig value, because
|
|
|
|
|
# LINUX_KCONFIG_DEFCONFIG will at least contain the
|
|
|
|
|
# trailing _defconfig
|
2015-12-23 09:37:36 +01:00
|
|
|
ifeq ($(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG)),)
|
2015-07-13 12:32:00 +02:00
|
|
|
$(error No kernel defconfig name specified, check your BR2_LINUX_KERNEL_DEFCONFIG setting)
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG),y)
|
2015-12-22 22:22:02 +01:00
|
|
|
ifeq ($(LINUX_KCONFIG_FILE),)
|
2015-07-13 12:32:00 +02:00
|
|
|
$(error No kernel configuration file specified, check your BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE setting)
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
2018-04-01 07:08:24 +02:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT):$(strip $(LINUX_DTS_NAME)),y:)
|
2015-07-13 12:32:00 +02:00
|
|
|
$(error No kernel device tree source specified, check your \
|
2018-04-01 07:08:23 +02:00
|
|
|
BR2_LINUX_KERNEL_INTREE_DTS_NAME / BR2_LINUX_KERNEL_CUSTOM_DTS_PATH settings)
|
2015-07-13 12:32:00 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
endif # BR_BUILDING
|
|
|
|
|
|
2015-02-03 15:21:47 +01:00
|
|
|
$(eval $(kconfig-package))
|
2011-10-14 16:56:56 +02:00
|
|
|
|
2011-09-06 23:16:09 +02:00
|
|
|
# Support for rebuilding the kernel after the cpio archive has
|
2017-11-12 18:45:41 +01:00
|
|
|
# been generated.
|
|
|
|
|
.PHONY: linux-rebuild-with-initramfs
|
|
|
|
|
linux-rebuild-with-initramfs: $(LINUX_DIR)/.stamp_target_installed
|
|
|
|
|
linux-rebuild-with-initramfs: $(LINUX_DIR)/.stamp_images_installed
|
|
|
|
|
linux-rebuild-with-initramfs: rootfs-cpio
|
|
|
|
|
linux-rebuild-with-initramfs:
|
linux: add support for initramfs
In Buildroot, the kernel is built and installed *before* the root
filesystems are built. This allows the root filesystem to correctly
contain the kernel modules that have been installed.
However, in the initramfs case, the root filesystem is part of the
kernel. Therefore, the kernel should be built *after* the root
filesystem (which, in the initramfs case simply builds a text file
listing all files/directories/devices/symlinks that should be part of
the initramfs). However, this isn't possible as the initramfs text
file would lack all kernel modules.
So, the solution choosen here is to keep the normal order: kernel is
built before the root filesystem is generated, and to add a little
quirk to retrigger a kernel compilation after the root filesystem
generation.
To do so, we add a ROOTFS_$(FSTYPE)_POST_TARGETS variable to the
fs/common.mk infrastructure. This allows individual filesystems to set
a target name that we should depend on *after* generating the root
filesystem itself (contrary to normal ROOTFS_$(FSTYPE)_DEPENDENCIES,
on which we depend *before* generating the root filesystem).
The initramfs code in fs/initramfs/initramfs.mk uses this to add a
dependency on 'linux26-rebuild-with-initramfs'.
In linux/linux.mk, we do various things :
* If BR2_TARGET_ROOTFS_INITRAMFS is enabled (i.e if initramfs is
enabled as a root filesystem type), then we create an empty
rootfs.initramfs file (remember that at this point, the root
filesystem hasn't been generated) and we adjust the kernel
configuration to include an initramfs. Of course, in the initial
kernel build, this initramfs will be empty.
* In the linux26-rebuild-with-initramfs target, we retrigger a
compilation of the kernel image, after removing the initramfs in
the kernel sources to make sure it gets properly rebuilt (we've
experienced cases were modifying the rootfs.initramfs file wouldn't
retrigger the generation of the initramfs at the kernel level).
This is fairly quirky, but initramfs really is a special case, so in
one way or another, we need a little quirk to solve its specialness.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-06-13 19:19:38 +02:00
|
|
|
@$(call MESSAGE,"Rebuilding kernel with initramfs")
|
|
|
|
|
# Build the kernel.
|
2017-11-12 18:45:41 +01:00
|
|
|
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(LINUX_DIR) $(LINUX_TARGET_NAME)
|
2013-07-31 17:47:36 +02:00
|
|
|
$(LINUX_APPEND_DTB)
|
2016-04-25 16:52:17 +02:00
|
|
|
# Copy the kernel image(s) to its(their) final destination
|
|
|
|
|
$(call LINUX_INSTALL_IMAGE,$(BINARIES_DIR))
|
2012-03-17 10:46:55 +01:00
|
|
|
# If there is a .ub file copy it to the final destination
|
2012-03-21 02:19:04 +01:00
|
|
|
test ! -f $(LINUX_IMAGE_PATH).ub || cp $(LINUX_IMAGE_PATH).ub $(BINARIES_DIR)
|
