Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

HKG15-505: Power Management interactions with OP-TEE and Trusted Firmware

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

  • Login to see the comments

HKG15-505: Power Management interactions with OP-TEE and Trusted Firmware

  1. 1. Presented by Date OP-TEE ARMv8-A PM integration programmer’s view Jorge A. Ramirez-Ortiz 4 Feb 2015 1
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13

×