ARMv8-A Architecture Overview

1 64-bit Android on ARM, Campus London, September 2015

 Chris Shore – ARM Training Manager
 With ARM for 16 years
 Managing customer training for 15 years
 Worldwide customer training delivery
 Approved Training Centers
 Active Assist onsite project services

 Background
 MA Physics & Computer Science, Cambridge University, 1986
 Background as an embedded software consultant for 17 years
 Software Engineer
 Project Manager
 Technical Director
 Engineering Manager
 Training Manager

 Regular conference speaker and trainer

2 64-bit Android on ARM, Campus London, September 2015

 Development of the ARM Architecture
 ARMv8-A is one of the most significant
architecture changes in ARM’s history
 Positions ARM to continue servicing
current markets as their needs grow

3 64-bit Android on ARM, Campus London, September 2015

 What’s new in ARMv8-A?
 ARMv8-A introduces two execution states: AArch32 and AArch64

 AArch32
 Evolution of ARMv7-A
 A32 (ARM) and T32 (Thumb) instruction sets
 ARMv8-A adds some new instructions
 Traditional ARM exception model
 Virtual addresses stored in 32-bit registers

 AArch64
 New 64-bit general purpose registers (X0 to X30)
 New instructions – A64, fixed length 32-bit instruction set
 Includes SIMD, floating point and crypto instructions
 New exception model
 Virtual addresses now stored in 64-bit registers

4 64-bit Android on ARM, Campus London, September 2015

 Agenda
Architecture versions

 Privilege levels

AArch64 Registers

A64 Instruction Set

AArch64 Exception Model

AArch64 Memory Model

5 64-bit Android on ARM, Campus London, September 2015

 AArch64 privilege model
 AArch64 has four exception levels, and two security states
 EL0 = least privileged, EL3 = most privileged
 Secure state and non-secure (or Normal) state
Non-Secure Secure

EL0 App App App App Trusted Services

EL1 OS OS Trusted Kernel

Hypervisor No EL2 in Secure

EL2 world

EL3 Secure Monitor

 EL2 and EL3 are optional

 A processor may not implement EL2/3 if Security or Virtualization are not required

6 64-bit Android on ARM, Campus London, September 2015

 AArch32 privilege model
 The privilege model in AArch32 is similar to ARMv7-A:

Non-Secure Secure

EL0 User App App App App Trusted Services EL0

SVC, Abort, OS
EL1 OS Trusted Kernel EL3
IRQ, etc...

Hypervisor No Hyp in Secure

EL2 Hyp
world

EL3 Mon Secure Monitor EL3

 When EL3 is using AArch32, in the Secure world the EL1 modes are treated as EL3
 No effect on the Normal world

7 64-bit Android on ARM, Campus London, September 2015

 Moving between AArch32 & AArch64
 Execution state can only change on exception entry or return
 Moving to a lower EL, execution state can stay the same or switch to AArch32
 Moving to a higher EL, execution state can stay the same or switch to AArch64

AArch64 OS can host

a mix of AArch64 and An AArch32 OS
AArch32 AArch64 AArch32 AArch64
AArch32 applications cannot host a AArch64
App App App App
application

AArch64 OS AArch32 OS

AArch64 Hypervisor
can host AArch64 and AArch32 Hypervisor
AArch32 OSs AArch64 Hypervisor cannot host AArch64
OSs

8 64-bit Android on ARM, Campus London, September 2015

 Agenda
Architecture versions

Privilege levels

 AArch64 Registers

A64 Instruction Set

AArch64 Exception Model

AArch64 Memory Model

9 64-bit Android on ARM, Campus London, September 2015

 Register banks
 AArch64 provides 31 general purpose registers
 Each register has a 32-bit (w0-w30) and 64-bit (x0-x30) form

63 32 31 0

Wn

Xn

 Separate register file for floating point, SIMD and crypto operations - Vn
 32 registers, each 128-bits
 Can also be accessed in 32-bit (Sn) or 64-bit (Dn) forms

S0 S1
D0 D1
V0 V1

