Re: Architecture baseline for Forky
On Wed, Oct 29, 2025 at 02:47:13PM +0100, Arnd Bergmann wrote:
> On Wed, Oct 29, 2025, at 08:39, Adrian Bunk wrote:
>...
> >> I would still agree with Marcin here: SAMA5D3 was Atmel's first attempt
> >> at an ARMv7 chip back in 2013, and everything after it had NEON including
> >> the 2014 SAMA4D4 and of course all the SAMA7. It only has DDR2/LPDDR2
> >> support, which means it's no longer cost-effective compared to newer
> >> chips with DDR3. I would expect even SAM9X7 to be much more popular
> >> than SAM5A3 in ongoing production: SAM9X7 is only an ARM926 and won't
> >> run anything newer than Trixie/Armel, but it does have modern I/O
> >> and DDR3 memory. If dropping SAM9x7 (along with all other v5/v6)
> >> support made sense for sid, then so should dropping support for the
> >> SAMA5D3/vfpv3d16.
> >
> > You are misunderstanding what the problems with armel are.
> >
> > On the technical side the problem with armel is that the ecosystem is
> > crumbling away. Not necessarily at the toolchain side, but e.g. Firefox
> > is no longer supporting armel and GNOME uses a copy of Firefox as
> > Javascript library and this has several transitive reverse dependencies.
>
> I don't see a fundamental difference here, but rather a gradual
> step where cutting off at a particular architecture level loses
> a set of users that are on older hardware as well as a set of
> developers that only care about newer hardware.
>
> > By now the number of people who still have the interest and time to
> > commit to constantly do non-trivial porting work for arm on Debian
> > has gotten even closer to 0.
You are talking about hardware support.
I am talking about lack of porters.
If there were hard porter criteria based on what would have been
considered a reasonable minimum porter activity a decade ago,
then our only potential 32-bit release architecture would be hppa.
Even arm64 might not qualify.
> > armel might be salvageable if suddenly a couple of DDs would declare
> > their desire to keep it alive and start working on it, but that won't
> > happen.
>
> Absolutely, and it makes total sense that there is only one 32-bit
> Arm target remaining in Debian, which in turn has to set a baseline
> that maximises the number of users but is new enough to reduce the
> work on the DD side.
>
> Hypothetically, I could se (at least) these eight options for a
> baseline if there can only be one:
>
> 1. armv8-aarch32+neon: loses all 32-bit hardware, only for
> compat mode on arm64 kernels, e.g. memory-optimized containers
> in cloud systems. Widely available for developers.
> 2. armv7ve+vfpv4d16+neon: runs on most currently shipping systems
> (cortex-a7) but loses most existing systems (cortex-a9 and
> older). Architecturally very similar to 1.
> 3. armv7-a+vfpv3d32+neon: Almost all ARMv7 systems, except Tegra2,
> ArmadaXP/370, Dove and SAMA5AD3 (probably others without
> upstream kernel support).
> Same baseline as Android and Arch Linux, misses FP16, FMA and
> IDIV instructions.
> 4. armv7-a+vfpv3d16: Current baseline, same as Ubuntu and
> OpenSUSE, loses NEON support.
> 5. armv6k+vfpv3d16: Most ARMv6/v7 machines, including Raspberry
> Pi zero/1 but not OMAP2 (Nokia N800/N810). Loses THUMB2 support
> and v7/v8 CPU barriers among other minor differences.
> 6. armv6+vfpv3d16: All ARMv6 machines including OMAP2 but loses
> modern atomics used in locking primitives. Currently used on
> Raspbian and a few other v6 distros that target Raspberry Pi.
> 7. armv5+vfpv2d16: lowest possible baseline for armhf compatible
> ABI, used in LPC32xx, but requires libatomic for even more
> cases.
> 8. armv5 softfloat: current baseline for armel, largest amount
> of supported hardware in total, but loses both VFP and NEON
> optimizations in addition to the other problems above.
>
> The only realistic choices I see here are 3, 4 and 5, with good
> arguments in favor of each one. Between these, I see both NEON
> and Thumb2 as important features that some developers are taking
> for granted the same way as hardfloat, though admittedly to a
> lesser degree. Changing from 4 to 3 would lose a very small number
> of users but gain an important feature, while going from 4 to 5
> would lose an important feature but gain a much larger number of
> (Raspberry Pi) users that previously had to use armel. Staying with
> 4 is of course the easy choice because it means not having to
> change anything.
Regarding option 5:
The baseline is encoded in a gazillion places, these need fixes
(though raspbian already has fixes for most).
And then you need a rebuild of the full archive.
It might be doable to basically merge raspbian into Debian
(but it would be weird to do that now and not a decade ago).
A relevant question would be how many and which packages are not
buildable on raspbian due to the lower baseline.
In any case this option would be a lot of work.
Regarding option 3:
The amount of work would be trivial, since asking the GCC maintainer
to change the baseline would be the only mandatory part of the change
(we did this on armel when raising the baseline from armv4te to armv5te
in buster).
Due to the common baseline without NEON most relevant software that
benefits from NEON got runtime detection 1-2 decades ago.
Due to armhf being a legacy platform today, it is unlikely that
important software will suddenly make NEON a hard requirement
now - it is more common that a package drops armhf support,
or more commonly support for 32-bit.
If the only tradeoff is between hardware support and marginal
performance improvements, that's not a good case for dropping
hardware support - and anyone who cares about performance
should anyway not be using armhf in 2027.
> Arnd
cu
Adrian
Reply to: