NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
42075dbed8
kumquat-buildroot/boot/at91bootstrap3/at91bootstrap3.mk

59 lines
2.0 KiB
Makefile
Raw Normal View History

Normalize separator size to 80 Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-06 23:54:13 +02:00
################################################################################
at91bootstrap3: new package Note that this new package, at91bootstrap3, is being added alongside the existing at91bootstrap. This was suggested by Thomas Petazzoni, whose comments on the mailing list are quoted below. For this package, I am not sure we can do a simple version bump. Since there is (was?) no upstream for AT91Bootstrap 1.x, many vendors/companies had to maintain their patches on top of AT91Bootstrap 1.x. See for example board/calao/usb-a9263/at91bootstrap-1.16-usb-a9263.patch. Therefore, removing AT91Bootstrap 1.x from the tree will prevent those platforms to work. I know people should upgrade, but AT91Bootstrap 3.x is quite significantly different, so the porting effort is not that simple. Therefore, I'm wondering whether we should kee at91bootstrap as it is, and create a separate package at91bootstrap3 for the 3.x generation. Signed-off-by: Simon Dawson <spdawson@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-17 10:36:23 +02:00
#
# at91bootstrap3
#
Normalize separator size to 80 Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-06 23:54:13 +02:00
################################################################################
Fix package headers to comply with coding style Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-06 01:53:25 +02:00
boot/at91bootstrap3: bump to v3.7.1 Change to use the _defconfig targets of at91bootstrap3 build system when a defconfig is used. [Thomas: adjust to make a better use of at91bootstrap3 defconfig mechanism.] Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-03 17:18:25 +01:00
AT91BOOTSTRAP3_VERSION = v3.7.1
at91bootstrap3: bump to v3.6.2 In preparation to add support for the SAMA5D3 Xplained board, this commit bumps the version of the at91bootstrap3 bootloader to v3.6.2. While doing this, it also: - Allows this bootloader on Cortex-A5 based platforms, since SAMA5D3 are based on Cortex-A5. - Removes a patch that no longer applies, and which has been taken into account in at91bootstrap3 upstream. - Switches to the upstream Github location as the source. - Updates the installation commands to match upstream changes in the installation process. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-15 15:33:48 +02:00
AT91BOOTSTRAP3_SITE = $(call github,linux4sam,at91bootstrap,$(AT91BOOTSTRAP3_VERSION))
at91bootstrap3: new package Note that this new package, at91bootstrap3, is being added alongside the existing at91bootstrap. This was suggested by Thomas Petazzoni, whose comments on the mailing list are quoted below. For this package, I am not sure we can do a simple version bump. Since there is (was?) no upstream for AT91Bootstrap 1.x, many vendors/companies had to maintain their patches on top of AT91Bootstrap 1.x. See for example board/calao/usb-a9263/at91bootstrap-1.16-usb-a9263.patch. Therefore, removing AT91Bootstrap 1.x from the tree will prevent those platforms to work. I know people should upgrade, but AT91Bootstrap 3.x is quite significantly different, so the porting effort is not that simple. Therefore, I'm wondering whether we should kee at91bootstrap as it is, and create a separate package at91bootstrap3 for the 3.x generation. Signed-off-by: Simon Dawson <spdawson@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-17 10:36:23 +02:00
AT91BOOTSTRAP3_INSTALL_IMAGES = YES
AT91BOOTSTRAP3_INSTALL_TARGET = NO
AT91BOOTSTRAP3_CUSTOM_PATCH_DIR = \
$(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_PATCH_DIR))
packages: rename FOO_MAKE_OPT into FOO_MAKE_OPTS While the autotools infrastructure was using FOO_MAKE_OPT, generic packages were typically using FOO_MAKE_OPTS. This inconsistency becomes a problem when a new infrastructure is introduced that wants to make use of FOO_MAKE_OPT(S), and can live alongside either generic-package or autotools-package. The new infrastructure will have to choose between either OPT or OPTS, and thus rule out transparent usage by respectively generic packages or generic packages. An example of such an infrastructure is kconfig-package, which provides kconfig-related make targets. The OPTS variant is more logical, as there are typically multiple options. This patch renames all occurrences of FOO_MAKE_OPT in FOO_MAKE_OPTS. Sed command used: find * -type f | xargs sed -i 's#_MAKE_OPT\>#&S#g' Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-09-27 21:32:38 +02:00
AT91BOOTSTRAP3_MAKE_OPTS = CROSS_COMPILE=$(TARGET_CROSS) DESTDIR=$(BINARIES_DIR)
at91bootstrap3: new package Note that this new package, at91bootstrap3, is being added alongside the existing at91bootstrap. This was suggested by Thomas Petazzoni, whose comments on the mailing list are quoted below. For this package, I am not sure we can do a simple version bump. Since there is (was?) no upstream for AT91Bootstrap 1.x, many vendors/companies had to maintain their patches on top of AT91Bootstrap 1.x. See for example board/calao/usb-a9263/at91bootstrap-1.16-usb-a9263.patch. Therefore, removing AT91Bootstrap 1.x from the tree will prevent those platforms to work. I know people should upgrade, but AT91Bootstrap 3.x is quite significantly different, so the porting effort is not that simple. Therefore, I'm wondering whether we should kee at91bootstrap as it is, and create a separate package at91bootstrap3 for the 3.x generation. Signed-off-by: Simon Dawson <spdawson@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-17 10:36:23 +02:00
ifneq ($(AT91BOOTSTRAP3_CUSTOM_PATCH_DIR),)
define AT91BOOTSTRAP3_APPLY_CUSTOM_PATCHES
packages: apply custom patches using *.patch instead of <pkg>-*.patch Several packages have some logic to apply custom patches that existed before the BR2_GLOBAL_PATCH_DIR mechanism: at91bootstrap, at91bootstrap3, barebox, uboot and linux. Currently, the logic of those packages to apply custom patches is to match <package-name>-*.patch, which is not consistent with what we've done for patches stored in the package directory, and for patches stored in BR2_GLOBAL_PATCH_DIR: in such cases, we simply apply *.patch. Therefore, for consistency reasons, this commit changes these packages to also apply *.patch. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2015-03-29 19:33:22 +02:00
$(APPLY_PATCHES) $(@D) $(AT91BOOTSTRAP3_CUSTOM_PATCH_DIR) \*.patch
at91bootstrap3: new package Note that this new package, at91bootstrap3, is being added alongside the existing at91bootstrap. This was suggested by Thomas Petazzoni, whose comments on the mailing list are quoted below. For this package, I am not sure we can do a simple version bump. Since there is (was?) no upstream for AT91Bootstrap 1.x, many vendors/companies had to maintain their patches on top of AT91Bootstrap 1.x. See for example board/calao/usb-a9263/at91bootstrap-1.16-usb-a9263.patch. Therefore, removing AT91Bootstrap 1.x from the tree will prevent those platforms to work. I know people should upgrade, but AT91Bootstrap 3.x is quite significantly different, so the porting effort is not that simple. Therefore, I'm wondering whether we should kee at91bootstrap as it is, and create a separate package at91bootstrap3 for the 3.x generation. Signed-off-by: Simon Dawson <spdawson@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-17 10:36:23 +02:00
endef
AT91BOOTSTRAP3_POST_PATCH_HOOKS += AT91BOOTSTRAP3_APPLY_CUSTOM_PATCHES
endif
define AT91BOOTSTRAP3_BUILD_CMDS
boot/at91bootstrap3: bump to v3.7.1 Change to use the _defconfig targets of at91bootstrap3 build system when a defconfig is used. [Thomas: adjust to make a better use of at91bootstrap3 defconfig mechanism.] Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-03 17:18:25 +01:00
$(MAKE) $(AT91BOOTSTRAP3_MAKE_OPTS) -C $(@D)
at91bootstrap3: new package Note that this new package, at91bootstrap3, is being added alongside the existing at91bootstrap. This was suggested by Thomas Petazzoni, whose comments on the mailing list are quoted below. For this package, I am not sure we can do a simple version bump. Since there is (was?) no upstream for AT91Bootstrap 1.x, many vendors/companies had to maintain their patches on top of AT91Bootstrap 1.x. See for example board/calao/usb-a9263/at91bootstrap-1.16-usb-a9263.patch. Therefore, removing AT91Bootstrap 1.x from the tree will prevent those platforms to work. I know people should upgrade, but AT91Bootstrap 3.x is quite significantly different, so the porting effort is not that simple. Therefore, I'm wondering whether we should kee at91bootstrap as it is, and create a separate package at91bootstrap3 for the 3.x generation. Signed-off-by: Simon Dawson <spdawson@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-17 10:36:23 +02:00
endef
define AT91BOOTSTRAP3_INSTALL_IMAGES_CMDS
at91bootstrap3: bump to v3.6.2 In preparation to add support for the SAMA5D3 Xplained board, this commit bumps the version of the at91bootstrap3 bootloader to v3.6.2. While doing this, it also: - Allows this bootloader on Cortex-A5 based platforms, since SAMA5D3 are based on Cortex-A5. - Removes a patch that no longer applies, and which has been taken into account in at91bootstrap3 upstream. - Switches to the upstream Github location as the source. - Updates the installation commands to match upstream changes in the installation process. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-15 15:33:48 +02:00
cp $(@D)/binaries/*.bin $(BINARIES_DIR)
at91bootstrap3: new package Note that this new package, at91bootstrap3, is being added alongside the existing at91bootstrap. This was suggested by Thomas Petazzoni, whose comments on the mailing list are quoted below. For this package, I am not sure we can do a simple version bump. Since there is (was?) no upstream for AT91Bootstrap 1.x, many vendors/companies had to maintain their patches on top of AT91Bootstrap 1.x. See for example board/calao/usb-a9263/at91bootstrap-1.16-usb-a9263.patch. Therefore, removing AT91Bootstrap 1.x from the tree will prevent those platforms to work. I know people should upgrade, but AT91Bootstrap 3.x is quite significantly different, so the porting effort is not that simple. Therefore, I'm wondering whether we should kee at91bootstrap as it is, and create a separate package at91bootstrap3 for the 3.x generation. Signed-off-by: Simon Dawson <spdawson@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-17 10:36:23 +02:00
endef
boot/at91bootstrap3: migrate to pkg-kconfig In at91bootstrap3, defconfig files are spread out in various sub-directories, so we can't easily construct the path to those defconfig files. As it turns out, there are no two defconfig files named the same; they all contain at least the board name, plus some extra info. And there is always only one directory depth below board/ where all defconfig files are to be found. Also, at91bootstrap3's own Makefile relies on this single-match as it runs a 'find' command to locate the defconfig file. So, even though we do not know the path to the defconfig file, we can construct a shell-glob quite easily (in the hope that there will never be more than one directory depth). Signed-off-by: Mauro Condarelli <mc5686@mclink.it> [yann.morin.1998@free.fr: - remove custom _CONFIGURE_CMDS, handled by pkg-kconfig (Thomas) - remove redundant intermediate variable - fix using internal defconfig files ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-06 16:03:06 +02:00
ifeq ($(BR2_TARGET_AT91BOOTSTRAP3_USE_DEFCONFIG),y)
at91bootstrap3: make sure AT91BOOTSTRAP3_KCONFIG_FILE is always defined For some (silly?) reason, the kconfig-package infra always wants <pkg>_KCONFIG_FILE to be defined. So let's do like barebox does: use a temporary AT91BOOTSTRAP3_SOURCE_CONFIG variable, and assign it to AT91BOOTSTRAP3_KCONFIG_FILE. This way, the latter is always defined, even if to the empty value. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-06 23:41:18 +02:00
AT91BOOTSTRAP3_SOURCE_CONFIG = $(AT91BOOTSTRAP3_DIR)/board/*/$(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP3_DEFCONFIG))_defconfig
boot/at91bootstrap3: migrate to pkg-kconfig In at91bootstrap3, defconfig files are spread out in various sub-directories, so we can't easily construct the path to those defconfig files. As it turns out, there are no two defconfig files named the same; they all contain at least the board name, plus some extra info. And there is always only one directory depth below board/ where all defconfig files are to be found. Also, at91bootstrap3's own Makefile relies on this single-match as it runs a 'find' command to locate the defconfig file. So, even though we do not know the path to the defconfig file, we can construct a shell-glob quite easily (in the hope that there will never be more than one directory depth). Signed-off-by: Mauro Condarelli <mc5686@mclink.it> [yann.morin.1998@free.fr: - remove custom _CONFIGURE_CMDS, handled by pkg-kconfig (Thomas) - remove redundant intermediate variable - fix using internal defconfig files ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-06 16:03:06 +02:00
else ifeq ($(BR2_TARGET_AT91BOOTSTRAP3_USE_CUSTOM_CONFIG),y)
at91bootstrap3: make sure AT91BOOTSTRAP3_KCONFIG_FILE is always defined For some (silly?) reason, the kconfig-package infra always wants <pkg>_KCONFIG_FILE to be defined. So let's do like barebox does: use a temporary AT91BOOTSTRAP3_SOURCE_CONFIG variable, and assign it to AT91BOOTSTRAP3_KCONFIG_FILE. This way, the latter is always defined, even if to the empty value. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-06 23:41:18 +02:00
AT91BOOTSTRAP3_SOURCE_CONFIG = $(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE))
boot/at91bootstrap3: migrate to pkg-kconfig In at91bootstrap3, defconfig files are spread out in various sub-directories, so we can't easily construct the path to those defconfig files. As it turns out, there are no two defconfig files named the same; they all contain at least the board name, plus some extra info. And there is always only one directory depth below board/ where all defconfig files are to be found. Also, at91bootstrap3's own Makefile relies on this single-match as it runs a 'find' command to locate the defconfig file. So, even though we do not know the path to the defconfig file, we can construct a shell-glob quite easily (in the hope that there will never be more than one directory depth). Signed-off-by: Mauro Condarelli <mc5686@mclink.it> [yann.morin.1998@free.fr: - remove custom _CONFIGURE_CMDS, handled by pkg-kconfig (Thomas) - remove redundant intermediate variable - fix using internal defconfig files ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-06 16:03:06 +02:00
endif
at91bootstrap3: make sure AT91BOOTSTRAP3_KCONFIG_FILE is always defined For some (silly?) reason, the kconfig-package infra always wants <pkg>_KCONFIG_FILE to be defined. So let's do like barebox does: use a temporary AT91BOOTSTRAP3_SOURCE_CONFIG variable, and assign it to AT91BOOTSTRAP3_KCONFIG_FILE. This way, the latter is always defined, even if to the empty value. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-06 23:41:18 +02:00
AT91BOOTSTRAP3_KCONFIG_FILE = $(AT91BOOTSTRAP3_SOURCE_CONFIG)
boot/at91bootstrap3: migrate to pkg-kconfig In at91bootstrap3, defconfig files are spread out in various sub-directories, so we can't easily construct the path to those defconfig files. As it turns out, there are no two defconfig files named the same; they all contain at least the board name, plus some extra info. And there is always only one directory depth below board/ where all defconfig files are to be found. Also, at91bootstrap3's own Makefile relies on this single-match as it runs a 'find' command to locate the defconfig file. So, even though we do not know the path to the defconfig file, we can construct a shell-glob quite easily (in the hope that there will never be more than one directory depth). Signed-off-by: Mauro Condarelli <mc5686@mclink.it> [yann.morin.1998@free.fr: - remove custom _CONFIGURE_CMDS, handled by pkg-kconfig (Thomas) - remove redundant intermediate variable - fix using internal defconfig files ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-06 16:03:06 +02:00
AT91BOOTSTRAP3_KCONFIG_EDITORS = menuconfig xconfig gconfig
AT91BOOTSTRAP3_KCONFIG_OPTS = $(AT91BOOTSTRAP3_MAKE_OPTS)
$(eval $(kconfig-package))
at91bootstrap3: new package Note that this new package, at91bootstrap3, is being added alongside the existing at91bootstrap. This was suggested by Thomas Petazzoni, whose comments on the mailing list are quoted below. For this package, I am not sure we can do a simple version bump. Since there is (was?) no upstream for AT91Bootstrap 1.x, many vendors/companies had to maintain their patches on top of AT91Bootstrap 1.x. See for example board/calao/usb-a9263/at91bootstrap-1.16-usb-a9263.patch. Therefore, removing AT91Bootstrap 1.x from the tree will prevent those platforms to work. I know people should upgrade, but AT91Bootstrap 3.x is quite significantly different, so the porting effort is not that simple. Therefore, I'm wondering whether we should kee at91bootstrap as it is, and create a separate package at91bootstrap3 for the 3.x generation. Signed-off-by: Simon Dawson <spdawson@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-17 10:36:23 +02:00
# Checks to give errors that the user can understand
packages: refactor checks using BR_BUILDING Instead of manually testing MAKECMDGOALS, use the newly introduced BR_BUILDING variable to know if we're building or not. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2015-04-26 11:51:15 +02:00
ifeq ($(BR_BUILDING),y)
at91bootstrap3: new package Note that this new package, at91bootstrap3, is being added alongside the existing at91bootstrap. This was suggested by Thomas Petazzoni, whose comments on the mailing list are quoted below. For this package, I am not sure we can do a simple version bump. Since there is (was?) no upstream for AT91Bootstrap 1.x, many vendors/companies had to maintain their patches on top of AT91Bootstrap 1.x. See for example board/calao/usb-a9263/at91bootstrap-1.16-usb-a9263.patch. Therefore, removing AT91Bootstrap 1.x from the tree will prevent those platforms to work. I know people should upgrade, but AT91Bootstrap 3.x is quite significantly different, so the porting effort is not that simple. Therefore, I'm wondering whether we should kee at91bootstrap as it is, and create a separate package at91bootstrap3 for the 3.x generation. Signed-off-by: Simon Dawson <spdawson@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-17 10:36:23 +02:00
ifeq ($(BR2_TARGET_AT91BOOTSTRAP3_USE_DEFCONFIG),y)
boot/at91bootstrap3: migrate to pkg-kconfig In at91bootstrap3, defconfig files are spread out in various sub-directories, so we can't easily construct the path to those defconfig files. As it turns out, there are no two defconfig files named the same; they all contain at least the board name, plus some extra info. And there is always only one directory depth below board/ where all defconfig files are to be found. Also, at91bootstrap3's own Makefile relies on this single-match as it runs a 'find' command to locate the defconfig file. So, even though we do not know the path to the defconfig file, we can construct a shell-glob quite easily (in the hope that there will never be more than one directory depth). Signed-off-by: Mauro Condarelli <mc5686@mclink.it> [yann.morin.1998@free.fr: - remove custom _CONFIGURE_CMDS, handled by pkg-kconfig (Thomas) - remove redundant intermediate variable - fix using internal defconfig files ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-06 16:03:06 +02:00
ifeq ($(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP3_DEFCONFIG)),)
at91bootstrap3: new package Note that this new package, at91bootstrap3, is being added alongside the existing at91bootstrap. This was suggested by Thomas Petazzoni, whose comments on the mailing list are quoted below. For this package, I am not sure we can do a simple version bump. Since there is (was?) no upstream for AT91Bootstrap 1.x, many vendors/companies had to maintain their patches on top of AT91Bootstrap 1.x. See for example board/calao/usb-a9263/at91bootstrap-1.16-usb-a9263.patch. Therefore, removing AT91Bootstrap 1.x from the tree will prevent those platforms to work. I know people should upgrade, but AT91Bootstrap 3.x is quite significantly different, so the porting effort is not that simple. Therefore, I'm wondering whether we should kee at91bootstrap as it is, and create a separate package at91bootstrap3 for the 3.x generation. Signed-off-by: Simon Dawson <spdawson@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-17 10:36:23 +02:00
$(error No at91bootstrap3 defconfig name specified, check your BR2_TARGET_AT91BOOTSTRAP3_DEFCONFIG setting)
endif
endif
ifeq ($(BR2_TARGET_AT91BOOTSTRAP3_USE_CUSTOM_CONFIG),y)
boot/at91bootstrap3: migrate to pkg-kconfig In at91bootstrap3, defconfig files are spread out in various sub-directories, so we can't easily construct the path to those defconfig files. As it turns out, there are no two defconfig files named the same; they all contain at least the board name, plus some extra info. And there is always only one directory depth below board/ where all defconfig files are to be found. Also, at91bootstrap3's own Makefile relies on this single-match as it runs a 'find' command to locate the defconfig file. So, even though we do not know the path to the defconfig file, we can construct a shell-glob quite easily (in the hope that there will never be more than one directory depth). Signed-off-by: Mauro Condarelli <mc5686@mclink.it> [yann.morin.1998@free.fr: - remove custom _CONFIGURE_CMDS, handled by pkg-kconfig (Thomas) - remove redundant intermediate variable - fix using internal defconfig files ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-06 16:03:06 +02:00
ifeq ($(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE)),)
at91bootstrap3: new package Note that this new package, at91bootstrap3, is being added alongside the existing at91bootstrap. This was suggested by Thomas Petazzoni, whose comments on the mailing list are quoted below. For this package, I am not sure we can do a simple version bump. Since there is (was?) no upstream for AT91Bootstrap 1.x, many vendors/companies had to maintain their patches on top of AT91Bootstrap 1.x. See for example board/calao/usb-a9263/at91bootstrap-1.16-usb-a9263.patch. Therefore, removing AT91Bootstrap 1.x from the tree will prevent those platforms to work. I know people should upgrade, but AT91Bootstrap 3.x is quite significantly different, so the porting effort is not that simple. Therefore, I'm wondering whether we should kee at91bootstrap as it is, and create a separate package at91bootstrap3 for the 3.x generation. Signed-off-by: Simon Dawson <spdawson@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-17 10:36:23 +02:00
$(error No at91bootstrap3 configuration file specified, check your BR2_TARGET_AT91BOOTSTRAP3_CUSTOM_CONFIG_FILE setting)
endif
endif
endif
Reference in New Issue Copy Permalink