[Buildroot] [PATCH] boot: introduce at91bootstrap4

[Buildroot] [PATCH] boot: introduce at91bootstrap4

[Eugen Hristev]

Introduce new bootloader package for the next generation
of at91bootstrap, at91bootstrap4

AT91Bootstrap4 only supports devices: sam9x60, sama5d2, sama5d3,
sama5d4, sama7g5.

Based on at91bootstrap3 recipes.

Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
 boot/Config.in                          |   1 +
 boot/at91bootstrap4/Config.in           | 103 ++++++++++++++++++++++++
 boot/at91bootstrap4/at91bootstrap4.hash |   3 +
 boot/at91bootstrap4/at91bootstrap4.mk   | 103 ++++++++++++++++++++++++
 4 files changed, 210 insertions(+)
 create mode 100644 boot/at91bootstrap4/Config.in
 create mode 100644 boot/at91bootstrap4/at91bootstrap4.hash
 create mode 100644 boot/at91bootstrap4/at91bootstrap4.mk

diff --git a/boot/Config.in b/boot/Config.in
index b3adbfc8bc..2e7eea542c 100644
--- a/boot/Config.in
+++ b/boot/Config.in
@@ -3,6 +3,7 @@ menu "Bootloaders"
 source "boot/afboot-stm32/Config.in"
 source "boot/at91bootstrap/Config.in"
 source "boot/at91bootstrap3/Config.in"
+source "boot/at91bootstrap4/Config.in"
 source "boot/at91dataflashboot/Config.in"
 source "boot/arm-trusted-firmware/Config.in"
 source "boot/barebox/Config.in"
