AArch64 (ARM64)#

Status: Unofficial
RFC: None

⚠️ Warning

There is currently no proposed RFC for this architecture. Any packages available for this architecture are:

• not built with Arch Linux infrastructure,
• not signed by Arch Linux Staff, and
• not hosted on Arch Linux domains/mirrors.

Packages may also be outdated, broken, or missing entirely.
Support is primarily provided by other Arch Linux users (i.e. not Staff).

Unofficial packages are publicly available to facilitate research and testing in preparation for an RFC. Pre-RFC Work Items (f.k.a. Issues) unrelated to specific packages are tracked here.

Most official Arch Linux packages build and run without modification on this architecture. One of the primary pre-RFC efforts is identifying packages that require relatively straightforward changes to build on non-x64 architectures and submitting those changes to the official package for consideration. See here for an example.

If a package needs modifications to build that cannot be/have not yet been merged into the official package, they are typically discoverable by examining an official package’s forks in GitLab. Most of the relevant forks can be found in the personal namespaces of solskogen and bschnei. If you are expecting to see one, but cannot find it, reach out on IRC.

If you are having issues with a specific package, please determine whether it is aarch64-specific or not before raising. Do not open aarch64-specific Work Items on upstream packages. Instead, consider: fixing the issue and submitting a merge request, creating a Work Item on one of the user-maintained forks, or reaching out on IRC.

Device support#

CPU features#

ARMv8-A is the first version of the ARM architecture to support 64-bit instructions. Since its introduction in 2011, there have been many extensions (ARMv8.2-A, ARMv9.0-A, etc.) of the original instruction set. In many cases, these extensions add new CPU instructions or require manufacturers to implement features that were only optional in prior versions.

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.

Be aware that a CPU generally advertised as being a certain version 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 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.

🛈️ Packages available on drzee.net target ARMv8.2-A.

The lack of certain CPU instructions can significantly affect performance or even cause some packages to fail to build. Determining the minimum supported instruction set for this architecture is an open Work Item.

Kernel configuration#

In contrast to x86_64 devices, which use standardized boot processes (BIOS/UEFI) and hardware discovery (ACPI), ARM systems traditionally rely on custom/proprietary bootloaders and static hardware configurations (devicetrees). The absence of a common boot procedure and hardware auto-detection poses challenges for supporting ARM devices broadly.

The linux package for this port intends to support devices with mainline Linux support (i.e. those that do not require vendor-/device-specific patches). This kernel is known to work on virtual hosts (e.g. cloud infrastructure) but has limited bare metal device support. If you own a device with mainline support and can contribute to the lists below and/or develop the kernel configuration, to support additional devices, your contributions are welcome.

Devices confirmed working#

• ASUS Vivobook S15 S5507Q
• Globalscale ESPRESSObin Ultra
• Lenovo Chromebook Duet
• ODROID-C4
• ODROID-M1
• ODROID-M2
• Radxa Orion O6
• Radxa Rock 5B

Devices suspected to work but unconfirmed#

• Anything with the Marvell Armada 37xx chipset
• Anything with the Qualcomm Snapdragon X Elite chipset

Devices needing special kernel packages#

• Raspberry Pi 5 (linux-rpi5)

Package repositories#

drzee.net#

These repos provide broad coverage of official Arch Linux packages and are well maintained. A status dashboard is available here. The build system runs on ARMv8.2 cloud infrastructure (i.e. no cross-compilation). The build host runs the unofficial packages that it itself builds.

⚠️ Packages are built for devices supporting the ARMv8.2 (and later) instruction sets only. That means they will not work on Raspberry Pi 4 or devices with the ARM Cortex A53 or earlier CPUs.

There are 3 repos: core, extra, and forge.
Core and extra are analogues of their x86_64 counterparts.
Forge is meant for packages that do not otherwise “belong” in core or extra (e.g. linux-rpi5).

To use these repos, adjust pacman.conf.
For example:

[core]
Server = https://arch-linux-repo.drzee.net/arch/$repo/os/$arch

[extra]
Server = https://arch-linux-repo.drzee.net/arch/$repo/os/$arch

[forge]
Server = https://arch-linux-repo.drzee.net/arch/$repo/os/$arch

The repositories are hosted on AWS S3, which does not generate directory listing/indexes for directory trees. To access the directory listing/index for a given repository, add a ‘/’ at the end of the repository path, e.g. https://arch-linux-repo.drzee.net/arch/core/os/aarch64/. Only the leaf folder can be browsed; other parts of the tree are not browse-able (e.g. https://arch-linux-repo.drzee.net/arch/), and an “access denied” message will be shown.

The package signing key is available here: https://arch-linux-repo.drzee.net/arch/extra/os/aarch64/public.key

Bootstrap tarballs built with the packages in these repos are available here: https://arch-linux-repo.drzee.net/arch/tarballs/os/aarch64/

Cloud Images#

Amazon Web Services - EC2#

A cloud image for use with AWS is built approximately every 15 days. The current AMI ID can be found here and is, at the moment, only available in eu-central-1 region.

To run on AWS you will need to setup an AWS account and spin up an EC2 instance using the AMI.

• Setup AWS account, make sure to follow all steps including securing the account with an MFA token!
• Launch an EC2 instance, make sure to choose/search for the AMI ID from the above link at the relevant step (Task 4, Step 4), double check that you have selected the eu-central-1 region.

If you don’t want to run in eu-central-1 region you can copy the AMI to a different region by following these instructions. This creates a copy of the AMI, with a new AMI ID, in your account. Your account will be charged for the storage costs.