diff options
Diffstat (limited to 'docs/psci-lib-integration-guide.md')
| -rw-r--r-- | docs/psci-lib-integration-guide.md | 536 |
1 files changed, 0 insertions, 536 deletions
diff --git a/docs/psci-lib-integration-guide.md b/docs/psci-lib-integration-guide.md deleted file mode 100644 index ab0276b0..00000000 --- a/docs/psci-lib-integration-guide.md +++ /dev/null @@ -1,536 +0,0 @@ -PSCI Library Integration guide for ARMv8-A AArch32 systems -========================================================== - -Contents - -1. [Introduction](#1-introduction) -2. [Generic call sequence for PSCI Library interface (AArch32)](#2-generic-call-sequence-for-psci-library-interface-aarch32) -3. [PSCI CPU context management](#3-psci-cpu-context-management) -4. [PSCI Library Interface](#4-psci-library-interface) -5. [EL3 Runtime Software dependencies](#5-el3-runtime-software-dependencies) - - -1. Introduction ---------------- - -This document describes the PSCI library interface with a focus on how to -integrate with a suitable Trusted OS for an ARMv8-A AArch32 system. The PSCI -Library implements the PSCI Standard as described in [PSCI spec] and is meant -to be integrated with EL3 Runtime Software which invokes the PSCI Library -interface appropriately. **EL3 Runtime Software** refers to software executing -at the highest secure privileged mode, which is EL3 in AArch64 or Secure SVC/ -Monitor mode in AArch32, and provides runtime services to the non-secure world. -The runtime service request is made via SMC (Secure Monitor Call) and the call -must adhere to [SMCCC]. In AArch32, EL3 Runtime Software may additionally -include Trusted OS functionality. A minimal AArch32 Secure Payload, SP-MIN, is -provided in ARM Trusted Firmware to illustrate the usage and integration of the -PSCI library. The description of PSCI library interface and its integration -with EL3 Runtime Software in this document is targeted towards AArch32 systems. - -2. Generic call sequence for PSCI Library interface (AArch32) -------------------------------------------------------------- - -The generic call sequence of PSCI Library interfaces (see -[section 4](#4-psci-library-interface)) during cold boot in AArch32 -system is described below: - -1. After cold reset, the EL3 Runtime Software performs its cold boot - initialization including the PSCI library pre-requisites mentioned in - [section 4](#4-psci-library-interface), and also the necessary platform - setup. - -2. Call `psci_setup()` in Monitor mode. - -3. Optionally call `psci_register_spd_pm_hook()` to register callbacks to - do bookkeeping for the EL3 Runtime Software during power management. - -4. Call `psci_prepare_next_non_secure_ctx()` to initialize the non-secure CPU - context. - -5. Get the non-secure `cpu_context_t` for the current CPU by calling - `cm_get_context()` , then programming the registers in the non-secure - context and exiting to non-secure world. If the EL3 Runtime Software needs - additional configuration to be set for non-secure context, like routing - FIQs to the secure world, the values of the registers can be modified prior - to programming. See [section 3](#3-psci-cpu-context-management) for more - details on CPU context management. - -The generic call sequence of PSCI library interfaces during warm boot in -AArch32 systems is described below: - -1. After warm reset, the EL3 Runtime Software performs the necessary warm - boot initialization including the PSCI library pre-requisites mentioned in - [section 4](#4-psci-library-interface) (Note that the Data cache - **must not** be enabled). - -2. Call `psci_warmboot_entrypoint()` in Monitor mode. This interface - initializes/restores the non-secure CPU context as well. - -3. Do step 5 of the cold boot call sequence described above. - -The generic call sequence of PSCI library interfaces on receipt of a PSCI SMC -on an AArch32 system is described below: - -1. On receipt of an SMC, save the register context as per [SMCCC]. - -2. If the SMC function identifier corresponds to a SMC32 PSCI API, construct - the appropriate arguments and call the `psci_smc_handler()` interface. - The invocation may or may not return back to the caller depending on - whether the PSCI API resulted in power down of the CPU. - -3. If `psci_smc_handler()` returns, populate the return value in R0 (AArch32)/ - X0 (AArch64) and restore other registers as per [SMCCC]. - - -3. PSCI CPU context management ------------------------------- - -PSCI library is in charge of initializing/restoring the non-secure CPU system -registers according to [PSCI specification][PSCI spec] during cold/warm boot. -This is referred to as `PSCI CPU Context Management`. Registers that need to -be preserved across CPU power down/power up cycles are maintained in -`cpu_context_t` data structure. The initialization of other non-secure CPU -system registers which do not require coordination with the EL3 Runtime -Software is done directly by the PSCI library (see `cm_prepare_el3_exit()`). - -The EL3 Runtime Software is responsible for managing register context -during switch between Normal and Secure worlds. The register context to be -saved and restored depends on the mechanism used to trigger the world switch. -For example, if the world switch was triggered by an SMC call, then the -registers need to be saved and restored according to [SMCCC]. In AArch64, -due to the tight integration with BL31, both BL31 and PSCI library -use the same `cpu_context_t` data structure for PSCI CPU context management -and register context management during world switch. This cannot be assumed -for AArch32 EL3 Runtime Software since most AArch32 Trusted OSes already implement -a mechanism for register context management during world switch. Hence, when -the PSCI library is integrated with a AArch32 EL3 Runtime Software, the -`cpu_context_t` is stripped down for just PSCI CPU context management. - -During cold/warm boot, after invoking appropriate PSCI library interfaces, it -is expected that the EL3 Runtime Software will query the `cpu_context_t` and -write appropriate values to the corresponding system registers. This mechanism -resolves 2 additional problems for AArch32 EL3 Runtime Software: - -1. Values for certain system registers like SCR and SCTLR cannot be - unilaterally determined by PSCI library and need inputs from the EL3 - Runtime Software. Using `cpu_context_t` as an intermediary data store - allows EL3 Runtime Software to modify the register values appropriately - before programming them. - -2. The PSCI library provides appropriate LR and SPSR values (entrypoint - information) for exit into non-secure world. Using `cpu_context_t` as an - intermediary data store allows the EL3 Runtime Software to store these - values safely until it is ready for exit to non-secure world. - -Currently the `cpu_context_t` data structure for AArch32 stores the following -registers: R0 - R3, LR (R14), SCR, SPSR, SCTLR. - -The EL3 Runtime Software must implement accessors to get/set pointers -to CPU context `cpu_context_t` data and these are described in -[section 5.2](#52-cpu-context-management-api). - - -4. PSCI Library Interface -------------------------- - -The PSCI library implements the [PSCI Specification][PSCI spec]. The interfaces -to this library are declared in `psci.h` and are as listed below: - -``` - u_register_t psci_smc_handler(uint32_t smc_fid, u_register_t x1, - u_register_t x2, u_register_t x3, - u_register_t x4, void *cookie, - void *handle, u_register_t flags); - int psci_setup(const psci_lib_args_t *lib_args); - void psci_warmboot_entrypoint(void); - void psci_register_spd_pm_hook(const spd_pm_ops_t *pm); - void psci_prepare_next_non_secure_ctx(entry_point_info_t *next_image_info); -``` - -The CPU context data 'cpu_context_t' is programmed to the registers differently -when PSCI is integrated with an AArch32 EL3 Runtime Software compared to -when the PSCI is integrated with an AArch64 EL3 Runtime Software (BL31). For -example, in the case of AArch64, there is no need to retrieve `cpu_context_t` -data and program the registers as it will done implicitly as part of -`el3_exit`. The description below of the PSCI interfaces is targeted at -integration with an AArch32 EL3 Runtime Software. - -The PSCI library is responsible for initializing/restoring the non-secure world -to an appropriate state after boot and may choose to directly program the -non-secure system registers. The PSCI generic code takes care not to directly -modify any of the system registers affecting the secure world and instead -returns the values to be programmed to these registers via `cpu_context_t`. -The EL3 Runtime Software is responsible for programming those registers and -can use the proposed values provided in the `cpu_context_t`, modifying the -values if required. - -PSCI library needs the flexibility to access both secure and non-secure -copies of banked registers. Hence it needs to be invoked in Monitor mode -for AArch32 and in EL3 for AArch64. The NS bit in SCR (in AArch32) or SCR_EL3 -(in AArch64) must be set to 0. Additional requirements for the PSCI library -interfaces are: - - * Instruction cache must be enabled - * Both IRQ and FIQ must be masked for the current CPU - * The page tables must be setup and the MMU enabled - * The C runtime environment must be setup and stack initialized - * The Data cache must be enabled prior to invoking any of the PSCI library - interfaces except for `psci_warmboot_entrypoint()`. For - `psci_warmboot_entrypoint()`, if the build option `HW_ASSISTED_COHERENCY` - is enabled however, data caches are expected to be enabled. - -Further requirements for each interface can be found in the interface -description. - -### 4.1 Interface : psci_setup() - - Argument : const psci_lib_args_t *lib_args - Return : void - -This function is to be called by the primary CPU during cold boot before -any other interface to the PSCI library. It takes `lib_args`, a const pointer -to `psci_lib_args_t`, as the argument. The `psci_lib_args_t` is a versioned -structure and is declared in `psci.h` header as follows: - -``` - typedef struct psci_lib_args { - /* The version information of PSCI Library Interface */ - param_header_t h; - /* The warm boot entrypoint function */ - mailbox_entrypoint_t mailbox_ep; - } psci_lib_args_t; -``` - -The first field `h`, of `param_header_t` type, provides the version -information. The second field `mailbox_ep` is the warm boot entrypoint address -and is used to configure the platform mailbox. Helper macros are provided in -psci.h to construct the `lib_args` argument statically or during runtime. Prior -to calling the `psci_setup()` interface, the platform setup for cold boot -must have completed. Major actions performed by this interface are: - - * Initializes architecture. - * Initializes PSCI power domain and state coordination data structures. - * Calls `plat_setup_psci_ops()` with warm boot entrypoint `mailbox_ep` as - argument. - * Calls `cm_set_context_by_index()` (see - [section 5.2](#52-cpu-context-management-api)) for all the CPUs in the - platform - -### 4.2 Interface : psci_prepare_next_non_secure_ctx() - - Argument : entry_point_info_t *next_image_info - Return : void - -After `psci_setup()` and prior to exit to the non-secure world, this function -must be called by the EL3 Runtime Software to initialize the non-secure world -context. The non-secure world entrypoint information `next_image_info` (first -argument) will be used to determine the non-secure context. After this function -returns, the EL3 Runtime Software must retrieve the `cpu_context_t` (using -cm_get_context()) for the current CPU and program the registers prior to exit -to the non-secure world. - -### 4.3 Interface : psci_register_spd_pm_hook() - - Argument : const spd_pm_ops_t * - Return : void - -As explained in [section 5.4](#54-secure-payload-power-management-callback), -the EL3 Runtime Software may want to perform some bookkeeping during power -management operations. This function is used to register the `spd_pm_ops_t` -(first argument) callbacks with the PSCI library which will be called -ppropriately during power management. Calling this function is optional and -need to be called by the primary CPU during the cold boot sequence after -`psci_setup()` has completed. - -### 4.4 Interface : psci_smc_handler() - - Argument : uint32_t smc_fid, u_register_t x1, - u_register_t x2, u_register_t x3, - u_register_t x4, void *cookie, - void *handle, u_register_t flags - Return : u_register_t - -This function is the top level handler for SMCs which fall within the -PSCI service range specified in [SMCCC]. The function ID `smc_fid` (first -argument) determines the PSCI API to be called. The `x1` to `x4` (2nd to 5th -arguments), are the values of the registers r1 - r4 (in AArch32) or x1 - x4 -(in AArch64) when the SMC is received. These are the arguments to PSCI API as -described in [PSCI spec]. The 'flags' (8th argument) is a bit field parameter -and is detailed in 'smcc.h' header. It includes whether the call is from the -secure or non-secure world. The `cookie` (6th argument) and the `handle` -(7th argument) are not used and are reserved for future use. - -The return value from this interface is the return value from the underlying -PSCI API corresponding to `smc_fid`. This function may not return back to the -caller if PSCI API causes power down of the CPU. In this case, when the CPU -wakes up, it will start execution from the warm reset address. - -### 4.5 Interface : psci_warmboot_entrypoint() - - Argument : void - Return : void - -This function performs the warm boot initialization/restoration as mandated by -[PSCI spec]. For AArch32, on wakeup from power down the CPU resets to secure SVC -mode and the EL3 Runtime Software must perform the prerequisite initializations -mentioned at top of this section. This function must be called with Data cache -disabled (unless build option `HW_ASSISTED_COHERENCY` is enabled) but with MMU -initialized and enabled. The major actions performed by this function are: - - * Invalidates the stack and enables the data cache. - * Initializes architecture and PSCI state coordination. - * Restores/Initializes the peripheral drivers to the required state via - appropriate `plat_psci_ops_t` hooks - * Restores the EL3 Runtime Software context via appropriate `spd_pm_ops_t` - callbacks. - * Restores/Initializes the non-secure context and populates the - `cpu_context_t` for the current CPU. - -Upon the return of this function, the EL3 Runtime Software must retrieve the -non-secure `cpu_context_t` using `cm_get_context()` and program the registers -prior to exit to the non-secure world. - - -5. EL3 Runtime Software dependencies ---------------------------------------- - -The PSCI Library includes supporting frameworks like context management, -cpu operations (cpu_ops) and per-cpu data framework. Other helper library -functions like bakery locks and spin locks are also included in the library. -The dependencies which must be fulfilled by the EL3 Runtime Software -for integration with PSCI library are described below. - -### 5.1 General dependencies - -The PSCI library being a Multiprocessor (MP) implementation, EL3 Runtime -Software must provide an SMC handling framework capable of MP adhering to -[SMCCC] specification. - -The EL3 Runtime Software must also export cache maintenance primitives -and some helper utilities for assert, print and memory operations as listed -below. The ARM Trusted Firmware source tree provides implementations for all -these functions but the EL3 Runtime Software may use its own implementation. - -**Functions : assert(), memcpy(), memset** - -These must be implemented as described in ISO C Standard. - -**Function : flush_dcache_range()** - - Argument : uintptr_t addr, size_t size - Return : void - -This function cleans and invalidates (flushes) the data cache for memory -at address `addr` (first argument) address and of size `size` (second argument). - -**Function : inv_dcache_range()** - - Argument : uintptr_t addr, size_t size - Return : void - -This function invalidates (flushes) the data cache for memory at address -`addr` (first argument) address and of size `size` (second argument). - -**Function : do_panic()** - - Argument : void - Return : void - -This function will be called by the PSCI library on encountering a critical -failure that cannot be recovered from. This function **must not** return. - -**Function : tf_printf()** - -This is printf-compatible function, but unlike printf, it does not return any -value. The ARM Trusted Firmware source tree provides an implementation which -is optimized for stack usage and supports only a subset of format specifiers. -The details of the format specifiers supported can be found in the -`tf_printf.c` file in ARM Trusted Firmware source tree. - -### 5.2 CPU Context management API - -The CPU context management data memory is statically allocated by PSCI library -in BSS section. The PSCI library requires the EL3 Runtime Software to implement -APIs to store and retrieve pointers to this CPU context data. SP-MIN -demonstrates how these APIs can be implemented but the EL3 Runtime Software can -choose a more optimal implementation (like dedicating the secure TPIDRPRW -system register (in AArch32) for storing these pointers). - -**Function : cm_set_context_by_index()** - - Argument : unsigned int cpu_idx, void *context, unsigned int security_state - Return : void - -This function is called during cold boot when the `psci_setup()` PSCI library -interface is called. - -This function must store the pointer to the CPU context data, `context` (2nd -argument), for the specified `security_state` (3rd argument) and CPU identified -by `cpu_idx` (first argument). The `security_state` will always be non-secure -when called by PSCI library and this argument is retained for compatibility -with BL31. The `cpu_idx` will correspond to the index returned by the -`plat_core_pos_by_mpidr()` for `mpidr` of the CPU. - -The actual method of storing the `context` pointers is implementation specific. -For example, SP-MIN stores the pointers in the array `sp_min_cpu_ctx_ptr` -declared in `sp_min_main.c`. - -**Function : cm_get_context()** - - Argument : uint32_t security_state - Return : void * - -This function must return the pointer to the `cpu_context_t` structure for -the specified `security_state` (first argument) for the current CPU. The caller -must ensure that `cm_set_context_by_index` is called first and the appropriate -context pointers are stored prior to invoking this API. The `security_state` -will always be non-secure when called by PSCI library and this argument -is retained for compatibility with BL31. - -**Function : cm_get_context_by_index()** - - Argument : unsigned int cpu_idx, unsigned int security_state - Return : void * - -This function must return the pointer to the `cpu_context_t` structure for -the specified `security_state` (second argument) for the CPU identified by -`cpu_idx` (first argument). The caller must ensure that -`cm_set_context_by_index` is called first and the appropriate context -pointers are stored prior to invoking this API. The `security_state` will -always be non-secure when called by PSCI library and this argument is -retained for compatibility with BL31. The `cpu_idx` will correspond to the -index returned by the `plat_core_pos_by_mpidr()` for `mpidr` of the CPU. - -### 5.3 Platform API - -The platform layer abstracts the platform-specific details from the generic -PSCI library. The following platform APIs/macros must be defined by the EL3 -Runtime Software for integration with the PSCI library. - -The mandatory platform APIs are: - - * plat_my_core_pos - * plat_core_pos_by_mpidr - * plat_get_syscnt_freq2 - * plat_get_power_domain_tree_desc - * plat_setup_psci_ops - * plat_reset_handler - * plat_panic_handler - * plat_get_my_stack - -The mandatory platform macros are: - - * PLATFORM_CORE_COUNT - * PLAT_MAX_PWR_LVL - * PLAT_NUM_PWR_DOMAINS - * CACHE_WRITEBACK_GRANULE - * PLAT_MAX_OFF_STATE - * PLAT_MAX_RET_STATE - * PLAT_MAX_PWR_LVL_STATES (optional) - * PLAT_PCPU_DATA_SIZE (optional) - -The details of these APIs/macros can be found in [Porting Guide]. - -All platform specific operations for power management are done via -`plat_psci_ops_t` callbacks registered by the platform when -`plat_setup_psci_ops()` API is called. The description of each of -the callbacks in `plat_psci_ops_t` can be found in PSCI section of the -[Porting Guide]. If any these callbacks are not registered, then the -PSCI API associated with that callback will not be supported by PSCI -library. - -### 5.4 Secure payload power management callback - -During PSCI power management operations, the EL3 Runtime Software may -need to perform some bookkeeping, and PSCI library provides -`spd_pm_ops_t` callbacks for this purpose. These hooks must be -populated and registered by using `psci_register_spd_pm_hook()` PSCI -library interface. - -Typical bookkeeping during PSCI power management calls include save/restore -of the EL3 Runtime Software context. Also if the EL3 Runtime Software makes -use of secure interrupts, then these interrupts must also be managed -appropriately during CPU power down/power up. Any secure interrupt targeted -to the current CPU must be disabled or re-targeted to other running CPU prior -to power down of the current CPU. During power up, these interrupt can be -enabled/re-targeted back to the current CPU. - -``` - typedef struct spd_pm_ops { - void (*svc_on)(u_register_t target_cpu); - int32_t (*svc_off)(u_register_t __unused); - void (*svc_suspend)(u_register_t max_off_pwrlvl); - void (*svc_on_finish)(u_register_t __unused); - void (*svc_suspend_finish)(u_register_t max_off_pwrlvl); - int32_t (*svc_migrate)(u_register_t from_cpu, u_register_t to_cpu); - int32_t (*svc_migrate_info)(u_register_t *resident_cpu); - void (*svc_system_off)(void); - void (*svc_system_reset)(void); - } spd_pm_ops_t; -``` -A brief description of each callback is given below: - -* svc_on, svc_off, svc_on_finish - - The `svc_on`, `svc_off` callbacks are called during PSCI_CPU_ON, - PSCI_CPU_OFF APIs respectively. The `svc_on_finish` is called when the - target CPU of PSCI_CPU_ON API powers up and executes the - `psci_warmboot_entrypoint()` PSCI library interface. - -* svc_suspend, svc_suspend_finish - - The `svc_suspend` callback is called during power down bu either - PSCI_SUSPEND or PSCI_SYSTEM_SUSPEND APIs. The `svc_suspend_finish` is - called when the CPU wakes up from suspend and executes the - `psci_warmboot_entrypoint()` PSCI library interface. The `max_off_pwrlvl` - (first parameter) denotes the highest power domain level being powered down - to or woken up from suspend. - -* svc_system_off, svc_system_reset - - These callbacks are called during PSCI_SYSTEM_OFF and PSCI_SYSTEM_RESET - PSCI APIs respectively. - -* svc_migrate_info - - This callback is called in response to PSCI_MIGRATE_INFO_TYPE or - PSCI_MIGRATE_INFO_UP_CPU APIs. The return value of this callback must - correspond to the return value of PSCI_MIGRATE_INFO_TYPE API as described - in [PSCI spec]. If the secure payload is a Uniprocessor (UP) - implementation, then it must update the mpidr of the CPU it is resident in - via `resident_cpu` (first argument). The updates to `resident_cpu` is - ignored if the secure payload is a multiprocessor (MP) implementation. - -* svc_migrate - - This callback is only relevant if the secure payload in EL3 Runtime - Software is a Uniprocessor (UP) implementation and supports migration from - the current CPU `from_cpu` (first argument) to another CPU `to_cpu` - (second argument). This callback is called in response to PSCI_MIGRATE - API. This callback is never called if the secure payload is a - Multiprocessor (MP) implementation. - -### 5.5 CPU operations - -The CPU operations (cpu_ops) framework implement power down sequence specific -to the CPU and the details of which can be found in the `CPU specific -operations framework` section of [Firmware Design]. The ARM Trusted Firmware -tree implements the `cpu_ops` for various supported CPUs and the EL3 Runtime -Software needs to include the required `cpu_ops` in its build. The start and -end of the `cpu_ops` descriptors must be exported by the EL3 Runtime Software -via the `__CPU_OPS_START__` and `__CPU_OPS_END__` linker symbols. - -The `cpu_ops` descriptors also include reset sequences and may include errata -workarounds for the CPU. The EL3 Runtime Software can choose to call this -during cold/warm reset if it does not implement its own reset sequence/errata -workarounds. - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - -_Copyright (c) 2016, ARM Limited and Contributors. All rights reserved._ - -[PSCI spec]: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf "Power State Coordination Interface PDD (ARM DEN 0022C)" -[SMCCC]: https://silver.arm.com/download/ARM_and_AMBA_Architecture/AR570-DA-80002-r0p0-00rel0/ARM_DEN0028A_SMC_Calling_Convention.pdf "SMC Calling Convention" -[Porting Guide]: porting-guide.md -[Firmware Design]: ./firmware-design.md |