The document outlines power management in ARM64 architecture, discussing software stacks, PSCI requirements, and the integration of OP-TEE. It highlights the significance of a generic interface for power control across systems, differentiating between secure and normal worlds. Various use cases for CPU power states and coordination, alongside system-level details specific to ARM's architecture, are also detailed.

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
oCPU_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 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

4. 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/opteed
4

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

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
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_suspen
d
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)
power_state: platform specific id understood by the firmware
(passed to the RichOS in firmware tables/dt)
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
Power domains
Power modes

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