10 64-bit Android on ARM, Campus London, September 2015

 Other registers
 AArch64 introduces the “zero” register – XZR and WZR
 Reads as 0, writes are ignored

 The PC is not a general purpose register, cannot be directly referenced

 There are separate link registers for function calls and exceptions
 X30 – Updated by branch with link instructions (BL & BLR)
Use RET instruction to return from sub-routines
 ELR_ELn – Updated on exception entry
Use ERET instruction to return from exceptions

 Each exception level has its own stack pointer

 SP_EL0, SP_EL1, SP_EL2 and SP_EL3
 The SPs are not general purpose registers
 Stack pointers must always be 128-bit aligned (bits 3:0 = b0000)
 Hardware checking of SP alignment can be enabled

11 64-bit Android on ARM, Campus London, September 2015

 Processor state
 AArch64 does not have a direct equivalent of the AArch32 CPSR
 Setting previously held in the CPSR are referred to as Processor State (or PSTATE) fields, and can be accessed
individually

Fields Description
N, Z, C and V ALU flags
Q Sticky overflow (AArch32 only)
DAIF Exception mask bits
SPSel SP selection (EL0 or ELn), not applicable to EL0
CurrentEL The current exception level
E Data endianness (AArch32 only)
IL Illegal flag. When set, all instructions treated as UNDEFINED
SS Software stepping bit

 AArch64 does include SPSRs, covered later...

12 64-bit Android on ARM, Campus London, September 2015

 Procedure call standard (1)
 There is a set of rules known as a Procedure Call Standard (PCS) that specifies how registers should
be used:
EXPORT foo
foo PROC
…
extern int foo(int, int); … Must preserve
… X19 - X29
int main(void) …
{ … Can corrupt:
... … X0 - X18
a = foo(b, c); …
... …
} … Return address: X30
…
(LR)
RET
ENDP

 Some registers are reserved...

13 64-bit Android on ARM, Campus London, September 2015

 Procedure call standard (2)
X0-X7 X8-X15 X16-X23 X24-X30
XR (X8) IP0 (X16)
IP1 (X17)
PR (X18) Callee-saved
(X24-28)
Parameter / result
registers Corruptible
(X0-7) Registers
(X9-15) Callee-saved
(X19-23) FP (X29)
LR (X30)

 IP0 & IP1: Intra-procedure-call temporary registers (corruptible)

 XR: Indirect result location parameter (corruptible)
 PR: Platform registers. Reserved for the use of platform ABIs
 FP: Frame pointer

14 64-bit Android on ARM, Campus London, September 2015

 Procedure call standard (3)
 The PCS also covers the use of the floating point/SIMD registers:

D0-D7 D8-D15 D16-D23 D24-D31

Parameter / result Callee saved

Corruptible registers Corruptible registers
registers registers

15 64-bit Android on ARM, Campus London, September 2015

 AArch64 ↔ AArch32 register mappings
X0-X7 X8-X15 X16-X23 X24-X30
R0 R8_usr R14_irq R8_fiq
R1 R9_usr R13_irq R9_fiq
R2 R10_usr R14_svc R10_fiq
R3 R11_usr R13_svc R11_fiq
R4 R12_usr R14_abt R12_fiq
R5 R13_usr R13_abt R13_fiq
R6 R14_usr R14_und R14_fiq
R7 R13_hyp R13_und

 When moving from AArch32 to AArch64

 Registers accessible in both registers widths
 Top 32 bits: UNKNOWN
 Bottom 32 bits: The value of the AArch32 register
 Registers that are not accessible in AArch32 retain value from previous AArch64 execution

16 64-bit Android on ARM, Campus London, September 2015

 System control
 In AArch64 system configuration is controlled through system registers
 Register names tell you the lowest exception levels they can be accessed from
 For example:
TTBR0_EL1 – can be accessed from EL1, EL2 and EL3
TTBR0_EL2 – can be accessed from EL2 and EL3

 Accessed using MSR and MRS instructions

MRS x0, TTBR0_EL1 ; Move TTBR0_EL1 into x0

MSR TTBR0_EL1, x0 ; Move x0 into TTBR0_EL1

