ePAPR Specification

PAPR Technical Subcommittee

Stuard Yoder
Chair, PAPR TSC

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.

Agenda
Background
Overview
Boot programs and client programs
Device tree
Multi-core boot architecture

Status and Future Plans

ePAPR Background
Power.org released the Power Architecture Platform
Requirements (PAPR) specification in August 2006-- for
desktop/server platforms
A complete platform definition is not applicable to embedded
systems, but there are areas where standardization helps
There are a huge number of highly-customized, fixed function,
embedded platforms-- routers, industrial controls, automotive, etc.

Initial effort is around defining standards (dubbed ePAPR)

around a boot program to client program interface
Defining what the client program sees

Standard is being developed by the Platform Architecture

Committee

Boot Program / Client program

Boot Program
Firmware
Second stage bootloader
Hypervisor

Client Program

Second stage bootloader

Hypevisor
Operating system
Other bare metal application

ePAPR 1.0
ePAPR 1.0 addresses boot services how a boot program initializes
hardware and boots a client program
Key areas
State of machine when control is transferred to client (e.g. registers, MMU, state
of interrupts)
Device Tree definition
Multi-cpu boot architecture
ELF (Executable and Linking Format) for client programs

Loosely related to IEEE 1275, and draws heavily on on-going work being
done in the PowerPC Linux community
(booting-without-of.txt)

Specification was released from the platform architecture committee for

formal approval April 2008. Expect final approval by power.org in August
time frame.

Initial Machine State

ePAPR defines the state of the hardware when control is
transferred to a client program

Registers
MMU
CPUs
Memory
State of I/O devices no interrupts or DMA

Intial State of Registers

Register

Value

MSR

PR=0 supervisor state

EE=0 interrupts disabled
ME=0 machine check interrupt disabled
IP=0 interrupt prefix-- low memory
IR=0,DR=0 real mode (see note 1)
IS=0,DS=0 address space 0 (see note 1)
SF=0, CM=0, ICM=0 32-bit mode

R3

Effective address of the device tree image.

R4, R5, R8,

R9

R7

shall be the size of the boot or secondary IMA in bytes

TCR

WRC=0, no watchdog timer reset will occur

Initial Mapped Areas (IMA)

A client programs IMA is a region of memory that contains
the entry points for a client program.
Requirements:
An IMA shall be virtually and physically contiguous
An IMA shall start at effective address zero (0) which shall be mapped
to a naturally aligned physical address
The mapping shall not be invalidated except by a client programs
explicit action
The Translation ID (TID) field in the TLB entry shall be zero.
The memory and cache access attributes (WIMGE) have the following
requirements:
WIMG unspecified
E=0 (i.e., big-endian)

An IMA may be mapped by a TLB entry larger than the IMA size,
provided the MMU guarded attribute is set (G=1)
An IMA may span multiple TLB entries.

Device Tree Overview

A device tree is a tree data structure with nodes that
describes the physical devices in a system
Primarily the non-probeable devices

Abstracts most hardware details out of the OS/client-enables firmware to provide an OS with a complete
description of the physical hardware in a system devices,
hardware address map, interrupt routing
Previously OSes were required to have hardcoded information about
system hardware.
Provides a basis for booting an operating system under a hypervisor in a
partitioned system

Each device node has property/value pairs that describe the

device
Common device types have a binding which document
required properties
9

Examples
/
soc

cpus
cpu@0

compatible = simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 e0000000 00100000>;
reg = <e0000000 00000200>;

cpu@1

soc

serial
ethernet
serial

10

compatible = "ns16550"
reg = <4600 100>
clock-frequency = <0>
interrupts = <a 8>
interrupt-parent = < &ipic >

Device Tree details

ePAPR defines requirements for:
Logical structure of the device tree node names, paths, properties
Standard properties
Hierarchy & routing of interrupts (including cascaded interrupt
controllers)
Representation of
CPUs
Memory
Caches

Device bindings for

PCI
Open PIC and ISA interrupt controllers
Serial devcies
Network devices
Device Control Registers (DCR)

Binary format of device tree DTB

DTS syntax

11

Standard Properties
compatible
model
phandle
status
#address-cells and #size-cells
reg
virtual-reg
ranges
dma-ranges

12

UART Node Definition Example

serial@11c500 {
device_type = "serial";
compatible = "fsl,ns16550", "ns16550";
reg = <11c500 100>;
clock-frequency = <0>;
interrupts = <24 2>;
interrupt-parent = <&mpic>;
};

13

Device Tree Compiler

The typical process of using a device tree in an embedded
Linux system is:
An ASCII representation of the device tree is created in an a 'device tree
source' (DTS) file
DTS is compiled into a binary 'device tree blob' (DTB) file using a device
tree compiler (DTC) tool
DTB format will be specified in the ePAPR

Firmware loads the DTB into RAM and passes a pointer to the DTB to
the Operating System kernel when it is started

14

Multicore boot architecture

ePAPR describes specifics on how secondary CPUs are booted
for a system with multiple CPUs
Default boot architecture
The boot program releases all CPUs from hardware reset
1 CPU is designated to be the client programs boot CPU
All other CPUs are secondary and are placed into loop where the CPUs
spin, waiting for a spin table field to change that directs them where to
go
Control is transferred to the client program on the boot CPU
When the client program is ready for secondary cores to start, it
releases them by writing the spin table field with the desired address

The architecture allows for other custom-defined secondary

CPU release mechanisms as well

15

Device Tree and Virtualization/Partitioning

Each OS in a partitioned system is presented with a device
tree describing that partitions subset of physical resources
CPU cores
Memory
I/O devices

Shared or virtualized resources would also be described

16

Future
Enhancements to the current speciciation
Virtualization:
OS to hypervisor ABI
Standardized APIs
Representations in device tree for virtualization

17