kumquat-buildroot/linux/linux.mk

623 lines
24 KiB
Makefile
Raw Normal View History

################################################################################
#
# Linux kernel target
#
################################################################################
LINUX_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
LINUX_LICENSE = GPL-2.0
ifeq ($(BR2_LINUX_KERNEL_LATEST_VERSION),y)
LINUX_LICENSE_FILES = \
COPYING \
LICENSES/preferred/GPL-2.0 \
LICENSES/exceptions/Linux-syscall-note
endif
LINUX_CPE_ID_VENDOR = linux
LINUX_CPE_ID_PRODUCT = linux_kernel
LINUX_CPE_ID_PREFIX = cpe:2.3:o
# Compute LINUX_SOURCE and LINUX_SITE from the configuration
ifeq ($(BR2_LINUX_KERNEL_CUSTOM_TARBALL),y)
LINUX_TARBALL = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION))
LINUX_SITE = $(patsubst %/,%,$(dir $(LINUX_TARBALL)))
LINUX_SOURCE = $(notdir $(LINUX_TARBALL))
else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_GIT),y)
LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL))
LINUX_SITE_METHOD = git
else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_HG),y)
LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL))
LINUX_SITE_METHOD = hg
else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_SVN),y)
LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL))
LINUX_SITE_METHOD = svn
else ifeq ($(BR2_LINUX_KERNEL_LATEST_CIP_VERSION)$(BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION),y)
LINUX_SOURCE = linux-cip-$(LINUX_VERSION).tar.gz
LINUX_SITE = https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/snapshot
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
else
LINUX_SOURCE = linux-$(LINUX_VERSION).tar.xz
ifeq ($(findstring x2.6.,x$(LINUX_VERSION)),x2.6.)
LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v2.6
else
LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v$(firstword $(subst ., ,$(LINUX_VERSION))).x
endif
endif
ifeq ($(BR2_LINUX_KERNEL)$(BR2_LINUX_KERNEL_LATEST_VERSION),y)
BR_NO_CHECK_HASH_FOR += $(LINUX_SOURCE)
endif
LINUX_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH))
# 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))
# 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.
LINUX_MAKE_ENV = \
$(HOST_MAKE_ENV) \
BR_BINARIES_DIR=$(BINARIES_DIR)
LINUX_INSTALL_IMAGES = YES
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 += \
$(if $(BR2_PACKAGE_INTEL_MICROCODE),intel-microcode) \
$(if $(BR2_PACKAGE_LINUX_FIRMWARE),linux-firmware) \
$(if $(BR2_PACKAGE_FREESCALE_IMX),firmware-imx) \
$(if $(BR2_PACKAGE_WIRELESS_REGDB),wireless-regdb)
# 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)
# 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
# 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
else ifeq ($(BR2_LINUX_KERNEL_ZSTD),y)
LINUX_DEPENDENCIES += host-zstd
endif
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
LINUX_COMPRESSION_OPT_$(BR2_LINUX_KERNEL_ZSTD) += CONFIG_KERNEL_ZSTD
LINUX_COMPRESSION_OPT_$(BR2_LINUX_KERNEL_UNCOMPRESSED) += CONFIG_KERNEL_UNCOMPRESSED
ifeq ($(BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL),y)
LINUX_DEPENDENCIES += host-openssl
endif
ifeq ($(BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF),y)
LINUX_DEPENDENCIES += host-elfutils host-pkgconf
endif
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
# 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)
LINUX_DEPENDENCIES += host-uboot-tools
endif
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
# 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_MAKE_FLAGS = \
HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" \
ARCH=$(KERNEL_ARCH) \
INSTALL_MOD_PATH=$(TARGET_DIR) \
CROSS_COMPILE="$(TARGET_CROSS)" \
DEPMOD=$(HOST_DIR)/sbin/depmod
ifeq ($(BR2_REPRODUCIBLE),y)
LINUX_MAKE_ENV += \
KBUILD_BUILD_VERSION=1 \
KBUILD_BUILD_USER=buildroot \
KBUILD_BUILD_HOST=buildroot \
KBUILD_BUILD_TIMESTAMP="$(shell LC_ALL=C date -d @$(SOURCE_DATE_EPOCH))"
endif
# 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
ifeq ($(BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT),y)
LINUX_MAKE_ENV += DTC_FLAGS=-@
endif
# 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`
LINUX_DTS_NAME += $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTS_NAME))
# 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.
LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)))))
LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME))
ifeq ($(BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM),y)
LINUX_IMAGE_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_IMAGE_NAME))
LINUX_TARGET_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_IMAGE_TARGET_NAME))
ifeq ($(LINUX_IMAGE_NAME),)
LINUX_IMAGE_NAME = $(LINUX_TARGET_NAME)
endif
else
ifeq ($(BR2_LINUX_KERNEL_UIMAGE),y)
LINUX_IMAGE_NAME = uImage
else ifeq ($(BR2_LINUX_KERNEL_APPENDED_UIMAGE),y)
LINUX_IMAGE_NAME = uImage
else ifeq ($(BR2_LINUX_KERNEL_BZIMAGE),y)
LINUX_IMAGE_NAME = bzImage
else ifeq ($(BR2_LINUX_KERNEL_ZIMAGE),y)
LINUX_IMAGE_NAME = zImage
else ifeq ($(BR2_LINUX_KERNEL_ZIMAGE_EPAPR),y)
LINUX_IMAGE_NAME = zImage.epapr
else ifeq ($(BR2_LINUX_KERNEL_APPENDED_ZIMAGE),y)
LINUX_IMAGE_NAME = zImage
else ifeq ($(BR2_LINUX_KERNEL_CUIMAGE),y)
LINUX_IMAGE_NAME = cuImage.$(firstword $(LINUX_DTS_NAME))
else ifeq ($(BR2_LINUX_KERNEL_SIMPLEIMAGE),y)
LINUX_IMAGE_NAME = simpleImage.$(firstword $(LINUX_DTS_NAME))
else ifeq ($(BR2_LINUX_KERNEL_IMAGE),y)
LINUX_IMAGE_NAME = Image
else ifeq ($(BR2_LINUX_KERNEL_IMAGEGZ),y)
LINUX_IMAGE_NAME = Image.gz
else ifeq ($(BR2_LINUX_KERNEL_LINUX_BIN),y)
LINUX_IMAGE_NAME = linux.bin
else ifeq ($(BR2_LINUX_KERNEL_VMLINUX_BIN),y)
LINUX_IMAGE_NAME = vmlinux.bin
else ifeq ($(BR2_LINUX_KERNEL_VMLINUX),y)
LINUX_IMAGE_NAME = vmlinux
else ifeq ($(BR2_LINUX_KERNEL_VMLINUZ),y)
LINUX_IMAGE_NAME = vmlinuz
else ifeq ($(BR2_LINUX_KERNEL_VMLINUZ_BIN),y)
LINUX_IMAGE_NAME = vmlinuz.bin
endif
# 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
LINUX_TARGET_NAME = $(LINUX_IMAGE_NAME)
endif
.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))
ifneq ($(LINUX_KERNEL_UIMAGE_LOADADDR),)
LINUX_MAKE_FLAGS += LOADADDR="$(LINUX_KERNEL_UIMAGE_LOADADDR)"
endif
# 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)
LINUX_ARCH_PATH = $(LINUX_DIR)/arch/x86
else ifeq ($(KERNEL_ARCH),x86_64)
LINUX_ARCH_PATH = $(LINUX_DIR)/arch/x86
else ifeq ($(KERNEL_ARCH),sparc64)
LINUX_ARCH_PATH = $(LINUX_DIR)/arch/sparc
else
LINUX_ARCH_PATH = $(LINUX_DIR)/arch/$(KERNEL_ARCH)
endif
ifeq ($(BR2_LINUX_KERNEL_VMLINUX),y)
LINUX_IMAGE_PATH = $(LINUX_DIR)/$(LINUX_IMAGE_NAME)
else ifeq ($(BR2_LINUX_KERNEL_VMLINUZ),y)
LINUX_IMAGE_PATH = $(LINUX_DIR)/$(LINUX_IMAGE_NAME)
else ifeq ($(BR2_LINUX_KERNEL_VMLINUZ_BIN),y)
LINUX_IMAGE_PATH = $(LINUX_DIR)/$(LINUX_IMAGE_NAME)
else
LINUX_IMAGE_PATH = $(LINUX_ARCH_PATH)/boot/$(LINUX_IMAGE_NAME)
endif # BR2_LINUX_KERNEL_VMLINUX
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 \
$(APPLY_PATCHES) $(@D) $$p \*.patch || exit 1 ; \
else \
$(APPLY_PATCHES) $(@D) `dirname $$p` `basename $$p` || exit 1; \
fi \
done
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
# 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
# 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
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
ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
LINUX_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfig
else ifeq ($(BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG),y)
ifeq ($(BR2_powerpc64le),y)
LINUX_KCONFIG_DEFCONFIG = ppc64le_defconfig
else
LINUX_KCONFIG_DEFCONFIG = defconfig
endif
else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG),y)
LINUX_KCONFIG_FILE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE))
endif
LINUX_KCONFIG_FRAGMENT_FILES = $(call qstrip,$(BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES))
LINUX_KCONFIG_EDITORS = menuconfig xconfig gconfig nconfig
linux: don't override HOSTCC for kconfig Kconfig uses either pkg-config or hard-coded /usr/include paths to find the ncurses or ncursesw library. If ncursesw is found, it will include <ncursesw.h>. Since Buildroot's host-ncurses doesn't install a .pc file, and linux.mk anyway doesn't pass the pkg-config options to find the host pkg-config files, Kconfig will always find the system's ncursesw.h. However, since commit dde090c299 (linux: fix passing of host CFLAGS and LDFLAGS) HOST_LDFLAGS is passed to the linux build system. Thus, if host-ncurses was already built before 'make linux-menuconfig' is called, the build will pick up libncurses from the host directory, which is NOT widechar. Thus, two different ncurses configurations are mixed into the final mconf program. This will result in serious breakage in the rendering of the menus (lots of @ and question mark characters). As a workaround (suggested by Yann), don't pass HOST_CFLAGS and HOST_LDFLAGS when running kconfig commands. For kconfig, we should never need host packages anyway. This way, the kconfig calls will always use the system's ncurses and never our host-ncurses. Note that the same problem could pop up for other kconfig packages as well if we ever pass HOST_CFLAGS/HOST_LDFLAGS to them. We could force HOSTCC=$(HOSTCC) directly in kconfig-package. However, for now there are no other packages that exhibit this problem, so this can be revisited when they do. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: David De Grave <david.degrave@essensium.com> Cc: Scott Fan <fancp2007@gmail.com> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Tested-by: Matt Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-17 14:39:21 +02:00
# LINUX_MAKE_FLAGS overrides HOSTCC to allow the kernel build to find
# our host-openssl and host-libelf. However, this triggers a bug in
# the kconfig build script that causes it to build with
# /usr/include/ncurses.h (which is typically wchar) but link with
# $(HOST_DIR)/lib/libncurses.so (which is not). We don't actually
# need any host-package for kconfig, so remove the HOSTCC override
# again. 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)"
# If no package has yet set it, set it from the Kconfig option
LINUX_NEEDS_MODULES ?= $(BR2_LINUX_NEEDS_MODULES)
# Make sure the Linux kernel is built with the right endianness. Not
# all architectures support
# CONFIG_CPU_BIG_ENDIAN/CONFIG_CPU_LITTLE_ENDIAN in Linux, but the
# option will be thrown away and ignored if it doesn't exist.
ifeq ($(BR2_ENDIAN),"BIG")
define LINUX_FIXUP_CONFIG_ENDIANNESS
$(call KCONFIG_ENABLE_OPT,CONFIG_CPU_BIG_ENDIAN)
endef
else
define LINUX_FIXUP_CONFIG_ENDIANNESS
$(call KCONFIG_ENABLE_OPT,CONFIG_CPU_LITTLE_ENDIAN)
endef
endif
define LINUX_KCONFIG_FIXUP_CMDS
$(if $(LINUX_NEEDS_MODULES),
$(call KCONFIG_ENABLE_OPT,CONFIG_MODULES))
$(call KCONFIG_ENABLE_OPT,$(strip $(LINUX_COMPRESSION_OPT_y)))
$(foreach opt, $(LINUX_COMPRESSION_OPT_),
$(call KCONFIG_DISABLE_OPT,$(opt))
)
$(LINUX_FIXUP_CONFIG_ENDIANNESS)
$(LINUX_FIXUP_CONFIG_PAHOLE_CHECK)
$(if $(BR2_arm)$(BR2_armeb),
$(call KCONFIG_ENABLE_OPT,CONFIG_AEABI))
linux: disable Werror for powerpc kernels >From patch [1] included in kernel >= 5.0: "The upcoming GCC 9 release extends the -Wmissing-attributes warnings (enabled by -Wall) to C and aliases: it warns when particular function attributes are missing in the aliases but not in their target. In particular, it triggers for all the init/cleanup_module aliases in the kernel (defined by the module_init/exit macros), ending up being very noisy. These aliases point to the __init/__exit functions of a module, which are defined as __cold (among other attributes). However, the aliases themselves do not have the __cold attribute. Since the compiler behaves differently when compiling a __cold function as well as when compiling paths leading to calls to __cold functions, the warning is trying to point out the possibly-forgotten attribute in the alias." Werror is set by default while building ppc kernel [2], but some warning can be introduced while building current kernel with newer compiler (for example building kernel 4.19 with gcc 9.1). For the same reason why we remove Werror in packages's compiler flags. Building with Werror is not bulletproof when we start using a newer compiler that introduce new warnings. This is the case here. Also this option is a bit strange since it's specific to ppc kernels: "The intention is to make it harder for people to inadvertantly introduce warnings in the arch/powerpc code." Other kernel developers on other arch may be interested by a similar/more generic option. So, It's clearly intended for kernel developers. Instead of backporting this patch [1] to kernel 4.19, select unconditionally the Kconfig option CONFIG_PPC_DISABLE_WERROR that allow to disable Werror. Fixes: https://gitlab.com/kubu93/toolchains-builder/-/jobs/205435741 [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=a6e60d84989fa0e91db7f236eda40453b0e44afa [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=ba55bd74360ea4b8b95e73ed79474d37ff482b36 [3] https://gitlab.com/bootlin/toolchains-builder Fix-suggested-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-06-20 12:07:12 +02:00
$(if $(BR2_powerpc)$(BR2_powerpc64)$(BR2_powerpc64le),
$(call KCONFIG_ENABLE_OPT,CONFIG_PPC_DISABLE_WERROR))
$(if $(BR2_ARC_PAGE_SIZE_4K),
$(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))
$(if $(BR2_ARC_PAGE_SIZE_8K),
$(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))
$(if $(BR2_ARC_PAGE_SIZE_16K),
$(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))
$(if $(BR2_TARGET_ROOTFS_CPIO),
$(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
# built, we create a fake cpio file. It'll be
# replaced later by the real cpio archive, and the kernel will be
# rebuilt using the linux-rebuild-with-initramfs target.
$(if $(BR2_TARGET_ROOTFS_INITRAMFS),
mkdir -p $(BINARIES_DIR)
touch $(BINARIES_DIR)/rootfs.cpio
$(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))
$(if $(BR2_ROOTFS_DEVICE_CREATION_STATIC),,
$(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS)
$(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS_MOUNT))
$(if $(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV),
$(call KCONFIG_ENABLE_OPT,CONFIG_INOTIFY_USER))
$(if $(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV),
$(call KCONFIG_ENABLE_OPT,CONFIG_NET))
$(if $(BR2_LINUX_KERNEL_APPENDED_DTB),
$(call KCONFIG_ENABLE_OPT,CONFIG_ARM_APPENDED_DTB))
$(if $(LINUX_KERNEL_CUSTOM_LOGO_PATH),
$(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)
endef
ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT),y)
# 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
ifeq ($(BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT),)
define LINUX_BUILD_DTB
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(LINUX_DTBS)
endef
ifeq ($(BR2_LINUX_KERNEL_APPENDED_DTB),)
define LINUX_INSTALL_DTB
# dtbs moved from arch/<ARCH>/boot to arch/<ARCH>/boot/dts since 3.8-rc1
$(foreach dtb,$(LINUX_DTBS), \
install -D \
$(or $(wildcard $(LINUX_ARCH_PATH)/boot/dts/$(dtb)),$(LINUX_ARCH_PATH)/boot/$(dtb)) \
$(1)/$(if $(BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME),$(dtb),$(notdir $(dtb)))
)
endef
endif # BR2_LINUX_KERNEL_APPENDED_DTB
endif # BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT
endif # BR2_LINUX_KERNEL_DTS_SUPPORT
ifeq ($(BR2_LINUX_KERNEL_APPENDED_DTB),y)
# dtbs moved from arch/$ARCH/boot to arch/$ARCH/boot/dts since 3.8-rc1
define LINUX_APPEND_DTB
(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)
endef
ifeq ($(BR2_LINUX_KERNEL_APPENDED_UIMAGE),y)
# 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) |\
sed -n -e 's/Image Name:[ ]*\(.*\)/-n \1/p' -e 's/Load Address:/-a/p' -e 's/Entry Point:/-e/p'`; \
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} \
-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
endif
endif
# 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
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)
$(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)
$(LINUX_BUILD_DTB)
$(LINUX_APPEND_DTB)
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)
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.
define LINUX_INSTALL_IMAGE
$(INSTALL) -m 0644 -D $(LINUX_IMAGE_PATH) $(1)/$(notdir $(LINUX_IMAGE_NAME))
endef
linux: don't build appended DTB image in place and support multiple images Currently, the linux.mk logic for appended DTB image does the appending of the DTB in place, directly at the end of the zImage using a >> sign. This is incorrect because if you run "make linux-rebuild" multiple times, you get the DTB appended over and over again to the image. Since keeping the 'zImage' or 'uImage' name for the appended DTB image is not very clear, this commit moves to using the 'zImage.<dtb>' and 'uImage.<dtb>' format. This way, we can clearly distinguish the original image from the appended one. In addition, this naming scheme easily allows to generate *multiple* appended DTB images: from one zImage, you can generate multiple zImage.<dtb> for several DTBs, and then generate (if requested) the corresponding uImage.<dtb>. To achieve this, this commit: - Changes the definition of LINUX_APPENDED_DTB to iterate over $(KERNEL_DTS_NAME), and generate a zImage.<dtb> image for each of them. - Changes the addition of LINUX_APPENDED_DTB for appended uImage to also iterate over $(KERNEL_DTS_NAME). - Provide a different implementation of LINUX_INSTALL_IMAGE which installs all the appended DTB images (but not the bare image) - Remove the checks that verified that only one DT name is passed when appended DTB is used, since we now support generating multiple DT images. Some of the tested configuration: - Normal uImage with several DTBs BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7" BR2_LINUX_KERNEL_UIMAGE=y BR2_LINUX_KERNEL_UIMAGE_LOADADDR="0x200000" BR2_LINUX_KERNEL_DTS_SUPPORT=y BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-xp-matrix armada-xp-gp armada-370-mirabox" Contents of output/images/: armada-370-mirabox.dtb armada-xp-gp.dtb armada-xp-matrix.dtb uImage - Normal zImage with several DTBs BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7" BR2_LINUX_KERNEL_ZIMAGE=y BR2_LINUX_KERNEL_DTS_SUPPORT=y BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-xp-matrix armada-xp-gp armada-370-mirabox" Contents of output/images: armada-370-mirabox.dtb armada-xp-gp.dtb armada-xp-matrix.dtb zImage - Appended uImage with several DTBs: BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7" BR2_LINUX_KERNEL_APPENDED_UIMAGE=y BR2_LINUX_KERNEL_UIMAGE_LOADADDR="0x200000" BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-xp-matrix armada-xp-gp armada-370-mirabox" Contents of output/images: uImage.armada-370-mirabox uImage.armada-xp-gp uImage.armada-xp-matrix - Appended zImage with several DTBs: BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7" BR2_LINUX_KERNEL_APPENDED_ZIMAGE=y BR2_LINUX_KERNEL_INTREE_DTS_NAME="armada-xp-matrix armada-xp-gp armada-370-mirabox" Contents of output/images: zImage.armada-370-mirabox zImage.armada-xp-gp zImage.armada-xp-matrix In all configurations, the contents of output/target/boot/ was the same if BR2_LINUX_KERNEL_INSTALL_TARGET=y. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-18 23:05:02 +02:00
endif
ifeq ($(BR2_LINUX_KERNEL_INSTALL_TARGET),y)
define LINUX_INSTALL_KERNEL_IMAGE_TO_TARGET
$(call LINUX_INSTALL_IMAGE,$(TARGET_DIR)/boot)
$(call LINUX_INSTALL_DTB,$(TARGET_DIR)/boot)
endef
endif
define LINUX_INSTALL_HOST_TOOLS
# Installing dtc (device tree compiler) as host tool, if selected
if grep -q "CONFIG_DTC=y" $(@D)/.config; then \
$(INSTALL) -D -m 0755 $(@D)/scripts/dtc/dtc $(HOST_DIR)/bin/linux-dtc ; \
$(if $(BR2_PACKAGE_HOST_DTC),,ln -sf linux-dtc $(HOST_DIR)/bin/dtc;) \
fi
endef
define LINUX_INSTALL_IMAGES_CMDS
$(call LINUX_INSTALL_IMAGE,$(BINARIES_DIR))
$(call LINUX_INSTALL_DTB,$(BINARIES_DIR))
endef
2016-09-19 16:12:05 +02:00
ifeq ($(BR2_STRIP_strip),y)
LINUX_MAKE_FLAGS += INSTALL_MOD_STRIP=1
endif
define LINUX_INSTALL_TARGET_CMDS
$(LINUX_INSTALL_KERNEL_IMAGE_TO_TARGET)
# Install modules and remove symbolic links pointing to build
# directories, not relevant on the target
@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; \
rm -f $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/build ; \
rm -f $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/source ; \
fi
$(LINUX_INSTALL_HOST_TOOLS)
endef
# Run depmod in a target-finalize hook, to encompass modules installed by
# packages.
define LINUX_RUN_DEPMOD
if test -d $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED) \
&& grep -q "CONFIG_MODULES=y" $(LINUX_DIR)/.config; then \
$(HOST_DIR)/sbin/depmod -a -b $(TARGET_DIR) $(LINUX_VERSION_PROBED); \
fi
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.
#
# 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.
#
include $(sort $(wildcard $(foreach ext,$(BR2_EXTERNAL_DIRS), \
$(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))
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))
# Checks to give errors that the user can understand
# 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
ifeq ($(BR_BUILDING),y)
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
ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
# We must use the user-supplied kconfig value, because
# LINUX_KCONFIG_DEFCONFIG will at least contain the
# trailing _defconfig
ifeq ($(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG)),)
$(error No kernel defconfig name specified, check your BR2_LINUX_KERNEL_DEFCONFIG setting)
endif
endif
ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG),y)
ifeq ($(LINUX_KCONFIG_FILE),)
$(error No kernel configuration file specified, check your BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE setting)
endif
endif
ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT):$(strip $(LINUX_DTS_NAME)),y:)
$(error No kernel device tree source specified, check your \
BR2_LINUX_KERNEL_INTREE_DTS_NAME / BR2_LINUX_KERNEL_CUSTOM_DTS_PATH settings)
endif
endif # BR_BUILDING
$(eval $(kconfig-package))
# Support for rebuilding the kernel after the cpio archive has
# 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.
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(LINUX_DIR) $(LINUX_TARGET_NAME)
$(LINUX_APPEND_DTB)
# Copy the kernel image(s) to its(their) final destination
$(call LINUX_INSTALL_IMAGE,$(BINARIES_DIR))
# If there is a .ub file copy it to the final destination
test ! -f $(LINUX_IMAGE_PATH).ub || cp $(LINUX_IMAGE_PATH).ub $(BINARIES_DIR)