8/10/2019 epapr_overview2

1/17

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.

ePAPR Specification

PAPR Technical SubcommitteeStuard YoderChair, PAPR TSC

8/10/2019 epapr_overview2

2/17

2

Agenda Background

Overview Boot programs and client programs

Device tree

Multi-core boot architecture

Status and Future Plans

8/10/2019 epapr_overview2

3/17

3

ePAPR Background

Power.org released the Power Architecture PlatformRequirements (PAPR) specification in August 2006-- fordesktop/server platforms

A complete platform definition is not applicable to embeddedsystems, 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 ArchitectureCommittee

8/10/2019 epapr_overview2

4/17

4

Boot Program / Client program Boot Program

Firmware

Second stage bootloader

Hypervisor

Client Program Second stage bootloader

Hypevisor

Operating system

Other bare metal application

8/10/2019 epapr_overview2

5/17

5

ePAPR 1.0

ePAPR 1.0 addresses boot services how a boot program initializeshardware and boots a client program

Key areas

State of machine when control is transferred to client (e.g. registers, MMU, stateof 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 beingdone 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 Augusttime frame.

8/10/2019 epapr_overview2

6/17

6

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

8/10/2019 epapr_overview2

7/17

7

Intial State of Registers

WRC=0, no watchdog timer reset will occurTCR

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

0R4, R5, R8,R9

Effective address of the device tree image.R3

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

MSR

ValueRegister

8/10/2019 epapr_overview2

8/17

8

Initial Mapped Areas (IMA)

A client programs IMA is a region of memory that containsthe 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 mappedto a naturally aligned physical address

The mapping shall not be invalidated except by a client programsexplicit action

The Translation ID (TID) field in the TLB entry shall be zero.

The memory and cache access attributes (WIMGE) have the followingrequirements:

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.

8/10/2019 epapr_overview2

9/17

9

Device Tree Overview

A device tree is a tree data structure with nodes thatdescribes 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 completedescription of the physical hardware in a systemdevices,hardware address map, interrupt routing

Previously OSes were required to have hardcoded information aboutsystem hardware.

Provides a basis for booting an operating system under a hypervisor in apartitioned system

Each device node has property/value pairs that describe the

device

Common device types have a binding which documentrequired properties

8/10/2019 epapr_overview2

10/17

8/10/2019 epapr_overview2

11/17

11

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 interruptcontrollers)

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

8/10/2019 epapr_overview2

12/17

12

Standard Properties compatible

model

phandle status

#address-cells and #size-cells

reg

virtual-reg

ranges

dma-ranges

8/10/2019 epapr_overview2

13/17

13

UART Node Definition Example

serial@11c500 {

device_type = "serial";compatible = "fsl,ns16550", "ns16550";

reg = ;

clock-frequency = ;

interrupts = ;

interrupt-parent = ;

};

8/10/2019 epapr_overview2

14/17

14

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 treesource' (DTS) file

DTS is compiled into a binary 'device tree blob' (DTB) file using a devicetree 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

8/10/2019 epapr_overview2

15/17

15

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 bootCPU

All other CPUs are secondaryand are placed into loop where the CPUsspin, 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, itreleases them by writing the spin table field with the desired address

The architecture allows for other custom-defined secondaryCPU release mechanisms as well

8/10/2019 epapr_overview2

16/17

16

Device Tree and Virtualization/Partitioning

Each OS in a partitioned system is presented with a devicetree describing that partitions subset of physical resources

CPU cores

Memory

I/O devices

Shared or virtualized resources would also be described

8/10/2019 epapr_overview2

17/17

17

Future Enhancements to the current speciciation

Virtualization: OS to hypervisor ABI

Standardized APIs

Representations in device tree for virtualization