Skip to content

Packages fail to build without LSE support

The absence of Large System Extensions (LSE) support is known to cause issues building certain packages:

Because the number of packages affected (and their dependencies) is not fully known/documented (help welcome!), it's unclear how much work this could be. More research is needed to get a sense of the scope of the issue. Other distributions do provide varying degrees of support for "ARM".

Background

ARMv8-A is the first version of the ARM architecture to support 64-bit instructions. There have been multiple extensions of the v8 instruction set. These are indicated by a minor version number (ARMv8.1-A, ARMv8.2-A, etc.). For example, the Raspberry Pi 4 uses the Cortex-A72 which uses the ARMv8-A instruction set, while the Raspberry Pi 5 uses the Cortex-A76 which includes ARMv8.2-A extensions.

This table is a helpful reference for understanding which products and CPUs use which version. But be aware that a CPU advertised as being a certain model may have different features depending on the date it was manufactured and/or its purpose in the final product. lscpu can provide helpful information for determining exactly what features/flags are supported by---as well as what issues might affect---a specific CPU. Sample output for a Cortex-A53 (ARMv8-A):

Architecture:                aarch64
  CPU op-mode(s):            32-bit, 64-bit
  Byte Order:                Little Endian
CPU(s):                      2
  On-line CPU(s) list:       0,1
Vendor ID:                   ARM
  Model name:                Cortex-A53
    Model:                   4
    Thread(s) per core:      1
    Core(s) per cluster:     2
    Socket(s):               -
    Cluster(s):              1
    Stepping:                r0p4
    Frequency boost:         disabled
    CPU(s) scaling MHz:      17%
    CPU max MHz:             1200.0000
    CPU min MHz:             200.0000
    BogoMIPS:                25.00
    Flags:                   fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

and for a Neoverse-N1 (ARMv8.2-A):

Architecture:                aarch64
  CPU op-mode(s):            32-bit, 64-bit
  Byte Order:                Little Endian
CPU(s):                      8
  On-line CPU(s) list:       0-7
Vendor ID:                   ARM
  Model name:                Neoverse-N1
    Model:                   1
    Thread(s) per core:      1
    Core(s) per socket:      8
    Socket(s):               1
    Stepping:                r3p1
    BogoMIPS:                50.00
    Flags:                   fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asim drdm lrcpc dcpop asimddp

Note the additional flags available for the Neoverse-N1. The presence of a flag indicates support for that feature/instruction. For example, the presence of the atomics flag indicates support for the Large System Extensions (LSE) feature.

Because extensions add new features to the instruction set, programs compiled for a specific instruction set are not backwards compatible. For example, programs compiled with gcc using a target architecture option of -march=armv8-a will run on ARMv8.2-A processors, but programs compiled with -march=armv8.2-a will include the lse feature and are not expected to work in general on ARMv8-A processors.

Possible resolutions

Only officially support ARMv8.2+

This effectively draws the line at the Raspberry Pi 5 and later devices. Cloud aarch64 VMs (including those provided by Hetzner and AWS) use ARMv8.2+ instruction sets. An argument in favor could be made that Arch Linux provides "desktop environment" packages and if a given piece of hardware isn't being supported by upstream providers of "desktop" applications, then perhaps we shouldn't support building any packages for those devices.

Only provide a subset of all Arch Linux (x64) packages for ARMv8

Because the scope is unknown, it's not clear if this is even feasible. If the troublesome packages cannot be cleanly "isolated" via severing dependencies on packages that do not build, this may not be feasible. It would seem unlikely for this to be the case, but I'm not aware of anyone having done the research yet (help welcome!).

This could also introduce the cost of carrying patches for PKGBUILDs to workaround intentionally missing packages. It also means building and hosting yet another copy of each package. The good (?) news is x86_64 has a small headstart with this and buildbtw may make this easier.

Find workarounds that allow us to build problematic packages without LSE

Scope/resources needed unknown. The advantage is broader device support (e.g. Raspberry Pi 4), but if there is not sufficient interest/contribution from the Arch community in supporting devices with a pre-v8.2 instruction set this may turn out to be infeasible.

Edited by Benjamin Schneider