Merge "docs(changelog): changelog for v2.9 release" into integration
diff --git a/.readthedocs.yaml b/.readthedocs.yaml
index 450d6be..6207066 100644
--- a/.readthedocs.yaml
+++ b/.readthedocs.yaml
@@ -17,10 +17,10 @@
- plantuml
jobs:
post_create_environment:
- - pip install poetry
+ - pip install poetry=="1.3.2"
- poetry config virtualenvs.create false
post_install:
- - poetry install --with docs
+ - poetry install --with doc
sphinx:
configuration: docs/conf.py
diff --git a/docs/about/features.rst b/docs/about/features.rst
index cb8b552..4a2c77e 100644
--- a/docs/about/features.rst
+++ b/docs/about/features.rst
@@ -22,8 +22,8 @@
Cache Coherent Network (CCN), Network Interconnect (NIC) and TrustZone
Controller (TZC).
-- A generic |SCMI| driver to interface with conforming power controllers, for
- example the Arm System Control Processor (SCP).
+- Secure Monitor library code such as world switching, EL2/EL1 context
+ management and interrupt routing.
- SMC (Secure Monitor Call) handling, conforming to the `SMC Calling
Convention`_ using an EL3 runtime services framework.
@@ -34,14 +34,22 @@
is also suitable for integration with other AArch32 EL3 Runtime Software,
for example an AArch32 Secure OS.
+- A generic |SCMI| driver to interface with conforming power controllers, for
+ example the Arm System Control Processor (SCP).
+
- A minimal AArch32 Secure Payload (*SP_MIN*) to demonstrate |PSCI| library
integration with AArch32 EL3 Runtime Software.
-- Secure Monitor library code such as world switching, EL1 context management
- and interrupt routing.
- When a Secure-EL1 Payload (SP) is present, for example a Secure OS, the
- AArch64 EL3 Runtime Software must be integrated with a Secure Payload
- Dispatcher (SPD) component to customize the interaction with the SP.
+- Secure partition manager dispatcher(SPMD) with following two configurations:
+
+ - S-EL2 SPMC implementation, widely compliant with FF-A v1.1 EAC0 and initial
+ support of FF-A v1.2.
+
+ - EL3 SPMC implementation, compliant with a subset of FF-A v1.1 EAC0.
+
+- Support for Arm CCA based on FEAT_RME which supports authenticated boot and
+ execution of RMM with the necessary routing of RMI commands as specified in
+ RMM Beta 0 Specification.
- A Test SP and SPD to demonstrate AArch64 Secure Monitor functionality and SP
interaction with PSCI.
@@ -50,12 +58,20 @@
`Trusty Secure OS`_ and `ProvenCore Secure OS`_.
- A Trusted Board Boot implementation, conforming to all mandatory TBBR
- requirements. This includes image authentication, Firmware Update (or
- recovery mode), and packaging of the various firmware images into a
+ requirements. This includes image authentication, Firmware recovery,
+ Firmware encryption and packaging of the various firmware images into a
Firmware Image Package (FIP).
-- Pre-integration of TBB with the Arm CryptoCell product, to take advantage of
- its hardware Root of Trust and crypto acceleration services.
+- Measured boot support with PoC to showcase its interaction with firmware TPM
+ (fTPM) service implemneted on top of OP-TEE.
+
+- Support for Dynamic Root of Trust for Measurement (DRTM).
+
+- Following firmware update mechanisms available:
+
+ - PSA Firmware Update (PSA FWU)
+
+ - TBBR Firmware Update (TBBR FWU)
- Reliability, Availability, and Serviceability (RAS) functionality, including
@@ -81,6 +97,8 @@
secure system processor, or where a non-TF-A ROM expects BL2 to be loaded
at EL3.
+- Support for Errata management firmware interface.
+
- Support for the GCC, LLVM and Arm Compiler 6 toolchains.
- Support for combining several libraries into a "romlib" image that may be
@@ -88,27 +106,13 @@
in ROM but is accessed through a jump-table that may be stored
in read-write memory, allowing for the library code to be patched.
-- Support for the Secure Partition Manager Dispatcher (SPMD) component as a
- new standard service.
-
-- Support for ARMv8.3 pointer authentication in the normal and secure worlds.
- The use of pointer authentication in the normal world is enabled whenever
- architectural support is available, without the need for additional build
- flags.
-
-- Position-Independent Executable (PIE) support. Currently for BL2, BL31, and
- TSP, with further support to be added in a future release.
+- Position-Independent Executable (PIE) support.
Still to come
-------------
- Support for additional platforms.
-- Refinements to Position Independent Executable (PIE) support.
-
-- Continued support for the FF-A v1.0 (formally known as SPCI) specification, to enable the
- use of secure partition management in the secure world.
-
- Documentation enhancements.
- Ongoing support for new architectural features, CPUs and System IP.
@@ -125,4 +129,4 @@
--------------
-*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
+*Copyright (c) 2019-2023, Arm Limited. All rights reserved.*
diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst
index 8dc1c61..e61dc20 100644
--- a/docs/components/secure-partition-manager.rst
+++ b/docs/components/secure-partition-manager.rst
@@ -461,8 +461,15 @@
- *cpus* node provide the platform topology and allows MPIDR to VMPIDR mapping.
Note the primary core is declared first, then secondary cores are declared
in reverse order.
-- The *memory* node provides platform information on the ranges of memory
- available to the SPMC.
+- The *memory* nodes provide platform information on the ranges of memory
+ available for use by SPs at runtime. These ranges relate to either
+ secure or non-secure memory, depending on the *device_type* field.
+ If the field specifies "memory" the range is secure, else if it specifies
+ "ns-memory" the memory is non-secure. The system integrator must exclude
+ the memory used by other components that are not SPs, such as the monitor,
+ or the SPMC itself, the OS Kernel/Hypervisor, or other NWd VMs. The SPMC
+ limits the SP's address space such that they do not access memory outside
+ of those ranges.
SPMC boot
~~~~~~~~~
@@ -562,7 +569,12 @@
- Memory regions are mapped in the SP EL1&0 Stage-2 translation regime at
load time (or EL1&0 Stage-1 for an S-EL1 SPMC). A memory region node can
specify RX/TX buffer regions in which case it is not necessary for an SP
- to explicitly invoke the ``FFA_RXTX_MAP`` interface.
+ to explicitly invoke the ``FFA_RXTX_MAP`` interface. The memory referred
+ shall be contained within the memory ranges defined in SPMC manifest. The
+ NS bit in the attributes field should be consistent with the security
+ state of the range that it relates to. I.e. non-secure memory shall be
+ part of a non-secure memory range, and secure memory shall be contained
+ in a secure memory range of a given platform.
- Device regions are mapped in the SP EL1&0 Stage-2 translation regime (or
EL1&0 Stage-1 for an S-EL1 SPMC) as peripherals and possibly allocate
additional resources (e.g. interrupts).
@@ -1029,6 +1041,68 @@
This is used in particular to convey power management messages.
+Memory Sharing
+--------------
+
+Hafnium implements the following memory sharing interfaces:
+
+ - ``FFA_MEM_SHARE`` - for shared access between lender and borrower.
+ - ``FFA_MEM_LEND`` - borrower to obtain exclusive access, though lender
+ retains ownership of the memory.
+ - ``FFA_MEM_DONATE`` - lender permanently relinquishes ownership of memory
+ to the borrower.
+
+The ``FFA_MEM_RETRIEVE_REQ`` interface is for the borrower to request the
+memory to be mapped into its address space: for S-EL1 partitions the SPM updates
+their stage 2 translation regime; for S-EL0 partitions the SPM updates their
+stage 1 translation regime. On a successful call, the SPMC responds back with
+``FFA_MEM_RETRIEVE_RESP``.
+
+The ``FFA_MEM_RELINQUISH`` interface is for when the borrower is done with using
+a memory region.
+
+The ``FFA_MEM_RECLAIM`` interface is for the owner of the memory to reestablish
+its ownership and exclusive access to the memory shared.
+
+The memory transaction descriptors are transmitted via RX/TX buffers. In
+situations where the size of the memory transaction descriptor exceeds the
+size of the RX/TX buffers, Hafnium provides support for fragmented transmission
+of the full transaction descriptor. The ``FFA_MEM_FRAG_RX`` and ``FFA_MEM_FRAG_TX``
+interfaces are for receiving and transmitting the next fragment, respectively.
+
+If lender and borrower(s) are SPs, all memory sharing operations are supported.
+
+Hafnium also supports memory sharing operations between the normal world and the
+secure world. If there is an SP involved, the SPMC allocates data to track the
+state of the operation.
+
+The SPMC is also the designated allocator for the memory handle. The hypervisor
+or OS kernel has the possibility to rely on the SPMC to maintain the state
+of the operation, thus saving memory.
+A lender SP can only donate NS memory to a borrower from the normal world.
+
+The SPMC supports the hypervisor retrieve request, as defined by the FF-A
+v1.1 EAC0 specification, in section 16.4.3. The intent is to aid with operations
+that the hypervisor must do for a VM retriever. For example, when handling
+an FFA_MEM_RECLAIM, if the hypervisor relies on SPMC to keep the state
+of the operation, the hypervisor retrieve request can be used to obtain
+that state information, do the necessary validations, and update stage 2
+memory translation.
+
+Hafnium also supports memory lend and share targetting multiple borrowers.
+This is the case for a lender SP to multiple SPs, and for a lender VM to
+multiple endpoints (from both secure world and normal world). If there is
+at least one borrower VM, the hypervisor is in charge of managing its
+stage 2 translation on a successful memory retrieve.
+The semantics of ``FFA_MEM_DONATE`` implies ownership transmission,
+which should target only one partition.
+
+The memory share interfaces are backwards compatible with memory transaction
+descriptors from FF-A v1.0. These get translated to FF-A v1.1 descriptors for
+Hafnium's internal processing of the operation. If the FF-A version of a
+borrower is v1.0, Hafnium provides FF-A v1.0 compliant memory transaction
+descriptors on memory retrieve response.
+
PE MMU configuration
--------------------
diff --git a/docs/design/firmware-design.rst b/docs/design/firmware-design.rst
index 2c9b76a..14b273e 100644
--- a/docs/design/firmware-design.rst
+++ b/docs/design/firmware-design.rst
@@ -2622,16 +2622,29 @@
section lists the usage of Architecture Extensions, and build flags
controlling them.
-In general, and unless individually mentioned, the build options
-``ARM_ARCH_MAJOR`` and ``ARM_ARCH_MINOR`` select the Architecture Extension to
-target when building TF-A. Subsequent Arm Architecture Extensions are backward
-compatible with previous versions.
+Build options
+~~~~~~~~~~~~~
+
+``ARM_ARCH_MAJOR`` and ``ARM_ARCH_MINOR``
+
+These build options serve dual purpose
+
+- Determine the architecture extension support in TF-A build: All the mandatory
+ architectural features up to ``ARM_ARCH_MAJOR.ARM_ARCH_MINOR`` are included
+ and unconditionally enabled by TF-A build system.
+
+- Passed to compiler via "-march" option to generate binary target : Tell the
+ compiler to emit instructions upto ``ARM_ARCH_MAJOR.ARM_ARCH_MINOR``
+
+The build system requires that the platform provides a valid numeric value based on
+CPU architecture extension, otherwise it defaults to base Armv8.0-A architecture.
+Subsequent Arm Architecture versions also support extensions which were introduced
+in previous versions.
-The build system only requires that ``ARM_ARCH_MAJOR`` and ``ARM_ARCH_MINOR`` have a
-valid numeric value. These build options only control whether or not
-Architecture Extension-specific code is included in the build. Otherwise, TF-A
-targets the base Armv8.0-A architecture; i.e. as if ``ARM_ARCH_MAJOR`` == 8
-and ``ARM_ARCH_MINOR`` == 0, which are also their respective default values.
+**TO-DO** : Its planned to decouple the two functionalities and introduce a new macro
+for compiler usage. The requirement for this decoupling arises becasue TF-A code
+always provides support for the latest and greatest architecture features but this
+is not the case for the target compiler.
.. seealso:: :ref:`Build Options`
diff --git a/docs/getting_started/prerequisites.rst b/docs/getting_started/prerequisites.rst
index a3f8cc8..f4c3c28 100644
--- a/docs/getting_started/prerequisites.rst
+++ b/docs/getting_started/prerequisites.rst
@@ -14,7 +14,7 @@
|TF-A| can be built using either a Linux or a Windows machine as the build host.
A relatively recent Linux distribution is recommended for building |TF-A|. We
-have performed tests using Ubuntu 20.04 LTS (64-bit) but other distributions
+have performed tests using Ubuntu 22.04 LTS (64-bit) but other distributions
should also work fine as a base, provided that the necessary tools and libraries
can be installed.
@@ -77,11 +77,11 @@
The following libraries are required for Trusted Board Boot and Measured Boot
support:
-- mbed TLS == 2.28.1 (tag: ``mbedtls-2.28.1``)
+- mbed TLS == 3.4.0 (tag: ``mbedtls-3.4.0``)
These tools are optional:
-- Device Tree Compiler (DTC) >= 1.4.6
+- Device Tree Compiler (DTC) >= 1.4.7
Needed if you want to rebuild the provided Flattened Device Tree (FDT)
source files (``.dts`` files). DTC is available for Linux through the package
diff --git a/docs/perf/index.rst b/docs/perf/index.rst
index b83c6e3..0938a17 100644
--- a/docs/perf/index.rst
+++ b/docs/perf/index.rst
@@ -7,6 +7,7 @@
psci-performance-instr
psci-performance-juno
+ psci-performance-n1sdp
psci-performance-methodology
tsp
performance-monitoring-unit
diff --git a/docs/perf/psci-performance-juno.rst b/docs/perf/psci-performance-juno.rst
index 7418669..7a484b8 100644
--- a/docs/perf/psci-performance-juno.rst
+++ b/docs/perf/psci-performance-juno.rst
@@ -25,62 +25,189 @@
Juno supports CPU, cluster and system power down states, corresponding to power
levels 0, 1 and 2 respectively. It does not support any retention states.
-We used the upstream `TF master as of 31/01/2017`_, building the platform using
-the ``ENABLE_RUNTIME_INSTRUMENTATION`` option:
+Given that runtime instrumentation using PMF is invasive, there is a small
+(unquantified) overhead on the results. PMF uses the generic counter for
+timestamps, which runs at 50MHz on Juno.
-.. code:: shell
+The following source trees and binaries were used:
- make PLAT=juno ENABLE_RUNTIME_INSTRUMENTATION=1 \
- SCP_BL2=<path/to/scp-fw.bin> \
- BL33=<path/to/test-fw.bin> \
- all fip
+- TF-A [`v2.9-rc0`_]
+- TFTF [`v2.9-rc0`_]
-When using the debug build of TF, there was no noticeable difference in the
-results.
+Please see the Runtime Instrumentation `Testing Methodology`_ page for more
+details.
-The tests are based on an ARM-internal test framework. The release build of this
-framework was used because the results in the debug build became skewed; the
-console output prevented some of the tests from executing in parallel.
+Procedure
+---------
-The tests consist of both parallel and sequential tests, which are broadly
-described as follows:
+#. Build TFTF with runtime instrumentation enabled:
-- **Parallel Tests** This type of test powers on all the non-lead CPUs and
- brings them and the lead CPU to a common synchronization point. The lead CPU
- then initiates the test on all CPUs in parallel.
+ .. code:: shell
-- **Sequential Tests** This type of test powers on each non-lead CPU in
- sequence. The lead CPU initiates the test on a non-lead CPU then waits for the
- test to complete before proceeding to the next non-lead CPU. The lead CPU then
- executes the test on itself.
+ make CROSS_COMPILE=aarch64-none-elf- PLAT=juno \
+ TESTS=runtime-instrumentation all
-In the results below, CPUs 0-3 refer to CPUs in the little cluster (A53) and
-CPUs 4-5 refer to CPUs in the big cluster (A57). In all cases CPU 4 is the lead
-CPU.
+#. Fetch Juno's SCP binary from TF-A's archive:
-``PSCI_ENTRY`` refers to the time taken from entering the TF PSCI implementation
-to the point the hardware enters the low power state (WFI). Referring to the TF
-runtime instrumentation points, this corresponds to:
-``(RT_INSTR_ENTER_HW_LOW_PWR - RT_INSTR_ENTER_PSCI)``.
+ .. code:: shell
-``PSCI_EXIT`` refers to the time taken from the point the hardware exits the low
-power state to exiting the TF PSCI implementation. This corresponds to:
-``(RT_INSTR_EXIT_PSCI - RT_INSTR_EXIT_HW_LOW_PWR)``.
+ curl --fail --connect-timeout 5 --retry 5 -sLS -o scp_bl2.bin \
+ https://downloads.trustedfirmware.org/tf-a/css_scp_2.12.0/juno/release/juno-bl2.bin
-``CFLUSH_OVERHEAD`` refers to the part of ``PSCI_ENTRY`` taken to flush the
-caches. This corresponds to: ``(RT_INSTR_EXIT_CFLUSH - RT_INSTR_ENTER_CFLUSH)``.
+#. Build TF-A with the following build options:
-Note there is very little variance observed in the values given (~1us), although
-the values for each CPU are sometimes interchanged, depending on the order in
-which locks are acquired. Also, there is very little variance observed between
-executing the tests sequentially in a single boot or rebooting between tests.
+ .. code:: shell
-Given that runtime instrumentation using PMF is invasive, there is a small
-(unquantified) overhead on the results. PMF uses the generic counter for
-timestamps, which runs at 50MHz on Juno.
+ make CROSS_COMPILE=aarch64-none-elf- PLAT=juno \
+ BL33="/path/to/tftf.bin" SCP_BL2="scp_bl2.bin" \
+ ENABLE_RUNTIME_INSTRUMENTATION=1 fiptool all fip
+
+#. Load the following images onto the development board: ``fip.bin``,
+ ``scp_bl2.bin``.
+
+Results
+-------
+
+``CPU_SUSPEND`` to deepest power level
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
+ parallel
+
+ +---------+------+-----------+---------+-------------+
+ | Cluster | Core | Powerdown | Wakekup | Cache Flush |
+ +=========+======+===========+=========+=============+
+ | 0 | 0 | 243.76 | 239.92 | 6.32 |
+ +---------+------+-----------+---------+-------------+
+ | 0 | 1 | 663.5 | 30.32 | 167.82 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 0 | 105.12 | 22.84 | 5.88 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 1 | 384.16 | 19.06 | 4.7 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 2 | 523.98 | 270.46 | 4.74 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 3 | 950.54 | 220.9 | 89.2 |
+ +---------+------+-----------+---------+-------------+
+
+.. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
+ serial
+
+ +---------+------+-----------+---------+-------------+
+ | Cluster | Core | Powerdown | Wakekup | Cache Flush |
+ +=========+======+===========+=========+=============+
+ | 0 | 0 | 266.96 | 31.74 | 167.92 |
+ +---------+------+-----------+---------+-------------+
+ | 0 | 1 | 266.9 | 31.52 | 167.82 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 0 | 279.86 | 23.42 | 87.52 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 1 | 101.38 | 18.8 | 4.64 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 2 | 101.18 | 19.28 | 4.64 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 3 | 101.32 | 19.02 | 4.62 |
+ +---------+------+-----------+---------+-------------+
+
+``CPU_SUSPEND`` to power level 0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Results and Commentary
-----------------------
+.. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in
+ parallel
+
+ +---------+------+-----------+---------+-------------+
+ | Cluster | Core | Powerdown | Wakekup | Cache Flush |
+ +=========+======+===========+=========+=============+
+ +---------+------+-----------+---------+-------------+
+ | 0 | 0 | 661.94 | 22.88 | 9.66 |
+ +---------+------+-----------+---------+-------------+
+ | 0 | 1 | 801.64 | 23.38 | 9.62 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 0 | 105.56 | 16.02 | 8.12 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 1 | 245.42 | 16.26 | 7.78 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 2 | 384.42 | 16.1 | 7.84 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 3 | 523.74 | 15.4 | 8.02 |
+ +---------+------+-----------+---------+-------------+
+
+.. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in serial
+
+ +---------+------+-----------+---------+-------------+
+ | Cluster | Core | Powerdown | Wakekup | Cache Flush |
+ +=========+======+===========+=========+=============+
+ | 0 | 0 | 102.16 | 23.64 | 6.7 |
+ +---------+------+-----------+---------+-------------+
+ | 0 | 1 | 101.66 | 23.78 | 6.6 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 0 | 277.74 | 15.96 | 4.66 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 1 | 98.0 | 15.88 | 4.64 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 2 | 97.66 | 15.88 | 4.62 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 3 | 97.76 | 15.38 | 4.64 |
+ +---------+------+-----------+---------+-------------+
+
+``CPU_OFF`` on all non-lead CPUs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``CPU_OFF`` on all non-lead CPUs in sequence then, ``CPU_SUSPEND`` on the lead
+core to the deepest power level.
+
+.. table:: ``CPU_OFF`` latencies (µs) on all non-lead CPUs
+
+ +---------+------+-----------+---------+-------------+
+ | Cluster | Core | Powerdown | Wakekup | Cache Flush |
+ +=========+======+===========+=========+=============+
+ | 0 | 0 | 265.38 | 34.12 | 167.36 |
+ +---------+------+-----------+---------+-------------+
+ | 0 | 1 | 265.72 | 33.98 | 167.48 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 0 | 185.3 | 23.18 | 87.42 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 1 | 101.58 | 23.46 | 4.48 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 2 | 101.66 | 22.02 | 4.72 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 3 | 101.48 | 22.22 | 4.52 |
+ +---------+------+-----------+---------+-------------+
+
+``CPU_VERSION`` in parallel
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. table:: ``CPU_VERSION`` latency (µs) in parallel on all cores
+
+ +-------------+--------+--------------+
+ | Cluster | Core | Latency |
+ +=============+========+==============+
+ | 0 | 0 | 1.22 |
+ +-------------+--------+--------------+
+ | 0 | 1 | 1.2 |
+ +-------------+--------+--------------+
+ | 1 | 0 | 0.6 |
+ +-------------+--------+--------------+
+ | 1 | 1 | 1.08 |
+ +-------------+--------+--------------+
+ | 1 | 2 | 1.04 |
+ +-------------+--------+--------------+
+ | 1 | 3 | 1.04 |
+ +-------------+--------+--------------+
+
+Annotated Historic Results
+--------------------------
+
+The following results are based on the upstream `TF master as of 31/01/2017`_.
+TF-A was built using the same build instructions as detailed in the procedure
+above.
+
+In the results below, CPUs 0-3 refer to CPUs in the little cluster (A53) and
+CPUs 4-5 refer to CPUs in the big cluster (A57). In all cases CPU 4 is the lead
+CPU.
+
+``PSCI_ENTRY`` corresponds to the powerdown latency, ``PSCI_EXIT`` the wakeup latency, and
+``CFLUSH_OVERHEAD`` the latency of the cache flush operation.
``CPU_SUSPEND`` to deepest power level on all CPUs in parallel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -290,3 +417,5 @@
.. _Juno R1 platform: https://developer.arm.com/documentation/100122/latest/
.. _TF master as of 31/01/2017: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/?id=c38b36d
+.. _v2.9-rc0: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/?h=v2.9-rc0
+.. _Testing Methodology: ../perf/psci-performance-methodology.html
diff --git a/docs/perf/psci-performance-n1sdp.rst b/docs/perf/psci-performance-n1sdp.rst
new file mode 100644
index 0000000..70a1436
--- /dev/null
+++ b/docs/perf/psci-performance-n1sdp.rst
@@ -0,0 +1,203 @@
+Runtime Instrumentation Testing - N1SDP
+=======================================
+
+For this test we used the N1 System Development Platform (`N1SDP`_), which
+contains an SoC consisting of two dual-core Arm N1 clusters.
+
+The following source trees and binaries were used:
+
+- TF-A [`v2.9-rc0-16-g666aec401`_]
+- TFTF [`v2.9-rc0`_]
+- SCP/MCP `Prebuilt Images`_
+
+Please see the Runtime Instrumentation `Testing Methodology`_ page for more
+details.
+
+Procedure
+---------
+
+#. Build TFTF with runtime instrumentation enabled:
+
+ .. code:: shell
+
+ make CROSS_COMPILE=aarch64-none-elf- PLAT=n1sdp \
+ TESTS=runtime-instrumentation all
+
+#. Build TF-A with the following build options:
+
+ .. code:: shell
+
+ make CROSS_COMPILE=aarch64-none-elf- PLAT=n1sdp \
+ ENABLE_RUNTIME_INSTRUMENTATION=1 fiptool all
+
+#. Fetch the SCP firmware images:
+
+ .. code:: shell
+
+ curl --fail --connect-timeout 5 --retry 5 \
+ -sLS -o build/n1sdp/release/scp_rom.bin \
+ https://downloads.trustedfirmware.org/tf-a/css_scp_2.12.0/n1sdp/release/n1sdp-bl1.bin
+ curl --fail --connect-timeout 5 \
+ --retry 5 -sLS -o build/n1sdp/release/scp_ram.bin \
+ https://downloads.trustedfirmware.org/tf-a/css_scp_2.12.0/n1sdp/release/n1sdp-bl2.bin
+
+#. Fetch the MCP firmware images:
+
+ .. code:: shell
+
+ curl --fail --connect-timeout 5 --retry 5 \
+ -sLS -o build/n1sdp/release/mcp_rom.bin \
+ https://downloads.trustedfirmware.org/tf-a/css_scp_2.12.0/n1sdp/release/n1sdp-mcp-bl1.bin
+ curl --fail --connect-timeout 5 --retry 5 \
+ -sLS -o build/n1sdp/release/mcp_ram.bin \
+ https://downloads.trustedfirmware.org/tf-a/css_scp_2.12.0/n1sdp/release/n1sdp-mcp-bl2.bin
+
+#. Using the fiptool, create a new FIP package and append the SCP ram image onto
+ it.
+
+ .. code:: shell
+
+ ./tools/fiptool/fiptool create --blob \
+ uuid=cfacc2c4-15e8-4668-82be-430a38fad705,file=build/n1sdp/release/bl1.bin \
+ --scp-fw build/n1sdp/release/scp_ram.bin build/n1sdp/release/scp_fw.bin
+
+#. Append the MCP image to the FIP.
+
+ .. code:: shell
+
+ ./tools/fiptool/fiptool create \
+ --blob uuid=54464222-a4cf-4bf8-b1b6-cee7dade539e,file=build/n1sdp/release/mcp_ram.bin \
+ build/n1sdp/release/mcp_fw.bin
+
+#. Then, add TFTF as the Non-Secure workload in the FIP image:
+
+ .. code:: shell
+
+ make CROSS_COMPILE=aarch64-none-elf- PLAT=n1sdp \
+ ENABLE_RUNTIME_INSTRUMENTATION=1 SCP_BL2=/dev/null \
+ BL33=<path/to/tftf.bin> fip
+
+#. Load the following images onto the development board: ``fip.bin``,
+ ``scp_rom.bin``, ``scp_ram.bin``, ``mcp_rom.bin``, and ``mcp_ram.bin``.
+
+.. note::
+
+ These instructions presume you have a complete firmware stack. The N1SDP
+ `user guide`_ provides a detailed explanation on how to get setup from
+ scratch.
+
+Results
+-------
+
+``CPU_SUSPEND`` to deepest power level
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
+ parallel
+
+ +---------+------+-----------+---------+-------------+
+ | Cluster | Core | Powerdown | Wakekup | Cache Flush |
+ +=========+======+===========+=========+=============+
+ | 0 | 0 | 3.44 | 10.04 | 0.4 |
+ +---------+------+-----------+---------+-------------+
+ | 0 | 1 | 4.98 | 12.72 | 0.16 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 0 | 3.58 | 15.42 | 0.2 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 1 | 5.24 | 17.78 | 0.18 |
+ +---------+------+-----------+---------+-------------+
+
+.. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
+ serial
+
+ +---------+------+-----------+---------+-------------+
+ | Cluster | Core | Powerdown | Wakekup | Cache Flush |
+ +=========+======+===========+=========+=============+
+ | 0 | 0 | 1.82 | 9.98 | 0.32 |
+ +---------+------+-----------+---------+-------------+
+ | 0 | 1 | 1.96 | 9.96 | 0.18 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 0 | 2.0 | 10.5 | 0.16 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 1 | 2.22 | 10.56 | 0.16 |
+ +---------+------+-----------+---------+-------------+
+
+``CPU_SUSPEND`` to power level 0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in
+ parallel
+
+ +---------+------+-----------+---------+-------------+
+ | Cluster | Core | Powerdown | Wakekup | Cache Flush |
+ +=========+======+===========+=========+=============+
+ | 0 | 0 | 1.52 | 11.84 | 0.34 |
+ +---------+------+-----------+---------+-------------+
+ | 0 | 1 | 1.1 | 13.66 | 0.14 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 0 | 2.18 | 9.48 | 0.18 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 1 | 2.06 | 14.4 | 0.16 |
+ +---------+------+-----------+---------+-------------+
+
+.. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in serial
+
+ +---------+------+-----------+---------+-------------+
+ | Cluster | Core | Powerdown | Wakekup | Cache Flush |
+ +=========+======+===========+=========+=============+
+ | 0 | 0 | 1.54 | 9.34 | 0.3 |
+ +---------+------+-----------+---------+-------------+
+ | 0 | 1 | 1.88 | 9.5 | 0.16 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 0 | 1.86 | 9.86 | 0.2 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 1 | 2.02 | 9.64 | 0.18 |
+ +---------+------+-----------+---------+-------------+
+
+``CPU_OFF`` on all non-lead CPUs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``CPU_OFF`` on all non-lead CPUs in sequence then, ``CPU_SUSPEND`` on the lead
+core to the deepest power level.
+
+.. table:: ``CPU_OFF`` latencies (µs) on all non-lead CPUs
+
+ +---------+------+-----------+---------+-------------+
+ | Cluster | Core | Powerdown | Wakekup | Cache Flush |
+ +=========+======+===========+=========+=============+
+ | 0 | 0 | 1.86 | 9.88 | 0.32 |
+ +---------+------+-----------+---------+-------------+
+ | 0 | 1 | 21.1 | 12.44 | 0.42 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 0 | 21.22 | 13.2 | 0.32 |
+ +---------+------+-----------+---------+-------------+
+ | 1 | 1 | 21.56 | 13.18 | 0.54 |
+ +---------+------+-----------+---------+-------------+
+
+``CPU_VERSION`` in parallel
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. table:: ``CPU_VERSION`` latency (µs) in parallel on all cores
+
+ +-------------+--------+--------------+
+ | Cluster | Core | Latency |
+ +=============+========+==============+
+ | 0 | 0 | 0.08 |
+ +-------------+--------+--------------+
+ | 0 | 1 | 0.22 |
+ +-------------+--------+--------------+
+ | 1 | 0 | 0.28 |
+ +-------------+--------+--------------+
+ | 1 | 1 | 0.26 |
+ +-------------+--------+--------------+
+
+--------------
+
+*Copyright (c) 2023, Arm Limited. All rights reserved.*
+
+.. _v2.9-rc0-16-g666aec401: https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/v2.9-rc0-16-g666aec401
+.. _v2.9-rc0: https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/tags/v2.9-rc0
+.. _user guide: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/blob/master/docs/n1sdp/user-guide.rst
+.. _Prebuilt Images: https://downloads.trustedfirmware.org/tf-a/css_scp_2.11.0/n1sdp/release/
+.. _N1SDP: https://developer.arm.com/documentation/101489/latest
+.. _Testing Methodology: ../perf/psci-performance-methodology.html
\ No newline at end of file
diff --git a/docs/threat_model/threat_model_spm.rst b/docs/threat_model/threat_model_spm.rst
index 98dbf76..9458a9f 100644
--- a/docs/threat_model/threat_model_spm.rst
+++ b/docs/threat_model/threat_model_spm.rst
@@ -35,7 +35,7 @@
- The TF-A implementation for the S-EL2 SPMC based on the Hafnium hypervisor
running in the secure world of TrustZone (at S-EL2 exception level).
The threat model is not related to the normal world Hypervisor or VMs.
- The S-EL1 SPMC solution is not covered.
+ The S-EL1 and EL3 SPMC solutions are not covered.
- The implementation complies with the FF-A v1.0 specification, and a few
features of FF-A v1.1 specification.
- Secure partitions are statically provisioned at boot time.
@@ -235,8 +235,8 @@
+------------------------+------------------+-----------------+---------------+
| ``Total Risk Rating`` | High (16) | High (16) | |
+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | In context of FF-A v1.0 this is the case of sharing|
-| | the RX/TX buffer pair and usage in the |
+| ``Mitigations`` | In context of FF-A v1.0 and v1.1 this is the case |
+| | of sharing the RX/TX buffer pair and usage in the |
| | PARTITION_INFO_GET or mem sharing primitives. |
| | The SPMC must copy the contents of the TX buffer |
| | to an internal temporary buffer before processing |
@@ -1151,11 +1151,189 @@
| | interrupted. |
+------------------------+----------------------------------------------------+
++------------------------+----------------------------------------------------+
+| ID | 25 |
++========================+====================================================+
+| ``Threat`` | **A rogue FF-A endpoint can use memory sharing |
+| | calls to exhaust SPMC resources.** |
+| | For each on-going operation that involves an SP, |
+| | the SPMC allocates resources to track its state. |
+| | If the operation is never concluded, the resources |
+| | are never freed. |
+| | In the worst scenario, multiple operations that |
+| | never conclude may exhaust the SPMC resources to a |
+| | point in which renders memory sharing operations |
+| | impossible. This could affect other, non-harmful |
+| | FF-A endpoints, from legitimately using memory |
+| | share functionality. The intent might even be |
+| | to cause the SPMC to consume excessive CPU cycles, |
+| | attempting to make it deny its service to the NWd. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF2 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC, SPMD |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SPMC state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Denial of Service |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | High (4) | Medium (3) | |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | High (4) | Medium (3) | |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | High (16) | Medium (9) | |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | The TF-A SPMC uses a statically allocated pool of |
+| | memory to keep track of on-going memory sharing |
+| | operations. After a possible attack, this could |
+| | fail due to insufficient memory, and return an |
+| | error to the caller. At this point, any other |
+| | endpoint that requires use of memory sharing for |
+| | its operation could get itself in an unusable |
+| | state. |
+| | Regarding CPU cycles starving threat, the SPMC |
+| | doesn't provide any mitigation for this, as any |
+| | FF-A endpoint, at the virtual FF-A instance is |
+| | allowed to invoke memory share/lend/donate. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 26 |
++========================+====================================================+
+| ``Threat`` | **A borrower may interfere with lender's |
+| | operation, if it terminates due to a fatal error |
+| | condition without releasing the memory |
+| | shared/lent.** |
+| | Such scenario may render the lender inoperable. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF2 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SP state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Denial of Service |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | High (4) | Low (2) | |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Medium (3) | Medium (3) | |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | High (12) | Medium(6) | |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | The TF-A SPMC does not provide mitigation for such |
+| | scenario. The FF-A endpoints must attempt to |
+| | relinquish memory shared/lent themselves in |
+| | case of failure. The memory used to track the |
+| | operation in the SPMC will also remain usuable. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 27 |
++========================+====================================================+
+| ``Threat`` | **A rogue FF-A endpoint may attempt to tamper with |
+| | the content of the memory shared/lent, whilst |
+| | being accessed by other FF-A endpoints.** |
+| | It might attempt to do so: using one of the clear |
+| | flags, when either retrieving or relinquishing |
+| | access to the memory via the respective FF-A |
+| | calls; or directly accessing memory without |
+| | respecting the synchronization protocol between |
+| | all involved endpoints. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF2 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC, FF-A endpoint |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SP state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Denial of Service, Tampering |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | Low (2) | Low (2) | |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Medium (3) | Medium (3) | |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | Medium (6) | Medium(6) | |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | The first case defined in the threat, the TF-A |
+| | SPMC mitigates it, by ensuring a memory is cleared |
+| | only when all borrowers have relinquished access |
+| | to the memory, in a scenario involving multiple |
+| | borrowers. Also, if the receiver is granted RO, |
+| | permissions, the SPMC will reject any request |
+| | to clear memory on behalf of the borrower, by |
+| | returning an error to the respective FF-A call. |
+| | The second case defined in the threat can't be |
+| | mitigated by the SPMC. It is up to the NS/S FF-A |
+| | endpoints to establish a robust protocol for using |
+| | the shared memory. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 28 |
++========================+====================================================+
+| ``Threat`` | **A rogue FF-A endpoint may attempt to share |
+| | memory that is not in its translation regime, or |
+| | attempt to specify attributes more permissive than |
+| | those it possesses at a given time.** |
+| | Both ways could be an attempt for escalating its |
+| | privileges. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF2 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC, FF-A endpoint |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SP state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Denial of Service, Tampering |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | High (4) | Low (2) | |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Medium (3) | Low (2) | |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | High (12) | Low (2) | |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | The TF-A SPMC mitigates this threat by performing |
+| | sanity checks to the provided memory region |
+| | descriptor. |
+| | For operations at the virtual FF-A instance, and |
+| | once the full memory descriptor is provided, |
+| | the SPMC validates that the memory is part of the |
+| | caller's translation regime. The SPMC also checks |
+| | that the memory attributes provided are within |
+| | those the owner possesses, in terms of |
+| | permissiveness. If more permissive attributes are |
+| | specified, the SPMC returns an error |
+| | FFA_INVALID_PARAMETERS. The permissiveness rules |
+| | are enforced in any call to share/lend or donate |
+| | the memory, and in retrieve requests. |
++------------------------+----------------------------------------------------+
+
--------------
-*Copyright (c) 2021-2022, Arm Limited. All rights reserved.*
+*Copyright (c) 2021-2023, Arm Limited. All rights reserved.*
.. _Arm Firmware Framework for Arm A-profile: https://developer.arm.com/docs/den0077/latest
.. _Secure Partition Manager: ../components/secure-partition-manager.html
.. _Generic TF-A threat model: ./threat_model.html#threat-analysis
.. _FF-A ACS: https://github.com/ARM-software/ff-a-acs/releases
+
diff --git a/plat/arm/board/morello/morello_bl31_setup.c b/plat/arm/board/morello/morello_bl31_setup.c
index e13a38b..8469cd1 100644
--- a/plat/arm/board/morello/morello_bl31_setup.c
+++ b/plat/arm/board/morello/morello_bl31_setup.c
@@ -35,7 +35,6 @@
const plat_psci_ops_t *plat_arm_psci_override_pm_ops(plat_psci_ops_t *ops)
{
ops->pwr_domain_off = morello_pwr_domain_off;
- ops->pwr_domain_suspend = morello_pwr_domain_suspend;
return css_scmi_override_pm_ops(ops);
}
diff --git a/plat/arm/board/morello/morello_pm.c b/plat/arm/board/morello/morello_pm.c
index dda006e..fa7bd1d 100644
--- a/plat/arm/board/morello/morello_pm.c
+++ b/plat/arm/board/morello/morello_pm.c
@@ -11,19 +11,13 @@
#include "morello_private.h"
/*******************************************************************************
- * Morello specific functions called when turning off or suspending a power
- * domain. Both additionally disable the GIC redistributor interface as cores
- * are disabled to let cluster-PPU state transition to completion when a
- * cluster is powered down.
+ * Morello specific function called when turning off a power domain.
+ * Additionally disables the GIC redistributor interface as cores are disabled
+ * to let cluster-PPU state transition to completion when a cluster is
+ * powered down.
******************************************************************************/
void morello_pwr_domain_off(const psci_power_state_t *target_state)
{
css_pwr_domain_off(target_state);
plat_arm_gic_redistif_off();
}
-
-void morello_pwr_domain_suspend(const psci_power_state_t *target_state)
-{
- css_pwr_domain_suspend(target_state);
- plat_arm_gic_redistif_off();
-}
diff --git a/plat/arm/board/morello/morello_private.h b/plat/arm/board/morello/morello_private.h
index ea2fce9..dea70fb 100644
--- a/plat/arm/board/morello/morello_private.h
+++ b/plat/arm/board/morello/morello_private.h
@@ -10,6 +10,5 @@
#include <lib/psci/psci.h>
void morello_pwr_domain_off(const psci_power_state_t *target_state);
-void morello_pwr_domain_suspend(const psci_power_state_t *target_state);
#endif /* MORELLO_PRIVATE_H */
diff --git a/plat/arm/board/n1sdp/n1sdp_bl31_setup.c b/plat/arm/board/n1sdp/n1sdp_bl31_setup.c
index db7215f..2b9ed25 100644
--- a/plat/arm/board/n1sdp/n1sdp_bl31_setup.c
+++ b/plat/arm/board/n1sdp/n1sdp_bl31_setup.c
@@ -71,7 +71,6 @@
const plat_psci_ops_t *plat_arm_psci_override_pm_ops(plat_psci_ops_t *ops)
{
ops->pwr_domain_off = n1sdp_pwr_domain_off;
- ops->pwr_domain_suspend = n1sdp_pwr_domain_suspend;
return css_scmi_override_pm_ops(ops);
}
diff --git a/plat/arm/board/n1sdp/n1sdp_pm.c b/plat/arm/board/n1sdp/n1sdp_pm.c
index e43832a..8d45354 100644
--- a/plat/arm/board/n1sdp/n1sdp_pm.c
+++ b/plat/arm/board/n1sdp/n1sdp_pm.c
@@ -11,19 +11,13 @@
#include "n1sdp_private.h"
/*******************************************************************************
- * N1SDP specific functions called when turning off or suspending a power
- * domain. Both additionally disable the GIC redistributor interface as cores
- * are disabled to let cluster-PPU state transition to completion when a
- * cluster is powered down.
+ * N1SDP specific function called when turning off a power domain. Additionally
+ * disables the GIC redistributor interface as cores are disabled to
+ * let cluster-PPU state transition to completion when a cluster is powered
+ * down.
******************************************************************************/
void n1sdp_pwr_domain_off(const psci_power_state_t *target_state)
{
css_pwr_domain_off(target_state);
plat_arm_gic_redistif_off();
}
-
-void n1sdp_pwr_domain_suspend(const psci_power_state_t *target_state)
-{
- css_pwr_domain_suspend(target_state);
- plat_arm_gic_redistif_off();
-}
diff --git a/plat/arm/board/n1sdp/n1sdp_private.h b/plat/arm/board/n1sdp/n1sdp_private.h
index 7a5c51d..4e48c0f 100644
--- a/plat/arm/board/n1sdp/n1sdp_private.h
+++ b/plat/arm/board/n1sdp/n1sdp_private.h
@@ -10,6 +10,5 @@
#include <lib/psci/psci.h>
void n1sdp_pwr_domain_off(const psci_power_state_t *target_state);
-void n1sdp_pwr_domain_suspend(const psci_power_state_t *target_state);
#endif /* N1SDP_PRIVATE_H */
diff --git a/plat/arm/board/tc/include/tc_plat.h b/plat/arm/board/tc/include/tc_plat.h
index 195366e..117fbb4 100644
--- a/plat/arm/board/tc/include/tc_plat.h
+++ b/plat/arm/board/tc/include/tc_plat.h
@@ -10,10 +10,11 @@
void tc_bl31_common_platform_setup(void);
#ifdef PLATFORM_TEST_TFM_TESTSUITE
-void run_platform_tests(void);
+int run_platform_tests(void);
#endif
+
#ifdef PLATFORM_TEST_NV_COUNTERS
-void nv_counter_test(void);
+int nv_counter_test(void);
#endif
#endif /* TC_PLAT_H */
diff --git a/plat/arm/board/tc/nv_counter_test.c b/plat/arm/board/tc/nv_counter_test.c
index 76c9915..f9e001e 100644
--- a/plat/arm/board/tc/nv_counter_test.c
+++ b/plat/arm/board/tc/nv_counter_test.c
@@ -13,7 +13,7 @@
#include <platform_def.h>
-void nv_counter_test(void)
+int nv_counter_test(void)
{
psa_status_t status;
uint32_t old_val;
@@ -23,7 +23,7 @@
status = rss_comms_init(PLAT_RSS_AP_SND_MHU_BASE, PLAT_RSS_AP_RCV_MHU_BASE);
if (status != PSA_SUCCESS) {
printf("Failed to initialize RSS communication channel\n");
- plat_error_handler(-1);
+ return -1;
}
for (id = 0; id < 3; id++) {
@@ -31,28 +31,30 @@
if (status != PSA_SUCCESS) {
printf("Failed during first id=(%d) rss_platform_nv_counter_read\n",
id);
- plat_error_handler(-1);
+ return -1;
}
status = rss_platform_nv_counter_increment(id);
if (status != PSA_SUCCESS) {
printf("Failed during id=(%d) rss_platform_nv_counter_increment\n",
id);
- plat_error_handler(-1);
+ return -1;
}
status = rss_platform_nv_counter_read(id, sizeof(new_val), (uint8_t *)&new_val);
if (status != PSA_SUCCESS) {
printf("Failed during second id=(%d) rss_platform_nv_counter_read\n",
id);
- plat_error_handler(-1);
+ return -1;
}
if (old_val + 1 != new_val) {
printf("Failed nv_counter_test: old_val (%d) + 1 != new_val (%d)\n",
old_val, new_val);
- plat_error_handler(-1);
+ return -1;
}
}
printf("Passed nv_counter_test\n");
+
+ return 0;
}
diff --git a/plat/arm/board/tc/platform.mk b/plat/arm/board/tc/platform.mk
index 98c2e0e..c29537c 100644
--- a/plat/arm/board/tc/platform.mk
+++ b/plat/arm/board/tc/platform.mk
@@ -196,28 +196,32 @@
endif
-ifeq (${PLATFORM_TEST},rss-nv-counters)
- include drivers/arm/rss/rss_comms.mk
+ifneq (${PLATFORM_TEST},)
+ $(eval $(call add_define,PLATFORM_TESTS))
- # Test code.
- BL31_SOURCES += plat/arm/board/tc/nv_counter_test.c
+ ifeq (${PLATFORM_TEST},rss-nv-counters)
+ include drivers/arm/rss/rss_comms.mk
- # Code under testing.
- BL31_SOURCES += lib/psa/rss_platform.c \
+ # Test code.
+ BL31_SOURCES += plat/arm/board/tc/nv_counter_test.c
+
+ # Code under testing.
+ BL31_SOURCES += lib/psa/rss_platform.c \
drivers/arm/rss/rss_comms.c \
${RSS_COMMS_SOURCES}
- PLAT_INCLUDES += -Iinclude/lib/psa
+ PLAT_INCLUDES += -Iinclude/lib/psa
- $(eval $(call add_define,PLATFORM_TEST_NV_COUNTERS))
-else ifeq (${PLATFORM_TEST},tfm-testsuite)
- # Add this include as first, before arm_common.mk. This is necessary
- # because arm_common.mk builds Mbed TLS, and platform_test.mk can
- # change the list of Mbed TLS files that are to be compiled
- # (LIBMBEDTLS_SRCS).
- include plat/arm/board/tc/platform_test.mk
-else ifneq (${PLATFORM_TEST},)
- $(error "Unsupported PLATFORM_TEST value")
+ $(eval $(call add_define,PLATFORM_TEST_NV_COUNTERS))
+ else ifeq (${PLATFORM_TEST},tfm-testsuite)
+ # Add this include as first, before arm_common.mk. This is necessary
+ # because arm_common.mk builds Mbed TLS, and platform_test.mk can
+ # change the list of Mbed TLS files that are to be compiled
+ # (LIBMBEDTLS_SRCS).
+ include plat/arm/board/tc/platform_test.mk
+ else
+ $(error "Unsupported PLATFORM_TEST value")
+ endif
endif
diff --git a/plat/arm/board/tc/rss_ap_tests.c b/plat/arm/board/tc/rss_ap_tests.c
index b62043e..8c40271 100644
--- a/plat/arm/board/tc/rss_ap_tests.c
+++ b/plat/arm/board/tc/rss_ap_tests.c
@@ -19,21 +19,28 @@
{.freg = register_testsuite_measured_boot},
};
-static void run_tests(void)
+/*
+ * Return 0 if we could run all tests.
+ * Note that this does not mean that all tests passed - only that they all run.
+ * One should then look at each individual test result inside the
+ * test_suites[].val field.
+ */
+static int run_tests(void)
{
enum test_suite_err_t ret;
psa_status_t status;
size_t i;
+ /* Initialize test environment. */
rss_comms_init(PLAT_RSS_AP_SND_MHU_BASE, PLAT_RSS_AP_RCV_MHU_BASE);
mbedtls_init();
status = psa_crypto_init();
if (status != PSA_SUCCESS) {
printf("\n\npsa_crypto_init failed (status = %d)\n", status);
- assert(false);
- plat_error_handler(-1);
+ return -1;
}
+ /* Run all tests. */
for (i = 0; i < ARRAY_SIZE(test_suites); ++i) {
struct test_suite_t *suite = &(test_suites[i]);
@@ -41,22 +48,33 @@
ret = run_testsuite(suite);
if (ret != TEST_SUITE_ERR_NO_ERROR) {
printf("\n\nError during executing testsuite '%s'.\n", suite->name);
- assert(false);
- plat_error_handler(-1);
+ return -1;
}
}
printf("\nAll tests are run.\n");
+
+ return 0;
}
void run_platform_tests(void)
{
size_t i;
+ int ret;
+ int failures = 0;
- run_tests();
+ ret = run_tests();
+ if (ret != 0) {
+ /* For some reason, we could not run all tests. */
+ return ret;
+ }
printf("\n\n");
- /* Print a summary of all the tests that had been run. */
+ /*
+ * Print a summary of all the tests that had been run.
+ * Also count the number of tests failure and report that back to the
+ * caller.
+ */
printf("SUMMARY:\n");
for (i = 0; i < ARRAY_SIZE(test_suites); ++i) {
@@ -67,6 +85,7 @@
printf(" %s PASSED.\n", suite->name);
break;
case TEST_FAILED:
+ failures++;
printf(" %s FAILED.\n", suite->name);
break;
case TEST_SKIPPED:
@@ -79,4 +98,6 @@
}
printf("\n\n");
+
+ return failures;
}
diff --git a/plat/arm/board/tc/tc_bl31_setup.c b/plat/arm/board/tc/tc_bl31_setup.c
index 6afbd99..ca3a032 100644
--- a/plat/arm/board/tc/tc_bl31_setup.c
+++ b/plat/arm/board/tc/tc_bl31_setup.c
@@ -50,18 +50,34 @@
fconf_populate("FW_CONFIG", arg1);
}
-void tc_bl31_common_platform_setup(void)
+#ifdef PLATFORM_TESTS
+static __dead2 void tc_run_platform_tests(void)
{
- arm_bl31_platform_setup();
+ int tests_failed;
+
+ printf("\nStarting platform tests...\n");
-#if defined(PLATFORM_TEST_NV_COUNTERS) || defined(PLATFORM_TEST_TFM_TESTSUITE)
#ifdef PLATFORM_TEST_NV_COUNTERS
- nv_counter_test();
+ tests_failed = nv_counter_test();
#elif PLATFORM_TEST_TFM_TESTSUITE
- run_platform_tests();
+ tests_failed = run_platform_tests();
#endif
- /* Suspend booting */
+
+ printf("Platform tests %s.\n",
+ (tests_failed != 0) ? "failed" : "succeeded");
+
+ /* Suspend booting, no matter the tests outcome. */
+ printf("Suspend booting...\n");
plat_error_handler(-1);
+}
+#endif
+
+void tc_bl31_common_platform_setup(void)
+{
+ arm_bl31_platform_setup();
+
+#ifdef PLATFORM_TESTS
+ tc_run_platform_tests();
#endif
}
diff --git a/plat/nvidia/tegra/soc/t210/plat_sip_calls.c b/plat/nvidia/tegra/soc/t210/plat_sip_calls.c
index 93d1283..f3ebd4b 100644
--- a/plat/nvidia/tegra/soc/t210/plat_sip_calls.c
+++ b/plat/nvidia/tegra/soc/t210/plat_sip_calls.c
@@ -33,8 +33,7 @@
/*******************************************************************************
* Tegra210 SiP SMCs
******************************************************************************/
-#define TEGRA_SIP_PMC_COMMANDS_LEGACY U(0xC2FEFE00)
-#define TEGRA_SIP_PMC_COMMANDS U(0xC2FFFE00)
+#define TEGRA_SIP_PMC_COMMANDS U(0xC200FE00)
/*******************************************************************************
* This function is responsible for handling all T210 SiP calls
@@ -55,10 +54,12 @@
if (!ns)
SMC_RET1(handle, SMC_UNK);
- if ((smc_fid == TEGRA_SIP_PMC_COMMANDS) || (smc_fid == TEGRA_SIP_PMC_COMMANDS_LEGACY)) {
+ if (smc_fid == TEGRA_SIP_PMC_COMMANDS) {
+
/* check the address is within PMC range and is 4byte aligned */
- if ((x2 >= TEGRA_PMC_SIZE) || (x2 & 0x3))
+ if ((x2 >= TEGRA_PMC_SIZE) || (x2 & 0x3)) {
return -EINVAL;
+ }
switch (x2) {
/* Black listed PMC registers */