HKG15-505: Power Management interactions with OP-TEE and Trusted Firmware --------------------------------------------------- Speaker: Jorge Ramirez-Ortiz Date: February 13, 2015 --------------------------------------------------- ★ Session Summary ★ [Note: this is a joint Security/Power Management session) Understand what use cases related to Power Management have to interact with Trusted Firmware via Secure calls. Walk through some key use cases like CPU Suspend and explain how PM Linux drivers interacts with Trusted Firmware / PSCI -------------------------------------------------- ★ Resources ★ Pathable: https://hkg15.pathable.com/meetings/250855 Video: https://www.youtube.com/watch?v=hQ2ITjHZY4s Etherpad: http://pad.linaro.org/p/hkg15-505 --------------------------------------------------- ★ Event Details ★ Linaro Connect Hong Kong 2015 - #HKG15 February 9-13th, 2015 Regal Airport Hotel Hong Kong Airport --------------------------------------------------- http://www.linaro.org http://connect.linaro.org

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