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)) {