The document discusses power management in ARMv8-A and the integration of OP-TEE with the ARM Trusted Firmware. It provides an overview of the software stack and PSCI requirements. It then describes OP-TEE's system view and how it integrates with ARM Trusted Firmware as a runtime service. Finally, it discusses the programmer's view of PSCI and provides examples of how CPU_ON, CPU_OFF, and CPU_SUSPEND operations are handled between Linux, ARM Trusted Firmware, and OP-TEE.

1. Presented by
Date
OP-TEE
ARMv8-A PM integration
programmer’s view
Jorge A. Ramirez-Ortiz
4 Feb 2015
1

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

3. 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 World
PowerController
cpu hotplug
secondary boot
idle management
bigLittle migration
3

4. AArch64 software stack
1. Normal World
a. RichOS kernels on EL1/EL2
b. Hypervisors on EL2
2. 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/opteed
4

5. 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 functions
a. PSCI_VERSION
b. AFFINITY_INFO
c. MIGRATE_INFO_TYPE *
d. MIGRATE_INFO_UP_CPU
e. SYSTEM_OFF
f. SYSTEM_RESET
3. All functions except MIGRATE/MIGRATE_INFO_UP_CPU are
compulsory
4. various return code changes.
PSCI v0.2
5

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

7. PSCI - developer’s view
Linux Kernel
EL1
ARM-TF
EL3
smc interface
psci service
dispatcher
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

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

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

10. AArch64 - use case CPU_SUSPEND
LINUX 3.19
NS-EL1
ARM-TF
EL3
suspend.c psci.c
cpu_suspend
cpu_psci_cpu_suspend
psci_cpu_suspend(STANDBY, entry)
smc//hyp
OP-TEE
S-EL1
plat/../plat_pm.c
psci_main.c
OP_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

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

12. 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. 13