Presented by

Date

OP-TEE

ARMv8-A PM integration

programmer’s view

Jorge A. Ramirez-Ortiz

4 Feb 2015

1

Agenda

●power management in arm64

●software stack

●psci requirements

●OP-TEE - system view

●psci - developer’s view

●use casesoCPU_ON/CPU_OFF/CPU_SUSPEND

2

Power Management in AArch64

■arm32 lack of established firmware interfaces

○platform specific code maintained in BSP trees

○the code can’t be upstreamed

■arm64 - clean sheet

○single tree strategy

○delegate the platform specific code to firmware

○define a generic interface to coordinate power control

across the concurrent supervisory systems

●idle, hotplug, system shutdown/reset, migration

○leave peripheral and DVFS to the supervisory sw

ARM recommends:

○Secure world: controls the power states

○Normal world: implements the policy in power and performance management

Rich OS

Secure World

cpu hotplug

secondary boot

idle management

bigLittle migration

3

AArch64 software stack

1.Normal World

a.RichOS kernels on EL1/EL2

b.Hypervisors on EL2

1.Secure World

a.Secure platform firmware

b.Trusted/Secure OS

PSCI details the interface between the Secure

and normal worlds

smc: requires EL3 being implemented.

hyp: option when EL3 is not present but EL2 is

The communication between the Secure Platform Firmware and the Secure OS is vendor dependent.

-OP-TEE integrates with the ARM Trusted Firmware as a runtime service

-https://github.com/ARM-software/arm-trusted-firmware/tree/master/services/spd/opteed4

Power State Coordination IF requirements

■Core idle management - not peripherals

○standby,

○retention,

○power down

■hotplug: switch processors on/off

■bigLittle TrustedOS migration

■save and restore execution states

■system shutdown and reset hooks:

○each silicon vendor must provide

its SoC implementation

1.standard function identifiers: no longer configurable via device tree

a.different ids for 32-bit PSCI and 64-bit PSCI functions allow

for different ATF implementations

1.added the following functions

a.PSCI_VERSION

b.AFFINITY_INFO

c.MIGRATE_INFO_TYPE *

d.MIGRATE_INFO_UP_CPU

e.SYSTEM_OFF

f.SYSTEM_RESET

1.All functions except MIGRATE/MIGRATE_INFO_UP_CPU are

compulsory

1.various return code changes.

PSCI v0.2

5

OP-TEE - Systems View

■OP-TEE OS runs in AArch32

■the OP-TEE linux driver uses smc32

○driver is out of tree

■the PSCI linux driver uses smc32/smc64

○driver is in kernel.org

■STANDALONE ■ARMv8-A: ARM-TF runtime service

6

PSCI - developer’s viewLinux Kernel

EL1

ARM-TF

EL3

smc interface

psci servicedispatcher

platform code

OP-TEE

s-EL1

psci

1

2

opteed

psci -{0.1, 0.2}

-32/64 calls

dtb

ARM-TF uses the opteed vector table provided during

OP-TEE initialization to be able to call the TrustedOS

(functions are platform dependent)

vector_std_smc_entry

vector_fast_smc_entry

vector_cpu_on_entry

vector_cpu_off_entry

vector_cpu_resume_entry

vector_cpu_suspend_entry

vector_fiq_entry

vector_system_off_entry

vector_system_reset_entry

static const struct thread_handlers handlers = {

.std_smc = main_tee_entry,

.fast_smc = main_tee_entry,

.fiq = main_fiq,

.svc = tee_svc_handler,

.abort = tee_pager_abort_handler,

.cpu_on = cpu_on_handler,

.cpu_off = main_cpu_off_handler,

.cpu_suspend = main_cpu_suspend_handler,

.cpu_resume = main_cpu_resume_handler,

.system_off = main_system_off_handler,

.system_reset = main_system_reset_handler,

};

platform dependent

optee dispatcher

aff {0}

aff {0, 1, 2}

7

AArch64 - use case CPU_ON

LINUX 3.19

NS-EL1

ARM-TF

EL3

smp.c psci.c

__cpu_up

boot_secondary

cpu_psci_cpu_boot

psci_cpu_on (secondary_entry)

smc//hyp

OP-TEE

S-EL1

CPU 1CPU 0

psci_afflvl_on.c

plat/../plat_pm.c

opteed_pm.c

psci_main.c

PMIC

RAM

NS- EL1

entry point

head.S: secondary_entry

psci_afflvl_on.c: psci_afflv{x}_on_finish

plat/../plat_pm.c

{0}

aff {0, 1, 2}

psci_common.c

platform handler

opteed_pm.c

aff {0, 1, 2}

{0}

8

AArch64 - use case CPU_OFF

LINUX 3.19

NS-EL1

ARM-TF

EL3

smp.c psci.c

cpu_die

cpu_psci_cpu_die

psci_cpu_off(POWER_DOWN)

smc//hyp

OP-TEE

S-EL1

psci_afflvl_off.c

psci_main.c

arm32/plat../main.c

plat/../plat_pm.c

opteed_pm.c

aff {0, 1, 2}

{0}__cpu_die

cpu_psci_cpu_kill

psci_affinity_info(mpidr, 0)

smc//hyp

[1] After performing the platform operations, the trusted

firmware framework enters the WFI loop for the CPU; this

allows the external power controller to power it down.

[2] the cpu_kill kernel interface only checks the status of

the CPU (identified via the mpidr) and does not perform any

power actions with the PMIC.

this call does not return

9

AArch64 - use case CPU_SUSPEND

LINUX 3.19

NS-EL1

ARM-TF

EL3

suspend.c psci.c

cpu_suspend

cpu_psci_cpu_suspen

d

psci_cpu_suspend(STANDBY, entry)

smc//hyp

OP-TEE

S-EL1plat/../plat_pm.c

psci_main.cOP_TEE doesn’t need to

implement support for STANDBY

since the firmware will not call

Only STANDBY supported in kernel PSCI interface: all core

context is maintained by the processor and state is entered by

executing WFI in EL3. Changing from standby to running does

not require a reset of the processor.

Other PM states are currently implemented in NS-EL1 (Linux

kernel)

power_state: platform specific id understood by the firmware

(passed to the RichOS in firmware tables/dt)

aff {0, 1, 2}

10

Juno Platform: Soc Power Control

http://infocenter.arm.com/help/topic/com.arm.doc.dto0038a/DTO0038A_juno_arm_development_platform_soc_technical_overview.pdf

11

Power domains

Power modes

Juno Platform: Software Overview

WFI

https://github.com/ARM-software/arm-trusted-firmware

SCPI - system control and power interface

MHU hardware

(mailbox)

https://github.com/ARM-software/linux/blob/1.4-Juno/drivers/mailbox/arm_mhu.c

https://github.com/ARM-software/linux/blob/1.4-

Juno/drivers/mailbox/scpi_protocol.c

The SCPI is the generic runtime interface to the SCP from the APthrough the MHU. It includes:

●Inquiring capabilities of the system and individual devices

●Obtaining and setting the state of the entire system and individual

devices under SCP control. This includes a thermal sensor interface.

●Obtaining and setting the performance level of the processors and

GPUs, that is, Digital Voltage and Frequency Scaling(DVFS).

●Watchdog services to non-trusted AP software. The AP non-trusted

world does not have direct access to a hardware watchdog in the ADP

hardware architecture. The SCP has access to a hardware watchdog

and uses this to help implement the interface.

●Reporting fault conditions.

PSCI

12

13