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 cases

○ CPU_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 trusted 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 RichOS

ARM recommends:○ Secure world: controls the power states○ Normal world: implements the policy in power and performance management

Rich OS

Secure WorldP

ower C

ontroller

cpu hotplug

secondary boot

idle management

bigLittle migration

3

AArch64 software stack

1. Normal Worlda. RichOS kernels on EL1/EL2b. Hypervisors on EL2

2. Secure Worlda. Secure platform firmwareb. 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/opteed

4

Power State Coordination IF requirements■ Idle management:

○ 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

2. added the following functionsa. PSCI_VERSIONb. AFFINITY_INFOc. MIGRATE_INFO_TYPE *d. MIGRATE_INFO_UP_CPUe. SYSTEM_OFFf. SYSTEM_RESET

3. All functions except MIGRATE/MIGRATE_INFO_UP_CPU are compulsory

4. 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-TEEs-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_entryvector_fast_smc_entryvector_cpu_on_entryvector_cpu_off_entryvector_cpu_resume_entryvector_cpu_suspend_entryvector_fiq_entryvector_system_off_entryvector_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.19NS-EL1

ARM-TFEL3

smp.c psci.c__cpu_upboot_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.19NS-EL1

ARM-TF EL3

smp.c psci.c

cpu_diecpu_psci_cpu_die

psci_cpu_off(POWER_DOWN) smc//hyp

OP-TEES-EL1

psci_afflvl_off.c

psci_main.c

arm32/plat../main.c

plat/../plat_pm.copteed_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-TFEL3

suspend.c psci.ccpu_suspend

cpu_psci_cpu_suspend

psci_cpu_suspend(STANDBY, entry) smc//hyp

OP-TEES-EL1

plat/../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)

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.pdf11

Juno Platform: Software Overview

WFI

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

SCPI - system control and power interface and NOT “Standard Commands for Programmable Instruments”

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 AP through 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