diff --git a/boot/at91bootstrap4/Config.in b/boot/at91bootstrap4/Config.in
new file mode 100644
index 0000000000..500cf7727f
--- /dev/null
+++ b/boot/at91bootstrap4/Config.in
@@ -0,0 +1,103 @@
+config BR2_TARGET_AT91BOOTSTRAP4
+	bool "AT91 Bootstrap 4"
+	depends on BR2_arm926t || BR2_cortex_a5 || BR2_cortex_a7
+	help
+	  AT91Bootstrap is a first level bootloader for the Microchip AT91
+	  devices. It integrates algorithms for:
+	  - Device initialization such as clock configuration, PIO
+	    settings...
+	  - Peripheral drivers such as PIO, PMC or SDRAMC...
+	  - Physical media algorithm such as DataFlash, NandFlash, NOR
+	    Flash...
+
+	  https://www.linux4sam.org/bin/view/Linux4SAM/AT91Bootstrap
+
+if BR2_TARGET_AT91BOOTSTRAP4
+
+choice
+
+	prompt "AT91 Bootstrap 4 version"
+
+config BR2_TARGET_AT91BOOTSTRAP4_LATEST_VERSION
+	bool "4.0.0-rc1"
+
+config BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_GIT
+	bool "Custom Git repository"
+	help
+	  This option allows Buildroot to get the AT91 Bootstrap 4
+	  source code from a Git repository.
+
+config BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL
+	bool "Custom tarball"
+
+endchoice
+
+config BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL_LOCATION
+	string "URL of custom AT91Bootstrap tarball"
+	depends on BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL
+
+if BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_GIT
+
+config BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_REPO_URL
+	string "URL of custom repository"
+
+config BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_REPO_VERSION
+	string "Custom repository version"
+	help
+	  Revision to use in the typical format used by Git
+	  E.G. a sha id, a tag, branch, ..
+
+endif
+
+config BR2_TARGET_AT91BOOTSTRAP4_VERSION
+	string
+	default "v4.0.0-rc1" if BR2_TARGET_AT91BOOTSTRAP4_LATEST_VERSION
+	default BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_REPO_VERSION \
+		if BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_GIT
+	default "custom"	if BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL
+
+config BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_PATCH_DIR
+	string "custom patch dir"
+	help
+	  If your board requires custom patches, add the path to the
+	  directory containing the patches here. The patches must be
+	  named at91bootstrap4-<something>.patch.
+
+	  Most users may leave this empty
+
+#
+# Configuration selection
+#
+
+choice
+	prompt "AT91 Bootstrap 4 configuration"
+	default BR2_TARGET_AT91BOOTSTRAP4_USE_DEFCONFIG
+
+config BR2_TARGET_AT91BOOTSTRAP4_USE_DEFCONFIG
+	bool "Using a defconfig"
+
+config BR2_TARGET_AT91BOOTSTRAP4_USE_CUSTOM_CONFIG
+	bool "Using a custom config file"
+
+endchoice
+
+config BR2_TARGET_AT91BOOTSTRAP4_DEFCONFIG
+	string "Defconfig name"
+	depends on BR2_TARGET_AT91BOOTSTRAP4_USE_DEFCONFIG
+	help
+	  Name of the at91bootstrap4 defconfig file to use, without the
+	  trailing _defconfig.  The defconfig is located at
+	  configs/ in the at91bootstrap4 tree.
+
+config BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_CONFIG_FILE
+	string "Configuration file path"
+	depends on BR2_TARGET_AT91BOOTSTRAP4_USE_CUSTOM_CONFIG
+	help
+	  Path to the at91bootstrap4 configuration file
+
+config BR2_TARGET_AT91BOOTSTRAP4_NEEDS_PYTHON3
+	bool "AT91Bootstrap4 requires host Python 3.x for NAND/PMECC scripts"
+	help
+	  Host Python 3.x needs to be installed to use the NAND/PMECC python scripts
+
+endif # BR2_TARGET_AT91BOOTSTRAP4
diff --git a/boot/at91bootstrap4/at91bootstrap4.hash b/boot/at91bootstrap4/at91bootstrap4.hash
new file mode 100644
index 0000000000..0408e73190
--- /dev/null
+++ b/boot/at91bootstrap4/at91bootstrap4.hash
@@ -0,0 +1,3 @@
+# Locally calculated
+sha256  6f0bab65b134cf3f5df7d5bf3b902c1217cba2f25aafb983350cd631a73db60d  at91bootstrap4-v4.0.0-rc1.tar.gz
+sha256  fd7a1ce5719bb7abf5e289da2e0ea8c933af3ba0f6ad03dbdbd2b7f54a77498a  main.c
diff --git a/boot/at91bootstrap4/at91bootstrap4.mk b/boot/at91bootstrap4/at91bootstrap4.mk
new file mode 100644
index 0000000000..0b46af767f
--- /dev/null
+++ b/boot/at91bootstrap4/at91bootstrap4.mk
@@ -0,0 +1,103 @@
+################################################################################
+#
+# at91bootstra44
+#
+################################################################################
+
+AT91BOOTSTRAP4_VERSION = $(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP4_VERSION))
+
+ifeq ($(BR2_TARGET_AT91BOOTSTRAP4_NEEDS_PYTHON3),y)
+AT91BOOTSTRAP3_DEPENDENCIES += host-python3
+endif
+
+ifeq ($(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL),y)
+AT91BOOTSTRAP4_TARBALL = $(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL_LOCATION))
+AT91BOOTSTRAP4_SITE = $(patsubst %/,%,$(dir $(AT91BOOTSTRAP4_TARBALL)))
+AT91BOOTSTRAP4_SOURCE = $(notdir $(AT91BOOTSTRAP4_TARBALL))
+BR_NO_CHECK_HASH_FOR += $(AT91BOOTSTRAP4_SOURCE)
+else ifeq ($(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_GIT),y)
+AT91BOOTSTRAP4_SITE = $(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_REPO_URL))
+AT91BOOTSTRAP4_SITE_METHOD = git
+BR_NO_CHECK_HASH_FOR += $(AT91BOOTSTRAP4_SOURCE)
+else
+AT91BOOTSTRAP4_SITE = $(call github,linux4sam,at91bootstrap,$(AT91BOOTSTRAP4_VERSION))
+endif
+
+AT91BOOTSTRAP4_LICENSE = Microchip License
+ifeq ($(BR2_TARGET_AT91BOOTSTRAP4_LATEST_VERSION),y)
+AT91BOOTSTRAP4_LICENSE_FILES = main.c
+endif
+
+AT91BOOTSTRAP4_CPE_ID_VENDOR = linux4sam
+AT91BOOTSTRAP4_CPE_ID_PRODUCT = at91bootstrap
+
+AT91BOOTSTRAP4_INSTALL_IMAGES = YES
+AT91BOOTSTRAP4_INSTALL_TARGET = NO
+
+AT91BOOTSTRAP4_CUSTOM_PATCH_DIR = \
+	$(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_PATCH_DIR))
+
+AT91BOOTSTRAP4_MAKE_OPTS = CROSS_COMPILE=$(TARGET_CROSS) DESTDIR=$(BINARIES_DIR)
+
+ifneq ($(AT91BOOTSTRAP4_CUSTOM_PATCH_DIR),)
+define AT91BOOTSTRAP4_APPLY_CUSTOM_PATCHES
+	$(APPLY_PATCHES) $(@D) $(AT91BOOTSTRAP4_CUSTOM_PATCH_DIR) \*.patch
+endef
+
+AT91BOOTSTRAP4_POST_PATCH_HOOKS += AT91BOOTSTRAP4_APPLY_CUSTOM_PATCHES
+endif
+
+define AT91BOOTSTRAP4_BUILD_CMDS
+	$(MAKE) $(AT91BOOTSTRAP4_MAKE_OPTS) -C $(@D)
+endef
+
+define AT91BOOTSTRAP4_INSTALL_IMAGES_CMDS
+	cp $(@D)/build/binaries/*.bin $(BINARIES_DIR)
+endef
+
+ifeq ($(BR2_TARGET_AT91BOOTSTRAP4_USE_DEFCONFIG),y)
+AT91BOOTSTRAP4_KCONFIG_DEFCONFIG = $(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP4_DEFCONFIG))_defconfig
+else ifeq ($(BR2_TARGET_AT91BOOTSTRAP4_USE_CUSTOM_CONFIG),y)
+AT91BOOTSTRAP4_KCONFIG_FILE = $(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_CONFIG_FILE))
+endif
+
+AT91BOOTSTRAP4_KCONFIG_EDITORS = menuconfig xconfig gconfig
+AT91BOOTSTRAP4_KCONFIG_OPTS = $(AT91BOOTSTRAP4_MAKE_OPTS)
+
+# Checks to give errors that the user can understand
+# Must be before we call to kconfig-package
+ifeq ($(BR_BUILDING),y)
+
+ifeq ($(BR2_TARGET_AT91BOOTSTRAP4_USE_DEFCONFIG),y)
+# We must use the user-supplied kconfig value, because
+# AT91BOOTSTRAP4_KCONFIG_DEFCONFIG will at least contain
+# the trailing _defconfig
+ifeq ($(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP4_DEFCONFIG)),)
+$(error No at91bootstrap4 defconfig name specified, check your BR2_TARGET_AT91BOOTSTRAP4_DEFCONFIG setting)
+endif
+endif
+
+ifeq ($(BR2_TARGET_AT91BOOTSTRAP4_USE_CUSTOM_CONFIG),y)
+ifeq ($(AT91BOOTSTRAP4_KCONFIG_FILE),)
+$(error No at91bootstrap4 configuration file specified, check your BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_CONFIG_FILE setting)
+endif
+endif
+
+ifeq ($(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_GIT),y)
+ifeq ($(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_REPO_URL)),)
+$(error No custom at91bootstrap4 repository URL specified. Check your BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_REPO_URL setting)
+endif
+ifeq ($(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_REPO_VERSION)),)
+$(error No custom at91bootstrap4 repository version specified. Check your BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_REPO_VERSION setting)
+endif
+endif
+
+ifeq ($(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL),y)
+ifeq ($(call qstrip,$(BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL_LOCATION)),)
+$(error No custom AT91Bootstrap4 tarball specified. Check your BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL_LOCATION setting)
+endif # qstrip BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL_LOCATION
+endif # BR2_TARGET_AT91BOOTSTRAP4_CUSTOM_TARBALL
+
+endif # BR_BUILDING
+
+$(eval $(kconfig-package))
-- 
2.25.1

[Buildroot] [PATCH] boot: introduce at91bootstrap4

[Thomas Petazzoni]

Hello Eugen,

On Fri, 23 Apr 2021 10:08:22 +0300
Eugen Hristev via buildroot <buildroot@busybox.net> wrote:

> Introduce new bootloader package for the next generation
> of at91bootstrap, at91bootstrap4
> 
> AT91Bootstrap4 only supports devices: sam9x60, sama5d2, sama5d3,
> sama5d4, sama7g5.
> 
> Based on at91bootstrap3 recipes.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>

Why would we need a new package for this? It still like just a new
version of at91bootstrap. I just had a look a the differences between
at91bootstrap3/ and at91bootstrap4/ and here are the only meaningful
differences:

+ifeq ($(BR2_TARGET_AT91BOOTSTRAP3_NEEDS_PYTHON3),y)
+AT91BOOTSTRAP3_DEPENDENCIES += host-python3
+endif

-AT91BOOTSTRAP3_LICENSE = Atmel License
+AT91BOOTSTRAP3_LICENSE = Microchip License

 (this one perhaps applies to at91bootstrap3 as well, in fact)

 define AT91BOOTSTRAP3_INSTALL_IMAGES_CMDS
-	cp $(@D)/binaries/*.bin $(BINARIES_DIR)
+	cp $(@D)/build/binaries/*.bin $(BINARIES_DIR)
 endef

So, shouldn't we instead have a single package covering both? Perhaps
with a sub-option to select "latest 3.x version" and "latest 4.x
version" ?

I know it would be annoying for this package to be named
"at91boostrap3". Perhaps we should, for once, do a bit of renaming
dance and change at91bootstrap to at91bootstrap1 or at91bootstrap-old,
and keep "at91bootstrap" for the "new" 3.x/4.x version? It is not great
in terms of backward compatibility for old configs, though.

(Side note: I find it somewhat annoying that such vendor-provided
solutions tend to drop support for older platforms... It seems that
open-source communities do a better job at maintaining long-term
support for older platforms. What would you say if you had to use a
decade old Buildroot or Yocto to build a system for an AT91SAM9263
processor ?)

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] boot: introduce at91bootstrap4

[Eugen.Hristev at microchip.com]

On 4/26/21 11:03 PM, Thomas Petazzoni wrote:
> Hello Eugen,
> 
> On Fri, 23 Apr 2021 10:08:22 +0300
> Eugen Hristev via buildroot <buildroot@busybox.net> wrote:
> 
>> Introduce new bootloader package for the next generation
>> of at91bootstrap, at91bootstrap4
>>
>> AT91Bootstrap4 only supports devices: sam9x60, sama5d2, sama5d3,
>> sama5d4, sama7g5.
>>
>> Based on at91bootstrap3 recipes.
>>
>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> 
> Why would we need a new package for this? It still like just a new
> version of at91bootstrap. I just had a look a the differences between
> at91bootstrap3/ and at91bootstrap4/ and here are the only meaningful
> differences:

One big reason for this is the fact that some MPUs are no longer 
supported. We have to keep the 3.x series available for MPUs like 9x5, 
9260, etc, which are not supported in bootstrap4.

Bootstrap4 only supports sama5d2, sama5d3, sama5d4, sam9x60 and sama7g5.
For these variants only, the user could possibly use either 
at91bootstrap3 or at91bootstrap4.
But all the older boards still need bootstrap3.

How would you manage this ?
I thought the easiest way is to have two separate packages, rather than 
trying to obtain two pretty much different versions of bootstrap in the 
same recipe.
And buildroot does not really have the 'machine concept' like yocto 
project does. So you don't really know for which machine you are 
building a package, inside that package's recipe. And probably in 
buildroot you don't even want to know and you don't care.

So, what do you think ?

> 
> +ifeq ($(BR2_TARGET_AT91BOOTSTRAP3_NEEDS_PYTHON3),y)
> +AT91BOOTSTRAP3_DEPENDENCIES += host-python3
> +endif
> 
> -AT91BOOTSTRAP3_LICENSE = Atmel License
> +AT91BOOTSTRAP3_LICENSE = Microchip License
> 
>   (this one perhaps applies to at91bootstrap3 as well, in fact)
> 
>   define AT91BOOTSTRAP3_INSTALL_IMAGES_CMDS
> -       cp $(@D)/binaries/*.bin $(BINARIES_DIR)
> +       cp $(@D)/build/binaries/*.bin $(BINARIES_DIR)
>   endef
> 
> So, shouldn't we instead have a single package covering both? Perhaps
> with a sub-option to select "latest 3.x version" and "latest 4.x
> version" ?

3.x versions series will be phased out. I mean, no longer updated . And 
not in long term, but , very soon.

> 
> I know it would be annoying for this package to be named
> "at91boostrap3". Perhaps we should, for once, do a bit of renaming
> dance and change at91bootstrap to at91bootstrap1 or at91bootstrap-old,
> and keep "at91bootstrap" for the "new" 3.x/4.x version? It is not great
> in terms of backward compatibility for old configs, though.
> 
> (Side note: I find it somewhat annoying that such vendor-provided
> solutions tend to drop support for older platforms... It seems that
> open-source communities do a better job at maintaining long-term
> support for older platforms. What would you say if you had to use a
> decade old Buildroot or Yocto to build a system for an AT91SAM9263
> processor ?)

Well. This happens with everything. Even in open source. Some old 
architectures are being removed. You cannot use kernel 5.12 for 
computers with floppy disks anymore. Such is life... things get 
obsoleted. There are still buildroot and yocto available for older 
processors, just not the latest versions.

Eugen

> 
> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 

[Buildroot] [PATCH] boot: introduce at91bootstrap4

[Thomas Petazzoni]

Hello,

On Tue, 27 Apr 2021 06:07:22 +0000
<Eugen.Hristev@microchip.com> wrote:

> > Why would we need a new package for this? It still like just a new
> > version of at91bootstrap. I just had a look a the differences between
> > at91bootstrap3/ and at91bootstrap4/ and here are the only meaningful
> > differences:  
> 
> One big reason for this is the fact that some MPUs are no longer 
> supported. We have to keep the 3.x series available for MPUs like 9x5, 
> 9260, etc, which are not supported in bootstrap4.
> 
> Bootstrap4 only supports sama5d2, sama5d3, sama5d4, sam9x60 and sama7g5.
> For these variants only, the user could possibly use either 
> at91bootstrap3 or at91bootstrap4.
> But all the older boards still need bootstrap3.
> 
> How would you manage this ?
> I thought the easiest way is to have two separate packages, rather than 
> trying to obtain two pretty much different versions of bootstrap in the 
> same recipe.
> And buildroot does not really have the 'machine concept' like yocto 
> project does. So you don't really know for which machine you are 
> building a package, inside that package's recipe. And probably in 
> buildroot you don't even want to know and you don't care.
> 
> So, what do you think ?

Well, I think what I suggested in my previous e-mail: to have a single
package, which allows to chose between the 3.x series and the 4.x
series.

> > So, shouldn't we instead have a single package covering both? Perhaps
> > with a sub-option to select "latest 3.x version" and "latest 4.x
> > version" ?  
> 
> 3.x versions series will be phased out. I mean, no longer updated . And 
> not in long term, but , very soon.

No longer updated by Microchip maybe. But no longer used by Buildroot
users, certainly not. There are plenty of people that still have AT91
platforms around, in production, and that continue to update them.

> > (Side note: I find it somewhat annoying that such vendor-provided
> > solutions tend to drop support for older platforms... It seems that
> > open-source communities do a better job at maintaining long-term
> > support for older platforms. What would you say if you had to use a
> > decade old Buildroot or Yocto to build a system for an AT91SAM9263
> > processor ?)  
> 
> Well. This happens with everything. Even in open source. Some old 
> architectures are being removed. You cannot use kernel 5.12 for 
> computers with floppy disks anymore. Such is life... things get 
> obsoleted. There are still buildroot and yocto available for older 
> processors, just not the latest versions.

Well, it depends on the speed at which things get phased out, and
whether they are still used in production. Linux 5.12 still has support
for AT91RM9200, and all ARMv5 AT91 processors, for example. And so has
the latest U-Boot release. For your own product line, Linux, U-Boot,
Buildroot, in their latest versions all continue to have support for
your oldest products, and AT91Bootstrap is the first component to phase
out support for these platforms, and ironically, it's the
vendor-provided software component.

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] boot: introduce at91bootstrap4

[Nicolas Ferre]

Thomas,

I don't recognize our intention in the discussion below, so I would like 
to add a little clarification.


On 27/04/2021 at 08:58, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 27 Apr 2021 06:07:22 +0000
> <Eugen.Hristev@microchip.com> wrote:
> 
>>> Why would we need a new package for this? It still like just a new
>>> version of at91bootstrap. I just had a look a the differences between
>>> at91bootstrap3/ and at91bootstrap4/ and here are the only meaningful
>>> differences:
>>
>> One big reason for this is the fact that some MPUs are no longer
>> supported. We have to keep the 3.x series available for MPUs like 9x5,
>> 9260, etc, which are not supported in bootstrap4.

Having 2 packages for addressing at91bootstrap3 and at91bootstrap4 (or 
next-generation, 4-and-beyond, or whatever) was fine with me.
Even if we are duplicating some content, it's far more readable and less 
confusing for the users (BR2_TARGET_AT91BOOTSTRAP3_V4=y: whaaat?, 
possible changes in defconfigs, future SoC not supported by 3.x branch, 
...).
Ok, we already have 2 versions of this package and a weird numbering 
added to it, but the arguments given back in the days might apply just 
as well today ;-):
https://git.busybox.net/buildroot/commit/boot/at91bootstrap3/at91bootstrap3.mk?id=ca0d69c61cce256e0a6abd144cea4a2e26c46df8

... BUT as I'm a sensible person, I agree that having 
"at91dataflashboot", "at91bootstrap", "at91bootstrap3" + one more (out 
of 21 directories)... might be a little bit too much for a single AT91 
family...

>> Bootstrap4 only supports sama5d2, sama5d3, sama5d4, sam9x60 and sama7g5.
>> For these variants only, the user could possibly use either
>> at91bootstrap3 or at91bootstrap4.
>> But all the older boards still need bootstrap3.
>>
>> How would you manage this ?
>> I thought the easiest way is to have two separate packages, rather than
>> trying to obtain two pretty much different versions of bootstrap in the
>> same recipe.
>> And buildroot does not really have the 'machine concept' like yocto
>> project does. So you don't really know for which machine you are
>> building a package, inside that package's recipe. And probably in
>> buildroot you don't even want to know and you don't care.
>>
>> So, what do you think ?
> 
> Well, I think what I suggested in my previous e-mail: to have a single
> package, which allows to chose between the 3.x series and the 4.x
> series.
> 
>>> So, shouldn't we instead have a single package covering both? Perhaps
>>> with a sub-option to select "latest 3.x version" and "latest 4.x
>>> version" ?
>>
>> 3.x versions series will be phased out. I mean, no longer updated . And
>> not in long term, but , very soon.

"phased out" -> maybe not the proper term.

> No longer updated by Microchip maybe. But no longer used by Buildroot
> users, certainly not. There are plenty of people that still have AT91
> platforms around, in production, and that continue to update them.

Sure, no problem with that, we certainly don't want users of one AT91 
chips to be blocked on older versions of Buildroot or Yocto Project. No 
code will be made unreachable and certainly not the 3.x "branch".

So I don't see why people will be impacted.

>>> (Side note: I find it somewhat annoying that such vendor-provided
>>> solutions tend to drop support for older platforms... It seems that
>>> open-source communities do a better job at maintaining long-term

Note that at91bootstrap is fully Open-Source and has a community with it 
(even if little).

>>> support for older platforms. What would you say if you had to use a
>>> decade old Buildroot or Yocto to build a system for an AT91SAM9263
>>> processor ?)

Here, I don't see why it should be like you describe. We do not remove, 
delete, hide older code. We'll accept patches and fixes for 
at91bootstrap 3, that will be queued in at91bootstrap-3.x branch, like 
any other open-source project out there, no question about that.

AT91Bootstrap 4 is about new features, code refactoring that we 
*back-ported* to sama5d3 (release in 2013) and SoCs onward.

>> Well. This happens with everything. Even in open source. Some old
>> architectures are being removed. You cannot use kernel 5.12 for
>> computers with floppy disks anymore. Such is life... things get
>> obsoleted. There are still buildroot and yocto available for older
>> processors, just not the latest versions.

I wouldn't use these images for qualifying what we're doing, as we don't 
"remove" anything.
And new buildroot and YP will still be available for older processors, 
that's for sure... But with at91bootstrap 3, eventually fixed if needed 
and maintained.

> Well, it depends on the speed at which things get phased out, and
> whether they are still used in production. Linux 5.12 still has support
> for AT91RM9200, and all ARMv5 AT91 processors, for example. And so has
> the latest U-Boot release. For your own product line, Linux, U-Boot,
> Buildroot, in their latest versions all continue to have support for
> your oldest products, and AT91Bootstrap is the first component to phase
> out support for these platforms, and ironically, it's the
> vendor-provided software component.

That's a way to present it. We're talking about a new version of a 
software component, and as the old branch won't go away, I don't agree 
with the shortcut taken in your description.

We're not forcing anyone to abandon anything;
We're making a good job in addressing nearly a decade-old processor with 
our latest features and code refactoring;
The project we're talking about is Open-Source, with BSD-1 Clause, open 
to anyone to participate;
Same git tree will address processors as old as AT91RM9200 up to latest 
sama7g5 in same project
There are projects that we use, support and promote that our customers 
can run if at91bootstrap don't fit their needs (namely U-Boot or Barebox).

That's already an achievement and I hope to have shed a different light 
on this update for at91bootstrap project.

Best regards,
-- 
Nicolas Ferre