kumquat-buildroot/boot/barebox/barebox.mk

179 lines
5.9 KiB
Makefile
Raw Normal View History

################################################################################
#
# barebox
#
################################################################################
################################################################################
# inner-barebox-package -- generates the KConfig logic and make targets needed
# to support a barebox package. All barebox packages are built from the same
# source (origin, version and patches). The remainder of the package
# configuration is unique to each barebox package.
#
# argument 1 is the uppercase package name (used for variable name-space)
################################################################################
define inner-barebox-package
$(1)_VERSION = $$(call qstrip,$$(BR2_TARGET_BAREBOX_VERSION))
ifeq ($$(BR2_TARGET_BAREBOX_CUSTOM_TARBALL),y)
# Handle custom Barebox tarballs as specified by the configuration
$(1)_TARBALL = $$(call qstrip,$$(BR2_TARGET_BAREBOX_CUSTOM_TARBALL_LOCATION))
$(1)_SITE = $$(patsubst %/,%,$$(dir $$($(1)_TARBALL)))
$(1)_SOURCE = $$(notdir $$($(1)_TARBALL))
else ifeq ($$(BR2_TARGET_BAREBOX_CUSTOM_GIT),y)
$(1)_SITE = $$(call qstrip,$$(BR2_TARGET_BAREBOX_CUSTOM_GIT_REPO_URL))
$(1)_SITE_METHOD = git
# Override the default value of _SOURCE to 'barebox-*' so that it is not
# downloaded a second time for barebox-aux; also alows avoiding the hash
# check:
$(1)_SOURCE = barebox-$$($(1)_VERSION)$$(BR_FMT_VERSION_git).tar.gz
else
# Handle stable official Barebox versions
$(1)_SOURCE = barebox-$$($(1)_VERSION).tar.bz2
$(1)_SITE = https://www.barebox.org/download
endif
$(1)_DL_SUBDIR = barebox
$(1)_DEPENDENCIES = host-lzop
$(1)_LICENSE = GPL-2.0 with exceptions
ifeq ($(BR2_TARGET_BAREBOX_LATEST_VERSION),y)
$(1)_LICENSE_FILES = COPYING
endif
$(1)_CUSTOM_EMBEDDED_ENV_PATH = $$(call qstrip,$$(BR2_TARGET_$(1)_CUSTOM_EMBEDDED_ENV_PATH))
ifneq ($$(call qstrip,$$(BR2_TARGET_BAREBOX_CUSTOM_PATCH_DIR)),)
define $(1)_APPLY_CUSTOM_PATCHES
$$(APPLY_PATCHES) $$(@D) \
$$(BR2_TARGET_BAREBOX_CUSTOM_PATCH_DIR) \*.patch
endef
$(1)_POST_PATCH_HOOKS += $(1)_APPLY_CUSTOM_PATCHES
endif
$(1)_INSTALL_IMAGES = YES
ifneq ($$(BR2_TARGET_$(1)_BAREBOXENV),y)
$(1)_INSTALL_TARGET = NO
endif
core: introduce NORMALIZED_ARCH as non-kernel replacement for KERNEL_ARCH The variable 'KERNEL_ARCH' is actually a normalized version of 'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just as all powerpc variants become 'powerpc'. It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically the first place where support for a new architecture is added, and thus is the entity that defines the normalized name. However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture used by the kernel', which need not be exactly the same as 'the normalized name for a certain arch'. In particular, for cases where a 64-bit architecture is running a 64-bit kernel but 32-bit userspace. Examples include: * aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace * x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace In such cases, the 'architecture used by the kernel' needs to refer to the 64-bit name (aarch64, x86_64), whereas all userspace applications need to refer the, potentially normalized, 32-bit name. This means that there need to be two different variables: KERNEL_ARCH: the architecture used by the kernel NORMALIZED_ARCH: the normalized name for the current userspace architecture At this moment, both will actually have the same content. But a subsequent patch will add basic support for situations described above, in which KERNEL_ARCH may become overwritten to the 64-bit architecture, while NORMALIZED_ARCH needs to remain the same (32-bit) case. This commit replaces use of KERNEL_ARCH where actually the userspace arch is needed. Places that use KERNEL_ARCH in combination with building of kernel modules are not touched. There may be cases where a package builds both a kernel module as userspace, in which case it may need to know about both KERNEL_ARCH and NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on a per-need basis. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> [Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-15 21:03:00 +01:00
ifeq ($$(NORMALIZED_ARCH),i386)
$(1)_ARCH = x86
core: introduce NORMALIZED_ARCH as non-kernel replacement for KERNEL_ARCH The variable 'KERNEL_ARCH' is actually a normalized version of 'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just as all powerpc variants become 'powerpc'. It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically the first place where support for a new architecture is added, and thus is the entity that defines the normalized name. However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture used by the kernel', which need not be exactly the same as 'the normalized name for a certain arch'. In particular, for cases where a 64-bit architecture is running a 64-bit kernel but 32-bit userspace. Examples include: * aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace * x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace In such cases, the 'architecture used by the kernel' needs to refer to the 64-bit name (aarch64, x86_64), whereas all userspace applications need to refer the, potentially normalized, 32-bit name. This means that there need to be two different variables: KERNEL_ARCH: the architecture used by the kernel NORMALIZED_ARCH: the normalized name for the current userspace architecture At this moment, both will actually have the same content. But a subsequent patch will add basic support for situations described above, in which KERNEL_ARCH may become overwritten to the 64-bit architecture, while NORMALIZED_ARCH needs to remain the same (32-bit) case. This commit replaces use of KERNEL_ARCH where actually the userspace arch is needed. Places that use KERNEL_ARCH in combination with building of kernel modules are not touched. There may be cases where a package builds both a kernel module as userspace, in which case it may need to know about both KERNEL_ARCH and NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on a per-need basis. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> [Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-15 21:03:00 +01:00
else ifeq ($$(NORMALIZED_ARCH),x86_64)
$(1)_ARCH = x86
core: introduce NORMALIZED_ARCH as non-kernel replacement for KERNEL_ARCH The variable 'KERNEL_ARCH' is actually a normalized version of 'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just as all powerpc variants become 'powerpc'. It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically the first place where support for a new architecture is added, and thus is the entity that defines the normalized name. However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture used by the kernel', which need not be exactly the same as 'the normalized name for a certain arch'. In particular, for cases where a 64-bit architecture is running a 64-bit kernel but 32-bit userspace. Examples include: * aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace * x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace In such cases, the 'architecture used by the kernel' needs to refer to the 64-bit name (aarch64, x86_64), whereas all userspace applications need to refer the, potentially normalized, 32-bit name. This means that there need to be two different variables: KERNEL_ARCH: the architecture used by the kernel NORMALIZED_ARCH: the normalized name for the current userspace architecture At this moment, both will actually have the same content. But a subsequent patch will add basic support for situations described above, in which KERNEL_ARCH may become overwritten to the 64-bit architecture, while NORMALIZED_ARCH needs to remain the same (32-bit) case. This commit replaces use of KERNEL_ARCH where actually the userspace arch is needed. Places that use KERNEL_ARCH in combination with building of kernel modules are not touched. There may be cases where a package builds both a kernel module as userspace, in which case it may need to know about both KERNEL_ARCH and NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on a per-need basis. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> [Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-15 21:03:00 +01:00
else ifeq ($$(NORMALIZED_ARCH),powerpc)
$(1)_ARCH = ppc
core: introduce NORMALIZED_ARCH as non-kernel replacement for KERNEL_ARCH The variable 'KERNEL_ARCH' is actually a normalized version of 'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just as all powerpc variants become 'powerpc'. It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically the first place where support for a new architecture is added, and thus is the entity that defines the normalized name. However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture used by the kernel', which need not be exactly the same as 'the normalized name for a certain arch'. In particular, for cases where a 64-bit architecture is running a 64-bit kernel but 32-bit userspace. Examples include: * aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace * x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace In such cases, the 'architecture used by the kernel' needs to refer to the 64-bit name (aarch64, x86_64), whereas all userspace applications need to refer the, potentially normalized, 32-bit name. This means that there need to be two different variables: KERNEL_ARCH: the architecture used by the kernel NORMALIZED_ARCH: the normalized name for the current userspace architecture At this moment, both will actually have the same content. But a subsequent patch will add basic support for situations described above, in which KERNEL_ARCH may become overwritten to the 64-bit architecture, while NORMALIZED_ARCH needs to remain the same (32-bit) case. This commit replaces use of KERNEL_ARCH where actually the userspace arch is needed. Places that use KERNEL_ARCH in combination with building of kernel modules are not touched. There may be cases where a package builds both a kernel module as userspace, in which case it may need to know about both KERNEL_ARCH and NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on a per-need basis. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> [Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-15 21:03:00 +01:00
else ifeq ($$(NORMALIZED_ARCH),arm64)
$(1)_ARCH = arm
else
core: introduce NORMALIZED_ARCH as non-kernel replacement for KERNEL_ARCH The variable 'KERNEL_ARCH' is actually a normalized version of 'ARCH'/'BR2_ARCH'. For example, 'arcle' and 'arceb' both become 'arc', just as all powerpc variants become 'powerpc'. It is presumably called 'KERNEL_ARCH' because the Linux kernel is typically the first place where support for a new architecture is added, and thus is the entity that defines the normalized name. However, the term 'KERNEL_ARCH' can also be interpreted as 'the architecture used by the kernel', which need not be exactly the same as 'the normalized name for a certain arch'. In particular, for cases where a 64-bit architecture is running a 64-bit kernel but 32-bit userspace. Examples include: * aarch64 architecture, with aarch64 kernel and 32-bit (ARM) userspace * x86_64 architecture, with x86_64 kernel and 32-bit (i386) userspace In such cases, the 'architecture used by the kernel' needs to refer to the 64-bit name (aarch64, x86_64), whereas all userspace applications need to refer the, potentially normalized, 32-bit name. This means that there need to be two different variables: KERNEL_ARCH: the architecture used by the kernel NORMALIZED_ARCH: the normalized name for the current userspace architecture At this moment, both will actually have the same content. But a subsequent patch will add basic support for situations described above, in which KERNEL_ARCH may become overwritten to the 64-bit architecture, while NORMALIZED_ARCH needs to remain the same (32-bit) case. This commit replaces use of KERNEL_ARCH where actually the userspace arch is needed. Places that use KERNEL_ARCH in combination with building of kernel modules are not touched. There may be cases where a package builds both a kernel module as userspace, in which case it may need to know about both KERNEL_ARCH and NORMALIZED_ARCH, for the case where they differ. But this is to be fixed on a per-need basis. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> [Arnout: Also rename BR2_KERNEL_ARCH to BR2_NORMALIZED_ARCH] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-01-15 21:03:00 +01:00
$(1)_ARCH = $$(NORMALIZED_ARCH)
endif
$(1)_MAKE_FLAGS = ARCH=$$($(1)_ARCH) CROSS_COMPILE="$$(TARGET_CROSS)"
$(1)_MAKE_ENV = $$(TARGET_MAKE_ENV)
ifeq ($$(BR2_TARGET_$(1)_USE_DEFCONFIG),y)
$(1)_KCONFIG_DEFCONFIG = $$(call qstrip,$$(BR2_TARGET_$(1)_BOARD_DEFCONFIG))_defconfig
else ifeq ($$(BR2_TARGET_$(1)_USE_CUSTOM_CONFIG),y)
$(1)_KCONFIG_FILE = $$(call qstrip,$$(BR2_TARGET_$(1)_CUSTOM_CONFIG_FILE))
endif
$(1)_KCONFIG_FRAGMENT_FILES = $$(call qstrip,$$(BR2_TARGET_$(1)_CONFIG_FRAGMENT_FILES))
$(1)_KCONFIG_EDITORS = menuconfig xconfig gconfig nconfig
$(1)_KCONFIG_OPTS = $$($(1)_MAKE_FLAGS)
$(1)_KCONFIG_DEPENDENCIES = \
$(BR2_BISON_HOST_DEPENDENCY) \
$(BR2_FLEX_HOST_DEPENDENCY)
ifeq ($$(BR2_TARGET_$(1)_CUSTOM_ENV),y)
$(1)_ENV_NAME = $$(notdir $$(call qstrip,\
$$(BR2_TARGET_$(1)_CUSTOM_ENV_PATH)))
define $(1)_BUILD_CUSTOM_ENV
$$(@D)/scripts/bareboxenv -s \
$$(call qstrip, $$(BR2_TARGET_$(1)_CUSTOM_ENV_PATH)) \
$$(@D)/$$($(1)_ENV_NAME)
endef
define $(1)_INSTALL_CUSTOM_ENV
cp $$(@D)/$$($(1)_ENV_NAME) $$(BINARIES_DIR)
endef
endif
ifneq ($$($(1)_CUSTOM_EMBEDDED_ENV_PATH),)
boot/barebox: fix target bareboxenv command compile The buildroot custom bareboxenv compile command misses the additional include path 'scripts/include' to gain access to the local copy of the kernel header files (which leads to compile error when using an older toolchain). This could be fixed by enhancing the custom bareboxenv compile command (see [1]) or by using the barebox build system by simply enabling the CONFIG_BAREBOXENV_TARGET option (available since April 2012, see [2]) instead (as suggested by Yann E. MORIN). Fixes (with BR2_TARGET_BAREBOX_BAREBOXENV enabled): build/barebox-2019.12.0/scripts/bareboxenv.c:100:10: fatal error: linux/list.h: No such file or directory [1] http://lists.busybox.net/pipermail/buildroot/2020-January/270942.html [2] https://git.pengutronix.de/cgit/barebox/commit/?id=afb03d7a554a2911a3742e316f011319fcb416f1 Note: a user who would previously provide a barebox config file which had CONFIG_BAREBOXENV_TARGET=y, but a Buildroot config file which did not have BR2_TARGET_BAREBOX_BAREBOXENV=y, would have bareboxenv-target built, but it would not be installed in the target. Now, and unset BR2_TARGET_BAREBOX_BAREBOXENV will not even build it, but his is not a regression: it was anyway previously not installed. Reported-by: Frederick Gotham <cauldwell.thomas@gmail.com> Signed-off-by: Peter Seiderer <ps.report@gmx.net> [yann.morin.1998@free.fr: - also explicitly disable it when not selected - rewrap commit log ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-10-03 11:59:02 +02:00
define $(1)_KCONFIG_FIXUP_CUSTOM_EMBEDDED_ENV_PATH
$$(call KCONFIG_ENABLE_OPT,CONFIG_DEFAULT_ENVIRONMENT)
$$(call KCONFIG_SET_OPT,CONFIG_DEFAULT_ENVIRONMENT_PATH,"$$($(1)_CUSTOM_EMBEDDED_ENV_PATH)")
endef
endif
boot/barebox: fix target bareboxenv command compile The buildroot custom bareboxenv compile command misses the additional include path 'scripts/include' to gain access to the local copy of the kernel header files (which leads to compile error when using an older toolchain). This could be fixed by enhancing the custom bareboxenv compile command (see [1]) or by using the barebox build system by simply enabling the CONFIG_BAREBOXENV_TARGET option (available since April 2012, see [2]) instead (as suggested by Yann E. MORIN). Fixes (with BR2_TARGET_BAREBOX_BAREBOXENV enabled): build/barebox-2019.12.0/scripts/bareboxenv.c:100:10: fatal error: linux/list.h: No such file or directory [1] http://lists.busybox.net/pipermail/buildroot/2020-January/270942.html [2] https://git.pengutronix.de/cgit/barebox/commit/?id=afb03d7a554a2911a3742e316f011319fcb416f1 Note: a user who would previously provide a barebox config file which had CONFIG_BAREBOXENV_TARGET=y, but a Buildroot config file which did not have BR2_TARGET_BAREBOX_BAREBOXENV=y, would have bareboxenv-target built, but it would not be installed in the target. Now, and unset BR2_TARGET_BAREBOX_BAREBOXENV will not even build it, but his is not a regression: it was anyway previously not installed. Reported-by: Frederick Gotham <cauldwell.thomas@gmail.com> Signed-off-by: Peter Seiderer <ps.report@gmx.net> [yann.morin.1998@free.fr: - also explicitly disable it when not selected - rewrap commit log ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-10-03 11:59:02 +02:00
define $(1)_KCONFIG_FIXUP_BAREBOXENV
$$(if $$(BR2_TARGET_$(1)_BAREBOXENV),\
$$(call KCONFIG_ENABLE_OPT,CONFIG_BAREBOXENV_TARGET),\
$$(call KCONFIG_DISABLE_OPT,CONFIG_BAREBOXENV_TARGET))
endef
define $(1)_KCONFIG_FIXUP_CMDS
$$($(1)_KCONFIG_FIXUP_CUSTOM_EMBEDDED_ENV_PATH)
$$($(1)_KCONFIG_FIXUP_BAREBOXENV)
endef
define $(1)_BUILD_CMDS
$$($(1)_BUILD_BAREBOXENV_CMDS)
$$(TARGET_MAKE_ENV) $$(MAKE) $$($(1)_MAKE_FLAGS) -C $$(@D)
$$($(1)_BUILD_CUSTOM_ENV)
endef
$(1)_IMAGE_FILES = $$(call qstrip,$$(BR2_TARGET_$(1)_IMAGE_FILE))
define $(1)_INSTALL_IMAGES_CMDS
if test -n "$$($(1)_IMAGE_FILES)"; then \
cp -L $$(foreach image,$$($(1)_IMAGE_FILES),$$(@D)/$$(image)) $$(BINARIES_DIR) ; \
elif test -h $$(@D)/barebox-flash-image ; then \
cp -L $$(@D)/barebox-flash-image $$(BINARIES_DIR)/barebox.bin ; \
else \
cp $$(@D)/barebox.bin $$(BINARIES_DIR);\
fi
$$($(1)_INSTALL_CUSTOM_ENV)
endef
# Starting with barebox v2020.09.0, the kconfig used calls the
# cross-compiler to check its capabilities. So we need the
# toolchain before we can call the configurators.
$(1)_KCONFIG_DEPENDENCIES += toolchain
ifeq ($$(BR2_TARGET_$(1)_BAREBOXENV),y)
define $(1)_INSTALL_TARGET_CMDS
boot/barebox: fix target bareboxenv command compile The buildroot custom bareboxenv compile command misses the additional include path 'scripts/include' to gain access to the local copy of the kernel header files (which leads to compile error when using an older toolchain). This could be fixed by enhancing the custom bareboxenv compile command (see [1]) or by using the barebox build system by simply enabling the CONFIG_BAREBOXENV_TARGET option (available since April 2012, see [2]) instead (as suggested by Yann E. MORIN). Fixes (with BR2_TARGET_BAREBOX_BAREBOXENV enabled): build/barebox-2019.12.0/scripts/bareboxenv.c:100:10: fatal error: linux/list.h: No such file or directory [1] http://lists.busybox.net/pipermail/buildroot/2020-January/270942.html [2] https://git.pengutronix.de/cgit/barebox/commit/?id=afb03d7a554a2911a3742e316f011319fcb416f1 Note: a user who would previously provide a barebox config file which had CONFIG_BAREBOXENV_TARGET=y, but a Buildroot config file which did not have BR2_TARGET_BAREBOX_BAREBOXENV=y, would have bareboxenv-target built, but it would not be installed in the target. Now, and unset BR2_TARGET_BAREBOX_BAREBOXENV will not even build it, but his is not a regression: it was anyway previously not installed. Reported-by: Frederick Gotham <cauldwell.thomas@gmail.com> Signed-off-by: Peter Seiderer <ps.report@gmx.net> [yann.morin.1998@free.fr: - also explicitly disable it when not selected - rewrap commit log ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-10-03 11:59:02 +02:00
cp $$(@D)/scripts/bareboxenv-target $$(TARGET_DIR)/usr/bin/bareboxenv
endef
endif
# Checks to give errors that the user can understand
# Must be before we call to kconfig-package
ifeq ($$(BR2_TARGET_$(1))$$(BR_BUILDING),yy)
# We must use the user-supplied kconfig value, because
# $(1)_KCONFIG_DEFCONFIG will at least contain the
# trailing _defconfig
ifeq ($$(or $$($(1)_KCONFIG_FILE),$$(call qstrip,$$(BR2_TARGET_$(1)_BOARD_DEFCONFIG))),)
$$(error No Barebox config. Check your BR2_TARGET_$(1)_BOARD_DEFCONFIG or BR2_TARGET_$(1)_CUSTOM_CONFIG_FILE settings)
endif
endif
$$(eval $$(kconfig-package))
endef
################################################################################
# barebox-package -- the target generator macro for barebox packages
################################################################################
barebox-package=$(call inner-barebox-package,$(call UPPERCASE,$(pkgname)))
include boot/barebox/barebox/barebox.mk
barebox: support auxiliary config build Adds support to build barebox with an auxiliary config. This is useful for building an SPL (Secondary Program Loader) in addition to the traditional TPL (Tertiary Program Loader). The Beaglebone Black for example has two barebox configurations: - am335x_defconfig builds the full barebox bootloader with device tree - am335x_mlo_defconfig builds the smaller MLO bootloader that loads the full barebox bootloader from the eMMC or SD card. Tested with the following defconfig: # architecture BR2_arm=y BR2_cortex_a8=y BR2_ARM_EABIHF=y # system BR2_TARGET_GENERIC_HOSTNAME="beaglebone" BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS=y BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW=y # filesystem BR2_PACKAGE_AM33X_CM3=y BR2_TARGET_ROOTFS_EXT2=y BR2_TARGET_ROOTFS_EXT2_4=y # bootloader BR2_TARGET_BAREBOX=y BR2_TARGET_BAREBOX_BOARD_DEFCONFIG="am335x" BR2_TARGET_BAREBOX_IMAGE_FILE="images/barebox-am33xx-beaglebone.img" BR2_TARGET_BAREBOX_CUSTOM_ENV=y BR2_TARGET_BAREBOX_CUSTOM_ENV_PATH="board/beaglebone/barebox/barebox.env" BR2_TARGET_BAREBOX_AUX=y BR2_TARGET_BAREBOX_AUX_BOARD_DEFCONFIG="am335x_mlo" BR2_TARGET_BAREBOX_AUX_IMAGE_FILE="images/barebox-am33xx-beaglebone-mlo.img" # kernel BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_USE_DEFCONFIG=y BR2_LINUX_KERNEL_DEFCONFIG="omap2plus" BR2_LINUX_KERNEL_ZIMAGE=y # use the barebox built-in dtb # BR2_LINUX_KERNEL_DTS_SUPPORT is not set Signed-off-by: Pieter Smith <pieter@boesman.nl> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-24 23:15:24 +02:00
include boot/barebox/barebox-aux/barebox-aux.mk
ifeq ($(BR2_TARGET_BAREBOX)$(BR2_TARGET_BAREBOX_LATEST_VERSION),y)
BR_NO_CHECK_HASH_FOR += $(BAREBOX_SOURCE)
endif