kumquat-buildroot/linux/linux.mk

456 lines
18 KiB
Makefile
Raw Normal View History

################################################################################
#
# Linux kernel target
#
################################################################################
LINUX_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
LINUX_LICENSE = GPLv2
LINUX_LICENSE_FILES = COPYING
# 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))
BR_NO_CHECK_HASH_FOR += $(LINUX_SOURCE)
else ifeq ($(BR2_LINUX_KERNEL_CUSTOM_LOCAL),y)
LINUX_SITE = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_LOCAL_PATH))
LINUX_SITE_METHOD = local
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
LINUX_SOURCE = linux-$(LINUX_VERSION).tar.xz
ifeq ($(BR2_LINUX_KERNEL_CUSTOM_VERSION),y)
BR_NO_CHECK_HASH_FOR += $(LINUX_SOURCE)
endif
# In X.Y.Z, get X and Y. We replace dots and dashes by spaces in order
# to use the $(word) function. We support versions such as 4.0, 3.1,
# 2.6.32, 2.6.32-rc1, 3.0-rc6, etc.
ifeq ($(findstring x2.6.,x$(LINUX_VERSION)),x2.6.)
LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v2.6
else ifeq ($(findstring x3.,x$(LINUX_VERSION)),x3.)
LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v3.x
else ifeq ($(findstring x4.,x$(LINUX_VERSION)),x4.)
LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v4.x
endif
# release candidates are in testing/ subdir
ifneq ($(findstring -rc,$(LINUX_VERSION)),)
LINUX_SITE := $(LINUX_SITE)/testing
endif # -rc
endif
LINUX_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH))
linux: use the package infrastructure to download patches The linux package has a special handling of patches, with quite a bit of legacy in it. A problem caused by this special handling is that the linux package calls directly the DOWNLOAD_WGET macro, which means that the package infrastructure isn't aware of which patches get downloaded, and it prevents doing changes inside the package download infrastructure. This commit changes the handling of patches in the linux package in the following way: * The LINUX_PATCHES variable is kept as is: it lists all the patches mentioned in the Config.in option BR2_LINUX_KERNEL_PATCH. This option can contain http://, ftp://, https:// URLs, path to local files or local directories. This variable is *not* used by the generic package infrastructure, so it is purely internal to the Linux package. * The LINUX_PATCH variable is now filled in with the list of patches that should be downloaded. It is derived from LINUX_PATCHES by filtering the patches that have http://, ftp:// or https:// in their path. Since <pkg>_PATCH is handled by the package infrastructure, it means that those patches are now automatically downloaded and applied by the package infrastructure. * The LINUX_APPLY_PATCHES hook is renamed to LINUX_APPLY_LOCAL_PATCHES, because it is now only responsible of applying local patches: remote patches are handled by LINUX_PATCH. The implementation of the hook is changed to filter out the patches that have already taken care of by LINUX_PATCH, so that we only iterate through the list of local patches or local patch directories. [Thomas: adjust comment in the code according to Yann comments.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2015-03-29 19:33:15 +02:00
# We rely on the generic package infrastructure to download and apply
# remote patches (downloaded from ftp, http or https). For local
# patches, we can't rely on that infrastructure, because there might
# be directories in the patch list (unlike for other packages).
LINUX_PATCH = $(filter ftp://% http://% https://%,$(LINUX_PATCHES))
LINUX_INSTALL_IMAGES = YES
LINUX_DEPENDENCIES += host-kmod
# host tools needed for kernel compression
ifeq ($(BR2_LINUX_KERNEL_LZ4),y)
LINUX_DEPENDENCIES += host-lz4
else ifeq ($(BR2_LINUX_KERNEL_LZMA),y)
LINUX_DEPENDENCIES += host-lzma
else ifeq ($(BR2_LINUX_KERNEL_LZO),y)
LINUX_DEPENDENCIES += host-lzop
else ifeq ($(BR2_LINUX_KERNEL_XZ),y)
LINUX_DEPENDENCIES += host-xz
endif
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
ifeq ($(BR2_LINUX_KERNEL_UBOOT_IMAGE),y)
LINUX_DEPENDENCIES += host-uboot-tools
endif
LINUX_MAKE_FLAGS = \
HOSTCC="$(HOSTCC)" \
HOSTCFLAGS="$(HOSTCFLAGS)" \
ARCH=$(KERNEL_ARCH) \
INSTALL_MOD_PATH=$(TARGET_DIR) \
CROSS_COMPILE="$(TARGET_CROSS)" \
DEPMOD=$(HOST_DIR)/sbin/depmod
linux: avoid unnecessary changes in defconfig for INITRAMFS_SOURCE When Buildroot is configured to append the root filesystem to the Linux kernel as initramfs, Buildroot sets the path to the initramfs source dynamically in the Linux configuration file. As this path is specified as an absolute path, typically being different for different users of the same project (e.g. containing a username), saving the configuration to a version control system (for example using 'make linux-update-defconfig') would result in a difference for this path at every invocation by a different user. Although this is technically not an issue, it is confusing that this generates a difference. Address this issue by using a not-yet-expanded make variable to specify the path to the initramfs source. That variable will be expanded by the Linux build system, which uses it both as a Makefile variable and a shell variable; thus, it needs to be specified in LINUX_MAKE_ENV (so it is exported and available in sub-processes of make). Any saved configuration file would simply contain the reference to the not-yet-expanded variable. As in the Linux build system, the config variables are both read from make as from a shell script, we cannot use $() syntax as this would be interpreted as a command invocation by the shell. Instead, use ${} syntax which is interpreted as variable reference both by the shell as by make. [Thomas: - Really make the patch work by using $(LINUX_MAKE_ENV) instead of $(TARGET_MAKE_ENV). Otherwise, the new BR2_BINARIES_DIR variable is not passed at all stages of the build process, which makes the build fail when an initramfs is used.] Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-03 15:21:48 +01:00
LINUX_MAKE_ENV = \
$(TARGET_MAKE_ENV) \
BR_BINARIES_DIR=$(BINARIES_DIR)
# Get the real Linux version, which tells us where kernel modules are
# going to be installed in the target filesystem.
LINUX_VERSION_PROBED = `$(MAKE) $(LINUX_MAKE_FLAGS) -C $(LINUX_DIR) --no-print-directory -s kernelrelease 2>/dev/null`
ifeq ($(BR2_LINUX_KERNEL_USE_INTREE_DTS),y)
KERNEL_DTS_NAME = $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTS_NAME))
else ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM_DTS),y)
# 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.
KERNEL_DTS_NAME = $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)))))
endif
KERNEL_DTBS = $(addsuffix .dtb,$(KERNEL_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.$(KERNEL_DTS_NAME)
else ifeq ($(BR2_LINUX_KERNEL_SIMPLEIMAGE),y)
LINUX_IMAGE_NAME = simpleImage.$(KERNEL_DTS_NAME)
else ifeq ($(BR2_LINUX_KERNEL_IMAGE),y)
LINUX_IMAGE_NAME = Image
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)
KERNEL_ARCH_PATH = $(LINUX_DIR)/arch/x86
else ifeq ($(KERNEL_ARCH),x86_64)
KERNEL_ARCH_PATH = $(LINUX_DIR)/arch/x86
else
KERNEL_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 = $(KERNEL_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 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
ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
LINUX_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfig
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_KCONFIG_OPTS = $(LINUX_MAKE_FLAGS)
# If no package has yet set it, set it from the Kconfig option
LINUX_NEEDS_MODULES ?= $(BR2_LINUX_NEEDS_MODULES)
define LINUX_KCONFIG_FIXUP_CMDS
$(if $(LINUX_NEEDS_MODULES),
$(call KCONFIG_ENABLE_OPT,CONFIG_MODULES,$(@D)/.config))
$(call KCONFIG_ENABLE_OPT,$(LINUX_COMPRESSION_OPT_y),$(@D)/.config)
$(foreach opt, $(LINUX_COMPRESSION_OPT_),
$(call KCONFIG_DISABLE_OPT,$(opt),$(@D)/.config)
)
$(if $(BR2_arm)$(BR2_armeb),
$(call KCONFIG_ENABLE_OPT,CONFIG_AEABI,$(@D)/.config))
$(if $(BR2_TARGET_ROOTFS_CPIO),
$(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_INITRD,$(@D)/.config))
linux: add support for initramfs In Buildroot, the kernel is built and installed *before* the root filesystems are built. This allows the root filesystem to correctly contain the kernel modules that have been installed. However, in the initramfs case, the root filesystem is part of the kernel. Therefore, the kernel should be built *after* the root filesystem (which, in the initramfs case simply builds a text file listing all files/directories/devices/symlinks that should be part of the initramfs). However, this isn't possible as the initramfs text file would lack all kernel modules. So, the solution choosen here is to keep the normal order: kernel is built before the root filesystem is generated, and to add a little quirk to retrigger a kernel compilation after the root filesystem generation. To do so, we add a ROOTFS_$(FSTYPE)_POST_TARGETS variable to the fs/common.mk infrastructure. This allows individual filesystems to set a target name that we should depend on *after* generating the root filesystem itself (contrary to normal ROOTFS_$(FSTYPE)_DEPENDENCIES, on which we depend *before* generating the root filesystem). The initramfs code in fs/initramfs/initramfs.mk uses this to add a dependency on 'linux26-rebuild-with-initramfs'. In linux/linux.mk, we do various things : * If BR2_TARGET_ROOTFS_INITRAMFS is enabled (i.e if initramfs is enabled as a root filesystem type), then we create an empty rootfs.initramfs file (remember that at this point, the root filesystem hasn't been generated) and we adjust the kernel configuration to include an initramfs. Of course, in the initial kernel build, this initramfs will be empty. * In the linux26-rebuild-with-initramfs target, we retrigger a compilation of the kernel image, after removing the initramfs in the kernel sources to make sure it gets properly rebuilt (we've experienced cases were modifying the rootfs.initramfs file wouldn't retrigger the generation of the initramfs at the kernel level). This is fairly quirky, but initramfs really is a special case, so in one way or another, we need a little quirk to solve its specialness. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2010-06-13 19:19:38 +02:00
# As the kernel gets compiled before root filesystems are
# 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),
touch $(BINARIES_DIR)/rootfs.cpio
linux: avoid unnecessary changes in defconfig for INITRAMFS_SOURCE When Buildroot is configured to append the root filesystem to the Linux kernel as initramfs, Buildroot sets the path to the initramfs source dynamically in the Linux configuration file. As this path is specified as an absolute path, typically being different for different users of the same project (e.g. containing a username), saving the configuration to a version control system (for example using 'make linux-update-defconfig') would result in a difference for this path at every invocation by a different user. Although this is technically not an issue, it is confusing that this generates a difference. Address this issue by using a not-yet-expanded make variable to specify the path to the initramfs source. That variable will be expanded by the Linux build system, which uses it both as a Makefile variable and a shell variable; thus, it needs to be specified in LINUX_MAKE_ENV (so it is exported and available in sub-processes of make). Any saved configuration file would simply contain the reference to the not-yet-expanded variable. As in the Linux build system, the config variables are both read from make as from a shell script, we cannot use $() syntax as this would be interpreted as a command invocation by the shell. Instead, use ${} syntax which is interpreted as variable reference both by the shell as by make. [Thomas: - Really make the patch work by using $(LINUX_MAKE_ENV) instead of $(TARGET_MAKE_ENV). Otherwise, the new BR2_BINARIES_DIR variable is not passed at all stages of the build process, which makes the build fail when an initramfs is used.] Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-03 15:21:48 +01:00
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_SOURCE,"$${BR_BINARIES_DIR}/rootfs.cpio",$(@D)/.config)
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_ROOT_UID,0,$(@D)/.config)
$(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_ROOT_GID,0,$(@D)/.config))
$(if $(BR2_ROOTFS_DEVICE_CREATION_STATIC),,
$(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS_MOUNT,$(@D)/.config))
$(if $(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV),
$(call KCONFIG_ENABLE_OPT,CONFIG_INOTIFY_USER,$(@D)/.config))
$(if $(BR2_PACKAGE_KTAP),
$(call KCONFIG_ENABLE_OPT,CONFIG_DEBUG_FS,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_ENABLE_DEFAULT_TRACERS,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_PERF_EVENTS,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_FUNCTION_TRACER,$(@D)/.config))
$(if $(BR2_PACKAGE_SYSTEMD),
$(call KCONFIG_ENABLE_OPT,CONFIG_CGROUPS,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_INOTIFY_USER,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_FHANDLE,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_XATTR,$(@D)/.config))
$(if $(BR2_PACKAGE_SMACK),
$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_SMACK,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_NETWORK,$(@D)/.config))
$(if $(BR2_PACKAGE_IPTABLES),
$(call KCONFIG_ENABLE_OPT,CONFIG_IP_NF_IPTABLES,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_IP_NF_FILTER,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER_XTABLES,$(@D)/.config))
$(if $(BR2_PACKAGE_XTABLES_ADDONS),
$(call KCONFIG_ENABLE_OPT,CONFIG_NETFILTER_ADVANCED,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_NF_CONNTRACK,$(@D)/.config)
$(call KCONFIG_ENABLE_OPT,CONFIG_NF_CONNTRACK_MARK,$(@D)/.config))
$(if $(BR2_LINUX_KERNEL_APPENDED_DTB),
$(call KCONFIG_ENABLE_OPT,CONFIG_ARM_APPENDED_DTB,$(@D)/.config))
$(if $(BR2_PACKAGE_KERNEL_MODULE_IMX_GPU_VIV),
$(call KCONFIG_DISABLE_OPT,CONFIG_MXC_GPU_VIV,$(@D)/.config))
endef
ifeq ($(BR2_LINUX_KERNEL_DTS_SUPPORT),y)
ifeq ($(BR2_LINUX_KERNEL_DTB_IS_SELF_BUILT),)
define LINUX_BUILD_DTB
linux: avoid unnecessary changes in defconfig for INITRAMFS_SOURCE When Buildroot is configured to append the root filesystem to the Linux kernel as initramfs, Buildroot sets the path to the initramfs source dynamically in the Linux configuration file. As this path is specified as an absolute path, typically being different for different users of the same project (e.g. containing a username), saving the configuration to a version control system (for example using 'make linux-update-defconfig') would result in a difference for this path at every invocation by a different user. Although this is technically not an issue, it is confusing that this generates a difference. Address this issue by using a not-yet-expanded make variable to specify the path to the initramfs source. That variable will be expanded by the Linux build system, which uses it both as a Makefile variable and a shell variable; thus, it needs to be specified in LINUX_MAKE_ENV (so it is exported and available in sub-processes of make). Any saved configuration file would simply contain the reference to the not-yet-expanded variable. As in the Linux build system, the config variables are both read from make as from a shell script, we cannot use $() syntax as this would be interpreted as a command invocation by the shell. Instead, use ${} syntax which is interpreted as variable reference both by the shell as by make. [Thomas: - Really make the patch work by using $(LINUX_MAKE_ENV) instead of $(TARGET_MAKE_ENV). Otherwise, the new BR2_BINARIES_DIR variable is not passed at all stages of the build process, which makes the build fail when an initramfs is used.] Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-03 15:21:48 +01:00
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(KERNEL_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
cp $(addprefix \
$(KERNEL_ARCH_PATH)/boot/$(if $(wildcard \
$(addprefix $(KERNEL_ARCH_PATH)/boot/dts/,$(KERNEL_DTBS))),dts/),$(KERNEL_DTBS)) \
$(1)
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
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
(cd $(KERNEL_ARCH_PATH)/boot; \
for dtb in $(KERNEL_DTS_NAME); do \
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'`; \
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
for dtb in $(KERNEL_DTS_NAME); do \
$(MKIMAGE) -A $(MKIMAGE_ARCH) -O linux \
-T kernel -C none $${MKIMAGE_ARGS} \
-d $(KERNEL_ARCH_PATH)/boot/zImage.$${dtb} $(LINUX_IMAGE_PATH).$${dtb}; \
done
endif
endif
# Compilation. We make sure the kernel gets rebuilt when the
# configuration has changed.
define LINUX_BUILD_CMDS
$(if $(BR2_LINUX_KERNEL_USE_CUSTOM_DTS),
cp -f $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)) $(KERNEL_ARCH_PATH)/boot/dts/)
linux: avoid unnecessary changes in defconfig for INITRAMFS_SOURCE When Buildroot is configured to append the root filesystem to the Linux kernel as initramfs, Buildroot sets the path to the initramfs source dynamically in the Linux configuration file. As this path is specified as an absolute path, typically being different for different users of the same project (e.g. containing a username), saving the configuration to a version control system (for example using 'make linux-update-defconfig') would result in a difference for this path at every invocation by a different user. Although this is technically not an issue, it is confusing that this generates a difference. Address this issue by using a not-yet-expanded make variable to specify the path to the initramfs source. That variable will be expanded by the Linux build system, which uses it both as a Makefile variable and a shell variable; thus, it needs to be specified in LINUX_MAKE_ENV (so it is exported and available in sub-processes of make). Any saved configuration file would simply contain the reference to the not-yet-expanded variable. As in the Linux build system, the config variables are both read from make as from a shell script, we cannot use $() syntax as this would be interpreted as a command invocation by the shell. Instead, use ${} syntax which is interpreted as variable reference both by the shell as by make. [Thomas: - Really make the patch work by using $(LINUX_MAKE_ENV) instead of $(TARGET_MAKE_ENV). Otherwise, the new BR2_BINARIES_DIR variable is not passed at all stages of the build process, which makes the build fail when an initramfs is used.] Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-03 15:21:48 +01:00
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(LINUX_TARGET_NAME)
@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) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) modules ; \
fi
$(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 $(KERNEL_ARCH_PATH)/boot/$(LINUX_IMAGE_NAME).* $(1)
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)/$(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)/usr/bin/linux-dtc ; \
fi
endef
define LINUX_INSTALL_IMAGES_CMDS
$(call LINUX_INSTALL_IMAGE,$(BINARIES_DIR))
$(call LINUX_INSTALL_DTB,$(BINARIES_DIR))
endef
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
# Include all our extensions and tools definitions.
#
# Note: our package infrastructure uses the full-path of the last-scanned
# Makefile to determine what package we're currently defining, using the
# last directory component in the path. As such, including other Makefile,
# like below, before we call one of the *-package macro is usally not
# working.
# However, since the files we include here are in the same directory as
# the current Makefile, we are OK. But this is a hard requirement: files
# included here *must* be in the same directory!
include $(sort $(wildcard linux/linux-ext-*.mk))
include $(sort $(wildcard linux/linux-tool-*.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))
# Install Linux kernel tools in the staging directory since some tools
# may install shared libraries and headers (e.g. cpupower). The kernel
# image is NOT installed in the staging directory.
LINUX_INSTALL_STAGING = YES
LINUX_DEPENDENCIES += $(foreach tool,$(LINUX_TOOLS),\
$(if $(BR2_LINUX_KERNEL_TOOL_$(call UPPERCASE,$(tool))),\
$($(call UPPERCASE,$(tool))_DEPENDENCIES)))
LINUX_POST_BUILD_HOOKS += $(foreach tool,$(LINUX_TOOLS),\
$(if $(BR2_LINUX_KERNEL_TOOL_$(call UPPERCASE,$(tool))),\
$(call UPPERCASE,$(tool))_BUILD_CMDS))
LINUX_POST_INSTALL_STAGING_HOOKS += $(foreach tool,$(LINUX_TOOLS),\
$(if $(BR2_LINUX_KERNEL_TOOL_$(call UPPERCASE,$(tool))),\
$(call UPPERCASE,$(tool))_INSTALL_STAGING_CMDS))
LINUX_POST_INSTALL_TARGET_HOOKS += $(foreach tool,$(LINUX_TOOLS),\
$(if $(BR2_LINUX_KERNEL_TOOL_$(call UPPERCASE,$(tool))),\
$(call UPPERCASE,$(tool))_INSTALL_TARGET_CMDS))
# Checks to give errors that the user can understand
ifeq ($(BR_BUILDING),y)
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)$(KERNEL_DTS_NAME),y)
$(error No kernel device tree source specified, check your \
BR2_LINUX_KERNEL_USE_INTREE_DTS / BR2_LINUX_KERNEL_USE_CUSTOM_DTS settings)
endif
endif # BR_BUILDING
$(eval $(kconfig-package))
# Support for rebuilding the kernel after the cpio archive has
# been generated in $(BINARIES_DIR)/rootfs.cpio.
$(LINUX_DIR)/.stamp_initramfs_rebuilt: $(LINUX_DIR)/.stamp_target_installed $(LINUX_DIR)/.stamp_images_installed $(BINARIES_DIR)/rootfs.cpio
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: avoid unnecessary changes in defconfig for INITRAMFS_SOURCE When Buildroot is configured to append the root filesystem to the Linux kernel as initramfs, Buildroot sets the path to the initramfs source dynamically in the Linux configuration file. As this path is specified as an absolute path, typically being different for different users of the same project (e.g. containing a username), saving the configuration to a version control system (for example using 'make linux-update-defconfig') would result in a difference for this path at every invocation by a different user. Although this is technically not an issue, it is confusing that this generates a difference. Address this issue by using a not-yet-expanded make variable to specify the path to the initramfs source. That variable will be expanded by the Linux build system, which uses it both as a Makefile variable and a shell variable; thus, it needs to be specified in LINUX_MAKE_ENV (so it is exported and available in sub-processes of make). Any saved configuration file would simply contain the reference to the not-yet-expanded variable. As in the Linux build system, the config variables are both read from make as from a shell script, we cannot use $() syntax as this would be interpreted as a command invocation by the shell. Instead, use ${} syntax which is interpreted as variable reference both by the shell as by make. [Thomas: - Really make the patch work by using $(LINUX_MAKE_ENV) instead of $(TARGET_MAKE_ENV). Otherwise, the new BR2_BINARIES_DIR variable is not passed at all stages of the build process, which makes the build fail when an initramfs is used.] Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: "Yann E. Morin" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-03 15:21:48 +01:00
$(LINUX_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(LINUX_TARGET_NAME)
$(LINUX_APPEND_DTB)
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
# Copy the kernel image to its final destination
cp $(LINUX_IMAGE_PATH) $(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)
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
$(Q)touch $@
# The initramfs building code must make sure this target gets called
# after it generated the initramfs list of files.
linux-rebuild-with-initramfs: $(LINUX_DIR)/.stamp_initramfs_rebuilt