- 26 Sep, 2019 1 commit
-
-
Madhukar Pappireddy authored
This patch invokes the new function gicv3_rdistif_probe() in the ARM platform specific gicv3 driver. Since this API modifies the shared GIC related data structure, it must be invoked coherently by using the platform specific pwr_domain_on_finish_late hook. Change-Id: I6efb17d5da61545a1c5a6641b8f58472b31e62a8 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
-
- 25 Jan, 2019 2 commits
-
-
Antonio Nino Diaz authored
Change-Id: Ida5dae39478654405d0ee31a6cbddb4579e76a7f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Use full include paths like it is done for common includes. This cleanup was started in commit d40e0e08283a ("Sanitise includes across codebase"), but it only cleaned common files and drivers. This patch does the same to Arm platforms. Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 04 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
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: e0ea0928 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca339 ("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>
-
- 23 Jun, 2018 2 commits
-
-
Nariman Poushin authored
In the case of the platform max power level being less than the system power level, make sure to not overrun the array of power states. This fixes Coverity Scan OVERRUN defect CID 267021. Change-Id: I52646ab9be2fceeb5c331b5dad7a6267991f4197 Signed-off-by: Nariman Poushin <nariman.poushin@linaro.org>
-
Nariman Poushin authored
This is to fix a number of Coverity Scan DEADCODE defects, CID numbers listed below, as reported from https://scan.coverity.com/projects/arm-software-arm-trusted-firmware CID 267023 CID 267022 CID 267020 Change-Id: I2963a799b210149e84ccab5c5b9082267ddfe337 Signed-off-by: Nariman Poushin <nariman.poushin@linaro.org>
-
- 01 May, 2018 1 commit
-
-
Roberto Vargas authored
Previously mem_protect used to be only supported from BL2. This is not helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates mem_protect from el3_runtime firmware on ARM Platforms specifically when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap tables temporarily and then the protected regions are then cleared. This avoids the need to map the non secure DRAM permanently to BL31/sp_min. The stack size is also increased, because DYNAMIC_XLAT_TABLES require a bigger stack. Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 13 Nov, 2017 1 commit
-
-
Jeenu Viswambharan authored
The function arm_validate_ns_entrypoint() validates a given non-secure physical address. This function however specifically returns PSCI error codes. Non-secure physical address validation is potentially useful across ARM platforms, even for non-PSCI use cases. Therefore make this function common by returning 0 for success or -1 otherwise. Having made the function common, make arm_validate_psci_entrypoint() a wrapper around arm_validate_ns_entrypoint() which only translates return value into PSCI error codes. This wrapper is now used where arm_validate_ns_entrypoint() was currently used for PSCI entry point validation. Change-Id: Ic781fc3105d6d199fd8f53f01aba5baea0ebc310 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 13 Oct, 2017 1 commit
-
-
Roberto Vargas authored
This function implements the platform dependant part of PSCI system reset2 for CSS platforms using SCMI. Change-Id: I724389decab484043cadf577aeed96b349c1466d Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 11 Oct, 2017 1 commit
-
-
Soby Mathew authored
Provides GICv3 save/restore feature to arm_system_pwr_domain_resume and arm_system_pwr_domain_save functions. Introduce FVP PSCI power level 3 (System level) support. This is solely done to provide example code on how to use the GICv3 save and restore helpers. Also make CSS GICv3 platforms power off the Redistributor on SYSTEM SUSPEND as its state is saved and restored. Change-Id: I0d852f3af8824edee1a17c085cf593ddd33a4e77 Signed-off-by: Soby Mathew <soby.mathew@arm.com> Co-Authored-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 25 Sep, 2017 1 commit
-
-
Roberto Vargas authored
mem_protect needs some kind of non-volatile memory because it has to remember its state across reset and power down events. The most suitable electronic part for this feature is a NVRAM which should be only accesible from the secure world. Juno and FVP lack such hardware and for this reason the MEM_PROTECT functionality is implemented with Flash EEPROM memory on both boards, even though this memory is accesible from the non-secure world. This is done only to show a full implementation of these PSCI features, but an actual system shouldn't use a non-secure NVRAM to implement it. The EL3 runtime software will write the mem_protect flag and BL2 will read and clear the memory ranges if enabled. It is done in BL2 because it reduces the time that TF needs access to the full non-secure memory. The memory layout of both boards is defined using macros which take different values in Juno and FVP platforms. Generic platform helpers are added that use the platform specific macros to generate a mem_region_t that is valid for the platform. Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 03 May, 2017 1 commit
-
-
dp-arm authored
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>
-
- 24 Apr, 2017 1 commit
-
-
Soby Mathew authored
The CSS power management layer previously allowed to suspend system power domain level via both PSCI CPU_SUSPEND and PSCI SYSTEM_SUSPEND APIs. System suspend via PSCI CPU_SUSPEND was always problematic to support because of issues with targeting wakeup interrupts to suspended cores before the per-cpu GIC initialization is done. This is not the case for PSCI SYSTEM_SUSPEND API because all the other cores are expected to be offlined prior to issuing system suspend and PSCI CPU_ON explicit calls will be made to power them on. Hence the Juno platform used to downgrade the PSCI CPU_SUSPEND request for system power domain level to cluster level by overriding the default `plat_psci_pm_ops` exported by CSS layer. Given the direction the new CSS platforms are evolving, it is best to limit the system suspend only via PSCI SYSTEM_SUSPEND API for all CSS platforms. This patch makes changes to allow system suspend only via PSCI SYSTEM_SUSPEND API. The override of `plat_psci_ops` for Juno is removed. Change-Id: Idb30eaad04890dd46074e9e888caeedc50a4b533 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 07 Dec, 2016 2 commits
-
-
Soby Mathew authored
The capabilities exposed by the PSCI generic layer depends on the hooks populated by the platform in `plat_arm_psci_pm_ops`. Currently ARM Standard platforms statically define this structure. However, some platforms may want to modify the hooks at runtime before registering them with the generic layer. This patch introduces a new ARM platform layer API `plat_arm_psci_override_pm_ops` which allows the platform to probe the power controller and modify `plat_arm_psci_pm_ops` if required. Consequently, 'plat_arm_psci_pm_ops' is no longer qualified as `const` on ARM Standard platforms. Change-Id: I7dbb44b7bd36c20ec14ded5ee45a96816ca2ab9d Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Soby Mathew authored
This patch introduces an additional layer of abstraction between CSS power management hooks and the SCPI driver. A new set of APIs are introduced in order to abstract out power management operations from underlying communication mechanism with the SCP. The SCPI and the associated MHU drivers are moved into a `drivers` folder in CSS. The new SCP communication abstraction layer is added in the `drivers/scp` folder. The existing CSS power management uses the new APIs to reflect this abstraction. Change-Id: I7d775129fc0558e9703c2724523fb8f0a916838c Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 15 Sep, 2016 1 commit
-
-
Jeenu Viswambharan authored
This patch implements CSS platform hook to support NODE_HW_STATE PSCI API. The platform hook queries SCP to obtain CSS power state. Power states returned by SCP are then converted to expected PSCI return codes. Juno's PSCI operation structure is modified to use the CSS implementation. Change-Id: I4a5edac0e5895dd77b51398cbd78f934831dafc0
-
- 08 Jun, 2016 1 commit
-
-
David Wang authored
In GICv3 mode, the non secure group1 interrupts are signalled via the FIQ line in EL3. To support waking up from CPU_SUSPEND to standby on these systems, EL3 should route FIQ to EL3 temporarily before wfi and restore the original setting after resume. This patch makes this change for the CSS platforms in the `css_cpu_standby` psci pm ops hook. Change-Id: Ibf3295d16e2f08da490847c1457bc839e1bac144
-
- 16 Feb, 2016 1 commit
-
-
Vikram Kanigiri authored
ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals. This patch adds a layer of abstraction to help ARM platform ports to choose the right interconnect driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been implemented to initialise an interconnect and for entering/exiting a cluster from coherency. These functions are prefixed as "plat_arm_interconnect_". Weak definitions of these functions have been provided for each type of driver. 2.`plat_print_interconnect_regs` macro used for printing CCI registers is moved from a common arm_macros.S to cci_macros.S. 3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure is renamed to `ARM_CONFIG_HAS_INTERCONNECT`. Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
-
- 09 Dec, 2015 2 commits
-
-
Achin Gupta authored
Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
-
Soby Mathew authored
This patch adds platform helpers for the new GICv2 and GICv3 drivers in plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate file in their build according to the GIC driver to be used. The existing plat_gic.c is only meant for the legacy GIC driver. In the case of ARM platforms, the major changes are as follows: 1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU interface register values has been modified to detect the type of CPU interface being used (System register or memory mappped interface) before using the right interface to print the registers. 2. The power management helper function that is called after a core is powered up has been further refactored. This is to highlight that the per-cpu distributor interface should be initialised only when the core was originally powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API was used. 3. In the case of CSS platforms, the system power domain restore helper `arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish` handler as the system power domain is always expected to be initialized when the `on_finish` handler is invoked. Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6
-
- 30 Oct, 2015 2 commits
-
-
Soby Mathew authored
This patch adds the capability to power down at system power domain level on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers are modified to add support for power management operations at system power domain level. A new helper for populating `get_sys_suspend_power_state` handler in plat_psci_ops is defined. On entering the system suspend state, the SCP powers down the SYSTOP power domain on the SoC and puts the memory into retention mode. On wakeup from the power down, the system components on the CSS will be reinitialized by the platform layer and the PSCI client is responsible for restoring the context of these system components. According to PSCI Specification, interrupts targeted to cores in PSCI CPU SUSPEND should be able to resume it. On Juno, when the system power domain is suspended, the GIC is also powered down. The SCP resumes the final core to be suspend when an external wake-up event is received. But the other cores cannot be woken up by a targeted interrupt, because GIC doesn't forward these interrupts to the SCP. Due to this hardware limitation, we down-grade PSCI CPU SUSPEND requests targeted to the system power domain level to cluster power domain level in `juno_validate_power_state()` and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c. A system power domain resume helper `arm_system_pwr_domain_resume()` is defined for ARM standard platforms which resumes/re-initializes the system components on wakeup from system suspend. The security setup also needs to be done on resume from system suspend, which means `plat_arm_security_setup()` must now be included in the BL3-1 image in addition to previous BL images if system suspend need to be supported. Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47
-
Soby Mathew authored
This patch implements the necessary topology changes for supporting system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform specific. In addition, the `arm_power_domain_tree_desc[]` and `arm_pm_idle_states[]` are modified to support the system power domain at level 2. With this patch, even though the power management operations involving the system power domain will not return any error, the platform layer will silently ignore any operations to the power domain. The actual power management support for the system power domain will be added later. Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
-
- 20 Oct, 2015 1 commit
-
-
Soby Mathew authored
This patch does the following reorganization to psci power management (PM) handler setup for ARM standard platform ports : 1. The mailbox programming required during `plat_setup_psci_ops()` is identical for all ARM platforms. Hence the implementation of this API is now moved to the common `arm_pm.c` file. Each ARM platform now must define the PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same as ARM_SHARED_RAM_BASE. 2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be exported via `plat_arm_psci_pm_ops`. This allows the common implementation of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`. In the case of CSS platforms, a default weak implementation of the same is provided in `css_pm.c` which can be overridden by each CSS platform. 3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now made library functions and a new header file `css_pm.h` is added to export these generic PM handlers. This allows the platform to reuse the adequate CSS PM handlers and redefine others which need to be customized when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`. Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede
-
- 13 Aug, 2015 4 commits
-
-
Soby Mathew authored
This patch implements the platform power managment handler to verify non secure entrypoint for ARM platforms. The handler ensures that the entry point specified by the normal world during CPU_SUSPEND, CPU_ON or SYSTEM_SUSPEND PSCI API is a valid address within the non secure DRAM. Change-Id: I4795452df99f67a24682b22f0e0967175c1de429
-
Sandrine Bailleux authored
Since there is a unique warm reset entry point, the FVP and Juno port can use a single mailbox instead of maintaining one per core. The mailbox gets programmed only once when plat_setup_psci_ops() is invoked during PSCI initialization. This means mailbox is not zeroed out during wakeup. Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432
-
Soby Mathew authored
This patch adds support to the Juno and FVP ports for composite power states with both the original and extended state-id power-state formats. Both the platform ports use the recommended state-id encoding as specified in Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag ARM_RECOM_STATE_ID_ENC is used to include this support. By default, to maintain backwards compatibility, the original power state parameter format is used and the state-id field is expected to be zero. Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
-
Soby Mathew authored
This patch migrates ARM reference platforms, Juno and FVP, to the new platform API mandated by the new PSCI power domain topology and composite power state frameworks. The platform specific makefiles now exports the build flag ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer. Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
-
- 28 Apr, 2015 1 commit
-
-
Dan Handley authored
This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
-
- 16 Mar, 2015 1 commit
-
-
Vikram Kanigiri authored
This patch updates the FVP and Juno platform ports to use the common driver for ARM Cache Coherent Interconnects. Change-Id: Ib142f456b9b673600592616a2ec99e9b230d6542
-
- 23 Jan, 2015 2 commits
-
-
Soby Mathew authored
This patch allows the platform to validate the power_state and entrypoint information from the normal world early on in PSCI calls so that we can return the error safely. New optional pm_ops hooks `validate_power_state` and `validate_ns_entrypoint` are introduced to do this. As a result of these changes, all the other pm_ops handlers except the PSCI_ON handler are expected to be successful. Also, the PSCI implementation will now assert if a PSCI API is invoked without the corresponding pm_ops handler being registered by the platform. NOTE : PLATFORM PORTS WILL BREAK ON MERGE OF THIS COMMIT. The pm hooks have 2 additional optional callbacks and the return type of the other hooks have changed. Fixes ARM-Software/tf-issues#229 Change-Id: I036bc0cff2349187c7b8b687b9ee0620aa7e24dc
-
Soby Mathew authored
This patch removes the non-secure entry point information being passed to the platform pm_ops which is not needed. Also, it removes the `mpidr` parameter for platform pm hooks which are meant to do power management operations only on the current cpu. NOTE: PLATFORM PORTS MUST BE UPDATED AFTER MERGING THIS COMMIT. Change-Id: If632376a990b7f3b355f910e78771884bf6b12e7
-
- 31 Oct, 2014 1 commit
-
-
Juan Castillo authored
This patch replaces the usage of the GIC private driver in Juno with the generic ARM GIC driver. The private driver is no longer necessary and has been removed from the Juno port. Fixes ARM-software/tf-issues#253 Change-Id: I6aaabc252e5e6fb5fcf44ab6d0febd9b38791056
-
- 21 Oct, 2014 1 commit
-
-
Vikram Kanigiri authored
This patch adds support on the Juno platform for entering a wfi in response to a PSCI CPU_SUSPEND call where the state type is a standby state. Change-Id: I0a102dee1f8d2ad936c63ad1d1d3ad001a4a4768
-
- 21 Aug, 2014 3 commits
-
-
Juan Castillo authored
This patch adds the Juno platform specific handlers for PSCI SYSTEM_OFF and SYSTEM_RESET operations. Change-Id: Ie389adead533ec2314af44d721b4d0f306147c7d
-
Achin Gupta authored
This patch adds support for PSCI CPU_OFF and CPU_SUSPEND APIs to the Juno port of the ARM Trusted Firmware. The maximum affinity level that can be suspended is the cluster level (affinity level 1). Support for suspending the system level is not present. Change-Id: Ie2c9da0acd7d1b0d5ac64940cdf40347153e52c8
-
Sandrine Bailleux authored
This patch adds the initial port of the ARM Trusted Firmware on the Juno development platform. This port does not support a BL3-2 image or any PSCI APIs apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno platform errata (Defect id 831273). Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
-