aboutsummaryrefslogtreecommitdiff
path: root/include/bl31
AgeCommit message (Collapse)Author
2020-01-28Use correct type when reading SCR registerLouis Mayencourt
The Secure Configuration Register is 64-bits in AArch64 and 32-bits in AArch32. Use u_register_t instead of unsigned int to reflect this. Change-Id: I51b69467baba36bf0cfaec2595dc8837b1566934 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
2019-08-01Replace __ASSEMBLY__ with compiler-builtin __ASSEMBLER__Julius Werner
NOTE: __ASSEMBLY__ macro is now deprecated in favor of __ASSEMBLER__. All common C compilers predefine a macro called __ASSEMBLER__ when preprocessing a .S file. There is no reason for TF-A to define it's own __ASSEMBLY__ macro for this purpose instead. To unify code with the export headers (which use __ASSEMBLER__ to avoid one extra dependency), let's deprecate __ASSEMBLY__ and switch the code base over to the predefined standard. Change-Id: Id7d0ec8cf330195da80499c68562b65cb5ab7417 Signed-off-by: Julius Werner <jwerner@chromium.org>
2019-02-27BL31: Enable pointer authentication supportAntonio Nino Diaz
The size increase after enabling options related to ARMv8.3-PAuth is: +----------------------------+-------+-------+-------+--------+ | | text | bss | data | rodata | +----------------------------+-------+-------+-------+--------+ | CTX_INCLUDE_PAUTH_REGS = 1 | +192 | +1536 | +0 | +0 | | | 0.3% | 3.1% | | | +----------------------------+-------+-------+-------+--------+ | ENABLE_PAUTH = 1 | +1848 | +1536 | +16 | +0 | | | 3.3% | 3.1% | 3.1% | | +----------------------------+-------+-------+-------+--------+ Results calculated with the following build configuration: make PLAT=fvp SPD=tspd DEBUG=1 \ SDEI_SUPPORT=1 \ EL3_EXCEPTION_HANDLING=1 \ TSP_NS_INTR_ASYNC_PREEMPT=1 \ CTX_INCLUDE_PAUTH_REGS=1 \ ENABLE_PAUTH=1 Change-Id: I43db7e509a4f39da6599ec2faa690d197573ec1b Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-01-04Sanitise includes across codebaseAntonio Nino Diaz
Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3a282 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca33988b9 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-11-08Standardise header guards across codebaseAntonio Nino Diaz
All identifiers, regardless of use, that start with two underscores are reserved. This means they can't be used in header guards. The style that this project is now to use the full name of the file in capital letters followed by 'H'. For example, for a file called "uart_example.h", the header guard is UART_EXAMPLE_H. The exceptions are files that are imported from other projects: - CryptoCell driver - dt-bindings folders - zlib headers Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-08-30Fix MISRA defects in BL31 common codeAntonio Nino Diaz
Change-Id: I5993b425445ee794e6d2a792c244c0af53640655 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-08-22libc: Fix all includes in codebaseAntonio Nino Diaz
The codebase was using non-standard headers. It is needed to replace them by the correct ones so that we can use the new libc headers. Change-Id: I530f71d9510cb036e69fe79823c8230afe890b9d Acked-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-08-20EHF: MISRA fixesJeenu Viswambharan
These changes address most of the required MISRA rules. In the process, some from generic code are also fixed. No functional changes. Change-Id: I19786070af7bc5e1f6d15bdba93e22a4451d8fe9 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-08-20SDEI: MISRA fixesJeenu Viswambharan
These changes address most of the required MISRA rules. In the process, some from generic code is also fixed. No functional changes. Change-Id: I6235a355e006f0b1c7c1c4d811b3964a64d0434f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-05-04RAS: Allow individual interrupt registrationJeenu Viswambharan
EHF currently allows for registering interrupt handlers for a defined priority ranges. This is primarily targeted at various EL3 dispatchers to own ranges of secure interrupt priorities in order to delegate execution to lower ELs. The RAS support added by earlier patches necessitates registering handlers based on interrupt number so that error handling agents shall receive and handle specific Error Recovery or Fault Handling interrupts at EL3. This patch introduces a macro, RAS_INTERRUPTS() to declare an array of interrupt numbers and handlers. Error handling agents can use this macro to register handlers for individual RAS interrupts. The array is expected to be sorted in the increasing order of interrupt numbers. As part of RAS initialisation, the list of all RAS interrupts are sorted based on their ID so that, given an interrupt, its handler can be looked up with a simple binary search. For an error handling agent that wants to handle a RAS interrupt, platform must: - Define PLAT_RAS_PRI to be the priority of all RAS exceptions. - Enumerate interrupts to have the GIC driver program individual EL3 interrupts to the required priority range. This is required by EHF even before this patch. Documentation to follow. Change-Id: I9471e4887ff541f8a7a63309e9cd8f771f76aeda Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-05-04AArch64: Introduce RAS handlingJeenu Viswambharan
RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional extensions to base ARMv8.0 architecture. This patch adds build system support to enable RAS features in ARM Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for this. With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is inserted at all EL3 vector entry and exit. ESBs will synchronize pending external aborts before entering EL3, and therefore will contain and attribute errors to lower EL execution. Any errors thus synchronized are detected via. DISR_EL1 register. When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1. Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-05-04AArch64: Introduce External Abort handlingJeenu Viswambharan
At present, any External Abort routed to EL3 is reported as an unhandled exception and cause a panic. This patch enables ARM Trusted Firmware to handle External Aborts routed to EL3. With this patch, when an External Abort is received at EL3, its handling is delegated to plat_ea_handler() function. Platforms can provide their own implementation of this function. This patch adds a weak definition of the said function that prints out a message and just panics. In order to support handling External Aborts at EL3, the build option HANDLE_EA_EL3_FIRST must be set to 1. Before this patch, HANDLE_EA_EL3_FIRST wasn't passed down to compilation; this patch fixes that too. Change-Id: I4d07b7e65eb191ff72d63b909ae9512478cd01a1 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-02-28Merge pull request #1282 from robertovargas-arm/misra-changesdavidcunado-arm
Misra changes
2018-02-28Fix MISRA rule 8.4 in common codeRoberto Vargas
Rule 8.4: A compatible declaration shall be visible when an object or function with external linkage is defined. Change-Id: I26e042cb251a6f9590afa1340fdac73e42f23979 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-02-28Fix MISRA rule 8.3 in common codeRoberto Vargas
Rule 8.3: All declarations of an object or function shall use the same names and type qualifiers. Change-Id: Iff384187c74a598a4e73f350a1893b60e9d16cec Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-02-27EHF: Introduce preempted return code parameter to ehf_allow_ns_preemption()Jeenu Viswambharan
When a Yielding SMC is preempted, it's possible that Non-secure world is resumed afterwards. In this case, Non-secure execution would find itself in a state where the SMC has returned. However, the dispatcher might not get an opportunity to populate the corrected return code for having been preempted, and therefore the caller of the Yielding SMC cannot reliably determine whether the SMC had successfully completed or had been preempted. To solve this, this patch introduces a new parameter to the ehf_allow_ns_preemption() API. An SPD, through this parameter, would provide the expected error code when a Yielding SMC is preempted. EHF can then populate the specified value in x0 of the Non-secure context so that the caller of the Yielding SMC correctly identifies the SMC return as a preemption. Documentation updates to follow. Change-Id: Ia9c3f8f03f9d72d81aa235eaae2ee0374b972e1e Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-02-06Deprecate one EL3 interrupt routing model with EL3 exception handlingJeenu Viswambharan
When ARM Trusted Firmware is built with EL3_EXCEPTION_HANDLING=1, EL3 interrupts (INTR_TYPE_EL3) will always preempt both Non-secure and secure execution. The interrupt management framework currently treats EL3 interrupt routing as valid. For the above reason, this patch makes them invalid when EL3_EXCEPTION_HANDLING is in effect. Change-Id: I95bca8f5dc8df8eb0ff6f305cfba098611522a39 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-11-13BL31: Program Priority Mask for SMC handlingJeenu Viswambharan
On GICv3 systems, as a side effect of adding provision to handle EL3 interrupts (unconditionally routing FIQs to EL3), pending Non-secure interrupts (signalled as FIQs) may preempt execution in lower Secure ELs [1]. This will inadvertently disrupt the semantics of Fast SMC (previously called Atomic SMC) calls. To retain semantics of Fast SMCs, the GIC PMR must be programmed to prevent Non-secure interrupts from preempting Secure execution. To that effect, two new functions in the Exception Handling Framework subscribe to events introduced in an earlier commit: - Upon 'cm_exited_normal_world', the Non-secure PMR is stashed, and the PMR is programmed to the highest Non-secure interrupt priority. - Upon 'cm_entering_normal_world', the previously stashed Non-secure PMR is restored. The above sequence however prevents Yielding SMCs from being preempted by Non-secure interrupts as intended. To facilitate this, the public API exc_allow_ns_preemption() is introduced that programs the PMR to the original Non-secure PMR value. Another API exc_is_ns_preemption_allowed() is also introduced to check if exc_allow_ns_preemption() had been called previously. API documentation to follow. [1] On GICv2 systems, this isn't a problem as, unlike GICv3, pending NS IRQs during Secure execution are signalled as IRQs, which aren't routed to EL3. Change-Id: Ief96b162b0067179b1012332cd991ee1b3051dd0 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-11-13BL31: Introduce Exception Handling FrameworkJeenu Viswambharan
EHF is a framework that allows dispatching of EL3 interrupts to their respective handlers in EL3. This framework facilitates the firmware-first error handling policy in which asynchronous exceptions may be routed to EL3. Such exceptions may be handed over to respective exception handlers. Individual handlers might further delegate exception handling to lower ELs. The framework associates the delegated execution to lower ELs with a priority value. For interrupts, this corresponds to the priorities programmed in GIC; for other types of exceptions, viz. SErrors or Synchronous External Aborts, individual dispatchers shall explicitly associate delegation to a secure priority. In order to prevent lower priority interrupts from preempting higher priority execution, the framework provides helpers to control preemption by virtue of programming Priority Mask register in the interrupt controller. This commit allows for handling interrupts targeted at EL3. Exception handlers own interrupts by assigning them a range of secure priorities, and registering handlers for each priority range it owns. Support for exception handling in BL31 image is enabled by setting the build option EL3_EXCEPTION_HANDLING=1. Documentation to follow. NOTE: The framework assumes the priority scheme supported by platform interrupt controller is compliant with that of ARM GIC architecture (v2 or later). Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-10-16GIC: Allow specifying interrupt propertiesJeenu Viswambharan
The GIC driver initialization currently allows an array of interrupts to be configured as secure. Future use cases would require more interrupt configuration other than just security, such as priority. This patch introduces a new interrupt property array as part of both GICv2 and GICv3 driver data. The platform can populate the array with interrupt numbers and respective properties. The corresponding driver initialization iterates through the array, and applies interrupt configuration as required. This capability, and the current way of supplying array (or arrays, in case of GICv3) of secure interrupts, are however mutually exclusive. Henceforth, the platform should supply either: - A list of interrupts to be mapped as secure (the current way). Platforms that do this will continue working as they were. With this patch, this scheme is deprecated. - A list of interrupt properties (properties include interrupt group). Individual interrupt properties are specified via. descriptors of type 'interrupt_prop_desc_t', which can be populated with the macro INTR_PROP_DESC(). A run time assert checks that the platform doesn't specify both. Henceforth the old scheme of providing list of secure interrupts is deprecated. When built with ERROR_DEPRECATED=1, GIC drivers will require that the interrupt properties are supplied instead of an array of secure interrupts. Add a section to firmware design about configuring secure interrupts. Fixes ARM-software/tf-issues#262 Change-Id: I8eec29e72eb69dbb6bce77879febf32c95376942 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-10-16GIC: Add API to set interrupt routingJeenu Viswambharan
SPIs can be routed to either a specific PE, or to any one of all available PEs. API documentation updated. Change-Id: I28675f634568aaf4ea1aa8aa7ebf25b419a963ed Co-authored-by: Yousuf A <yousuf.sait@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-06-14include: add U()/ULL() macros for constantsVarun Wadekar
This patch uses the U() and ULL() macros for constants, to fix some of the signed-ness defects flagged by the MISRA scanner. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
2017-05-03Use SPDX license identifiersdp-arm
To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file. NOTE: Files that have been imported by FreeBSD have not been modified. [0]: https://spdx.org/ Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2016-07-19Introduce PSCI Library InterfaceSoby Mathew
This patch introduces the PSCI Library interface. The major changes introduced are as follows: * Earlier BL31 was responsible for Architectural initialization during cold boot via bl31_arch_setup() whereas PSCI was responsible for the same during warm boot. This functionality is now consolidated by the PSCI library and it does Architectural initialization via psci_arch_setup() during both cold and warm boots. * Earlier the warm boot entry point was always `psci_entrypoint()`. This was not flexible enough as a library interface. Now PSCI expects the runtime firmware to provide the entry point via `psci_setup()`. A new function `bl31_warm_entrypoint` is introduced in BL31 and the previous `psci_entrypoint()` is deprecated. * The `smc_helpers.h` is reorganized to separate the SMC Calling Convention defines from the Trusted Firmware SMC helpers. The former is now in a new header file `smcc.h` and the SMC helpers are moved to Architecture specific header. * The CPU context is used by PSCI for context initialization and restoration after power down (PSCI Context). It is also used by BL31 for SMC handling and context management during Normal-Secure world switch (SMC Context). The `psci_smc_handler()` interface is redefined to not use SMC helper macros thus enabling to decouple the PSCI context from EL3 runtime firmware SMC context. This enables PSCI to be integrated with other runtime firmware using a different SMC context. NOTE: With this patch the architectural setup done in `bl31_arch_setup()` is done as part of `psci_setup()` and hence `bl31_platform_setup()` will be invoked prior to architectural setup. It is highly unlikely that the platform setup will depend on architectural setup and cause any failure. Please be be aware of this change in sequence. Change-Id: I7f497a08d33be234bbb822c28146250cb20dab73
2016-07-18Introduce `el3_runtime` and `PSCI` librariesSoby Mathew
This patch moves the PSCI services and BL31 frameworks like context management and per-cpu data into new library components `PSCI` and `el3_runtime` respectively. This enables PSCI to be built independently from BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant PSCI library sources and gets included by `bl31.mk`. Other changes which are done as part of this patch are: * The runtime services framework is now moved to the `common/` folder to enable reuse. * The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture specific folder. * The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder to `plat/common` folder. The original file location now has a stub which just includes the file from new location to maintain platform compatibility. Most of the changes wouldn't affect platform builds as they just involve changes to the generic bl1.mk and bl31.mk makefiles. NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION. Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86
2016-07-18Fix coding guideline warningsSoby Mathew
This patch fixes some coding guideline warnings reported by the checkpatch script. Only files related to upcoming feature development have been fixed. Change-Id: I26fbce75c02ed62f00493ed6c106fe7c863ddbc5
2016-07-18Rework type usage in Trusted FirmwareSoby Mathew
This patch reworks type usage in generic code, drivers and ARM platform files to make it more portable. The major changes done with respect to type usage are as listed below: * Use uintptr_t for storing address instead of uint64_t or unsigned long. * Review usage of unsigned long as it can no longer be assumed to be 64 bit. * Use u_register_t for register values whose width varies depending on whether AArch64 or AArch32. * Use generic C types where-ever possible. In addition to the above changes, this patch also modifies format specifiers in print invocations so that they are AArch64/AArch32 agnostic. Only files related to upcoming feature development have been reworked. Change-Id: I9f8c78347c5a52ba7027ff389791f1dad63ee5f8
2016-06-16Add optional PSCI STAT residency & count functionsYatharth Kochar
This patch adds following optional PSCI STAT functions: - PSCI_STAT_RESIDENCY: This call returns the amount of time spent in power_state in microseconds, by the node represented by the `target_cpu` and the highest level of `power_state`. - PSCI_STAT_COUNT: This call returns the number of times a `power_state` has been used by the node represented by the `target_cpu` and the highest power level of `power_state`. These APIs provides residency statistics for power states that has been used by the platform. They are implemented according to v1.0 of the PSCI specification. By default this optional feature is disabled in the PSCI implementation. To enable it, set the boolean flag `ENABLE_PSCI_STAT` to 1. This also sets `ENABLE_PMF` to 1. Change-Id: Ie62e9d37d6d416ccb1813acd7f616d1ddd3e8aff
2016-05-25PSCI: Add pwr_domain_pwr_down_wfi() hook in plat_psci_opsSoby Mathew
This patch adds a new optional platform hook `pwr_domain_pwr_down_wfi()` in the plat_psci_ops structure. This hook allows the platform to perform platform specific actions including the wfi invocation to enter powerdown. This hook is invoked by both psci_do_cpu_off() and psci_cpu_suspend_start() functions. The porting-guide.md is also updated for the same. This patch also modifies the `psci_power_down_wfi()` function to invoke `plat_panic_handler` incase of panic instead of the busy while loop. Fixes ARM-Software/tf-issues#375 Change-Id: Iba104469a1445ee8d59fb3a6fdd0a98e7f24dfa3
2016-01-14Remove direct usage of __attribute__((foo))Soren Brinkmann
Migrate all direct usage of __attribute__ to usage of their corresponding macros from cdefs.h. e.g.: - __attribute__((unused)) -> __unused Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
2016-01-13Use designated initialization in DECLARE_RT_SVC macroSoby Mathew
This patch changes the anonymous initialization of `rt_svc_desc_t` structure by the `DECLARE_RT_SVC` macro to designated initialization. This makes the code more robust and less sensitive to potential changes to the `rt_svc_desc_t` structure. Change-Id: If6f1586730c0d29d92ef09e07eff7dd0d22857c7
2015-12-21Miscellaneous doc fixes for v1.2Sandrine Bailleux
Change-Id: I6f49bd779f2a4d577c6443dd160290656cdbc59b
2015-12-09Move context management code to common locationYatharth Kochar
The upcoming Firmware Update feature needs transitioning across Secure/Normal worlds to complete the FWU process and hence requires context management code to perform this task. Currently context management code is part of BL31 stage only. This patch moves the code from (include)/bl31 to (include)/common. Some function declarations/definitions and macros have also moved to different files to help code sharing. Change-Id: I3858b08aecdb76d390765ab2b099f457873f7b0c
2015-12-09Enable support for EL3 interrupt in IMFSoby Mathew
This patch enables support for EL3 interrupts in the Interrupt Management Framework (IMF) of ARM Trusted Firmware. Please note that although the registration of the EL3 interrupt type is now supported, it has not been tested on any of the ARM Standard platforms. Change-Id: If4dcdc7584621522a2f3ea13ea9b1ad0a76bb8a1
2015-09-14Merge pull request #390 from vikramkanigiri/at/unify_bakery_locks_v2Achin Gupta
Re-design bakery lock allocation and algorithm
2015-09-11Re-design bakery lock memory allocation and algorithmAndrew Thoelke
This patch unifies the bakery lock api's across coherent and normal memory implementation of locks by using same data type `bakery_lock_t` and similar arguments to functions. A separate section `bakery_lock` has been created and used to allocate memory for bakery locks using `DEFINE_BAKERY_LOCK`. When locks are allocated in normal memory, each lock for a core has to spread across multiple cache lines. By using the total size allocated in a separate cache line for a single core at compile time, the memory for other core locks is allocated at link time by multiplying the single core locks size with (PLATFORM_CORE_COUNT - 1). The normal memory lock algorithm now uses lock address instead of the `id` in the per_cpu_data. For locks allocated in coherent memory, it moves locks from tzfw_coherent_memory to bakery_lock section. The bakery locks are allocated as part of bss or in coherent memory depending on usage of coherent memory. Both these regions are initialised to zero as part of run_time_init before locks are used. Hence, bakery_lock_init() is made an empty function as the lock memory is already initialised to zero. The above design lead to the removal of psci bakery locks from non_cpu_power_pd_node to psci_locks. NOTE: THE BAKERY LOCK API WHEN USE_COHERENT_MEM IS NOT SET HAS CHANGED. THIS IS A BREAKING CHANGE FOR ALL PLATFORM PORTS THAT ALLOCATE BAKERY LOCKS IN NORMAL MEMORY. Change-Id: Ic3751c0066b8032dcbf9d88f1d4dc73d15f61d8b
2015-09-10Pass the target suspend level to SPD suspend hooksAchin Gupta
In certain Trusted OS implementations it is a requirement to pass them the highest power level which will enter a power down state during a PSCI CPU_SUSPEND or SYSTEM_SUSPEND API invocation. This patch passes this power level to the SPD in the "max_off_pwrlvl" parameter of the svc_suspend() hook. Currently, the highest power level which was requested to be placed in a low power state (retention or power down) is passed to the SPD svc_suspend_finish() hook. This hook is called after emerging from the low power state. It is more useful to pass the highest power level which was powered down instead. This patch does this by changing the semantics of the parameter passed to an SPD's svc_suspend_finish() hook. The name of the parameter has been changed from "suspend_level" to "max_off_pwrlvl" as well. Same changes have been made to the parameter passed to the tsp_cpu_resume_main() function. NOTE: THIS PATCH CHANGES THE SEMANTICS OF THE EXISTING "svc_suspend_finish()" API BETWEEN THE PSCI AND SPD/SP IMPLEMENTATIONS. THE LATTER MIGHT NEED UPDATES TO ENSURE CORRECT BEHAVIOUR. Change-Id: If3a9d39b13119bbb6281f508a91f78a2f46a8b90
2015-08-13PSCI: Rework generic code to conform to coding guidelinesSoby Mathew
This patch reworks the PSCI generic implementation to conform to ARM Trusted Firmware coding guidelines as described here: https://github.com/ARM-software/arm-trusted-firmware/wiki This patch also reviews the use of signed data types within PSCI Generic code and replaces them with their unsigned counterparts wherever they are not appropriate. The PSCI_INVALID_DATA macro which was defined to -1 is now replaced with PSCI_INVALID_PWR_LVL macro which is defined to PLAT_MAX_PWR_LVL + 1. Change-Id: Iaea422d0e46fc314e0b173c2b4c16e0d56b2515a
2015-08-13PSCI: Fix the return code for invalid entrypointSoby Mathew
As per PSCI1.0 specification, the error code to be returned when an invalid non secure entrypoint address is specified by the PSCI client for CPU_SUSPEND, CPU_ON or SYSTEM_SUSPEND must be PSCI_E_INVALID_ADDRESS. The current PSCI implementation returned PSCI_E_INVAL_PARAMS. This patch rectifies this error and also implements a common helper function to validate the entrypoint information to be used across these PSCI API implementations. Change-Id: I52d697d236c8bf0cd3297da4008c8e8c2399b170
2015-08-13PSCI: Migrate TF to the new platform API and CM helpersSoby Mathew
This patch migrates the rest of Trusted Firmware excluding Secure Payload and the dispatchers to the new platform and context management API. The per-cpu data framework APIs which took MPIDRs as their arguments are deleted and only the ones which take core index as parameter are retained. Change-Id: I839d05ad995df34d2163a1cfed6baa768a5a595d
2015-08-13PSCI: Add deprecated API for SPD when compatibility is disabledSoby Mathew
This patch defines deprecated platform APIs to enable Trusted Firmware components like Secure Payload and their dispatchers(SPD) to continue to build and run when platform compatibility is disabled. This decouples the migration of platform ports to the new platform API from SPD and enables them to be migrated independently. The deprecated platform APIs defined in this patch are : platform_get_core_pos(), platform_get_stack() and platform_set_stack(). The patch also deprecates MPIDR based context management helpers like cm_get_context_by_mpidr(), cm_set_context_by_mpidr() and cm_init_context(). A mechanism to deprecate APIs and identify callers of these APIs during build is introduced, which is controlled by the build flag WARN_DEPRECATED. If WARN_DEPRECATED is defined to 1, the users of the deprecated APIs will be flagged either as a link error for assembly files or compile time warning for C files during build. Change-Id: Ib72c7d5dc956e1a74d2294a939205b200f055613
2015-08-13PSCI: Switch to the new PSCI frameworksSoby Mathew
This commit does the switch to the new PSCI framework implementation replacing the existing files in PSCI folder with the ones in PSCI1.0 folder. The corresponding makefiles are modified as required for the new implementation. The platform.h header file is also is switched to the new one as required by the new frameworks. The build flag ENABLE_PLAT_COMPAT defaults to 1 to enable compatibility layer which let the existing platform ports to continue to build and run with minimal changes. The default weak implementation of platform_get_core_pos() is now removed from platform_helpers.S and is provided by the compatibility layer. Note: The Secure Payloads and their dispatchers still use the old platform and framework APIs and hence it is expected that the ENABLE_PLAT_COMPAT build flag will remain enabled in subsequent patch. The compatibility for SPDs using the older APIs on platforms migrated to the new APIs will be added in the following patch. Change-Id: I18c51b3a085b564aa05fdd98d11c9f3335712719
2015-08-13PSCI: Implement platform compatibility layerSoby Mathew
The new PSCI topology framework and PSCI extended State framework introduces a breaking change in the platform port APIs. To ease the migration of the platform ports to the new porting interface, a compatibility layer is introduced which essentially defines the new platform API in terms of the old API. The old PSCI helpers to retrieve the power-state, its associated fields and the highest coordinated physical OFF affinity level of a core are also implemented for compatibility. This allows the existing platform ports to work with the new PSCI framework without significant rework. This layer will be enabled by default once the switch to the new PSCI framework is done and is controlled by the build flag ENABLE_PLAT_COMPAT. Change-Id: I4b17cac3a4f3375910a36dba6b03d8f1700d07e3
2015-08-13PSCI: Unify warm reset entry pointsSandrine Bailleux
There used to be 2 warm reset entry points: - the "on finisher", for when the core has been turned on using a PSCI CPU_ON call; - the "suspend finisher", entered upon resumption from a previous PSCI CPU_SUSPEND call. The appropriate warm reset entry point used to be programmed into the mailboxes by the power management hooks. However, it is not required to provide this information to the PSCI entry point code, as it can figure it out by itself. By querying affinity info state, a core is able to determine on which execution path it is. If the state is ON_PENDING then it means it's been turned on else it is resuming from suspend. This patch unifies the 2 warm reset entry points into a single one: psci_entrypoint(). The patch also implements the necessary logic to distinguish between the 2 types of warm resets in the power up finisher. The plat_setup_psci_ops() API now takes the secure entry point as an additional parameter to enable the platforms to configure their mailbox. The platform hooks `pwr_domain_on` and `pwr_domain_suspend` no longer take secure entry point as a parameter. Change-Id: I7d1c93787b54213aefdbc046b8cd66a555dfbfd9
2015-08-13PSCI: Add framework to handle composite power statesSoby Mathew
The state-id field in the power-state parameter of a CPU_SUSPEND call can be used to describe composite power states specific to a platform. The current PSCI implementation does not interpret the state-id field. It relies on the target power level and the state type fields in the power-state parameter to perform state coordination and power management operations. The framework introduced in this patch allows the PSCI implementation to intepret generic global states like RUN, RETENTION or OFF from the State-ID to make global state coordination decisions and reduce the complexity of platform ports. It adds support to involve the platform in state coordination which facilitates the use of composite power states and improves the support for entering standby states at multiple power domains. The patch also includes support for extended state-id format for the power state parameter as specified by PSCIv1.0. The PSCI implementation now defines a generic representation of the power-state parameter. It depends on the platform port to convert the power-state parameter (possibly encoding a composite power state) passed in a CPU_SUSPEND call to this representation via the `validate_power_state()` plat_psci_ops handler. It is an array where each index corresponds to a power level. Each entry contains the local power state the power domain at that power level could enter. The meaning of the local power state values is platform defined, and may vary between levels in a single platform. The PSCI implementation constrains the values only so that it can classify the state as RUN, RETENTION or OFF as required by the specification: * zero means RUN * all OFF state values at all levels must be higher than all RETENTION state values at all levels * the platform provides PLAT_MAX_RET_STATE and PLAT_MAX_OFF_STATE values to the framework The platform also must define the macros PLAT_MAX_RET_STATE and PLAT_MAX_OFF_STATE which lets the PSCI implementation find out which power domains have been requested to enter a retention or power down state. The PSCI implementation does not interpret the local power states defined by the platform. The only constraint is that the PLAT_MAX_RET_STATE < PLAT_MAX_OFF_STATE. For a power domain tree, the generic implementation maintains an array of local power states. These are the states requested for each power domain by all the cores contained within the domain. During a request to place multiple power domains in a low power state, the platform is passed an array of requested power-states for each power domain through the plat_get_target_pwr_state() API. It coordinates amongst these states to determine a target local power state for the power domain. A default weak implementation of this API is provided in the platform layer which returns the minimum of the requested power-states back to the PSCI state coordination. Finally, the plat_psci_ops power management handlers are passed the target local power states for each affected power domain using the generic representation described above. The platform executes operations specific to these target states. The platform power management handler for placing a power domain in a standby state (plat_pm_ops_t.pwr_domain_standby()) is now only used as a fast path for placing a core power domain into a standby or retention state should now be used to only place the core power domain in a standby or retention state. The extended state-id power state format can be enabled by setting the build flag PSCI_EXTENDED_STATE_ID=1 and it is disabled by default. Change-Id: I9d4123d97e179529802c1f589baaa4101759d80c
2015-08-13PSCI: Introduce new platform interface to describe topologySoby Mathew
This patch removes the assumption in the current PSCI implementation that MPIDR based affinity levels map directly to levels in a power domain tree. This enables PSCI generic code to support complex power domain topologies as envisaged by PSCIv1.0 specification. The platform interface for querying the power domain topology has been changed such that: 1. The generic PSCI code does not generate MPIDRs and use them to query the platform about the number of power domains at a particular power level. The platform now provides a description of the power domain tree on the SoC through a data structure. The existing platform APIs to provide the same information have been removed. 2. The linear indices returned by plat_core_pos_by_mpidr() and plat_my_core_pos() are used to retrieve core power domain nodes from the power domain tree. Power domains above the core level are accessed using a 'parent' field in the tree node descriptors. The platform describes the power domain tree in an array of 'unsigned char's. The first entry in the array specifies the number of power domains at the highest power level implemented in the system. Each susbsequent entry corresponds to a power domain and contains the number of power domains that are its direct children. This array is exported to the generic PSCI implementation via the new `plat_get_power_domain_tree_desc()` platform API. The PSCI generic code uses this array to populate its internal power domain tree using the Breadth First Search like algorithm. The tree is split into two arrays: 1. An array that contains all the core power domain nodes 2. An array that contains all the other power domain nodes A separate array for core nodes allows certain core specific optimisations to be implemented e.g. remove the bakery lock, re-use per-cpu data framework for storing some information. Entries in the core power domain array are allocated such that the array index of the domain is equal to the linear index returned by plat_core_pos_by_mpidr() and plat_my_core_pos() for the MPIDR corresponding to that domain. This relationship is key to be able to use an MPIDR to find the corresponding core power domain node, traverse to higher power domain nodes and index into arrays that contain core specific information. An introductory document has been added to briefly describe the new interface. Change-Id: I4b444719e8e927ba391cae48a23558308447da13
2015-08-13PSCI: Introduce new platform and CM helper APIsSoby Mathew
This patch introduces new platform APIs and context management helper APIs to support the new topology framework based on linear core position. This framework will be introduced in the follwoing patch and it removes the assumption that the MPIDR based affinity levels map directly to levels in a power domain tree. The new platforms APIs and context management helpers based on core position are as described below: * plat_my_core_pos() and plat_core_pos_by_mpidr() These 2 new mandatory platform APIs are meant to replace the existing 'platform_get_core_pos()' API. The 'plat_my_core_pos()' API returns the linear index of the calling core and 'plat_core_pos_by_mpidr()' returns the linear index of a core specified by its MPIDR. The latter API will also validate the MPIDR passed as an argument and will return an error code (-1) if an invalid MPIDR is passed as the argument. This enables the caller to safely convert an MPIDR of another core to its linear index without querying the PSCI topology tree e.g. during a call to PSCI CPU_ON. Since the 'plat_core_pos_by_mpidr()' API verifies an MPIDR, which is always platform specific, it is no longer possible to maintain a default implementation of this API. Also it might not be possible for a platform port to verify an MPIDR before the C runtime has been setup or the topology has been initialized. This would prevent 'plat_core_pos_by_mpidr()' from being callable prior to topology setup. As a result, the generic Trusted Firmware code does not call this API before the topology setup has been done. The 'plat_my_core_pos' API should be able to run without a C runtime. Since this API needs to return a core position which is equal to the one returned by 'plat_core_pos_by_mpidr()' API for the corresponding MPIDR, this too cannot have default implementation and is a mandatory API for platform ports. These APIs will be implemented by the ARM reference platform ports later in the patch stack. * plat_get_my_stack() and plat_set_my_stack() These APIs are the stack management APIs which set/return stack addresses appropriate for the calling core. These replace the 'platform_get_stack()' and 'platform_set_stack()' APIs. A default weak MP version and a global UP version of these APIs are provided for the platforms. * Context management helpers based on linear core position A set of new context management(CM) helpers viz cm_get_context_by_index(), cm_set_context_by_index(), cm_init_my_context() and cm_init_context_by_index() are defined which are meant to replace the old helpers which took MPIDR as argument. The old CM helpers are implemented based on the new helpers to allow for code consolidation and will be deprecated once the switch to the new framework is done. Change-Id: I89758632b370c2812973a4b2efdd9b81a41f9b69
2015-08-05PSCI: Remove references to affinity based power managementSoby Mathew
As per Section 4.2.2. in the PSCI specification, the term "affinity" is used in the context of describing the hierarchical arrangement of cores. This often, but not always, maps directly to the processor power domain topology of the system. The current PSCI implementation assumes that this is always the case i.e. MPIDR based levels of affinity always map to levels in a power domain topology tree. This patch is the first in a series of patches which remove this assumption. It removes all occurences of the terms "affinity instances and levels" when used to describe the power domain topology. Only the terminology is changed in this patch. Subsequent patches will implement functional changes to remove the above mentioned assumption. Change-Id: Iee162f051b228828310610c5a320ff9d31009b4e
2015-08-05PSCI: Invoke PM hooks only for the highest levelSoby Mathew
This patch optimizes the invocation of the platform power management hooks for ON, OFF and SUSPEND such that they are called only for the highest affinity level which will be powered off/on. Earlier, the hooks were being invoked for all the intermediate levels as well. This patch requires that the platforms migrate to the new semantics of the PM hooks. It also removes the `state` parameter from the pm hooks as the `afflvl` parameter now indicates the highest affinity level for which power management operations are required. Change-Id: I57c87931d8a2723aeade14acc710e5b78ac41732
2015-08-05PSCI: Create new directory to implement new frameworksSoby Mathew
This patch creates a copy of the existing PSCI files and related psci.h and platform.h header files in a new `PSCI1.0` directory. The changes for the new PSCI power domain topology and extended state-ID frameworks will be added incrementally to these files. This incremental approach will aid in review and in understanding the changes better. Once all the changes have been introduced, these files will replace the existing PSCI files. Change-Id: Ibb8a52e265daa4204e34829ed050bddd7e3316ff