AArch64 (ARM64)#

Status#

⚠️ Warning

There is no official Port for this architecture. A Port is made official via an approved RFC, and there is no 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).

The community does maintain unofficial packages to facilitate research, development, and testing in preparation for an RFC. Coverage of [core] and [extra] packages is very good. Most official Arch Linux packages build and run without patches on this architecture.

There is no central GitLab namespace for aarch64-related forks of official package source repositories. But if a package does need modifications that cannot be merged, or 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 GitLab namespaces of solskogen and bschnei.

The AUR does not accept packages that do not have x86_64 in arch(), but adding aarch64 to arch() when it also contains x86_64 is permitted and encouraged.

Community discussion and support is facilitated by the #archlinux-ports IRC channel.

Device support#

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). It also supports virtual hosts (e.g. Hetzner and AWS cloud compute resources).

Support for bare metal devices is entirely community-driven. The devices listed below are those reported by the community to be working with the kernel available in the package repositories:

The following devices require installing a non-mainline kernel:

Raspberry Pi 5 (linux-rpi5)

Devices with the following chipsets are also expected to work:

Marvell Armada 37xx
NXP i.MX91/93
Qualcomm Snapdragon X Elite
Rockchip rk3588

If you own a device with mainline support, consider joining the community.

Installation notes#

The ISOs available use systemd-boot as their boot manager which only supports UEFI booting. Unlike modern x86_64 devices, aarch64 devices often use custom/proprietary bootloaders that may not support UEFI.

ISOs will also only work on devices supported by the linux package as configured for this Port. Note that it is not uncommon for ARM devices to require special kernel parameters in order to boot. These can often be found by examining them on an already-running Linux distribution on your device. They can be added on the systemd-boot boot menu.

The ISOs also use stubble which provides support for automatically loading necessary devicetrees for devices supported by the stubble project.

Devicetrees are packaged in linux-dtbs. This package only installs devicetrees to /usr/lib/modules/$kernver/dtb. If your device’s bootloader needs to load a devicetree to boot, you will need to configure stubble (if it supports your device), write a pacman hook, or use other community-provided solutions.

Migrate from Arch Linux ARM#

For supported devices, it is possible to simply update pacman.conf to use one of the unofficial package repositories, however it is not without some degree of risk, and reverting is not possible. After changing pacman.conf, it is critical to reinstall all packages to avoid a broken system. As a result, it is important to confirm that all of the packages you need are available in the repository to which you intend to migrate.

Package repositories#

⚠️ Similar to the unofficial user repositories available for x86_64, the following repositories are community-maintained, and the same warning applies.

arch.bens.haus (ARMv8+)#

These repos are for ARMv8 (or v8.1) devices (e.g. Raspberry Pi 4). If your device supports ARMv8.2 (or later) instructions, these packages will work, but packages in drzee.net repos provide better support/performance.

These repositories primarily exist to support research into the cost/feasibility of ARMv8 support.

drzee.net (ARMv8.2+)#

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 the 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 browsable (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/

Installation and recovery ISO images for supported devices are available here:

https://codeberg.org/ironrobin/archiso-aarch64/releases/latest

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 only available in the eu-central-1 region.

To run on AWS you will need to set up 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 the 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.

Get involved#

If you are comfortable running the unofficial packages provided by the community on your ARM device, please join us! We are having a lot of fun getting Arch running on our Raspberry Pis and ARM laptops.

If you have a device with mainline Linux support, but it is not in the list of devices confirmed to be working, consider testing and contributing to kernel configuration as needed to bring support to your device.

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.

One of the primary pre-RFC efforts is identifying packages that require relatively straightforward changes to build on non-x86_64 architectures and submitting those changes to the official package for consideration. See here for an example.

Generic aarch64-related Work Items (issues unrelated to specific packages) are tracked here.

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, 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 implements the ARMv8-A instruction set, while the Raspberry Pi 5 uses the Cortex-A76, which implements 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 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.