17 64-bit Android on ARM, Campus London, September 2015

 Some important System Registers
 SCTLR_ELn (System Control Register)
 Controls architectural features, for example MMU, caches and alignment checking
 ACTLR_ELn (Auxiliary Control Register)
 Controls processor specific features
 SCR_EL3 (Secure Configuration Register)
 Controls secure state and trapping of exceptions to EL3
 HCR_EL2 (Hypervisor Configuration Register)
 Controls virtualization settings, and trapping of exceptions to EL2
 MIDR_EL1 (Main ID Register)
 The type of processor the code is running on (e.g. part number and revision)
 MPIDR_EL1 (Multiprocessor Affinity Register)
 The core and cluster IDs, in multi-core/cluster systems
 CTR_EL0 (Cache Type register)
 Information about the integrated caches (e.g. the size)

18 64-bit Android on ARM, Campus London, September 2015

 Agenda
Architecture versions

Privilege levels

AArch64 Registers

 A64 Instruction Set

AArch64 Exception Model

AArch64 Memory Model

19 64-bit Android on ARM, Campus London, September 2015

 A64 overview
 AArch64 introduces new A64 instruction set
 Similar set of functionality as traditional A32 (ARM) and T32 (Thumb) ISAs

 Fixed length 32-bit instructions

 Syntax similar to A32 and T32

ADD W0, W1, W2  w0 = w1 + w2 (32-bit addition)

ADD X0, X1, X2  x0 = x1 + x2 (64-bit addition)

 Most instructions are not conditional

 Optional floating point and Advanced SIMD instructions

 Optional cryptographic extensions

20 64-bit Android on ARM, Campus London, September 2015

 Agenda
Architecture versions

Privilege levels

AArch64 Registers

A64 Instruction Set

 AArch64 Exception Model

AArch64 Memory Model

21 64-bit Android on ARM, Campus London, September 2015

 AArch64 exceptions
 In AArch64 exceptions are split between:
 Synchronous
 Data aborts from MMU, permission/alignment failures, service call instructions, etc.
 Asynchronous
 IRQ/FIQ
 SError (System Error)

 On taking an exception the EL can stay the same OR get higher

 Exceptions are never taken to EL0

 Synchronous exceptions are normally IRQ ?

EL0 (App)
taken in the current EL
EL1 (OS)
 Asynchronous exceptions can be routed to a
higher EL EL2 (Hyp)
 SCR_EL3 specifies exceptions to be routed to EL3
 HCR_EL2 specifies exceptions to be routed to EL2 EL3 (Monitor)

 Separate bits to control routing of IRQs, FIQs and SErrors

22 64-bit Android on ARM, Campus London, September 2015

 Taking an exception
Handler for
Application code
specific source
Core branches to Top-level handler
vector table

 When an exception occurs:  To return from an exception execute ERET

 SPSR_ELn updated instruction, this:
 PSTATE updated  Restores PSTATE from SPSR_ELn
 EL stays the same OR gets higher  Restores PC from ELR_ELn
 Return address stored to ELR_ELn
 PC set to vector address
 If synchronous or SError exception, ESR_ELn updated
with cause of exception

23 64-bit Android on ARM, Campus London, September 2015

 Agenda
Architecture versions

Privilege levels

AArch64 Registers

A64 Instruction Set

AArch64 Exception Model

 AArch64 Memory Model

24 64-bit Android on ARM, Campus London, September 2015

 Memory types
 Address locations must be described in terms of a type
 The “type” tells the processor how it can access that location
 Access ordering rules
 Speculation

 Normal
 Used for code and data
 Processor allowed to re-order, re-size and repeat accesses
 Speculative accesses allowed

 Device
 Used for peripherals
 Accesses could have side effects, so there are more restrictions on what optimizations a processor can perform
 Speculative data accesses not allowed

 Other attributes can also be specified

 For example whether a region is executable, shareable and cacheable

25 64-bit Android on ARM, Campus London, September 2015

 Alignment
 Unaligned data accesses are allowed to address ranges marked as Normal

 Optionally, all unaligned data accesses can trapped

 Trapped unaligned accesses cause a synchronous data abort
 Trapping can be enabled independently separately for EL0/EL1, EL2 and EL3
 Controlled by SCTLR_ELn.A bits

 Unaligned data accesses to addresses marked as Device will always trigger an exception
 Synchronous data abort

 Instruction fetches must always be aligned

 A64 instructions must be 4-byte aligned (bits 1:0 = b00)
 Synchronous exception

