Re: Architecture baseline for Forky
On Wed, Oct 29, 2025, at 08:39, Adrian Bunk wrote:
> On Mon, Oct 27, 2025 at 10:22:35PM +0100, Arnd Bergmann wrote:
>> On Mon, Oct 27, 2025, at 12:31, Adrian Bunk wrote:
>>...
>> >> There could be one change done to armhf: enabling NEON by default as Tegra2
>> >> is long time gone.
>> >
>> > Atmel SAMA5D3 is still in production, and popular for low-end embedded devices.
>>
>> SAMA5D3 is an interesting corner case, possibly the only ARMv7+VFPv3d16
>> chip you can still buy after the end of Tegra2 and ArmadaXP (which still
>> have users).
>
> SAMA5D3 is ARMv7+VFPv4d16.
>
> While the FPU itself is optional, when it is present it's v4 since A5 is
> a relatively recent (compared to A8/A9) design.
My mistake, it does have the vfpv4 FMA instructions that Cortex-A8/A9 did
not have, and the FP16 extensions that were added in Cortex-A9/R4 and
mandatory in vfpv4. In practice the "d16" portion is the only thing
we worry about though.
>> 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.
>
> 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.
Arnd
Reply to: