Arm64

= ARM64 primer = This is meant as an brief introduction to the ARM64 architecture, mostly to bring people with ARM(32) background up to speed.

ARM64 cheat sheet
This table is somewhat simplified to give a quick overview. For more information refer to either Wikipedia, the ARM Architecture Reference Manual (ARM ARM) or the sections below.

Instruction set architecture
Though the mnemonics for the assembly instructions are somewhat similar, AArch32 and AArch64 assembly code are ultimately incompatible due to the different register naming (r0 vs. x0/w0). Also the instruction encoding is completely different. The generic, but rarely used coprocessor interface on ARMv7 is replaced with a dedicated system register access scheme, with the system registers official identified as (mostly architectural) strings by the assembler, but eventually encoded similar to the ARMv7 CP15 interface. While AArch32 features conditional execution for almost every instruction, AArch64 uses those extra bits to address more registers and encode the 32 or 64-bit operand size. So branches and some selected instructions like "conditional set" are the only instructions which can execute conditionally.

Naming conventions
There is an updated ARM architecture revision called "ARMv8", which evolved from the ARMv7 architecture. Among other things it introduces a new execution state called "AArch64", which provides a full 64-bit architecture.

ARMv8 compliant implementations can provide this state or not, also they are free to implement the "AArch32" state, which closely resembles the ARMv7 architecture. So both 32-bit and 64-bit states are optional - but you should of course have at least one ;-). ARM Cortex cores provide both states, while there are implementations from other vendors which do not provide AArch32, for instance.

The Linux kernel chose to call this new architecture "arm64", the same name got picked up by Debian for their architecture port name.

The GNU toolchain however elected the official "aarch64" name for the port, so the GCC (cross-)compiler is usually called "aarch64-linux-gnu-gcc". So although the arm64 name is not official, it can be used interchangeably for aarch64.

Boot modes
In cores implementing both AArch32 and AArch64, it is IMPLEMENTATION DEFINED in which state they start execution when coming out of reset after power up. ARM Cortex cores feature a (RTL defined) pin, which determines the initial execution state. Usually SoC vendors don't connect this to a real pin on the SoC's package, but tie it to a fixed level during integration. The Allwinner A64 SoC for instance chose to come up in the AArch32 state, so the BROM code is standard 32-bit ARM code, as are the following parts of the Allwinner firmware stack, including U-Boot.

It is always possible to "decrease the bitness" when dropping down from a higher privileged execution level, but one can't grow bigger this way. This for instance allows 64-bit firmware to boot 32-bit kernels, 64-bit hypervisors with 32-bit guests or 64-bit kernels with 32-bit userland programs, but not the other way round.

To switch execution state from AArch32 back to AArch64, one has to either call into a higher execution level (given that this level is using AArch64) or do a warm reset using the RMR register.

The RMR register allows to trigger a warm reset of the processor core, allowing to change the initial execution state of the core directly after it comes out of the (warm) reset condition. Execution starts at the address in the RVBAR register, in the highest implemented exception level, which is EL3 for the ARM Cortex cores used in the Allwinner SoCs. This is utilized by the Allwinner firmware implementation, which starts 64-bit Linux kernels using this technique from an U-Boot running otherwise completely in 32-bit.