Merge "docs(changelog): changelog for v2.8 release" into integration
diff --git a/.gitignore b/.gitignore
index b005fab..1f4efb6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -43,3 +43,9 @@
# Node.js
node_modules/
+
+# common python virtual environment directories
+.env/
+env/
+.venv/
+venv/
diff --git a/docs/about/index.rst b/docs/about/index.rst
index 3a10266..06973ef 100644
--- a/docs/about/index.rst
+++ b/docs/about/index.rst
@@ -4,7 +4,6 @@
.. toctree::
:maxdepth: 1
:caption: Contents
- :numbered:
features
release-information
diff --git a/docs/about/release-information.rst b/docs/about/release-information.rst
index cb2b883..dead4f7 100644
--- a/docs/about/release-information.rst
+++ b/docs/about/release-information.rst
@@ -52,6 +52,8 @@
+-----------------+---------------------------+------------------------------+
| v2.8 | 5th week of Nov '22 | 3rd week of Nov '22 |
+-----------------+---------------------------+------------------------------+
+| v2.9 | 1st week of May '23 | 3rd week of Apr '23 |
++-----------------+---------------------------+------------------------------+
Removal of Deprecated Interfaces
--------------------------------
diff --git a/docs/components/ffa-manifest-binding.rst b/docs/components/ffa-manifest-binding.rst
index 6d2f905..7483c90 100644
--- a/docs/components/ffa-manifest-binding.rst
+++ b/docs/components/ffa-manifest-binding.rst
@@ -114,6 +114,19 @@
- managed-exit
- value type: <empty>
- Specifies if managed exit is supported.
+ - This field is deprecated in favor of ns-interrupts-action field in the FF-A
+ v1.1 EAC0 spec.
+
+- ns-interrupts-action [mandatory]
+ - value type: <u32>
+ - Specifies the action that the SPMC must take in response to a Non-secure
+ physical interrupt.
+
+ - 0x0: Non-secure interrupt is queued
+ - 0x1: Non-secure interrupt is signaled after a managed exit
+ - 0x2: Non-secure interrupt is signaled
+
+ - This field supersedes the managed-exit field in the FF-A v1.0 spec.
- has-primary-scheduler
- value type: <empty>
diff --git a/docs/components/index.rst b/docs/components/index.rst
index 0972a68..30d80fc 100644
--- a/docs/components/index.rst
+++ b/docs/components/index.rst
@@ -4,7 +4,6 @@
.. toctree::
:maxdepth: 1
:caption: Contents
- :numbered:
spd/index
activity-monitors
diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst
index 18d870b..cd439ad 100644
--- a/docs/components/secure-partition-manager.rst
+++ b/docs/components/secure-partition-manager.rst
@@ -794,6 +794,8 @@
- ``FFA_SECONDARY_EP_REGISTER``
- ``FFA_MEM_PERM_GET``
- ``FFA_MEM_PERM_SET``
+ - ``FFA_MSG_SEND2``
+ - ``FFA_RX_ACQUIRE``
FFA_VERSION
~~~~~~~~~~~
@@ -827,7 +829,11 @@
When invoked from the Hypervisor or OS kernel, the buffers are mapped into the
SPMC EL2 Stage-1 translation regime and marked as NS buffers in the MMU
-descriptors.
+descriptors. The provided addresses may be owned by a VM in the normal world,
+which is expected to receive messages from the secure world. The SPMC will in
+this case allocate internal state structures to facilitate RX buffer access
+synchronization (through FFA_RX_ACQUIRE interface), and to permit SPs to send
+messages.
The FFA_RXTX_UNMAP unmaps the RX/TX pair from the translation regime of the
caller, either it being the Hypervisor or OS kernel, as well as a secure
@@ -969,6 +975,53 @@
A secondary EC is first resumed either upon invocation of PSCI_CPU_ON from
the NWd or by invocation of FFA_RUN.
+FFA_RX_ACQUIRE/FFA_RX_RELEASE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The RX buffers can be used to pass information to an FF-A endpoint in the
+following scenarios:
+
+ - When it was targetted by a FFA_MSG_SEND2 invokation from another endpoint.
+ - Return the result of calling ``FFA_PARTITION_INFO_GET``.
+ - In a memory share operation, as part of the ``FFA_MEM_RETRIEVE_RESP``,
+ with the memory descriptor of the shared memory.
+
+If a normal world VM is expected to exchange messages with secure world,
+its RX/TX buffer addresses are forwarded to the SPMC via FFA_RXTX_MAP ABI,
+and are from this moment owned by the SPMC.
+The hypervisor must call the FFA_RX_ACQUIRE interface before attempting
+to use the RX buffer, in any of the aforementioned scenarios. A successful
+call to FFA_RX_ACQUIRE transfers ownership of RX buffer to hypervisor, such
+that it can be safely used.
+
+The FFA_RX_RELEASE interface is used after the FF-A endpoint is done with
+processing the data received in its RX buffer. If the RX buffer has been
+acquired by the hypervisor, the FFA_RX_RELEASE call must be forwarded to
+the SPMC to reestablish SPMC's RX ownership.
+
+An attempt from an SP to send a message to a normal world VM whose RX buffer
+was acquired by the hypervisor fails with error code FFA_BUSY, to preserve
+the RX buffer integrity.
+The operation could then be conducted after FFA_RX_RELEASE.
+
+FFA_MSG_SEND2
+~~~~~~~~~~~~~
+
+Hafnium copies a message from the sender TX buffer into receiver's RX buffer.
+For messages from SPs to VMs, operation is only possible if the SPMC owns
+the receiver's RX buffer.
+
+Both receiver and sender need to enable support for indirect messaging,
+in their respective partition manifest. The discovery of support
+of such feature can be done via FFA_PARTITION_INFO_GET.
+
+On a successful message send, Hafnium pends an RX buffer full framework
+notification for the receiver, to inform it about a message in the RX buffer.
+
+The handling of framework notifications is similar to that of
+global notifications. Binding of these is not necessary, as these are
+reserved to be used by the hypervisor or SPMC.
+
SPMC-SPMD direct requests/responses
-----------------------------------
@@ -1009,6 +1062,40 @@
For S-EL0 partitions with VHE enabled, a single secure EL2&0 Stage-1 translation
regime is used for both Hafnium and the partition.
+Schedule modes and SP Call chains
+---------------------------------
+
+An SP execution context is said to be in SPMC scheduled mode if CPU cycles are
+allocated to it by SPMC. Correspondingly, an SP execution context is said to be
+in Normal world scheduled mode if CPU cycles are allocated by the normal world.
+
+A call chain represents all SPs in a sequence of invocations of a direct message
+request. When execution on a PE is in the secure state, only a single call chain
+that runs in the Normal World scheduled mode can exist. FF-A v1.1 spec allows
+any number of call chains to run in the SPMC scheduled mode but the Hafnium
+SPMC restricts the number of call chains in SPMC scheduled mode to only one for
+keeping the implementation simple.
+
+Partition runtime models
+------------------------
+
+The runtime model of an endpoint describes the transitions permitted for an
+execution context between various states. These are the four partition runtime
+models supported (refer to `[1]`_ section 7):
+
+ - RTM_FFA_RUN: runtime model presented to an execution context that is
+ allocated CPU cycles through FFA_RUN interface.
+ - RTM_FFA_DIR_REQ: runtime model presented to an execution context that is
+ allocated CPU cycles through FFA_MSG_SEND_DIRECT_REQ interface.
+ - RTM_SEC_INTERRUPT: runtime model presented to an execution context that is
+ allocated CPU cycles by SPMC to handle a secure interrupt.
+ - RTM_SP_INIT: runtime model presented to an execution context that is
+ allocated CPU cycles by SPMC to initialize its state.
+
+If an endpoint execution context attempts to make an invalid transition or a
+valid transition that could lead to a loop in the call chain, SPMC denies the
+transition with the help of above runtime models.
+
Interrupt management
--------------------
@@ -1020,44 +1107,58 @@
IDs based on SP manifests. The SPMC acknowledges physical interrupts and injects
virtual interrupts by setting the use of vIRQ/vFIQ bits before resuming a SP.
-Non-secure interrupt handling
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Abbreviations:
-The following illustrate the scenarios of non secure physical interrupts trapped
-by the SPMC:
+ - NS-Int: A non-secure physical interrupt. It requires a switch to the normal
+ world to be handled if it triggers while execution is in secure world.
+ - Other S-Int: A secure physical interrupt targeted to an SP different from
+ the one that is currently running.
+ - Self S-Int: A secure physical interrupt targeted to the SP that is currently
+ running.
-- The SP handles a managed exit operation:
+Non-secure interrupt handling
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.. image:: ../resources/diagrams/ffa-ns-interrupt-handling-managed-exit.png
+This section documents the actions supported in SPMC in response to a non-secure
+interrupt as per the guidance provided by FF-A v1.1 EAC0 specification.
+An SP specifies one of the following actions in its partition manifest:
-- The SP is pre-empted without managed exit:
+ - Non-secure interrupt is signaled.
+ - Non-secure interrupt is signaled after a managed exit.
+ - Non-secure interrupt is queued.
-.. image:: ../resources/diagrams/ffa-ns-interrupt-handling-sp-preemption.png
+An SP execution context in a call chain could specify a less permissive action
+than subsequent SP execution contexts in the same call chain. The less
+permissive action takes precedence over the more permissive actions specified
+by the subsequent execution contexts. Please refer to FF-A v1.1 EAC0 section
+8.3.1 for further explanation.
Secure interrupt handling
--------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~
This section documents the support implemented for secure interrupt handling in
-SPMC as per the guidance provided by FF-A v1.1 Beta0 specification.
+SPMC as per the guidance provided by FF-A v1.1 EAC0 specification.
The following assumptions are made about the system configuration:
- In the current implementation, S-EL1 SPs are expected to use the para
- virtualized ABIs for interrupt management rather than accessing virtual GIC
- interface.
+ virtualized ABIs for interrupt management rather than accessing the virtual
+ GIC interface.
- Unless explicitly stated otherwise, this support is applicable only for
S-EL1 SPs managed by SPMC.
- Secure interrupts are configured as G1S or G0 interrupts.
- All physical interrupts are routed to SPMC when running a secure partition
execution context.
+ - All endpoints with multiple execution contexts have their contexts pinned
+ to corresponding CPUs. Hence, a secure virtual interrupt cannot be signaled
+ to a target vCPU that is currently running or blocked on a different
+ physical CPU.
-A physical secure interrupt could preempt normal world execution. Moreover, when
-the execution is in secure world, it is highly likely that the target of a
-secure interrupt is not the currently running execution context of an SP. It
-could be targeted to another FF-A component. Consequently, secure interrupt
-management depends on the state of the target execution context of the SP that
-is responsible for handling the interrupt. Hence, the spec provides guidance on
-how to signal start and completion of secure interrupt handling as discussed in
-further sections.
+A physical secure interrupt could trigger while CPU is executing in normal world
+or secure world.
+The action of SPMC for a secure interrupt depends on: the state of the target
+execution context of the SP that is responsible for handling the interrupt;
+whether the interrupt triggered while execution was in normal world or secure
+world.
Secure interrupt signaling mechanisms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1100,47 +1201,46 @@
- ``FFA_MSG_WAIT`` ABI if it was in WAITING state.
- ``FFA_RUN`` ABI if its was in BLOCKED state.
-In the current implementation, S-EL1 SPs use para-virtualized HVC interface
-implemented by SPMC to perform priority drop and interrupt deactivation (we
-assume EOImode = 0, i.e. priority drop and deactivation are done together).
+This is a remnant of SPMC implementation based on the FF-A v1.0 specification.
+In the current implementation, S-EL1 SPs use the para-virtualized HVC interface
+implemented by SPMC to perform priority drop and interrupt deactivation (SPMC
+configures EOImode = 0, i.e. priority drop and deactivation are done together).
+The SPMC performs checks to deny the state transition upon invocation of
+either FFA_MSG_WAIT or FFA_RUN interface if the SP didn't perform the
+deactivation of the secure virtual interrupt.
-If normal world execution was preempted by secure interrupt, SPMC uses
-FFA_NORMAL_WORLD_RESUME ABI to indicate completion of secure interrupt handling
-and further return execution to normal world. If the current SP execution
-context was preempted by a secure interrupt to be handled by execution context
-of target SP, SPMC resumes current SP after signal completion by target SP
-execution context.
+If the current SP execution context was preempted by a secure interrupt to be
+handled by execution context of target SP, SPMC resumes current SP after signal
+completion by target SP execution context.
-An action is broadly a set of steps taken by the SPMC in response to a physical
-interrupt. In order to simplify the design, the current version of secure
-interrupt management support in SPMC (Hafnium) does not fully implement the
-Scheduling models and Partition runtime models. However, the current
-implementation loosely maps to the following actions that are legally allowed
-by the specification. Please refer to the Table 8.4 in the spec for further
-description of actions. The action specified for a type of interrupt when the
-SP is in the message processing running state cannot be less permissive than the
-action specified for the same type of interrupt when the SP is in the interrupt
-handling running state.
+Actions for a secure interrupt triggered while execution is in normal world
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-+--------------------+--------------------+------------+-------------+
-| Runtime Model | NS-Int | Self S-Int | Other S-Int |
-+--------------------+--------------------+------------+-------------+
-| Message Processing | Signalable with ME | Signalable | Signalable |
-+--------------------+--------------------+------------+-------------+
-| Interrupt Handling | Queued | Queued | Queued |
-+--------------------+--------------------+------------+-------------+
++-------------------+----------+-----------------------------------------------+
+| State of target | Action | Description |
+| execution context | | |
++-------------------+----------+-----------------------------------------------+
+| WAITING | Signaled | This starts a new call chain in SPMC scheduled|
+| | | mode. |
++-------------------+----------+-----------------------------------------------+
+| PREEMPTED | Queued | The target execution must have been preempted |
+| | | by a non-secure interrupt. SPMC queues the |
+| | | secure virtual interrupt now. It is signaled |
+| | | when the target execution context next enters |
+| | | the RUNNING state. |
++-------------------+----------+-----------------------------------------------+
+| BLOCKED, RUNNING | NA | The target execution context is blocked or |
+| | | running on a different CPU. This is not |
+| | | supported by current SPMC implementation and |
+| | | execution hits panic. |
++-------------------+----------+-----------------------------------------------+
-Abbreviations:
-
- - NS-Int: A Non-secure physical interrupt. It requires a switch to the Normal
- world to be handled.
- - Other S-Int: A secure physical interrupt targeted to an SP different from
- the one that is currently running.
- - Self S-Int: A secure physical interrupt targeted to the SP that is currently
- running.
+If normal world execution was preempted by a secure interrupt, SPMC uses
+FFA_NORMAL_WORLD_RESUME ABI to indicate completion of secure interrupt handling
+and further returns execution to normal world.
-The following figure describes interrupt handling flow when secure interrupt
-triggers while in normal world:
+The following figure describes interrupt handling flow when a secure interrupt
+triggers while execution is in normal world:
.. image:: ../resources/diagrams/ffa-secure-interrupt-handling-nwd.png
@@ -1151,40 +1251,78 @@
- 3) SPMD signals secure interrupt to SPMC at S-EL2 using FFA_INTERRUPT ABI.
- 4) SPMC identifies target vCPU of SP and injects virtual interrupt (pends
vIRQ).
- - 5) Since SP1 vCPU is in WAITING state, SPMC signals using FFA_INTERRUPT with
- interrupt id as argument and resume it using ERET.
- - 6) Execution traps to vIRQ handler in SP1 provided that interrupt is not
- masked i.e., PSTATE.I = 0
- - 7) SP1 services the interrupt and invokes the de-activation HVC call.
- - 8) SPMC does internal state management and further de-activates the physical
- interrupt and resumes SP vCPU.
- - 9) SP performs secure interrupt completion through FFA_MSG_WAIT ABI.
+ - 5) Assuming SP1 vCPU is in WAITING state, SPMC signals virtual interrupt
+ using FFA_INTERRUPT with interrupt id as an argument and resumes the SP1
+ vCPU using ERET in SPMC scheduled mode.
+ - 6) Execution traps to vIRQ handler in SP1 provided that the virtual
+ interrupt is not masked i.e., PSTATE.I = 0
+ - 7) SP1 queries for the pending virtual interrupt id using a paravirtualized
+ HVC call. SPMC clears the pending virtual interrupt state management
+ and returns the pending virtual interrupt id.
+ - 8) SP1 services the virtual interrupt and invokes the paravirtualized
+ de-activation HVC call. SPMC de-activates the physical interrupt,
+ clears the fields tracking the secure interrupt and resumes SP1 vCPU.
+ - 9) SP1 performs secure interrupt completion through FFA_MSG_WAIT ABI.
- 10) SPMC returns control to EL3 using FFA_NORMAL_WORLD_RESUME.
- 11) EL3 resumes normal world execution.
-The following figure describes interrupt handling flow when secure interrupt
-triggers while in secure world:
+Actions for a secure interrupt triggered while execution is in secure world
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
++-------------------+----------+------------------------------------------------+
+| State of target | Action | Description |
+| execution context | | |
++-------------------+----------+------------------------------------------------+
+| WAITING | Signaled | This starts a new call chain in SPMC scheduled |
+| | | mode. |
++-------------------+----------+------------------------------------------------+
+| PREEMPTED by Self | Signaled | The target execution context reenters the |
+| S-Int | | RUNNING state to handle the secure virtual |
+| | | interrupt. |
++-------------------+----------+------------------------------------------------+
+| PREEMPTED by | Queued | SPMC queues the secure virtual interrupt now. |
+| NS-Int | | It is signaled when the target execution |
+| | | context next enters the RUNNING state. |
++-------------------+----------+------------------------------------------------+
+| BLOCKED | Signaled | Both preempted and target execution contexts |
+| | | must have been part of the Normal world |
+| | | scheduled call chain. Refer scenario 1 of |
+| | | Table 8.4 in the FF-A v1.1 EAC0 spec. |
++-------------------+----------+------------------------------------------------+
+| RUNNING | NA | The target execution context is running on a |
+| | | different CPU. This scenario is not supported |
+| | | by current SPMC implementation and execution |
+| | | hits panic. |
++-------------------+----------+------------------------------------------------+
+
+The following figure describes interrupt handling flow when a secure interrupt
+triggers while execution is in secure world. We assume OS kernel sends a direct
+request message to SP1. Further, SP1 sends a direct request message to SP2. SP1
+enters BLOCKED state and SPMC resumes SP2.
.. image:: ../resources/diagrams/ffa-secure-interrupt-handling-swd.png
A brief description of the events:
- - 1) Secure interrupt triggers while SP2 is running and SP1 is blocked.
- - 2) Gets trapped to SPMC as IRQ.
+ - 1) Secure interrupt triggers while SP2 is running.
+ - 2) SP2 gets preempted and execution traps to SPMC as IRQ.
- 3) SPMC finds the target vCPU of secure partition responsible for handling
this secure interrupt. In this scenario, it is SP1.
- 4) SPMC pends vIRQ for SP1 and signals through FFA_INTERRUPT interface.
- SPMC further resumes SP1 through ERET conduit.
- - 5) Execution traps to vIRQ handler in SP1 provided that interrupt is not
- masked i.e., PSTATE.I = 0
- - 6) SP1 services the secure interrupt and invokes the de-activation HVC call.
- - 7) SPMC does internal state management, de-activates the physical interrupt
- and resumes SP1 vCPU.
- - 8) Assuming SP1 is in BLOCKED state, SP1 performs secure interrupt completion
- through FFA_RUN ABI.
+ SPMC further resumes SP1 through ERET conduit. Note that SP1 remains in
+ Normal world schedule mode.
+ - 6) Execution traps to vIRQ handler in SP1 provided that the virtual
+ interrupt is not masked i.e., PSTATE.I = 0
+ - 7) SP1 queries for the pending virtual interrupt id using a paravirtualized
+ HVC call. SPMC clears the pending virtual interrupt state management
+ and returns the pending virtual interrupt id.
+ - 8) SP1 services the virtual interrupt and invokes the paravirtualized
+ de-activation HVC call. SPMC de-activates the physical interrupt and
+ clears the fields tracking the secure interrupt and resumes SP1 vCPU.
+ - 9) Since SP1 direct request completed with FFA_INTERRUPT, it resumes the
+ direct request to SP2 by invoking FFA_RUN.
- 9) SPMC resumes the pre-empted vCPU of SP2.
-
Power management
----------------
@@ -1374,13 +1512,13 @@
capable of migrating, and the SPMC enforces this requirement. The SPMC allows
a S-EL0 partition to accept a direct message from secure world and normal world,
and generate direct responses to them.
+All S-EL0 partitions must use AArch64. AArch32 S-EL0 partitions are not supported.
-Memory sharing between and with S-EL0 partitions is supported.
-Indirect messaging, Interrupt handling and Notifications are not supported with
-S-EL0 partitions and is work in progress, planned for future releases.
-All S-EL0 partitions must use AArch64. AArch32 S-EL0 partitions are not
-supported.
+Memory sharing, indirect messaging, and notifications functionality with S-EL0
+partitions is supported.
+Interrupt handling is not supported with S-EL0 partitions and is work in
+progress.
References
==========
diff --git a/docs/conf.py b/docs/conf.py
index ef77f6b..371632a 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -36,12 +36,13 @@
#
# This is also used if you do content translation via gettext catalogs.
# Usually you set "language" from the command line for these cases.
-language = None
+language = "en"
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
# This pattern also affects html_static_path and html_extra_path .
-exclude_patterns = []
+# Don't try to build the venv in case it's placed with the sources
+exclude_patterns = [".env", "env", ".venv", "venv"]
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
diff --git a/docs/design/index.rst b/docs/design/index.rst
index e3b8f74..17ef756 100644
--- a/docs/design/index.rst
+++ b/docs/design/index.rst
@@ -4,7 +4,6 @@
.. toctree::
:maxdepth: 1
:caption: Contents
- :numbered:
alt-boot-flows
auth-framework
diff --git a/docs/design_documents/index.rst b/docs/design_documents/index.rst
index 765efe6..3e20c07 100644
--- a/docs/design_documents/index.rst
+++ b/docs/design_documents/index.rst
@@ -4,7 +4,6 @@
.. toctree::
:maxdepth: 1
:caption: Contents
- :numbered:
cmake_framework
context_mgmt_rework
diff --git a/docs/getting_started/docs-build.rst b/docs/getting_started/docs-build.rst
index 87c677f..4a48059 100644
--- a/docs/getting_started/docs-build.rst
+++ b/docs/getting_started/docs-build.rst
@@ -17,22 +17,28 @@
Prerequisites
-------------
-For building a local copy of the |TF-A| documentation you will need, at minimum:
+For building a local copy of the |TF-A| documentation you will need:
- Python 3 (3.5 or later)
- PlantUML (1.2017.15 or later)
+- Python modules specified in ``docs/requirements.txt``
-Optionally, the `Dia`_ application can be installed if you need to edit
-existing ``.dia`` diagram files, or create new ones.
+ You can install these with ``pip3`` (the Python Package Installer) by
+ passing it the requirements file above (with ``-r``). An optional ``--user``
+ argument will install them locally, but you have to add their location to
+ $PATH (pip will emit a warning). Alternatively, they can be installed
+ globally (but will probably require root privileges).
-You must also install the Python modules that are specified in the
-``requirements.txt`` file in the root of the ``docs`` directory. These modules
-can be installed using ``pip3`` (the Python Package Installer). Passing this
-requirements file as an argument to ``pip3`` automatically installs the specific
-module versions required by |TF-A|.
+ .. note::
+ Although not necessary, it is recommended you use a virtual environment.
+ More advanced usage instructions for *pip* are beyond the scope of this
+ document but you can refer to the `pip homepage`_ for detailed guides.
-An example set of installation commands for Ubuntu 18.04 LTS follows, assuming
-that the working directory is ``docs``:
+- Optionally, the `Dia`_ application can be installed if you need to edit
+ existing ``.dia`` diagram files, or create new ones.
+
+An example set of installation commands for Ubuntu follows, assuming that the
+working directory is ``docs``:
.. code:: shell
@@ -44,15 +50,6 @@
the list to ensure that there will be no conflicts with other modules already
installed in your environment.
-Passing the optional ``--user`` argument to ``pip3`` will install the Python
-packages only for the current user. Omitting this argument will attempt to
-install the packages globally and this will likely require the command to be run
-as root or using ``sudo``.
-
-.. note::
- More advanced usage instructions for *pip* are beyond the scope of this
- document but you can refer to the `pip homepage`_ for detailed guides.
-
Building rendered documentation
-------------------------------
diff --git a/docs/getting_started/image-terminology.rst b/docs/getting_started/image-terminology.rst
index a90ec0b..66f47e8 100644
--- a/docs/getting_started/image-terminology.rst
+++ b/docs/getting_started/image-terminology.rst
@@ -4,8 +4,8 @@
This page contains the current name, abbreviated name and purpose of the various
images referred to in the Trusted Firmware project.
-General Notes
--------------
+Common Image Features
+---------------------
- Some of the names and abbreviated names have changed to accommodate new
requirements. The changed names are as backward compatible as possible to
@@ -40,6 +40,15 @@
Trusted Firmware Images
-----------------------
+Firmware Image Package: ``FIP``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is a packaging format used by TF-A to package firmware images in a single
+binary. The number and type of images that should be packed in a FIP is
+platform-specific and may include TF-A images and other firmware images
+required by the platform. For example, most platforms require a BL33 image
+which corresponds to the normal world bootloader (e.g. UEFI or U-Boot).
+
AP Boot ROM: ``AP_BL1``
~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/getting_started/index.rst b/docs/getting_started/index.rst
index 817beaf..3fbf48d 100644
--- a/docs/getting_started/index.rst
+++ b/docs/getting_started/index.rst
@@ -4,12 +4,11 @@
.. toctree::
:maxdepth: 1
:caption: Contents
- :numbered:
prerequisites
docs-build
- tools-build
initial-build
+ tools-build
build-options
image-terminology
porting-guide
diff --git a/docs/getting_started/initial-build.rst b/docs/getting_started/initial-build.rst
index 62f1941..4f41be4 100644
--- a/docs/getting_started/initial-build.rst
+++ b/docs/getting_started/initial-build.rst
@@ -2,7 +2,7 @@
===========================
- Before building TF-A, the environment variable ``CROSS_COMPILE`` must point
- to the Linaro cross compiler.
+ to your cross compiler.
For AArch64:
diff --git a/docs/getting_started/prerequisites.rst b/docs/getting_started/prerequisites.rst
index 62ef826..3723294 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 16.04 LTS (64-bit) but other distributions
+have performed tests using Ubuntu 20.04 LTS (64-bit) but other distributions
should also work fine as a base, provided that the necessary tools and libraries
can be installed.
@@ -27,6 +27,10 @@
target the Armv7-A or Armv8-A architectures:
- GCC >= 11.3.Rel1 (from the `Arm Developer website`_)
+
+ You will need the targets ``arm-none-eabi`` and ``aarch64-none-elf`` for
+ AArch32 and AArch64 builds respectively.
+
- Clang >= 14.0.0
- Arm Compiler >= 6.18
diff --git a/docs/getting_started/tools-build.rst b/docs/getting_started/tools-build.rst
index daf7e06..166b527 100644
--- a/docs/getting_started/tools-build.rst
+++ b/docs/getting_started/tools-build.rst
@@ -14,12 +14,11 @@
Building and using the FIP tool
-------------------------------
-Firmware Image Package (FIP) is a packaging format used by TF-A to package
-firmware images in a single binary. The number and type of images that should
-be packed in a FIP is platform specific and may include TF-A images and other
-firmware images required by the platform. For example, most platforms require
-a BL33 image which corresponds to the normal world bootloader (e.g. UEFI or
-U-Boot).
+The following snippets build a :ref:`FIP<Image Terminology>` for the FVP
+platform. While it is not an intrinsic part of the FIP format, a BL33 image is
+required for these examples. For the purposes of experimentation, `Trusted
+Firmware-A Tests`_ (`tftf.bin``) may be used. Refer to to the `TFTF
+documentation`_ for instructions on building a TFTF binary.
The TF-A build system provides the make target ``fip`` to create a FIP file
for the specified platform using the FIP creation tool included in the TF-A
@@ -175,3 +174,6 @@
--------------
*Copyright (c) 2019-2022, Arm Limited. All rights reserved.*
+
+.. _Trusted Firmware-A Tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/
+.. _TFTF documentation: https://trustedfirmware-a-tests.readthedocs.io/en/latest/
diff --git a/docs/index.rst b/docs/index.rst
index edc2535..3860199 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -3,7 +3,7 @@
.. toctree::
:maxdepth: 1
- :hidden:
+ :numbered:
Home<self>
about/index
diff --git a/docs/perf/index.rst b/docs/perf/index.rst
index 1482b80..bccad00 100644
--- a/docs/perf/index.rst
+++ b/docs/perf/index.rst
@@ -4,7 +4,6 @@
.. toctree::
:maxdepth: 1
:caption: Contents
- :numbered:
psci-performance-juno
tsp
diff --git a/docs/plat/index.rst b/docs/plat/index.rst
index 3eac6f7..a4e2067 100644
--- a/docs/plat/index.rst
+++ b/docs/plat/index.rst
@@ -4,7 +4,6 @@
.. toctree::
:maxdepth: 1
:caption: Contents
- :numbered:
:hidden:
allwinner
diff --git a/docs/plat/marvell/armada/build.rst b/docs/plat/marvell/armada/build.rst
index ff7b573..8cb3fdf 100644
--- a/docs/plat/marvell/armada/build.rst
+++ b/docs/plat/marvell/armada/build.rst
@@ -26,7 +26,7 @@
*u-boot.bin* should be used and not *u-boot-spl.bin*
-Set MSS/SCP image path (mandatory only for A7K/8K/CN913x when MSS_SUPPORT=1)
+Set MSS/SCP image path (mandatory only for A7K/A8K/CN913x when MSS_SUPPORT=1)
.. code:: shell
@@ -109,7 +109,7 @@
- MV_DDR_PATH
This parameter is required for ``mrvl_flash`` and ``mrvl_uart`` targets.
- For A7K/8K/CN913x it is used for BLE build and for Armada37x0 it used
+ For A7K/A8K/CN913x it is used for BLE build and for Armada37x0 it used
for ddr_tool build.
Specify path to the full checkout of Marvell mv-ddr-marvell git
@@ -131,7 +131,7 @@
values with CP_NUM are in a range of 1 to 3.
-A7K/8K/CN913x specific build options:
+A7K/A8K/CN913x specific build options:
- BLE_PATH
@@ -387,7 +387,7 @@
- PLAT_RECOVERY_IMAGE_ENABLE
When set this option to enable secondary recovery function when build atf.
In order to build UART recovery image this operation should be disabled for
- A7K/8K/CN913x because of hardware limitation (boot from secondary image
+ A7K/A8K/CN913x because of hardware limitation (boot from secondary image
can interrupt UART recovery process). This MACRO definition is set in
``plat/marvell/armada/a8k/common/include/platform_def.h`` file.
diff --git a/docs/plat/marvell/armada/uart-booting.rst b/docs/plat/marvell/armada/uart-booting.rst
index 06601d1..04ce464 100644
--- a/docs/plat/marvell/armada/uart-booting.rst
+++ b/docs/plat/marvell/armada/uart-booting.rst
@@ -79,10 +79,10 @@
bootrom during transferring of image files. This mini terminal can be quit by CTRL-\\ + C keypress.
-A7K/8K/CN913x UART image downloading
-------------------------------------
+A7K/A8K/CN913x UART image downloading
+-------------------------------------
-A7K/8K/CN913x uses same image ``flash-image.bin`` for both flashing and booting over UART.
+A7K/A8K/CN913x uses same image ``flash-image.bin`` for both flashing and booting over UART.
For downloading image over UART it is possible to use mvebu64boot tool.
Compilation:
diff --git a/docs/process/index.rst b/docs/process/index.rst
index 422ab28..7914a4e 100644
--- a/docs/process/index.rst
+++ b/docs/process/index.rst
@@ -4,7 +4,6 @@
.. toctree::
:maxdepth: 1
:caption: Contents
- :numbered:
security
platform-ports-policy
diff --git a/docs/security_advisories/index.rst b/docs/security_advisories/index.rst
index 887b06a..b80ba34 100644
--- a/docs/security_advisories/index.rst
+++ b/docs/security_advisories/index.rst
@@ -4,7 +4,6 @@
.. toctree::
:maxdepth: 1
:caption: Contents
- :numbered:
security-advisory-tfv-1.rst
security-advisory-tfv-2.rst
diff --git a/docs/threat_model/index.rst b/docs/threat_model/index.rst
index 9d84f5b..ad8b82a 100644
--- a/docs/threat_model/index.rst
+++ b/docs/threat_model/index.rst
@@ -11,7 +11,6 @@
.. toctree::
:maxdepth: 1
:caption: Contents
- :numbered:
threat_model
threat_model_spm
diff --git a/plat/xilinx/common/include/pm_ipi.h b/plat/xilinx/common/include/pm_ipi.h
index 8a15668..52dfc47 100644
--- a/plat/xilinx/common/include/pm_ipi.h
+++ b/plat/xilinx/common/include/pm_ipi.h
@@ -16,7 +16,7 @@
#define IPI_BLOCKING 1
#define IPI_NON_BLOCKING 0
-int32_t pm_ipi_init(const struct pm_proc *proc);
+void pm_ipi_init(const struct pm_proc *proc);
enum pm_ret_status pm_ipi_send(const struct pm_proc *proc,
uint32_t payload[PAYLOAD_ARG_CNT]);
diff --git a/plat/xilinx/common/pm_service/pm_ipi.c b/plat/xilinx/common/pm_service/pm_ipi.c
index a0403cf..513d6be 100644
--- a/plat/xilinx/common/pm_service/pm_ipi.c
+++ b/plat/xilinx/common/pm_service/pm_ipi.c
@@ -19,6 +19,7 @@
#include "pm_ipi.h"
#define ERROR_CODE_MASK (0xFFFFU)
+#define PM_OFFSET (0U)
DEFINE_BAKERY_LOCK(pm_secure_lock);
@@ -33,12 +34,10 @@
*
* Called from pm_setup initialization function
*/
-int32_t pm_ipi_init(const struct pm_proc *proc)
+void pm_ipi_init(const struct pm_proc *proc)
{
bakery_lock_init(&pm_secure_lock);
ipi_mb_open(proc->ipi->local_ipi_id, proc->ipi->remote_ipi_id);
-
- return 0;
}
/**
@@ -55,7 +54,7 @@
uint32_t payload[PAYLOAD_ARG_CNT],
uint32_t is_blocking)
{
- unsigned int offset = 0;
+ uint32_t offset = PM_OFFSET;
uintptr_t buffer_base = proc->ipi->buffer_base +
IPI_BUFFER_TARGET_REMOTE_OFFSET +
IPI_BUFFER_REQ_OFFSET;
@@ -185,7 +184,7 @@
size_t i;
#if IPI_CRC_CHECK
size_t j;
- unsigned int response_payload[PAYLOAD_ARG_CNT];
+ unsigned int response_payload[PAYLOAD_ARG_CNT] = {0};
#endif
uintptr_t buffer_base = IPI_BUFFER_REMOTE_BASE +
IPI_BUFFER_TARGET_LOCAL_OFFSET +
diff --git a/plat/xilinx/versal/pm_service/pm_svc_main.c b/plat/xilinx/versal/pm_service/pm_svc_main.c
index 48888e4..9eb426a 100644
--- a/plat/xilinx/versal/pm_service/pm_svc_main.c
+++ b/plat/xilinx/versal/pm_service/pm_svc_main.c
@@ -119,16 +119,10 @@
*/
int32_t pm_setup(void)
{
- int32_t status, ret = 0;
-
- status = pm_ipi_init(primary_proc);
+ int32_t ret = 0;
- if (status < 0) {
- INFO("BL31: PM Service Init Failed, Error Code %d!\n", status);
- ret = status;
- } else {
- pm_up = true;
- }
+ pm_ipi_init(primary_proc);
+ pm_up = true;
/*
* Enable IPI IRQ
diff --git a/plat/xilinx/zynqmp/include/plat_ipi.h b/plat/xilinx/zynqmp/include/plat_ipi.h
index bccd2f1..a78f93a 100644
--- a/plat/xilinx/zynqmp/include/plat_ipi.h
+++ b/plat/xilinx/zynqmp/include/plat_ipi.h
@@ -41,7 +41,7 @@
#define IPI_BUFFER_TARGET_LOCAL_OFFSET 0x80U
#define IPI_BUFFER_TARGET_REMOTE_OFFSET 0x1C0U
-#define IPI_BUFFER_MAX_WORDS 8
+#define IPI_BUFFER_MAX_WORDS 8U
#define IPI_BUFFER_REQ_OFFSET 0x0U
#define IPI_BUFFER_RESP_OFFSET 0x20U
diff --git a/plat/xilinx/zynqmp/pm_service/pm_client.c b/plat/xilinx/zynqmp/pm_service/pm_client.c
index a853e38..7217fa1 100644
--- a/plat/xilinx/zynqmp/pm_service/pm_client.c
+++ b/plat/xilinx/zynqmp/pm_service/pm_client.c
@@ -176,7 +176,7 @@
static void pm_client_set_wakeup_sources(void)
{
uint32_t reg_num;
- uint8_t pm_wakeup_nodes_set[NODE_MAX];
+ uint8_t pm_wakeup_nodes_set[NODE_MAX] = { 0 };
uintptr_t isenabler1 = BASE_GICD_BASE + GICD_ISENABLER + 4U;
/* In case of power-off suspend, only NODE_EXTERN must be set */
diff --git a/plat/xilinx/zynqmp/pm_service/pm_svc_main.c b/plat/xilinx/zynqmp/pm_service/pm_svc_main.c
index b91878e..03fa316 100644
--- a/plat/xilinx/zynqmp/pm_service/pm_svc_main.c
+++ b/plat/xilinx/zynqmp/pm_service/pm_svc_main.c
@@ -207,11 +207,10 @@
*/
int32_t pm_setup(void)
{
- int32_t status, ret;
- status = pm_ipi_init(primary_proc);
+ pm_ipi_init(primary_proc);
- ret = pm_get_api_version(&pm_ctx.api_version);
+ pm_get_api_version(&pm_ctx.api_version);
if (pm_ctx.api_version < PM_VERSION) {
ERROR("BL31: Platform Management API version error. Expected: "
"v%d.%d - Found: v%d.%d\n", PM_VERSION_MAJOR,
@@ -220,6 +219,7 @@
return -EINVAL;
}
+ int32_t status = 0, ret = 0;
#if ZYNQMP_WDT_RESTART
status = pm_wdt_restart_setup();
if (status)
@@ -263,7 +263,7 @@
uint32_t payload[PAYLOAD_ARG_CNT];
uint32_t pm_arg[5];
- uint32_t result[PAYLOAD_ARG_CNT];
+ uint32_t result[PAYLOAD_ARG_CNT] = {0};
uint32_t api_id;
/* Handle case where PM wasn't initialized properly */
@@ -350,7 +350,7 @@
case PM_FPGA_GET_STATUS:
{
- uint32_t value;
+ uint32_t value = 0;
ret = pm_fpga_get_status(&value);
SMC_RET1(handle, (uint64_t)ret | ((uint64_t)value) << 32);
@@ -368,7 +368,7 @@
(uint64_t)result[2] | ((uint64_t)result[3] << 32));
case PM_IOCTL:
{
- uint32_t value;
+ uint32_t value = 0;
ret = pm_ioctl(pm_arg[0], pm_arg[1], pm_arg[2],
pm_arg[3], &value);
@@ -395,7 +395,7 @@
case PM_CLOCK_GETSTATE:
{
- uint32_t value;
+ uint32_t value = 0;
ret = pm_clock_getstate(pm_arg[0], &value);
SMC_RET1(handle, (uint64_t)ret | ((uint64_t)value) << 32);
@@ -407,7 +407,7 @@
case PM_CLOCK_GETDIVIDER:
{
- uint32_t value;
+ uint32_t value = 0;
ret = pm_clock_getdivider(pm_arg[0], &value);
SMC_RET1(handle, (uint64_t)ret | ((uint64_t)value) << 32);
@@ -436,7 +436,7 @@
case PM_CLOCK_GETPARENT:
{
- uint32_t value;
+ uint32_t value = 0;
ret = pm_clock_getparent(pm_arg[0], &value);
SMC_RET1(handle, (uint64_t)ret | ((uint64_t)value) << 32U);
@@ -470,7 +470,7 @@
case PM_FPGA_READ:
{
- uint32_t value;
+ uint32_t value = 0;
ret = pm_fpga_read(pm_arg[0], pm_arg[1], pm_arg[2], pm_arg[3],
&value);
@@ -479,7 +479,7 @@
case PM_SECURE_AES:
{
- uint32_t value;
+ uint32_t value = 0;
ret = pm_aes_engine(pm_arg[0], pm_arg[1], &value);
SMC_RET1(handle, (uint64_t)ret | ((uint64_t)value) << 32U);
@@ -491,7 +491,7 @@
case PM_PLL_GET_PARAMETER:
{
- uint32_t value;
+ uint32_t value = 0;
ret = pm_pll_get_parameter(pm_arg[0], pm_arg[1], &value);
SMC_RET1(handle, (uint64_t)ret | ((uint64_t)value << 32U));
@@ -503,7 +503,7 @@
case PM_PLL_GET_MODE:
{
- uint32_t mode;
+ uint32_t mode = 0;
ret = pm_pll_get_mode(pm_arg[0], &mode);
SMC_RET1(handle, (uint64_t)ret | ((uint64_t)mode << 32U));
@@ -511,7 +511,7 @@
case PM_REGISTER_ACCESS:
{
- uint32_t value;
+ uint32_t value = 0;
ret = pm_register_access(pm_arg[0], pm_arg[1], pm_arg[2],
pm_arg[3], &value);
@@ -520,7 +520,7 @@
case PM_EFUSE_ACCESS:
{
- uint32_t value;
+ uint32_t value = 0;
#if defined(ZYNQMP_SECURE_EFUSES)
if (is_caller_non_secure(flags)) {