PORTING SOFTWARE FROM POWER ARCHITECTURE® TO ARM® FTF-DES-N1841
BHUPESH SHARMA TEAM LEAD, UEFI FIRMWARE, DIGITAL NETWORKING FTF-DES-N1841 MAY 16, 2016
PUBLIC USE AGENDA
• Overview of QorIQ Processors • Comparison of environments: Power® vs ARM® − 32-bit v/s 64-bit − Instruction Set Architecture (ISA) − IP Ecosystem − Endianness • ARM fundamentals for good software design − Memory Model − Exception Model − Security Model • Software Support • Summary
1 PUBLIC USE #NXPFTF 1 PUBLIC USE #NXPFTF OVERVIEW OF QORIQ PROCESSORS
2 PUBLIC USE #NXPFTF Overview of QorIQ Processors
3 PUBLIC USE #NXPFTF Power Architecture Technology - Core Overview
ISA / MHz Platforms
e5500 Platforms e5500 e6500 Power Architecture ISA QorIQ P5, T1 Platforms Core Core 1.2 GHz – 2.2Ghz e6500 Platforms QorIQ T2, B4, T4 Platforms
e600 Platforms Power Architecture ISA MPC86xx host processors e600 600 MHz – 1.8 GHz Core MPC74xx host processors
e500 Platforms PowerQUICC III MPC85xx e500 e500-mc Power Architecture ISA QorIQ P1 & P2020 Platforms Core Core 533 MHz – 1.5 GHz e500-mc Platforms QorIQ P204x, P3 and P4 Platforms e300 Platforms e300 PowerQUICC II Pro MPC83xx Power Architecture ISA PowerQUICC II MPC82xx Core 266 MHz – 667 MHz MPC52xx microcontrollers MPC51xx microcontrollers
e200 Power Architecture e200 Platforms Core 80 MHz – 475 MHz MPC55xx auto microcontrollers
4 PUBLIC USE #NXPFTF e300 ↔ e500 ↔ e500mc ↔ e5500 ↔ e6500 Cores Relative Optimized Performance
Frequency overlap allows for incremental performance boosts as required • e6500 frequency range: 1.6 GHz – 1.8 Ghz e6500 Platform • e5500 frequency range: 1.2 GHz – 2.2 GHz • e500mc frequency range: 1 GHz – 1.5 GHz • e500 frequency range: 533 MHz – 1.5 GHz • e300 frequency range: 266 MHz – 667 MHz • More efficient core • Multi Thread support e5500 Platform • AltiVec™ SIMD vector processor • Advanced power saving modes
• 64-bit ISA • Back side L2 • Dual Precision FPU
e500 Platform Each platform architecture leads to higher efficiency/cycle
5 PUBLIC USE #NXPFTF ARM Cores Device Family ARM Processor Family ARM Architecture Core ARM700 ARM7 ARMv3 ARM710 ARM710a ARM1136J ARM1156T2
Classic ARM Classic ARM11 ARMv6 ARM1176JZ ARM11MPCore Cortex-M0 ARMv6-M Cortex-M1 Cortex-M ARMv7-M CortexM3
Embedded ARMv7E-M Cortex-M4
Cortex-R4 Time - Cortex-R ARMv7-R Cortex-R5
Real Cortex-R7 Cortex-A5 Cortex-A7 Cortex-A ARMv7-A Cortex-A8 Cortex-A9 Application Cortex-A15 Cortex-A53
Cortex-A5x ARMv8-A Cortex-A57
bit bit Core -
64 Cortex-A72
6 PUBLIC USE #NXPFTF QorIQ SoCs and Core Architectures Power ARM QorIQ SoCs QorIQ SoCs Cores Cores
• P1010 32bit • BSC913x • LS1021A e500 arch ARMv7
• T1040 • P5040 ARMv8 • LS1043A e5500 (DPAA1)
64bit • B4860 arch • LS2080A • T4240 ARMv8 e6500 • B5T10 (DPAA2) • LS1088A*
* These devices are under development
7 PUBLIC USE #NXPFTF COMPARISON OF ENVIRONMENTS: POWER® VS ARM® - 32 BIT V/S 64-BIT
8 PUBLIC USE #NXPFTF Data Size and Instruction Sets
• Both Power Architecture and ARM are based on RISC architecture − Fixed instruction set length − Most instructions execute in a single cycle − Superscalar dual issue core with out-of-order execution and in-order completion − ARM: Every instruction can be conditionally executed
9 PUBLIC USE #NXPFTF Power Architecture: 32bit vs 64bit – SW Programmers View
32-bit Power 64-bit Power machines machines
Supports 32bit and 64bit execution modes Supports 32bit execution mode - 32-bit execution mode is like 32-bit implementation (shown on the left) - 32-bit effective address - 64-bit execution mode: - 32-bit registers ~ 64-bit effective address - Instructions to manipulate 32-bit address and 32-bit registers ~ 64-bit registers ~ Instructions to manipulate 64-bit address and 64-bit registers
U-boot executes in 32bit mode U-boot, Linux and apps execute in 32bit mode Linux executes in 64bit mode Apps: 32b and 64b
10 PUBLIC USE #NXPFTF Power Architecture Registers: General Purpose Registers
bit bit bit bit 32-bit implementations 63 32 31 0 Example Cores: e500#, e500mc H I G H E R W O R D L O W E R W O R D Used in: BSC9131, P4080
Lower 32-bits accessible to integer instructions
All 64-bits accessible to SPE instructions
bit bit bit bit 64-bit implementations 63 32 31 0 Example Cores: e5500, e6500 H I G H E R W O R D L O W E R W O R D Used in: T1040, T102x, T4240
Lower 32-bits accessible to 32-bit execution mode
All 64-bits accessible to 64-bit execution mode, and to SPE instructions
11 PUBLIC USE #NXPFTF Power Architecture: Types of Registers
• GPR:
− Used by integer instructions
− All registers are user privileged
• Floating Point registers:
− Used by floating point instructions
− SPE (signal processing engine) don’t use it: SPE uses GPRs
• Vector Registers: AltiVec
• SPR (Special Purpose Register):
− Ex: Link Register
− Instructions used to manipulate these registers: m[t|f]spr
− Not all registers are privileged ones
• MSR: Machine State Register
• Memory Mapped Registers – used to manipulate L2 cache settings
• Thread Management Registers (eg: setting CPU-thread priority)
− CPU threads
• Performance Monitor Register: User RO
12 PUBLIC USE #NXPFTF ARM Architecture: 32bit vs 64bit - SW Programmers View
32-bit ARM 64-bit ARM machines machines
Supports 32bit (AArch32) and Supports 32bit execution 64bit (AArch64) execution mode states
Bootloader, Linux and Bootloader executes in 64bit mode apps execute in 32bit Linux executes in 64bit mode mode Apps: 32b and 64b
13 PUBLIC USE #NXPFTF ARM Architecture: 32bit vs 64bit - SW Programmers View
• Rather than sharing the instruction decoder between 16-bit only 32-bit and 64-bit instruction sets, ARM implements Thumb a separate decoder for A64 Execution − This means that when running 64-bit software the State 32-bit part of the machine does not need to be active. Jazelle Execution • Limitation: State (can execute − Transition between 32-bit and 64-bit execution raw java states can only occur on exception boundaries byte- . i.e. it is not possible to interleave 32 bit and 64 codes) bit code
14 PUBLIC USE #NXPFTF ARM Register Set (32-bit Implementations)
• 37 registers in total ARM state general purpose register and program counter • 16 general purpose registers
• 20 banked register
• Registers are 32-bits long
• The registers are arranged into several banks, with the accessible bank being governed by the processor mode.
• Some of the registers have special significance
− R13 – stack pointer (SP)
− R14- link registers (LR)
− R15 – Dedicated program counter (PC)
• Status registers
• 1 dedicated Current Program Status Register (CPSR)
Current Banked out • mode 5 dedicated Saved Program Status Register (SPSR) registers
• There are banked SPs, LRs, and SPSRs for each privileged mode. 15 PUBLIC USE #NXPFTF ARM Register Set (64-bit Implementations) 31 general purpose registers • AArch64 has 31 general purpose registers (X0 – X30) accessible at all times – SP and PC are not general purpose registers. • AArch64 Banked registers are banked by exception level − Used for exception return information and stack pointer − EL0 Stack Pointer can be used by higher exception levels after exception taken.
Un-Banked Registers
Banked Registers
16 PUBLIC USE #NXPFTF COMPARISON OF ENVIRONMENTS: POWER® VS ARM® - ISA
17 PUBLIC USE #NXPFTF Instruction Set Architecture (ISA) – Power Architecture
Single ISA • Only one ISA is defined
32bit • 32-bit effective address • 32-bit registers execution • Instructions to manipulate 32-bit address and mode 32-bit registers
64bit • 64-bit effective address • 64-bit registers execution • Instructions to manipulate 64-bit address and mode 64-bit registers
18 PUBLIC USE #NXPFTF Instruction Set Architecture (ISA) – ARM Architecture
• Fixed length (32b) instructions ARM Execution • Available in ARMv8 and earlier architectures State: AArch32 • ISA is A32 (ARMv7 and before: it’s called ARM instructions)
T32 (aka Thumb- • A variable length (16b, 32b) instruction set 2, applicable for • ARMv7 & before, referred to as Thumb AArch32) instructions and all instructions were 16-bit
ARM Execution • Available in ARMv8 architecture only • Instruction set is called A64 State: AArch64 • Fixed length (32b) instructions
19 PUBLIC USE #NXPFTF ARM Vs PA Instruction Set Examples
Memory access instructions: Memory access instructions:
STRB r4,[r7], #8 ; storing a byte stbu r4,0x8(r7) ; storing a byte ; store the lower byte of r4 in to the address ; store the lower byte of r4 in to the pointing to by r7 address pointing to by r7+0x8 ; then update r7 with 8 ; then update r7 with r7 + 0x8
Program flow instructions: Program flow instructions:
21 PUBLIC USE #NXPFTF ARM v/s PA - IP Ecosystem
Power based QorIQ ARM based QorIQ IP SoCs SoCs Interrupt Controller MPIC GIC
IOMMU PAMU SMMU Vector Instruction AltiVec NEON Processing Bus Corenet CCN504, CCI400 DPAA2 (WRIOP) Data Path Arch DPAA1 (Fman) DPAA1 (Fman) PowerPC timers ARM generic timers Timers FlexTimer FlexTimer Watchdog NXP’s WDT ARM’s WDT
Platform cache (L3) NXP’s CPC ARM CCN
22 PUBLIC USE #NXPFTF ARM v/s PA - Misc Hardware Related Features
• Power Architecture supports CPC (Corenet Platform Cache), an L3 cache. Cache as • CPC supports converting a part of cache into SRAM. • Above SRAM is used during boot phase till DDR is initialized. SRAM • ARM: L3 cache doesn’t support above feature
• CPC supports decorated operation: High performance atomic “fire Decorated and forget” operations on memory Load / Store • ARM L3 cache doesn’t have it.
• LAW stands for Local Access Window. • Power architecture (using LAW) allows relocating the address of a LAW target device. • ARM SoCs instead support a flat memory model.
23 PUBLIC USE #NXPFTF COMPARISON OF ENVIRONMENTS: POWER® VS ARM® - ENDIANNESS
24 PUBLIC USE #NXPFTF Power Core Endianness
• Power processors are big-endian by Big-endian default (can
• Big-endian memory systems − least significant byte is at lowest address. − Example: byte 0 of the memory system connects to data lines 31 to 24
25 PUBLIC USE #NXPFTF ARM Core Endianness
• ARM processors are little-endian by default (can be configured to access big- Big-endian endian memory system).
• Big-endian memory systems − least significant byte is at lowest address. − Example: byte 0 of the memory system connects to data lines 31 to 24
• Little-endian memory systems − most significant byte is at lowest address Little-Endian − Example: byte 0 of the memory system connects to data lines 7 to 0. 26 PUBLIC USE #NXPFTF Endianness – How Does It Affect a S/W Programmer?
NW apps: • Network packets follow network byte-order on wire – BE format • If a networking program written originally for PPC platforms, Interpretation of doesn’t take care of byte-ordering while interpreting a packet, it’ll network packets still work on BE machines but it may not work on LE machine.
Device drivers: • In QorIQ SoCs, most of the hardware registers are 32bit sized • If a driver accesses a sub-field of the 32bit hardware register, the Accessing driver software needs attention when it migrates to ARM from hardware registers PPC.
Bitwise fields in • Bitwise members in struct may become a challenge for porting a structures software across architectures of opposite endianness
27 PUBLIC USE #NXPFTF Endianness – Rework S/W to Ease Transition to ARM
NW apps: • Use “ntoh()” family (ntohs, ntohl etc) while parsing the RX’ed packet. • Use “hton()” family (htons, htonl etc) while forming a packet. Interpretation of • Once above is done, the same source code compiles appropriately network packets for the either core-endianness.
Device drivers: • Use accessors to access hardware registers • U-boot: IFC driver uses ifc_out32() to write IFC registers. Accessing • Accessors get compiled according to the underlying core hardware registers endianness.
Bitwise fields in • Avoid using such struct when writing architecture independent code. structures
28 PUBLIC USE #NXPFTF ARM FUNDAMENTALS FOR GOOD SOFTWARE DESIGN - MEMORY MODEL
29 PUBLIC USE #NXPFTF Memory Model
• A system includes different memories System Memory Map and peripherals Non-cacheable − The processor needs to be told how it Peripherals should access different devices
Privileged OS • For each address region: − Access permissions (R/W permissions Application for User/Privileged modes) User Space − Memory types (Caching/Buffering and access ordering rules for memory access) Cached/Read only Vectors
30 PUBLIC USE #NXPFTF ARM Memory Types
• The type tells the attributes of the memory region • ARMv8 Memory attributes: − Gathering (merging multiple transactions), − Re-ordering (accesses in program-order), − Early-Write-Ack-hint (only the end-point returns ack)
• In v6/v7: three memory types specified: Normal, Device and Strongly-ordered
Normal • Typically, memory used for program code and for data storage is ‘Normal’ • Sharable normal memory: Inner, Outer sharability domains • Non-sharable normal memory: hardware generally doesn’t do coherency ops Device • Memory map accesses to system are defined as Device/ peripherals. • Reads may result into side effect • Memory attributes: nGnRE – no gathering, no re-ordering, early-ack Strongly- ordered • Examples: memory-mapped peripherals and I/O locations.(data used by legacy code) • Memory attributes: “nGnRnE” – no gathering, no re-ordering, no early-ack
Note: In ARMv8: Device and Strongly-Ordered have been renamed to nGnRnE, nGnRE respectively
31 PUBLIC USE #NXPFTF Data & Stack Alignment
• Data Alignment Requirements − ARM cores supporting architecture v6 and later are capable of supporting unaligned accesses in hardware. . Data access can be unaligned . Address marked as “Normal” can be accessed unaligned
− Load and store unit will access memory with aligned memory access.
− ARM processor instruction and data is little-endian (by default), but data side can be configured to access big- endian system.
• Stack Alignment Requirements − For AArch32 architectures: . Stack must be aligned to a 8-byte boundary. − For AArch64 architectures: . Stack must be aligned to a 16-byte boundary.
32 PUBLIC USE #NXPFTF ARM FUNDAMENTALS FOR GOOD SOFTWARE DESIGN - EXCEPTION MODEL
33 PUBLIC USE #NXPFTF Exceptions and Interrupts
• Interrupts
− Action where processor saves current context Operating System Applications (Exception Handlers) and begins execution at predetermined NORMAL interrupt handler rfi User Supervisor Privilege Privilege Level Level • Exceptions Errors, − Events which cause the Traps, processor to take an interrupt Interrupts
. Synchronous Exception . Asynchronous Context Switching
34 PUBLIC USE #NXPFTF PowerPC Exceptions Classes
Type Exception
Machine Check Asynchronous/non maskable System Reset
External Interrupt Asynchronous/maskable Decrementer
Instruction caused exception, excluding floating point imprecise Synchronous/Precise exceptions
Instruction caused imprecise exceptions Synchronous/imprecise (Floating-point imprecise exception)
35 PUBLIC USE #NXPFTF ARM processor Events (<= ARMv6)
ARM processor has 7 events that can halt the normal sequential execution of instructions.
Simultaneous multiple events :
- Current instruction will be completed no matter what event has been raised.
- Except when a data abort occurs on the first offending data address being accessed by LDM or STM. Set /Cleared by I and F bits ARM core (No represent the S/W intervention respective required) CPSR bits
36 PUBLIC USE #NXPFTF ARM processor Events (= ARMv7)
Two new ARM modes were introduced in ARMv7
Monitor Hypervisor mode mode
Monitor mode is a Hyp mode is a Non- Secure mode secure EL2 mode.
S/W running in Monitor mode has Used to provide access to both the virtualization Secure and Non- support. secure copies of system registers.
37 PUBLIC USE #NXPFTF ARM Processor Events (= ARMv8)
• Architecture based around “Exception Levels” and • EL0 Privilege Levels − Lowest software execution privilege, − EL0/EL1/EL2/EL3 and PL0/PL1/PL2/PL3 − Execution at EL0 is called unprivileged execution. • Increased values of n, from 1 to 3, indicate • Increased software execution privilege. • Exception levels broadly designed for one software “layer” • EL2 provides support for virtualization. − EL0 – Application • EL3 provides support for two security states. − EL1 – OS Kernel On taking an exception to a higher exception − EL2 – Hypervisor (non-secure only) level, the execution state: − EL3 – Secure Monitor • Can either: — Remain the same. — Increase from AArch32 state to AArch64 state.
• Cannot decrease from AArch64 state to AArch32 state.
On returning from an exception to a lower exception level, the execution state:
• Can either: — Remain the same. — Decrease from AArch64 state to AArch32 state.
• Cannot increase from AArch32 state to AArch64 state. 38 PUBLIC USE #NXPFTF ARM FUNDAMENTALS FOR GOOD SOFTWARE DESIGN - SECURITY MODEL
39 PUBLIC USE #NXPFTF ARM Trustzone
• Security of the system is achieved by: − Partitioning all of the SoC’s hardware and software resources so that they exist in one of two worlds . Secure world for the security subsystem, and . Normal world for everything else
Normal World Secure World Application Application Trusted Service Secure Guest OS Guest OS Monitor Trusted OS Hypervisor
40 PUBLIC USE #NXPFTF SOFTWARE SUPPORT
41 PUBLIC USE #NXPFTF Power vs ARM: Should QorIQ Developers Worry?
• Power and ARM SoC: SDKs of both are packaged using Packaging Yocto Familiar host and target experience Development • SDKs use GNU based compiler tools • GCC tool-chains also support BE and ILP32 for ARM Environment • CodeWarrior® Debugger supports Power and ARM Enablement SW • QorIQ LS software drivers already support both ARM and takes care of Common Power SoCs. architectural differences Drivers • You need not worry about endianness
• NXP is aggressive in upstreaming the platform and IP Quality software Quality support code. on all QorIQ SoCs • Extensive testing for ARM and PowerPC based SoCs
Smooth transition of developers between Power and ARM QorIQ SoCs
42 PUBLIC USE #NXPFTF SUMMARY
43 PUBLIC USE #NXPFTF Summary
QorIQ family includes both PowerPC and ARM based SoCs
There are architectural differences between PowerPC and ARM cores/SoCs
Developers moving from one architecture to the other should know these differences
QorIQ SDK takes care of above differences
Ease of use for driver development: Hassle-free transition between the two architectures
44 PUBLIC USE #NXPFTF
ATTRIBUTION STATEMENT
NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD, CoolFlux, EMBRACE, GREENCHIP, HITAG, I2C BUS, ICODE, JCOP, LIFE VIBES, MIFARE, MIFARE Classic, MIFARE DESFire, MIFARE Plus, MIFARE FleX, MANTIS, MIFARE ULTRALIGHT, MIFARE4MOBILE, MIGLO, NTAG, ROADLINK, SMARTLX, SMARTMX, STARPLUG, TOPFET, TrenchMOS, UCODE, Freescale, the Freescale logo, AltiVec, C 5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C Ware, the Energy Efficient Solutions logo, Kinetis, Layerscape, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert, QorIQ, QorIQ Qonverge, Ready Play, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid, Airfast, BeeKit, BeeStack, CoreNet, Flexis, MXC, Platform in a Package, QUICC Engine, SMARTMOS, Tower, TurboLink, and UMEMS are trademarks of NXP B.V. All other product or service names are the property of their respective owners. ARM, AMBA, ARM Powered, Artisan, Cortex, Jazelle, Keil, SecurCore, Thumb, TrustZone, and μVision are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. ARM7, ARM9, ARM11, big.LITTLE, CoreLink, CoreSight, DesignStart, Mali, mbed, NEON, POP, Sensinode, Socrates, ULINK and Versatile are trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. The Power Architecture and Power.org word marks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org. © 2015–2016 NXP B.V.
46 PUBLIC USE #NXPFTF