26 64-bit Android on ARM, Campus London, September 2015

 Virtual address space
 Virtual addresses are 64-bit wide, but not all addresses are accessible
 Virtual memory address space split between two translation tables
 Each covering a configurable size, up to 48 bits of address space (TCR_ELn)
 Addresses not covered by either translation table generate translation faults

Virtual address space

0xFFFF,FFFF,FFFF,FFFF
Physical address space
Not available in EL2 or Peripherals
Translation
EL3 OS Tables
Peripherals

0xFFFF,0000,0000,0000 TTBR1_EL1 FLASH

FAULT
RAM
0x0000,FFFF,FFFF,FFFF

Translation
Application
Tables

0x0 TTBR0_ELn

27 64-bit Android on ARM, Campus London, September 2015

 Multiple virtual address spaces
 A system may define App / OS Virtual
multiple virtual address address space
spaces:
Peripherals
Translation
Table Physical address space
OS
 OS and applications TTBR1_EL1
Peripherals
 TTBR0_EL1 FAULT
 TTBR1_EL1 Translation
FLASH
Application Table
 TCR_EL1
TTBR0_EL1

 Hypervisor Hypervisor’s Virtual RAM

address space
 TTBR0_EL2
 TCR_EL2 Peripherals
Translation
Table
Data
 Secure Monitor TTBR0_EL2
Hypervisor Code
 TTBR0_EL3
 TCR_EL3

28 64-bit Android on ARM, Campus London, September 2015

 Physical address spaces
 ARMv8-A defines two security states: Secure and Non-secure (Normal)
 It also defines two physical address spaces: Secure and Non-secure

Secure EL1/EL0 Secure physical

 These are in theory completely address space
Secure
separate: Peripherals Translation
Tables RAM
 SP:0x8000 != NP:0x8000 Secure Data

 But most systems treat Secure/Non- Non-Secure Data Peripherals

Secure as an attribute for access control
Secure Code
FLASH
 Normal world can only access the non-
secure physical address space Non-secure EL1/EL0 Non-secure physical
address space
Non-Secure
 Secure world can access BOTH Peripherals Translation
RAM
physical address spaces Tables
Non-Secure Data
 Controlled through translation tables
Peripherals
Non-Secure Code
FLASH

29 64-bit Android on ARM, Campus London, September 2015

 MPCore configurations
 Many implementations of ARM processors have a multi-core configuration
 Multiple cores contained within the same block

 Each core has its own MMU configuration , register bank, internal state and Program Counter
 Core0 might be executing in Non-secure, AArch32 EL0 while Core1 is executing in Secure, AArch64 EL1

 Cores can be powered and brought in and out of

reset independently
 ID registers allow discovery of core affinity

 Each core has separate L1 data and instruction Core0 Core1 Core2 Core3
caches
 Hardware will maintain coherency between L1 data D$ I$ D$ I$ D$ I$ D$ I$
caches for certain memory types
Unified L2 Cache
 Some cache and TLB instructions are broadcast to other
cores
 All cores share a common physical memory map

30 64-bit Android on ARM, Campus London, September 2015

 Appendix

31 64-bit Android on ARM, Campus London, September 2015

 ARMv8 terminology reference
 EL3, EL2, EL1 and EL0 are Exception Levels
 The EL denotes the level of privilege

 AArch32 and AArch64 are Execution States

 The programmer’s model being used

 Secure and Non-Secure are Security States

 EL3 is always Secure, EL2 is always Non-Secure
 EL0/1 can be Secure or Non-Secure (sometime S.ELn or NS.ELn are used as shorthand)

 A64, A32 and T32 are Instruction Sets

 A64 used when in AArch64
 A32 and T32 used when in AArch32
 In previous architecture versions A32 was called ARM, and T32 was called Thumb

 Examples:
 Processor currently executing in EL3 as AArch64, executing A64 instructions

32 64-bit Android on ARM, Campus London, September 2015

 REServed bits and the v8 Architecture
 System registers often include REServed bit fields
 Indicating fields that are not used by hardware
