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
|
2020-02-05 15:48:38 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_LATEST_VERSION),y)
|
|
|
|
|
LINUX_LICENSE_FILES = \
|
|
|
|
|
COPYING \
|
|
|
|
|
LICENSES/preferred/GPL-2.0 \
|
|
|
|
|
LICENSES/exceptions/Linux-syscall-note
|
|
|
|
|
endif
|
2021-01-14 23:34:30 +01:00
|
|
|
LINUX_CPE_ID_VENDOR = linux
|
2021-01-18 18:41:51 +01:00
|
|
|
LINUX_CPE_ID_PRODUCT = linux_kernel
|
2021-01-07 22:13:34 +01:00
|
|
|
LINUX_CPE_ID_PREFIX = cpe:2.3:o
|
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
|
|
|
# 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
|
2019-11-26 12:59:33 +01:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_LATEST_CIP_VERSION)$(BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION),y)
|
2019-11-20 19:58:53 +01:00
|
|
|
LINUX_SOURCE = linux-cip-$(LINUX_VERSION).tar.gz
|
|
|
|
|
LINUX_SITE = https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/snapshot
|
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-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
|
2019-03-06 22:28:15 +01:00
|
|
|
else
|
|
|
|
|
LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v$(firstword $(subst ., ,$(LINUX_VERSION))).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))
|
|
|
|
|
|
2019-02-16 19:34:26 +01:00
|
|
|
# We have no way to know the hashes for user-supplied patches.
|
|
|
|
|
BR_NO_CHECK_HASH_FOR += $(notdir $(LINUX_PATCHES))
|
|
|
|
|
|
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))
|
|
|
|
|
|
2020-01-31 18:49:39 +01:00
|
|
|
# while the kernel is built for the target, the build may need various
|
|
|
|
|
# host libraries depending on config (and version), so use
|
|
|
|
|
# HOST_MAKE_ENV here. In particular, this ensures that our
|
|
|
|
|
# host-pkgconf will look for host libraries and not target ones.
|
2019-04-08 20:42:33 +02:00
|
|
|
LINUX_MAKE_ENV = \
|
2020-01-31 18:49:39 +01:00
|
|
|
$(HOST_MAKE_ENV) \
|
2019-04-08 20:42:33 +02:00
|
|
|
BR_BINARIES_DIR=$(BINARIES_DIR)
|
|
|
|
|
|
2011-07-11 22:46:08 +02:00
|
|
|
LINUX_INSTALL_IMAGES = YES
|
2022-05-05 05:20:27 +02:00
|
|
|
LINUX_DEPENDENCIES = host-kmod
|
|
|
|
|
|
|
|
|
|
# The kernel CONFIG_EXTRA_FIRMWARE feature requires firmware files at build
|
|
|
|
|
# time. Make sure they are available before the kernel builds.
|
|
|
|
|
LINUX_DEPENDENCIES += \
|
2021-02-15 17:05:57 +01:00
|
|
|
$(if $(BR2_PACKAGE_INTEL_MICROCODE),intel-microcode) \
|
2022-01-31 21:21:51 +01:00
|
|
|
$(if $(BR2_PACKAGE_LINUX_FIRMWARE),linux-firmware) \
|
2022-08-12 17:58:55 +02:00
|
|
|
$(if $(BR2_PACKAGE_FIRMWARE_IMX),firmware-imx) \
|
2022-01-31 21:21:51 +01:00
|
|
|
$(if $(BR2_PACKAGE_WIRELESS_REGDB),wireless-regdb)
|
2018-08-17 18:06:47 +02:00
|
|
|
|
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
|
2020-09-01 15:48:49 +02:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_ZSTD),y)
|
|
|
|
|
LINUX_DEPENDENCIES += host-zstd
|
2015-07-12 13:43:32 +02:00
|
|
|
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
|
2020-09-01 15:48:49 +02:00
|
|
|
LINUX_COMPRESSION_OPT_$(BR2_LINUX_KERNEL_ZSTD) += CONFIG_KERNEL_ZSTD
|
2021-03-24 12:45:22 +01:00
|
|
|
LINUX_COMPRESSION_OPT_$(BR2_LINUX_KERNEL_UNCOMPRESSED) += CONFIG_KERNEL_UNCOMPRESSED
|
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)
|
2019-04-08 20:42:33 +02:00
|
|
|
LINUX_DEPENDENCIES += host-elfutils host-pkgconf
|
2018-03-04 22:31:16 +01:00
|
|
|
endif
|
|
|
|
|
|
2021-12-22 18:49:05 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_NEEDS_HOST_PAHOLE),y)
|
|
|
|
|
LINUX_DEPENDENCIES += host-pahole
|
|
|
|
|
else
|
|
|
|
|
define LINUX_FIXUP_CONFIG_PAHOLE_CHECK
|
|
|
|
|
if grep -q "^CONFIG_DEBUG_INFO_BTF=y" $(KCONFIG_DOT_CONFIG); then \
|
|
|
|
|
echo "To use CONFIG_DEBUG_INFO_BTF, enable host-pahole (BR2_LINUX_KERNEL_NEEDS_HOST_PAHOLE)" 1>&2; \
|
|
|
|
|
exit 1; \
|
|
|
|
|
fi
|
|
|
|
|
endef
|
|
|
|
|
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
|
|
|
|
|
|
2020-03-21 00:35:44 +01:00
|
|
|
# We don't want to run depmod after installing the kernel. It's done in a
|
|
|
|
|
# target-finalize hook, to encompass modules installed by packages.
|
linux: disable -Werror when building host tools
gcc-12 is starting to trickle down to some distros, like Archlinux.
gcc-12 has new warnings, and detects more cases of issues, like new
UAF cases, which is causing build issues in code that was previously
building fine, as reported in #14826:
In file included from sigchain.c:3:
In function 'xrealloc',
inlined from 'sigchain_push.isra' at sigchain.c:26:2:
subcmd-util.h:56:23: error: pointer may be used after 'realloc' [-Werror=use-after-free]
56 | ret = realloc(ptr, size);
| ^~~~~~~~~~~~~~~~~~
subcmd-util.h:52:21: note: call to 'realloc' here
52 | void *ret = realloc(ptr, size);
| ^~~~~~~~~~~~~~~~~~
subcmd-util.h:58:31: error: pointer may be used after 'realloc' [-Werror=use-after-free]
58 | ret = realloc(ptr, 1);
| ^~~~~~~~~~~~~~~
subcmd-util.h:52:21: note: call to 'realloc' here
52 | void *ret = realloc(ptr, size);
| ^~~~~~~~~~~~~~~~~~
In that case, the kernel has already fixed their code, which is part of
5.17:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=52a9dab6d892763b2a8334a568bd4e2c1a6fde66
However, we can't easily carry that patch, because we don't know
whether the kernel the user uses already has the fix or not.
Instead, we can just tell the kernel to disable use of -Werror when
building host tools.
As a consequence, we can drop it from the perf-specific setting.
Fixes: #14826
Reported-by: Anders Pitman <buildroot@apitman.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-06-02 23:04:21 +02:00
|
|
|
# Disable building host tools with -Werror: newer gcc versions can be
|
|
|
|
|
# extra picky about some code (https://bugs.busybox.net/show_bug.cgi?id=14826)
|
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)" \
|
linux: disable -Werror when building host tools
gcc-12 is starting to trickle down to some distros, like Archlinux.
gcc-12 has new warnings, and detects more cases of issues, like new
UAF cases, which is causing build issues in code that was previously
building fine, as reported in #14826:
In file included from sigchain.c:3:
In function 'xrealloc',
inlined from 'sigchain_push.isra' at sigchain.c:26:2:
subcmd-util.h:56:23: error: pointer may be used after 'realloc' [-Werror=use-after-free]
56 | ret = realloc(ptr, size);
| ^~~~~~~~~~~~~~~~~~
subcmd-util.h:52:21: note: call to 'realloc' here
52 | void *ret = realloc(ptr, size);
| ^~~~~~~~~~~~~~~~~~
subcmd-util.h:58:31: error: pointer may be used after 'realloc' [-Werror=use-after-free]
58 | ret = realloc(ptr, 1);
| ^~~~~~~~~~~~~~~
subcmd-util.h:52:21: note: call to 'realloc' here
52 | void *ret = realloc(ptr, size);
| ^~~~~~~~~~~~~~~~~~
In that case, the kernel has already fixed their code, which is part of
5.17:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=52a9dab6d892763b2a8334a568bd4e2c1a6fde66
However, we can't easily carry that patch, because we don't know
whether the kernel the user uses already has the fix or not.
Instead, we can just tell the kernel to disable use of -Werror when
building host tools.
As a consequence, we can drop it from the perf-specific setting.
Fixes: #14826
Reported-by: Anders Pitman <buildroot@apitman.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-06-02 23:04:21 +02:00
|
|
|
WERROR=0 \
|
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
|
|
|
|
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
|
|
|
|
|
|
2019-01-15 15:15:48 +01:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT),y)
|
|
|
|
|
LINUX_MAKE_ENV += DTC_FLAGS=-@
|
|
|
|
|
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.
|
linux: workaround make-4.1 bug
On Ubuntu 18.04, make-4.1 emits spurious, incorrect "entering/leaving"
messages, which end up in the LINUX_VERSION_PROBED variable:
printf 'probed linux version: "%s"\n' "$(LINUX_VERSION_PROBED)"
probed linux version: "make[1]: Entering directory '/home/buildroot'
4.19.78-linux4sam-6.2
make[1]: Leaving directory '/home/buildroot/output/build/linux-linux4sam_6.2'"
First, the messages are displayed even though we do explicitly pass
--no-print-directory -s.
Second, the entering and leaving messages are not about the same
directory!
This *only* occurs in the following conditions:
- the user has the correct 0022 umask,
- top-level parallel is used (with or without PPD),
- initial -C is specified as well.
$ umask 0022
$ make -j16 -C $(pwd)
[...]
depmod: ERROR: Bad version passed make[1]:
[...]
(yes, 'make[1]:' is the string depmod is trying, and fails, to parse as
a version string).
If any of the three conditions above is removed, the problem no longer
occurs. Here's a table of the MAKEFLAGS:
| 0002 | 0022 |
----+-------+------------------------------------------------+--------------------------+
| no-j | --no-print-directory -- | |
noC | +------------------------------------------------+--------------------------+
| -j16 | -j --jobserver-fds=3,4 --no-print-directory -- | -j --jobserver-fds=3,4 |
----+-------+------------------------------------------------+--------------------------+
| no-j | --no-print-directory -- | w |
-C | +------------------------------------------------+--------------------------+
| -j16 | -j --jobserver-fds=3,4 --no-print-directory -- | w -j --jobserver-fds=3,4 |
----+-------+------------------------------------------------+--------------------------+
0002: umask == 0002
0022: umask == 0022
no-j: no -j flag
-j16: -j16 flag
noC: no -C flag
-C : -C /path/of/buildroot/
Only the bottom-right-most case fails...
This behaviour goes against what is documented:
https://www.gnu.org/software/make/manual/make.html#g_t_002dw-Option
5.7.4 The ‘--print-directory’ Option
[...]
you do not need to specify this option because ‘make’ does it for
you: ‘-w’ is turned on automatically when you use the ‘-C’ option,
and in sub-makes. make will not automatically turn on ‘-w’ if you
also use ‘-s’, which says to be silent, or if you use
‘--no-print-directory’ to explicitly disable it.
So this exactly describes our situation; yet 'w' is added to MAKEFLAGS.
Getting rid of the 'w' flag makes the build succeed again, so that's
what we do here (bleark, icky)...
Furthermore, the documented way to override MAKEFLAGS is to do so as a
make parameter:
https://www.gnu.org/software/make/manual/make.html#Options_002fRecursion
5.7.3 Communicating Options to a Sub-make
[...]
If you do not want to pass the other flags down, you must change the
value of MAKEFLAGS, like this:
subsystem:
cd subdir && $(MAKE) MAKEFLAGS=
However, doing so does not fix the issue. So we resort to pass the
modified MAKEFLAGS via the environment (bleark, icky)...
Fixes: #13141
Reported-by: Laurent <laurent@neko-labs.eu>
Reported-by: Asaf Kahlon <asafka7@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-08-26 13:37:59 +02:00
|
|
|
# Filter out 'w' from MAKEFLAGS, to workaround a bug in make 4.1 (#13141)
|
|
|
|
|
LINUX_VERSION_PROBED = `MAKEFLAGS='$(filter-out w,$(MAKEFLAGS))' $(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
|
2021-01-22 11:39:49 +01:00
|
|
|
else ifeq ($(BR2_LINUX_KERNEL_IMAGEGZ),y)
|
|
|
|
|
LINUX_IMAGE_NAME = Image.gz
|
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
|
2022-01-15 21:03:05 +01:00
|
|
|
else ifeq ($(KERNEL_ARCH),sparc64)
|
|
|
|
|
LINUX_ARCH_PATH = $(LINUX_DIR)/arch/sparc
|
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
|
|
|
|
2022-01-31 22:38:09 +01:00
|
|
|
# Older versions break on gcc 10+ because of redefined symbols
|
|
|
|
|
define LINUX_DROP_YYLLOC
|
|
|
|
|
$(Q)grep -Z -l -r -E '^YYLTYPE yylloc;$$' $(@D) \
|
|
|
|
|
|xargs -0 -r $(SED) '/^YYLTYPE yylloc;$$/d'
|
|
|
|
|
endef
|
|
|
|
|
LINUX_POST_PATCH_HOOKS += LINUX_DROP_YYLLOC
|
|
|
|
|
|
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)
|
2022-05-10 04:20:55 +02:00
|
|
|
ifeq ($(BR2_powerpc64le),y)
|
|
|
|
|
LINUX_KCONFIG_DEFCONFIG = ppc64le_defconfig
|
|
|
|
|
else
|
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
|
|
|
LINUX_KCONFIG_DEFCONFIG = defconfig
|
2022-05-10 04:20:55 +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
|
|
|
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
|
|
|
|
2019-01-10 22:15:00 +01: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. In addition, even though linux depends on the toolchain and
|
|
|
|
|
# therefore host-ccache would be ready, we use HOSTCC_NOCCACHE for
|
|
|
|
|
# consistency with other kconfig packages.
|
|
|
|
|
LINUX_KCONFIG_OPTS = $(LINUX_MAKE_FLAGS) HOSTCC="$(HOSTCC_NOCCACHE)"
|
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
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_CPU_BIG_ENDIAN)
|
2016-05-19 15:17:03 +02:00
|
|
|
endef
|
|
|
|
|
else
|
|
|
|
|
define LINUX_FIXUP_CONFIG_ENDIANNESS
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_CPU_LITTLE_ENDIAN)
|
2016-05-19 15:17:03 +02:00
|
|
|
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),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_MODULES))
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,$(strip $(LINUX_COMPRESSION_OPT_y)))
|
2015-07-12 13:43:32 +02:00
|
|
|
$(foreach opt, $(LINUX_COMPRESSION_OPT_),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_DISABLE_OPT,$(opt))
|
2015-07-12 13:43:32 +02:00
|
|
|
)
|
2016-05-19 15:17:03 +02:00
|
|
|
$(LINUX_FIXUP_CONFIG_ENDIANNESS)
|
2021-12-22 18:49:05 +01:00
|
|
|
$(LINUX_FIXUP_CONFIG_PAHOLE_CHECK)
|
2013-07-14 00:27:30 +02:00
|
|
|
$(if $(BR2_arm)$(BR2_armeb),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_AEABI))
|
2019-06-20 12:07:12 +02:00
|
|
|
$(if $(BR2_powerpc)$(BR2_powerpc64)$(BR2_powerpc64le),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_PPC_DISABLE_WERROR))
|
2019-12-17 14:15:28 +01:00
|
|
|
$(if $(BR2_ARC_PAGE_SIZE_4K),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_ARC_PAGE_SIZE_4K)
|
|
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_ARC_PAGE_SIZE_8K)
|
|
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_ARC_PAGE_SIZE_16K))
|
2019-12-17 14:15:28 +01:00
|
|
|
$(if $(BR2_ARC_PAGE_SIZE_8K),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_ARC_PAGE_SIZE_4K)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_ARC_PAGE_SIZE_8K)
|
|
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_ARC_PAGE_SIZE_16K))
|
2019-12-17 14:15:28 +01:00
|
|
|
$(if $(BR2_ARC_PAGE_SIZE_16K),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_ARC_PAGE_SIZE_4K)
|
|
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_ARC_PAGE_SIZE_8K)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_ARC_PAGE_SIZE_16K))
|
arch: add support for configurable page size on ARM64
This commit is based on earlier work from Łukasz Stelmach
<l.stelmach@samsung.com> to add support for different page sizes on
ARM64.
In his initial submission, Łukasz took an approach similar to this
one, i.e make it ARM64-specific. Following the feedback on the mailing
list, his second version [1] tried to generalize the logic to
configure the page size between architectures. But the general
consensus during the review process was that there wasn't much to
generalize in the end.
So, this new iteration is back to a simpler approach:
* We have new options in Config.in.arm to configure the page
size. Only 4 KB and 64 KB are supported, because our testing in
Qemu and real hardware has not allowed to get a successful setup
for 16 KB pages. We can always re-add support for 16 KB later if
that is resolved.
* The logic to define the ARCH_TOOLCHAIN_WRAPPER_OPTS options is
moved from the ARC-specific file to arch/arch.mk, and extended to
cover ARM64.
* The appropriate logic in uclibc.mk and linux.mk is added to tweak
the relevant configuration options.
* A test case is added in the runtime test infrastructure to test
building and booting under Qemu a 64 KB configuration, with all 3 C
libraries.
For the regular configuration of 4 KB pages, this commit makes one
functional change: on ARM64, -Wl,-z,max-page-size=4096 is now passed in
the compiler flags of the wrapper.
[1] https://patchwork.ozlabs.org/project/buildroot/list/?series=275452
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-07-26 15:12:48 +02:00
|
|
|
$(if $(BR2_ARM64_PAGE_SIZE_4K),
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_ARM64_4K_PAGES)
|
|
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_ARM64_16K_PAGES)
|
|
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_ARM64_64K_PAGES))
|
|
|
|
|
$(if $(BR2_ARM64_PAGE_SIZE_64K),
|
|
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_ARM64_4K_PAGES)
|
|
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_ARM64_16K_PAGES)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_ARM64_64K_PAGES))
|
2013-12-29 18:33:45 +01:00
|
|
|
$(if $(BR2_TARGET_ROOTFS_CPIO),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_INITRD))
|
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
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_SOURCE,"$${BR_BINARIES_DIR}/rootfs.cpio")
|
|
|
|
|
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_ROOT_UID,0)
|
|
|
|
|
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_ROOT_GID,0))
|
2011-07-11 22:46:08 +02:00
|
|
|
$(if $(BR2_ROOTFS_DEVICE_CREATION_STATIC),,
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS_MOUNT))
|
2014-02-07 14:21:32 +01:00
|
|
|
$(if $(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_INOTIFY_USER))
|
2019-06-20 18:59:44 +02:00
|
|
|
$(if $(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_NET))
|
2012-07-30 14:32:47 +02:00
|
|
|
$(if $(BR2_LINUX_KERNEL_APPENDED_DTB),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_ARM_APPENDED_DTB))
|
2018-08-24 15:44:58 +02:00
|
|
|
$(if $(LINUX_KERNEL_CUSTOM_LOGO_PATH),
|
2020-04-04 14:10:20 +02:00
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_FB)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_LOGO)
|
|
|
|
|
$(call KCONFIG_ENABLE_OPT,CONFIG_LOGO_LINUX_CLUT224))
|
linux: forcibly disable use of gcc plugins
The soon-to-be-released linux 5.7 has changed the way it detects the
ability of gcc to use plugins, when it dropped support for gcc 4.7 or
older [0].
To detect the ability to use gcc plugins, the kernel has to check
whether the host gcc is capable enough to build them.
When we call one of the configurator for the Linux kernel, we explicitly
pass a value of HOSTCC=$(HOSTCC_NOCCACHE), because there might be a
discrepancy between the ncurses headers and libraries as found by the
Linux kconfig build [1] [2].
But then, when we build the kernel, we pass another value to use [3]
HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" which boils down to
roughly: gcc -I.../host/include -L.../host/lib -Wl,-rpath,.../host/lib
This is needed so that at build time, the kernel can build host tools
that link with our openssl et al.
So, the two HOSTCC we pass to the kernel may have different behaviours.
For example, on a machine where gmp is missing in the system, it is
available in $(O)/host/ when using an internal toolchain (and under a
few other conditions).
In that case, when configuring the kernel, it decides that the host
compiler can't build plugins, so the dependencies of CONFIG_GCC_PLUGINS
are not met, and that option is not present in the linux' .config file
(neither as "=y" nor as "is not set"). But then, when we build the
kernel, the host compiler suddenly becomes capable of building the
plugins, and the internal syncconfig run by the kernel will notice that
the dependencies of CONFIG_GCC_PLUGINS are now met, and that the user
shall decide on its value. And this blocks a build on an interactive
console (abbreviated):
* Restart config...
* GCC plugins
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) _
But most problematic is the behaviour when run in a shell that is not
interactiove (e.g. a CI job or such) (abbreviated):
* Restart config...
* GCC plugins
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW)
Error in reading or end of file.
Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW)
Error in reading or end of file.
Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW)
Error in reading or end of file.
* Memory initialization
Initialize kernel stack variables at function entry
> 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak) (GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong) (GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong) (GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
choice[1-4?]:
Error in reading or end of file.
Poison kernel stack before returning from syscalls (GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW)
Error in reading or end of file.
Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n
The most obvious and simple solution would be to unconditionally disable
gcc plugins altogether, in the KCONFIG_FIXUP hook. But that can't work
either, because after applying the fixups, we call olddefconfig (or the
likes) with the incapable HOSTCC, so the disabled option would be removed
anyway, and we'd be back to square one.
So, in addition to the above, we also forcibly hack the same call just
before actually building the kernel.
Note that the two are needed: the one in the fixups is needed for those
that have a system that already allows building gcc plugins, and the
second is needed in the other case, where the system does not allow it
but would work with our additional headers and libs in $(O)/host/. The
two ensure there is a very similar experience in the two situations.
Forcibly disabling the use of gcc plugins is not a regression on our
side: it has never been possible to do so so far. We're now making sure
that can't work by accident.
Reported-by: Ganesh <ganesh45in@gmail.com>,
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Michael Walle <michael.walle@kontron.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-12 22:33:53 +02:00
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_GCC_PLUGINS)
|
linux: allow packages to set kernel config options
Currently, the linux kernel will apply some fixups on its .config file,
based on whether some packages are enabled or not. That list of
conditional fixups is getting bigger and bigger with each new package
that needs such fixups, culminating with the pending firewalld one [0].
Furthermore, these fixups are not accessible to packages in br2-external
trees.
Add a new per-package variable, that packages may set to the commands to
run to fixup the kernel .config file, which is added at the end of the
linux' own fixups.
This opens the possibility to write things like;
define FOO_LINUX_CONFIG_FIXUPS
$(call KCONFIG_ENABLE_OPT,BLA)
endef
Of course, it also opens the way to run arbitrary commands in there, but
any alternative that would be declarative only, such as a list of
options to enable or disable (as an example):
FOO_LINUX_CONFIG_FIXUPS = +BAR -FOO +BUZ="value"
.. is not very nice either, and such lists fall flat when a value would
have a space.
For packages that we have in-tree, we can ensure they won't play foul
with their _LINUX_CONFIG_FIXUPS. For packages in br2-external trees,
there's nothing we can do; users already have the opportunity to hack
into the linux configure process by providing LINUX_PRE_CONFIGURE_HOOKS
or LINUX_POST_CONFIGURE_HOOKS anyway...
.. which brings the question of why we don't use that to implement the
per-package fixups. We don't, because _PRE or _POST_CONFIGURE_HOOKS are
run after we run 'make oldconfig' to sanitise the mangled .config.
[0] http://lists.busybox.net/pipermail/buildroot/2020-March/278683.html
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-04-04 14:10:21 +02:00
|
|
|
$(PACKAGES_LINUX_CONFIG_FIXUPS)
|
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
|
2020-06-05 00:11:21 +02:00
|
|
|
$(foreach dtb,$(LINUX_DTBS), \
|
|
|
|
|
install -D \
|
|
|
|
|
$(or $(wildcard $(LINUX_ARCH_PATH)/boot/dts/$(dtb)),$(LINUX_ARCH_PATH)/boot/$(dtb)) \
|
2020-06-07 09:21:12 +02:00
|
|
|
$(1)/$(if $(BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME),$(dtb),$(notdir $(dtb)))
|
2020-06-05 00:11:21 +02:00
|
|
|
)
|
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
|
2019-04-22 22:08:25 +02:00
|
|
|
# configuration has changed. We call the 'all' and
|
|
|
|
|
# '$(LINUX_TARGET_NAME)' targets separately because calling them in
|
|
|
|
|
# the same $(MAKE) invocation has shown to cause parallel build
|
|
|
|
|
# issues.
|
linux: forcibly disable use of gcc plugins
The soon-to-be-released linux 5.7 has changed the way it detects the
ability of gcc to use plugins, when it dropped support for gcc 4.7 or
older [0].
To detect the ability to use gcc plugins, the kernel has to check
whether the host gcc is capable enough to build them.
When we call one of the configurator for the Linux kernel, we explicitly
pass a value of HOSTCC=$(HOSTCC_NOCCACHE), because there might be a
discrepancy between the ncurses headers and libraries as found by the
Linux kconfig build [1] [2].
But then, when we build the kernel, we pass another value to use [3]
HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" which boils down to
roughly: gcc -I.../host/include -L.../host/lib -Wl,-rpath,.../host/lib
This is needed so that at build time, the kernel can build host tools
that link with our openssl et al.
So, the two HOSTCC we pass to the kernel may have different behaviours.
For example, on a machine where gmp is missing in the system, it is
available in $(O)/host/ when using an internal toolchain (and under a
few other conditions).
In that case, when configuring the kernel, it decides that the host
compiler can't build plugins, so the dependencies of CONFIG_GCC_PLUGINS
are not met, and that option is not present in the linux' .config file
(neither as "=y" nor as "is not set"). But then, when we build the
kernel, the host compiler suddenly becomes capable of building the
plugins, and the internal syncconfig run by the kernel will notice that
the dependencies of CONFIG_GCC_PLUGINS are now met, and that the user
shall decide on its value. And this blocks a build on an interactive
console (abbreviated):
* Restart config...
* GCC plugins
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) _
But most problematic is the behaviour when run in a shell that is not
interactiove (e.g. a CI job or such) (abbreviated):
* Restart config...
* GCC plugins
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW)
Error in reading or end of file.
Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW)
Error in reading or end of file.
Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW)
Error in reading or end of file.
* Memory initialization
Initialize kernel stack variables at function entry
> 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak) (GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong) (GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong) (GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
choice[1-4?]:
Error in reading or end of file.
Poison kernel stack before returning from syscalls (GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW)
Error in reading or end of file.
Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n
The most obvious and simple solution would be to unconditionally disable
gcc plugins altogether, in the KCONFIG_FIXUP hook. But that can't work
either, because after applying the fixups, we call olddefconfig (or the
likes) with the incapable HOSTCC, so the disabled option would be removed
anyway, and we'd be back to square one.
So, in addition to the above, we also forcibly hack the same call just
before actually building the kernel.
Note that the two are needed: the one in the fixups is needed for those
that have a system that already allows building gcc plugins, and the
second is needed in the other case, where the system does not allow it
but would work with our additional headers and libs in $(O)/host/. The
two ensure there is a very similar experience in the two situations.
Forcibly disabling the use of gcc plugins is not a regression on our
side: it has never been possible to do so so far. We're now making sure
that can't work by accident.
Reported-by: Ganesh <ganesh45in@gmail.com>,
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Michael Walle <michael.walle@kontron.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-12 22:33:53 +02:00
|
|
|
# The call to disable gcc-plugins is a stop-gap measure:
|
|
|
|
|
# http://lists.busybox.net/pipermail/buildroot/2020-May/282727.html
|
2011-07-11 22:46:08 +02:00
|
|
|
define LINUX_BUILD_CMDS
|
linux: forcibly disable use of gcc plugins
The soon-to-be-released linux 5.7 has changed the way it detects the
ability of gcc to use plugins, when it dropped support for gcc 4.7 or
older [0].
To detect the ability to use gcc plugins, the kernel has to check
whether the host gcc is capable enough to build them.
When we call one of the configurator for the Linux kernel, we explicitly
pass a value of HOSTCC=$(HOSTCC_NOCCACHE), because there might be a
discrepancy between the ncurses headers and libraries as found by the
Linux kconfig build [1] [2].
But then, when we build the kernel, we pass another value to use [3]
HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" which boils down to
roughly: gcc -I.../host/include -L.../host/lib -Wl,-rpath,.../host/lib
This is needed so that at build time, the kernel can build host tools
that link with our openssl et al.
So, the two HOSTCC we pass to the kernel may have different behaviours.
For example, on a machine where gmp is missing in the system, it is
available in $(O)/host/ when using an internal toolchain (and under a
few other conditions).
In that case, when configuring the kernel, it decides that the host
compiler can't build plugins, so the dependencies of CONFIG_GCC_PLUGINS
are not met, and that option is not present in the linux' .config file
(neither as "=y" nor as "is not set"). But then, when we build the
kernel, the host compiler suddenly becomes capable of building the
plugins, and the internal syncconfig run by the kernel will notice that
the dependencies of CONFIG_GCC_PLUGINS are now met, and that the user
shall decide on its value. And this blocks a build on an interactive
console (abbreviated):
* Restart config...
* GCC plugins
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) _
But most problematic is the behaviour when run in a shell that is not
interactiove (e.g. a CI job or such) (abbreviated):
* Restart config...
* GCC plugins
GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW)
Error in reading or end of file.
Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW)
Error in reading or end of file.
Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW)
Error in reading or end of file.
* Memory initialization
Initialize kernel stack variables at function entry
> 1. no automatic initialization (weakest) (INIT_STACK_NONE)
2. zero-init structs marked for userspace (weak) (GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
3. zero-init structs passed by reference (strong) (GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
4. zero-init anything passed by reference (very strong) (GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
choice[1-4?]:
Error in reading or end of file.
Poison kernel stack before returning from syscalls (GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW)
Error in reading or end of file.
Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n
The most obvious and simple solution would be to unconditionally disable
gcc plugins altogether, in the KCONFIG_FIXUP hook. But that can't work
either, because after applying the fixups, we call olddefconfig (or the
likes) with the incapable HOSTCC, so the disabled option would be removed
anyway, and we'd be back to square one.
So, in addition to the above, we also forcibly hack the same call just
before actually building the kernel.
Note that the two are needed: the one in the fixups is needed for those
that have a system that already allows building gcc plugins, and the
second is needed in the other case, where the system does not allow it
but would work with our additional headers and libs in $(O)/host/. The
two ensure there is a very similar experience in the two situations.
Forcibly disabling the use of gcc plugins is not a regression on our
side: it has never been possible to do so so far. We're now making sure
that can't work by accident.
Reported-by: Ganesh <ganesh45in@gmail.com>,
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Michael Walle <michael.walle@kontron.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-12 22:33:53 +02:00
|
|
|
$(call KCONFIG_DISABLE_OPT,CONFIG_GCC_PLUGINS)
|
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/
|
|
|
|
|
)
|
2019-04-22 22:08:25 +02:00
|
|
|
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) all
|
|
|
|
|
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(LINUX_TARGET_NAME)
|
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
|
2020-04-02 23:45:48 +02:00
|
|
|
$(INSTALL) -m 0644 -D $(LINUX_IMAGE_PATH) $(1)/$(notdir $(LINUX_IMAGE_NAME))
|
2015-10-18 23:05:00 +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
|
|
|
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
|
|
|
|
2020-03-21 00:35:44 +01:00
|
|
|
# Run depmod in a target-finalize hook, to encompass modules installed by
|
|
|
|
|
# packages.
|
|
|
|
|
define LINUX_RUN_DEPMOD
|
2020-06-23 13:38:59 +02:00
|
|
|
if test -d $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED) \
|
|
|
|
|
&& grep -q "CONFIG_MODULES=y" $(LINUX_DIR)/.config; then \
|
2020-03-25 01:21:54 +01:00
|
|
|
$(HOST_DIR)/sbin/depmod -a -b $(TARGET_DIR) $(LINUX_VERSION_PROBED); \
|
|
|
|
|
fi
|
2020-03-21 00:35:44 +01:00
|
|
|
endef
|
|
|
|
|
LINUX_TARGET_FINALIZE_HOOKS += LINUX_RUN_DEPMOD
|
|
|
|
|
|
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
|
package/linux: fix LINUX_PKGDIR with br2-external linux-extensions
When 'make' includes a new Makefile, it appends its path to the MAKEFILE_LIST
variable. From that variable, we construct a few set of derivative
variables:
pkgdir = $(dir $(lastword $(MAKEFILE_LIST)))
pkgname = $(lastword $(subst /, ,$(pkgdir)))
Essentially, pkgdir is the full directory where the package is located
(either relative to Buildroot's top directory for in-tree packages, or
absolute for packages in br2-external trees), while pkgname is the last
component of that directory.
pkgdir is in turn used to seed FOO_PKGDIR.
This all happens when we eventually call the package-generic infra,
later down in the file.
When they are parsed, the Makefiles for each linux-extensions are
appended to MAKEFILE_LIST, after the linux.mk one. But since they are
located in the same directory as the main linux.mk, the last component
of MAKEFILE_LIST, which is no longer the main linux.mk, will still yield
the correct values for the linux package.
This is a tough assumption we made there and then.
When we added the support for br2-external linux extensions, we where
very cautious to explicitly scan them from a directory named 'linux', so
that this would yield the correct package name.
And that worked well so far, until someone needed to build an older
kernel, for which our conditional patch is needed, and which just
failed:
/bin/bash: [...]/buildroot-external-linux-test/linux//0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional: No such file or directory
When we scan linux extensions from a br2-external tree, the last
component of MAKEFILE_LIST is no longer in the same directory as the
main linux.mk, and thus the assumption above falls to pieces...
Again, when we added support for linux extensions from br2-external,
although we cared about the package name (pkgname), we completely missed
out on the package directory, and the LINUX_PKGDIR variable.
We do not have a very clean way out of this mess, but we have a nice
dirty trick: Scan the linux extensions from a br2-external tree before we
scan the in-tree ones. That way, the last component of MAKEFILE_LIST is
back to one that is in the same directory as the main linux.mk, and
we're back on tracks.
This is still very fragile, though, but short of a complete overhaul on
how packages are parsed and evaluated, this is the best we can come in
short order.
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Heiko Thiery <heiko.thiery@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-01-24 22:38:55 +01:00
|
|
|
# last directory component in the path. Additionally, the full path of
|
|
|
|
|
# the package directory is also stored in _PKGDIR (e.g. to find patches)
|
|
|
|
|
#
|
|
|
|
|
# As such, including other Makefiles, like below, before we call one of
|
|
|
|
|
# the *-package macros usually doesn't work.
|
|
|
|
|
#
|
|
|
|
|
# However, by including the in-tree extensions after the ones from the
|
|
|
|
|
# br2-external trees, we're back to the situation where the last Makefile
|
|
|
|
|
# scanned *is* included from the correct directory.
|
|
|
|
|
#
|
|
|
|
|
# NOTE: this is very fragile, and extra care must be taken to ensure that
|
|
|
|
|
# we always end up with an in-tree included file. That's mostly OK, because
|
|
|
|
|
# we do have in-tree linux-extensions.
|
|
|
|
|
#
|
2019-09-28 19:49:37 +02:00
|
|
|
include $(sort $(wildcard $(foreach ext,$(BR2_EXTERNAL_DIRS), \
|
2019-09-29 20:16:05 +02:00
|
|
|
$(ext)/linux/linux-ext-*.mk)))
|
package/linux: fix LINUX_PKGDIR with br2-external linux-extensions
When 'make' includes a new Makefile, it appends its path to the MAKEFILE_LIST
variable. From that variable, we construct a few set of derivative
variables:
pkgdir = $(dir $(lastword $(MAKEFILE_LIST)))
pkgname = $(lastword $(subst /, ,$(pkgdir)))
Essentially, pkgdir is the full directory where the package is located
(either relative to Buildroot's top directory for in-tree packages, or
absolute for packages in br2-external trees), while pkgname is the last
component of that directory.
pkgdir is in turn used to seed FOO_PKGDIR.
This all happens when we eventually call the package-generic infra,
later down in the file.
When they are parsed, the Makefiles for each linux-extensions are
appended to MAKEFILE_LIST, after the linux.mk one. But since they are
located in the same directory as the main linux.mk, the last component
of MAKEFILE_LIST, which is no longer the main linux.mk, will still yield
the correct values for the linux package.
This is a tough assumption we made there and then.
When we added the support for br2-external linux extensions, we where
very cautious to explicitly scan them from a directory named 'linux', so
that this would yield the correct package name.
And that worked well so far, until someone needed to build an older
kernel, for which our conditional patch is needed, and which just
failed:
/bin/bash: [...]/buildroot-external-linux-test/linux//0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional: No such file or directory
When we scan linux extensions from a br2-external tree, the last
component of MAKEFILE_LIST is no longer in the same directory as the
main linux.mk, and thus the assumption above falls to pieces...
Again, when we added support for linux extensions from br2-external,
although we cared about the package name (pkgname), we completely missed
out on the package directory, and the LINUX_PKGDIR variable.
We do not have a very clean way out of this mess, but we have a nice
dirty trick: Scan the linux extensions from a br2-external tree before we
scan the in-tree ones. That way, the last component of MAKEFILE_LIST is
back to one that is in the same directory as the main linux.mk, and
we're back on tracks.
This is still very fragile, though, but short of a complete overhaul on
how packages are parsed and evaluated, this is the best we can come in
short order.
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Heiko Thiery <heiko.thiery@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-01-24 22:38:55 +01:00
|
|
|
include $(sort $(wildcard linux/linux-ext-*.mk))
|
2019-09-28 19:49:37 +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)
|
|
|
|
|
|
2022-04-05 03:20:59 +02:00
|
|
|
ifeq ($(BR2_LINUX_KERNEL_CUSTOM_VERSION),y)
|
|
|
|
|
ifeq ($(LINUX_VERSION),)
|
|
|
|
|
$(error No custom kernel version set. Check your BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE setting)
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
2015-07-13 12:32:00 +02:00
|
|
|
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)
|
