There are a lot of historical ARM architecture versions, but this article focuses on ARMv6 and newer.
Floating point units in ARM are called “vector floating point”, abbreviated as VFP.
- VFPv2 is used optionally in ARMv6
- VFPv3 is used in ARMv7
This comment in Android source code has some more details.
Most Linux distribtions like Debian have “armhf” builds. This means “ARMv7+VFPv3+D16”. There are exceptions to this, like Alpine and Raspbian, who have “armhf” build which are actually “ARMv6+VFPv2”, but these binaries are also forward compatible with most of the newer ARM implementations. This also means that Alpine is not compatible with minimal ARMv6 implementations, because the VPFv2 extention is optional.
Alpine also has an “armv7” build, which is the same as “armhf” in Debian and other distributions.
Examples of ARMv6 SoCs that include the VFPv2 extension are:
- The Broadcom BCM2835 (sometimes referred to by its family name BMC2708 which only includes this SoC), used in early Raspberry Pi models and later Raspberry Pi Zero models, which are produced until at least 2026.
- The Broadcom BCM21553 used in the Samsung Galaxy Ace i, Samsung Galaxy Pop Plus/Galaxy Mini Plus and the Samsung Galaxy Y.
- The Samsung S3C6410 used in the Samsung Galaxy Spica.
- The Qualcomm MSM7227 used in e.g. the HTC myTouch 3G Slide and the Samsung Galaxy Ace
Alpine considered dropping ARMv6+VFPv2 in April 2019 for further releases but hasn’t done that yet as of December 2020.
Using the SETEND instruction it can be switched at runtime, even from userspace. When not explicitly mentioned by software, it is most likely using little endian. Sometimes it is explicitly mentioned, by calling it “ARMv7l” or “v7l”.
The GNU triplets for hardware floating point ARMv7 are arm-linux-gnueabihf for little endian and armeb-linux-gnueabihf for big endian.
ARMv8 includes a 64-bit execution mode called “AArch64”, but is also compatible with 32-bit code, comparable to the way it is in x86-64. “AArch64” builds are ARMv8 builds that use 64-bit code. Debian calls their AArch64 port “Arm64Port” and so does the derivative Ubuntu (arm64), but Fedora and Alpine are calling it “aarch64”. On ARMv8, endianness is dynamic, but only for the data side.
The Linux kernel calls it ARM64 internally, but this name is not used in the ARM specificaton.
Apple their M1 is currently not supported with Linux, but Hector Martin his port called Asahi Linux is in progress.
Some ARMv8 SoCs such have dropped the 32-bit execution unit: the Cavium ThunderX2, Qualcomm Centriq and the Apple M1. The standard ARM Cortex-A65(AE) and A34 also removed it. Removing this means that any code compiled for ARMv7 or older will no longer run.
- Fedora: lacks support for ARMv6, has support for ARMv7 (armhfp) and ARMv8 (aarch64).
- Debian: supports ARMv6 (armel), but only with software floating point. It also has support for ARMv7 (armhf) and ARMv8 (arm64).
- Alpine: supports ARMv6 (armhf), but only with hardware floating point. It also has support for ARMv7 and ARMv8 (aarch64).
- Gentoo: supports all ARM versions up from ARMv4, with configurable VFP. See here
As can be seen, when using a binary distribution Debian supports the most and is the only choice for ARMv6 without VFPv2, but does not make use of it when one is present. For ARMv6 with VFPv2 Alpine is the best choice. For ARMv7 and v8 any distribution will work. When you want ultimate flexibility, Gentoo is still the best option.
My personal opinion is that support for ARMv6+VFPv2 should be maintained in distributions like Debian and Fedora. Even though it’s deprecated by ARM itself, there is still at least one SoC being manufactured with this architecture in the coming years which is inculded in a popular device. It’s sad we are dependent on the Debian fork Raspberry Pi OS (formerly Raspbian) and Alpine, even though I think Alpine is a very decent distro. Let’s hope that Alpine won’t drop the support any time soon.
Regarding other systems, if the ARM arhictecure version is supported by a particular distribution, that doens’t mean the SoC and peripherals are supported. Both need to have support in the mainline kernel, otherwise the only choice is a vendor fork of the kernel.
This is quickly changing in the AArch64 world, thanks to the work on things like SystemReady, which is standardizing ARM firmware and makes it possible to boot generic kernels who are not aware of the underlying hardware at build time. The future for ARM seems exciting, but for current hardware the support isn’t great in a lot of cases.
Edit: added ThunderX2 and Centriq
Found a mistake? Please send me a message