Hypothetical architecturally mapped System Registers Some bits have a defined use in one Execution State,
31 0 but not the other
RES1 AARCH32 Q
Some bit fields defined as REServed (RES0/RES1) in
both AArch32 and AArch64
RES1 AARCH64 RES0

 Where a bit can be RES at one Execution State and used in another
 The Architecture defines the bit field as writeable or “stateful”
 Allows the correct value to be written for a context switch

 Where bits are unused in both Execution States

 Typically an implementation would make these fields write-ignore
 However the Architecture does permit writing to such fields
 Changing the value will have no functional impact in current implementations
 Future Architecture revisions may use these fields
 RES0/RES1 indicate expected values SW should write to guarantee current behaviour

33 64-bit Android on ARM, Campus London, September 2015

 System Register contents at reset
 In AArch64 most System Register fields are defined as UNKNOWN at reset
 If an implementation defines unused RES bits as stateful
 These fields are also defined as UNKNOWN at reset
 Recommended that software always writes the full register field when initializing (rather than read/modify write)
 Including any RES0/RES1 bits as b0/b1

 The Execution State of the highest EL (entered on reset) defines the reset contents of System
Registers
 If the highest EL uses AArch64, but lower ELs use AArch32
 You may need to initialize ARMv7/AArch32 System Registers with expected ARMv7/AArch32 reset values in software
before changing EL

34 64-bit Android on ARM, Campus London, September 2015

 ARMv8.1-A
 The ARM architecture continues to evolve, with the announcement of ARMv8.1-A

 Instruction set enhancements

 Atomic read-write instructions added to A64
 For example: Compare and swap
 Additional SIMD instructions
 Example use case is colour space conversion
 Load and stores with ordering limited to a configurable region

 Virtualization Host Extensions

 To improve performance of Type 2 Hypervisors

 And other enhancements to the memory system architecture, such as Privileged Access Never
(PAN) state bit

35 64-bit Android on ARM, Campus London, September 2015

 ARMv8-A software support
 ARMv8 software support now widely available in the open source community

 Linux Kernel
 AArch64 support has been available in mainline for several releases
 Under arch/arm64/

 Filesystems
 AArch64 kernel supports both legacy ARMv7-A and AAarch64 filesystem components
 Some guidance on building file-systems for AArch64 is available here
https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded
 Both Fedora and openSUSE have AArch64 releases

 ARM Foundation Model

 Linaro provide an example kernel and file-system, which can be executed on ARM's free virtual software platform
(Foundation Model)
 http://www.arm.com/products/tools/models/fast-models/foundation-model.php
 http://www.linaro.org/engineering/engineering-projects/armv8


36 64-bit Android on ARM, Campus London, September 2015

 ARMv8-A software support continued
 Open Source Tools Support
 Linaro provide prebuilt AArch64 GCC toolchain binaries (GCC, GDB, etc.) with Linux and bare-metal library options
 These are available as cross or native toolchains
 GCC 4.8 includes –mcpu tuning support for Cortex-A53
 https://launchpad.net/linaro-toolchain-binaries/

 ARM tools
 The ARM compiler supports AArch64 and is suitable for bare-metal/validation environments
 DS-5 includes debug support for ARMv8 hardware and models http://www.arm.com/products/tools/software-tools/ds-
5/index.php
 Fast Models allows the creation of Cortex-A5x based ARM Virtual Platforms for software development

37 64-bit Android on ARM, Campus London, September 2015

 ARM Technical Training
 Available
 Covering all ARM cores and GPUs
 Hardware and Software options
 Customizable agendas from 2 hours (Live Remote only) to 5 days
 Accessible
 Private, onsite delivery for corporate customers
 Public course schedule for open enrolment
 Live Remote webex for flexible delivery
 Affordable
 Standard Private course fees include all ARM’s related expenses
 Public course pricing accessible to individuals
 Live Remote is cost effective for small teams
 Learn from the experts

http://www.arm.com/training

38 64-bit Android on ARM, Campus London, September 2015

 ARMv8-A Architecture Overview

39 64-bit Android on ARM, Campus London, September 2015