Merge changes from topic "pb/sphinx-doc" into integration

* changes: doc: Use proper note and warning annotations doc: Refactor contributor acknowledgements doc: Reorganise images and update links doc: Set correct syntax highlighting style doc: Add minimal glossary doc: Remove per-page contents lists doc: Make checkpatch ignore rst files doc: Format security advisory titles and headings doc: Reformat platform port documents doc: Normalise section numbering and headings doc: Reword document titles
6 years ago · ced1711297
100 changed files with 756 additions and 565 deletions
--- a/6
+++ b/6
@ -55,7 +55,7 @@ ROOT_DIRS_TO_CHECK	:=	$(sort $(filter-out			\
 					lib				\
 					include				\
 					docs				\
-					%.md,				\
+					%.rst,				\
 					$(wildcard *)))
 CHECK_PATHS		:=	${ROOT_DIRS_TO_CHECK}			\
 				${INC_DIRS_TO_CHECK}			\
@ -815,7 +815,7 @@ realclean distclean:
 checkcodebase:		locate-checkpatch
 	@echo "  CHECKING STYLE"
 	@if test -d .git ; then						\
-		git ls-files | grep -E -v 'libfdt|libc|docs|\.md' |	\
+		git ls-files | grep -E -v 'libfdt|libc|docs|\.rst' |	\
 		while read GIT_FILE ;					\
 		do ${CHECKPATCH} ${CHECKCODE_ARGS} -f $$GIT_FILE ;	\
 		done ;							\
@ -825,7 +825,7 @@ checkcodebase:		locate-checkpatch
 		 -not -iwholename "*libfdt*"				\
 		 -not -iwholename "*libc*"				\
 		 -not -iwholename "*docs*"				\
-		 -not -iwholename "*.md"				\
+		 -not -iwholename "*.rst"				\
 		 -exec ${CHECKPATCH} ${CHECKCODE_ARGS} -f {} \; ;	\
 	fi

--- a/docs/acknowledgements.rst
+++ b/docs/acknowledgements.rst
@ -1,28 +1,17 @@
-**Note: This file is only relevant for legacy contributions, to acknowledge the
-specific contributors referred to in "Arm Limited and Contributors" copyright
-notices. As contributors are now encouraged to put their name or company name
-directly into the copyright notices, this file is not relevant for new
-contributions.**
-
 Contributor Acknowledgements
 ============================

-Companies
---------
-
-Linaro Limited
-
-NVIDIA Corporation
-
-Socionext Inc.
-
-Xilinx, Inc.
-
-NXP Semiconductors
-
-Marvell International Ltd.
-
-STMicroelectronics
-
-Individuals
-----------
+.. note::
+   This file is only relevant for legacy contributions, to acknowledge the
+   specific contributors referred to in "Arm Limited and Contributors" copyright
+   notices. As contributors are now encouraged to put their name or company name
+   directly into the copyright notices, this file is not relevant for new
+   contributions.
+
+- Linaro Limited
+- Marvell International Ltd.
+- NVIDIA Corporation
+- NXP Semiconductors
+- Socionext Inc.
+- STMicroelectronics
+- Xilinx, Inc.
--- a/docs/change-log.rst
+++ b/docs/change-log.rst
@ -1,11 +1,9 @@
-Trusted Firmware-A Release Notes
-================================
+Change Log & Release Notes
+==========================

 This document contains a summary of the new features, changes, fixes and known
 issues in each release of Trusted Firmware-A.

-.. contents::
-
 Version 2.1
 -----------

@ -296,12 +294,12 @@ Changed

 - SDEI
   - Added support for unconditionally resuming secure world execution after
-     SDEI event processing completes
+     |SDEI| event processing completes

-     SDEI interrupts, although targeting EL3, occur on behalf of the non-secure
+     |SDEI| interrupts, although targeting EL3, occur on behalf of the non-secure
     world, and may have higher priority than secure world
     interrupts. Therefore they might preempt secure execution and yield
-     execution to the non-secure SDEI handler. Upon completion of SDEI event
+     execution to the non-secure |SDEI| handler. Upon completion of |SDEI| event
     handling, resume secure execution if it was preempted.

 - Translation Tables (XLAT)
@ -503,7 +501,7 @@ New Features

   -  Implement dynamic mitigation for CVE-2018-3639 on Cortex-A76

-   -  Ensure SDEI handler executes with CVE-2018-3639 mitigation enabled
+   -  Ensure |SDEI| handler executes with CVE-2018-3639 mitigation enabled

 -  Introduce RAS handling on AArch64

@ -623,7 +621,7 @@ New Features

   -  Introduce jump primitives for BL31

-   -  Mask events after CPU wakeup in SDEI dispatcher to conform to the
+   -  Mask events after CPU wakeup in |SDEI| dispatcher to conform to the
      specification

 -  Misc TF-A Core Common Code Enhancements
@ -787,8 +785,8 @@ New features
      management and security services. The SPM is the firmware component that
      is responsible for managing a Secure Partition.

-   -  SDEI dispatcher: Support for interrupt-based SDEI events and all
-      interfaces as defined by the SDEI specification v1.0, see
+   -  SDEI dispatcher: Support for interrupt-based |SDEI| events and all
+      interfaces as defined by the |SDEI| specification v1.0, see
      `SDEI Specification`_

   -  Exception Handling Framework (EHF): Framework that allows dispatching of
@ -1188,7 +1186,8 @@ New features
 -  Migrated to use SPDX[0] license identifiers to make software license
   auditing simpler.

-   *NOTE:* Files that have been imported by FreeBSD have not been modified.
+   .. note::
+      Files that have been imported by FreeBSD have not been modified.

   [0]: https://spdx.org/

@ -2207,7 +2206,8 @@ New features
   be used on the AEMv8 and Cortex-A57-A53 Base FVPs, as well as the Foundation
   FVP.

-   NOTE: The software will not work on Version 1.0 of the Foundation FVP.
+   .. note::
+      The software will not work on Version 1.0 of the Foundation FVP.

 -  Enabled third party contributions. Added a new contributing.md containing
   instructions for how to contribute and updated copyright text in all files
@ -2238,13 +2238,16 @@ New features
   FIP from NOR flash, although some support for image loading using semi-
   hosting is retained.

-   NOTE: Building a FIP by default is a non-backwards-compatible change.
+   .. note::
+      Building a FIP by default is a non-backwards-compatible change.

-   NOTE: Generic BL2 code now loads a BL3-3 (non-trusted firmware) image into
+   .. note::
+      Generic BL2 code now loads a BL3-3 (non-trusted firmware) image into
      DRAM instead of expecting this to be pre-loaded at known location. This is
      also a non-backwards-compatible change.

-   NOTE: Some non-trusted firmware (e.g. UEFI) will need to be rebuilt so that
+   .. note::
+      Some non-trusted firmware (e.g. UEFI) will need to be rebuilt so that
      it knows the new location to execute from and no longer needs to copy
      particular code modules to DRAM itself.

@ -2272,8 +2275,11 @@ New features
   Dispatcher (TSPD), which is loaded as an EL3 runtime service. The TSPD
   implements Secure Monitor functionality such as world switching and
   EL1 context management, and is responsible for communication with the TSP.
-   NOTE: The TSPD does not yet contain support for secure world interrupts.
-   NOTE: The TSP/TSPD is not built by default.
+
+   .. note::
+      The TSPD does not yet contain support for secure world interrupts.
+   .. note::
+      The TSP/TSPD is not built by default.

 Issues resolved since last release
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--- a/docs/components/arm-sip-service.rst
+++ b/docs/components/arm-sip-service.rst
@ -1,5 +1,5 @@
-Arm SiP Service
-===============
+Arm SiP Services
+================

 This document enumerates and describes the Arm SiP (Silicon Provider) services.

--- a/docs/components/exception-handling.rst
+++ b/docs/components/exception-handling.rst
@ -1,14 +1,5 @@
-Exception Handling Framework in Trusted Firmware-A
-==================================================
-
-
-
-
-.. contents::
-    :depth: 2
-
-.. |EHF| replace:: Exception Handling Framework
-.. |TF-A| replace:: Trusted Firmware-A
+Exception Handling Framework
+============================

 This document describes various aspects of handling exceptions by Runtime
 Firmware (BL31) that are targeted at EL3, other than SMCs. The |EHF| takes care
@ -54,11 +45,11 @@ exceptions are targeted at and handled in EL3. For instance:

 -  The Arm `SDEI specification`_ defines interfaces through which Normal world
   interacts with the Runtime Firmware in order to request notification of
-   system events. The SDEI specification requires that these events are notified
-   even when the Normal world executes with the exceptions masked. This too
-   implies that firmware-first handling is required, where the events are first
-   received by the EL3 firmware, and then dispatched to Normal world through
-   purely software mechanism.
+   system events. The |SDEI| specification requires that these events are
+   notified even when the Normal world executes with the exceptions masked. This
+   too implies that firmware-first handling is required, where the events are
+   first received by the EL3 firmware, and then dispatched to Normal world
+   through purely software mechanism.

 For |TF-A|, firmware-first handling means that asynchronous exceptions are
 suitably routed to EL3, and the Runtime Firmware (BL31) is extended to include
@ -79,8 +70,8 @@ choose to:
   processing of the error to dedicated software stack running at lower secure
   ELs (as above); additionally, the Normal world may also be required to
   participate in the handling, or be notified of such events (for example, as
-   an SDEI event). In this scheme, exception handling potentially and maximally
-   spans all ELs in both Secure and Normal worlds.
+   an |SDEI| event). In this scheme, exception handling potentially and
+   maximally spans all ELs in both Secure and Normal worlds.

 On any given system, all of the above handling models may be employed
 independently depending on platform choice and the nature of the exception
@ -116,7 +107,7 @@ for more than one priority level.

 .. _ehf-figure:

-.. image:: ../draw.io/ehf.svg
+.. image:: ../resources/diagrams/draw.io/ehf.svg

 A priority level is *active* when a handler at that priority level is currently
 executing in EL3, or has delegated the execution to a lower EL. For interrupts,
@ -202,7 +193,7 @@ priority assignment:
   6 and 5), the platform can partition into 4 secure priority ranges: ``0x0``,
   ``0x20``, ``0x40``, and ``0x60``. See `Interrupt handling example`_.

-Note:
+.. note::

   The Arm GIC architecture requires that a GIC implementation that supports two
   security states must implement at least 32 priority levels; i.e., at least 5
@ -224,7 +215,7 @@ priority level descriptors. Each entry in the array is of type
 ``ehf_pri_desc_t``, and declares a priority level, and shall be populated by the
 ``EHF_PRI_DESC()`` macro.

-Note:
+.. warning::

   The macro ``EHF_PRI_DESC()`` installs the descriptors in the array at a
   computed index, and not necessarily where the macro is placed in the array.
@ -609,8 +600,8 @@ should carefully consider the assignment of priorities to dispatchers integrated
 into runtime firmware. The platform should sensibly delineate priority to
 various dispatchers according to their nature. In particular, dispatchers of
 critical nature (RAS, for example) should be assigned higher priority than
-others (SDEI, for example); and within SDEI, Critical priority SDEI should be
-assigned higher priority than Normal ones.
+others (|SDEI|, for example); and within |SDEI|, Critical priority
+|SDEI| should be assigned higher priority than Normal ones.

 Limitations
 -----------
--- a/docs/components/firmware-update.rst
+++ b/docs/components/firmware-update.rst
@ -1,12 +1,5 @@
-Trusted Firmware-A - Firmware Update design guide
-=================================================
-
-
-
-
-.. contents::
-
--------------
+Firmware Update (FWU)
+=====================

 Introduction
 ------------
@ -407,5 +400,5 @@ This is only allowed if the image is not being executed.
 .. _Authentication Framework Design: ./auth-framework.rst
 .. _Universally Unique Identifier: https://tools.ietf.org/rfc/rfc4122.txt

-.. |Flow Diagram| image:: diagrams/fwu_flow.png?raw=true
-.. |FWU state machine| image:: diagrams/fwu_states.png?raw=true
+.. |Flow Diagram| image:: ../resources/diagrams/fwu_flow.png
+.. |FWU state machine| image:: ../resources/diagrams/fwu_states.png
--- a/docs/components/platform-interrupt-controller-API.rst
+++ b/docs/components/platform-interrupt-controller-API.rst
@ -1,9 +1,5 @@
-Platform Interrupt Controller API documentation
-===============================================
-
-
-
-.. contents::
+Platform Interrupt Controller API
+=================================

 This document lists the optional platform interrupt controller API that
 abstracts the runtime configuration and control of interrupt controller from the
--- a/docs/components/ras.rst
+++ b/docs/components/ras.rst
@ -1,10 +1,5 @@
-RAS support in Trusted Firmware-A
-=================================
-
-
-
-.. contents::
-    :depth: 2
+Reliability, Availability, and Serviceability (RAS) Extensions
+==============================================================

 .. |EHF| replace:: Exception Handling Framework
 .. |TF-A| replace:: Trusted Firmware-A
@ -44,7 +39,7 @@ be set ``1``.

 .. _ras-figure:

-.. image:: ../draw.io/ras.svg
+.. image:: ../resources/diagrams/draw.io/ras.svg

 See more on `Engaging the RAS framework`_.

--- a/docs/components/romlib-design.rst
+++ b/docs/components/romlib-design.rst
@ -1,11 +1,6 @@
 Library at ROM
 ==============

-.. section-numbering::
-    :suffix: .
-
-.. contents::
-
 This document provides an overview of the "library at ROM" implementation in
 Trusted Firmware-A (TF-A).

@ -28,7 +23,7 @@ are placed in ROM. The capabilities of the "library at ROM" are:
 Index file
 ~~~~~~~~~~

-.. image:: diagrams/romlib_design.png
+.. image:: ../resources/diagrams/romlib_design.png
    :width: 600

 Library at ROM is described by an index file with the list of functions to be
@ -59,7 +54,7 @@ For an index file example, refer to ``lib/romlib/jmptbl.i``.
 Wrapper functions
 ~~~~~~~~~~~~~~~~~

-.. image:: diagrams/romlib_wrapper.png
+.. image:: ../resources/diagrams/romlib_wrapper.png
    :width: 600

 When invoking a function of the "library at ROM", the calling sequence is as
@ -111,7 +106,7 @@ The environment variable ``CROSS_COMPILE`` must be set as per the user guide.
 In the below example the usage of ROMLIB together with mbed TLS is demonstrated
 to showcase the benefits of library at ROM - it's not mandatory.

-::
+.. code:: shell

    make PLAT=fvp                                                   \
    MBEDTLS_DIR=</path/to/mbedtls/>                                 \
--- a/docs/components/sdei.rst
+++ b/docs/components/sdei.rst
@ -1,9 +1,6 @@
 SDEI: Software Delegated Exception Interface
 ============================================

-.. contents::
-    :depth: 2
-
 This document provides an overview of the SDEI dispatcher implementation in
 Trusted Firmware-A (TF-A).

@ -29,7 +26,7 @@ The following figure depicts a general sequence involving SDEI client executing
 at EL2 and an event dispatch resulting from the triggering of a bound interrupt.
 A commentary is provided below:

-.. image:: ../plantuml/sdei_general.svg
+.. image:: ../resources/diagrams/plantuml/sdei_general.svg

 As part of initialisation, the SDEI client binds a Non-secure interrupt [1], and
 the SDEI dispatcher returns a platform dynamic event number [2]. The client then
@ -227,7 +224,7 @@ activity, such as receiving a Secure interrupt or an exception.
 The SDEI dispatcher implementation provides ``sdei_dispatch_event()`` API for
 this purpose. The API has the following signature:

-::
+.. code:: c

        int sdei_dispatch_event(int ev_num);

@ -237,7 +234,7 @@ on success, or ``-1`` on failure.
 The following figure depicts a scenario involving explicit dispatch of SDEI
 event. A commentary is provided below:

-.. image:: ../plantuml/sdei_explicit_dispatch.svg
+.. image:: ../resources/diagrams/plantuml/sdei_explicit_dispatch.svg

 As part of initialisation, the SDEI client registers a handler for a platform
 event [1], enables the event [3], and unmasks the current PE [5]. Note that,
--- a/docs/components/secure-partition-manager-design.rst
+++ b/docs/components/secure-partition-manager-design.rst
@ -1,10 +1,5 @@
-*******************************
-Secure Partition Manager Design
-*******************************
-
-
-
-.. contents::
+Secure Partition Manager
+************************

 Background
 ==========
@ -135,7 +130,7 @@ First, build the Standalone MM Secure Partition. To build it, refer to the
 Then build TF-A with SPM support and include the Standalone MM Secure Partition
 image in the FIP:

-::
+.. code:: shell

    BL32=path/to/standalone/mm/sp BL33=path/to/bl33.bin \
    make PLAT=fvp ENABLE_SPM=1 ARM_BL31_IN_DRAM=1 fip all
@ -819,5 +814,5 @@ Error Codes
 .. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
 .. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf

-.. |Image 1| image:: ../diagrams/secure_sw_stack_tos.png
-.. |Image 2| image:: ../diagrams/secure_sw_stack_sp.png
+.. |Image 1| image:: ../resources/diagrams/secure_sw_stack_tos.png
+.. |Image 2| image:: ../resources/diagrams/secure_sw_stack_sp.png
--- a/docs/components/spd/index.rst
+++ b/docs/components/spd/index.rst
@ -4,7 +4,6 @@ Secure Payload Dispatcher (SPD)
 .. toctree::
   :maxdepth: 1
   :caption: Contents
-   :numbered:

   optee-dispatcher
   tlk-dispatcher
--- a/docs/components/spd/tlk-dispatcher.rst
+++ b/docs/components/spd/tlk-dispatcher.rst
@ -15,7 +15,7 @@ Once a BL32 is ready, TLKD can be included in the image by adding "SPD=tlkd"
 to the build command.

 Trusted Little Kernel (TLK)
-===========================
+---------------------------

 TLK is a Trusted OS running as Secure EL1. It is a Free Open Source Software
 (FOSS) release of the NVIDIA® Trusted Little Kernel (TLK) technology, which
@ -54,20 +54,20 @@ TLK and OTE can be found in the Tegra\_BSP\_for\_Android\_TLK\_FOSS\_Reference.p
 manual located under the "documentation" directory\_.

 Build TLK
-=========
+---------

 To build and execute TLK, follow the instructions from "Building a TLK Device"
 section from Tegra\_BSP\_for\_Android\_TLK\_FOSS\_Reference.pdf manual.

 Input parameters to TLK
-=======================
+-----------------------

 TLK expects the TZDRAM size and a structure containing the boot arguments. BL2
 passes this information to the EL3 software as members of the bl32\_ep\_info
 struct, where bl32\_ep\_info is part of bl31\_params\_t (passed by BL2 in X0)

-Example:
--------
+Example
+~~~~~~~

 ::

--- a/docs/components/spd/trusty-dispatcher.rst
+++ b/docs/components/spd/trusty-dispatcher.rst
@ -9,7 +9,7 @@ Open Source Project (AOSP) webpage for Trusty hosted at
 https://source.android.com/security/trusty

 Boot parameters
-===============
+---------------

 Custom boot parameters can be passed to Trusty by providing a platform
 specific function:
@ -26,7 +26,7 @@ can be set to a platform specific parameter block, and ``args->arg2``
 should then be set to the size of that block.

 Supported platforms
-===================
+-------------------

 Out of all the platforms supported by Trusted Firmware-A, Trusty is only
 verified and supported by NVIDIA's Tegra SoCs.
--- a/docs/components/xlat-tables-lib-v2-design.rst
+++ b/docs/components/xlat-tables-lib-v2-design.rst
@ -1,12 +1,6 @@
-Translation Tables Library Design
+Translation (XLAT) Tables Library
 =================================

-
-
-
-.. contents::
-
-
 This document describes the design of the translation tables library (version 2)
 used by Trusted Firmware-A (TF-A). This library provides APIs to create page
 tables based on a description of the memory layout, as well as setting up system
@ -424,4 +418,4 @@ mapping cannot be cached in the TLBs.
 .. _aarch32/xlat_tables_arch.c: ../../lib/xlat_tables_v2/aarch32/xlat_tables_arch.c
 .. _aarch64/xlat_tables_arch.c: ../../lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
 .. _Porting Guide: ../getting_started/porting-guide.rst
-.. |Alignment Example| image:: ../diagrams/xlat_align.png?raw=true
+.. |Alignment Example| image:: ../resources/diagrams/xlat_align.png
--- a/docs/conf.py
+++ b/docs/conf.py
@ -9,6 +9,8 @@
 #
 # See the options documentation at http://www.sphinx-doc.org/en/master/config

+import os
+
 # -- Project information -----------------------------------------------------

 project = 'Trusted Firmware-A'
@ -16,7 +18,6 @@ project = 'Trusted Firmware-A'
 version = '2.1'
 release = version # We don't need these to be distinct

-
 # -- General configuration ---------------------------------------------------

 # Add any Sphinx extension module names here, as strings. They can be
@ -48,6 +49,10 @@ exclude_patterns = []
 # The name of the Pygments (syntax highlighting) style to use.
 pygments_style = 'sphinx'

+# Load the contents of the global substitutions file into the 'rst_prolog'
+# variable. This ensures that the substitutions are all inserted into each page.
+with open('global_substitutions.txt', 'r') as subs:
+  rst_prolog = subs.read()

 # -- Options for HTML output -------------------------------------------------

--- a/docs/design/auth-framework.rst
+++ b/docs/design/auth-framework.rst
@ -1,10 +1,5 @@
-Abstracting a Chain of Trust
-============================
-
-
-
-
-.. contents::
+Authentication Framework & Chain of Trust
+=========================================

 The aim of this document is to describe the authentication framework
 implemented in Trusted Firmware-A (TF-A). This framework fulfills the
@ -413,7 +408,7 @@ An IPL must provide functions with the following prototypes:

 An IPL for each type must be registered using the following macro:

-::
+.. code:: c

    REGISTER_IMG_PARSER_LIB(_type, _name, _init, _check_int, _get_param)

@ -958,9 +953,11 @@ sources in the build for the various algorithms. Setting the variable to
 `rsa+ecdsa` enables support for both rsa and ecdsa algorithms in the mbedTLS
 library.

-Note: If code size is a concern, the build option ``MBEDTLS_SHA256_SMALLER`` can
-be defined in the platform Makefile. It will make mbed TLS use an implementation
-of SHA-256 with smaller memory footprint (~1.5 KB less) but slower (~30%).
+.. note::
+   If code size is a concern, the build option ``MBEDTLS_SHA256_SMALLER`` can
+   be defined in the platform Makefile. It will make mbed TLS use an
+   implementation of SHA-256 with smaller memory footprint (~1.5 KB less) but
+   slower (~30%).

 --------------

--- a/docs/design/cpu-specific-build-macros.rst
+++ b/docs/design/cpu-specific-build-macros.rst
@ -1,11 +1,6 @@
 Arm CPU Specific Build Macros
 =============================

-
-
-
-.. contents::
-
 This document describes the various build options present in the CPU specific
 operations framework to enable errata workarounds and to enable optimizations
 for a specific CPU on a platform.
--- a/docs/design/firmware-design.rst
+++ b/docs/design/firmware-design.rst
@ -1,10 +1,5 @@
-Trusted Firmware-A design
-=========================
-
-
-
-
-.. contents::
+Firmware Design
+===============

 Trusted Firmware-A (TF-A) implements a subset of the Trusted Board Boot
 Requirements (TBBR) Platform Design Document (PDD) [1]_ for Arm reference
@ -1146,7 +1141,9 @@ returning through EL3 and running the non-trusted firmware (BL33):
   ``bl31_register_bl32_init()`` which provides a SPD-defined mechanism to
   invoke a 'world-switch synchronous call' to Secure-EL1 to run the BL32
   entrypoint.
-   NOTE: The Test SPD service included with TF-A provides one implementation
+
+   .. note::
+      The Test SPD service included with TF-A provides one implementation
      of such a mechanism.

   On completion BL32 returns control to BL31 via a SMC, and on receipt the
@ -1680,7 +1677,8 @@ The location of the BL32 image will result in different memory maps. This is
 illustrated for both FVP and Juno in the following diagrams, using the TSP as
 an example.

-Note: Loading the BL32 image in TZC secured DRAM doesn't change the memory
+.. note::
+   Loading the BL32 image in TZC secured DRAM doesn't change the memory
   layout of the other images in Trusted SRAM.

 CONFIG section in memory layouts shown below contains:
@ -2220,7 +2218,8 @@ The default memory layout for each BL image is as follows:
       |       Code        |
       +-------------------+ BLx_BASE

-Note: The 2KB alignment for the exception vectors is an architectural
+.. note::
+   The 2KB alignment for the exception vectors is an architectural
   requirement.

 The read-write data start on a new memory page so that they can be mapped with
@ -2309,7 +2308,7 @@ result in build error. Subscribing to an undefined event however won't.
 Subscribed handlers must be of type ``pubsub_cb_t``, with following function
 signature:

-::
+.. code:: c

   typedef void* (*pubsub_cb_t)(const void *arg);

@ -2336,7 +2335,7 @@ A publisher that wants to publish event ``foo`` would:

 -  Define the event ``foo`` in the ``pubsub_events.h``.

-   ::
+   .. code:: c

      REGISTER_PUBSUB_EVENT(foo);

@ -2472,7 +2471,7 @@ respectively.
 From outside TF-A, timestamps for individual CPUs can be retrieved by calling
 into ``pmf_smc_handler()``.

-.. code:: c
+::

    Interface : pmf_smc_handler()
    Argument  : unsigned int smc_fid, u_register_t x1,
@ -2602,7 +2601,7 @@ Platform may choose to not define straight the toolchain target architecture
 directive by defining ``MARCH32_DIRECTIVE``.
 I.e:

-::
+.. code:: make

   MARCH32_DIRECTIVE := -mach=armv7-a

@ -2684,4 +2683,4 @@ References
 .. _ROMLIB Design: romlib-design.rst
 .. _Trusted Board Boot Requirements CLIENT (TBBR-CLIENT) Armv8-A (ARM DEN0006D): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a

-.. |Image 1| image:: diagrams/rt-svc-descs-layout.png?raw=true
+.. |Image 1| image:: ../resources/diagrams/rt-svc-descs-layout.png
--- a/docs/design/interrupt-framework-design.rst
+++ b/docs/design/interrupt-framework-design.rst
@ -1,10 +1,5 @@
-Trusted Firmware-A interrupt management design guide
-====================================================
-
-
-
-
-.. contents::
+Interrupt Management Framework 
+==============================

 This framework is responsible for managing interrupts routed to EL3. It also
 allows EL3 software to configure the interrupt routing behavior. Its main
@ -53,7 +48,7 @@ the exception level(s) it is handled in.
 The following constants define the various interrupt types in the framework
 implementation.

-::
+.. code:: c

    #define INTR_TYPE_S_EL1      0
    #define INTR_TYPE_EL3        1
@ -421,7 +416,8 @@ runtime.
 Test secure payload dispatcher behavior
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-**Note:** where this document discusses ``TSP_NS_INTR_ASYNC_PREEMPT`` as being
+.. note::
+   Where this document discusses ``TSP_NS_INTR_ASYNC_PREEMPT`` as being
   ``1``, the same results also apply when ``EL3_EXCEPTION_HANDLING`` is ``1``.

 The TSPD only handles Secure-EL1 interrupts and is provided with the following
@ -1020,5 +1016,5 @@ TSP by returning ``SMC_UNK`` error.
 .. _Porting Guide: ../getting_started/porting-guide.rst
 .. _SMC calling convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html

-.. |Image 1| image:: diagrams/sec-int-handling.png?raw=true
-.. |Image 2| image:: diagrams/non-sec-int-handling.png?raw=true
+.. |Image 1| image:: ../resources/diagrams/sec-int-handling.png
+.. |Image 2| image:: ../resources/diagrams/non-sec-int-handling.png
--- a/docs/design/psci-pd-tree.rst
+++ b/docs/design/psci-pd-tree.rst
@ -1,12 +1,5 @@
-PSCI Power Domain Tree design
-=============================
-
-
-
-
-.. contents::
-
--------------
+PSCI Power Domain Tree Structure
+================================

 Requirements
 ------------
@ -116,7 +109,7 @@ separately.

 This tree is defined by the platform as the array described above as follows:

-::
+.. code:: c

        #define PLAT_NUM_POWER_DOMAINS       20
        #define PLATFORM_CORE_COUNT          13
@ -226,7 +219,7 @@ to represent leaf and non-leaf power domain nodes in the tree.
 The power domain tree is implemented as a combination of the following data
 structures.

-::
+.. code:: c

    non_cpu_pd_node_t psci_non_cpu_pd_nodes[PSCI_NUM_NON_CPU_PWR_DOMAINS];
    cpu_pd_node_t psci_cpu_pd_nodes[PLATFORM_CORE_COUNT];
--- a/docs/design/reset-design.rst
+++ b/docs/design/reset-design.rst
@ -1,10 +1,5 @@
-Trusted Firmware-A reset design
-===============================
-
-
-
-
-.. contents::
+CPU Reset
+=========

 This document describes the high-level design of the framework to handle CPU
 resets in Trusted Firmware-A (TF-A). It also describes how the platform
@ -28,7 +23,8 @@ configuration, some of these steps might be unnecessary. The following sections
 guide the platform integrator by indicating which build options exclude which
 steps, depending on the capability of the platform.

-Note: If BL31 is used as the TF-A entry point instead of BL1, the diagram
+.. note::
+   If BL31 is used as the TF-A entry point instead of BL1, the diagram
   above is still relevant, as all these operations will occur in BL31 in
   this case. Please refer to section 6 "Using BL31 entrypoint as the reset
   address" for more information.
@ -159,7 +155,7 @@ This might be done by the Trusted Boot Firmware or by platform code in BL31.
 .. _Firmware Design: firmware-design.rst
 .. _User Guide: ../getting_started/user-guide.rst

-.. |Default reset code flow| image:: ../diagrams/default_reset_code.png?raw=true
-.. |Reset code flow with programmable reset address| image:: ../diagrams/reset_code_no_boot_type_check.png?raw=true
-.. |Reset code flow with single CPU released out of reset| image:: ../diagrams/reset_code_no_cpu_check.png?raw=true
-.. |Reset code flow with programmable reset address and single CPU released out of reset| image:: ../diagrams/reset_code_no_checks.png?raw=true
+.. |Default reset code flow| image:: ../resources/diagrams/default_reset_code.png
+.. |Reset code flow with programmable reset address| image:: ../resources/diagrams/reset_code_no_boot_type_check.png
+.. |Reset code flow with single CPU released out of reset| image:: ../resources/diagrams/reset_code_no_cpu_check.png
+.. |Reset code flow with programmable reset address and single CPU released out of reset| image:: ../resources/diagrams/reset_code_no_checks.png
--- a/docs/design/trusted-board-boot.rst
+++ b/docs/design/trusted-board-boot.rst
@ -1,10 +1,5 @@
-Trusted Board Boot Design Guide
-===============================
-
-
-
-
-.. contents::
+Trusted Board Boot
+==================

 The Trusted Board Boot (TBB) feature prevents malicious firmware from running on
 the platform by authenticating all firmware images up to and including the
@ -146,7 +141,8 @@ if any of the steps fail.
   compared with the hash of the ROTPK read from the trusted root-key storage
   registers. If they match, the BL2 hash is read from the certificate.

-   Note: the matching operation is platform specific and is currently
+   .. note::
+      The matching operation is platform specific and is currently
      unimplemented on the Arm development platforms.

 -  BL1 loads the BL2 image. Its hash is calculated and compared with the hash
--- a/docs/getting_started/image-terminology.rst
+++ b/docs/getting_started/image-terminology.rst
@ -1,11 +1,6 @@
 Image Terminology
 =================

-.. section-numbering::
-    :suffix: .
-
-.. contents::
-
 This page contains the current name, abbreviated name and purpose of the various
 images referred to in the Trusted Firmware project.

--- a/docs/getting_started/porting-guide.rst
+++ b/docs/getting_started/porting-guide.rst
@ -1,9 +1,5 @@
-Trusted Firmware-A Porting Guide
-================================
-
-
-
-.. contents::
+Porting Guide
+=============

 Introduction
 ------------
@ -335,7 +331,9 @@ must also be defined:

   SCP_BL2U image identifier, used by BL1 to fetch an image descriptor
   corresponding to SCP_BL2U.
-   NOTE: TF-A does not provide source code for this image.
+
+   .. note::
+      TF-A does not provide source code for this image.

 If the Non-Secure Firmware Updater ROM, NS_BL1U is used, the following must
 also be defined:
@ -344,7 +342,9 @@ also be defined:

   Defines the base address in non-secure ROM where NS_BL1U executes.
   Must be aligned on a page-size boundary.
-   NOTE: TF-A does not provide source code for this image.
+
+   .. note::
+      TF-A does not provide source code for this image.

 -  **#define : NS_BL1U_IMAGE_ID**

@ -358,7 +358,9 @@ be defined:

   Defines the base address in non-secure memory where NS_BL2U executes.
   Must be aligned on a page-size boundary.
-   NOTE: TF-A does not provide source code for this image.
+
+   .. note::
+      TF-A does not provide source code for this image.

 -  **#define : NS_BL2U_IMAGE_ID**

@ -1004,7 +1006,8 @@ situation from which it cannot recover. This function must not return,
 and must be implemented in assembly because it may be called before the C
 environment is initialized.

-Note: The address from where it was called is stored in x30 (Link Register).
+.. note::
+   The address from where it was called is stored in x30 (Link Register).
   The default implementation simply spins.

 Function : plat_get_bl_image_load_info()
@ -1046,9 +1049,10 @@ value will weaken the protection as the attacker could easily write the right
 value as part of the attack most of the time. Therefore, it should return a
 true random number.

-Note: For the protection to be effective, the global data need to be placed at
-a lower address than the stack bases. Failure to do so would allow an attacker
-to overwrite the canary as part of the stack buffer overflow attack.
+.. warning::
+   For the protection to be effective, the global data need to be placed at
+   a lower address than the stack bases. Failure to do so would allow an
+   attacker to overwrite the canary as part of the stack buffer overflow attack.

 Function : plat_flush_next_bl_params()
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -1844,7 +1848,7 @@ line boundary.
 SDEI porting requirements
 ~~~~~~~~~~~~~~~~~~~~~~~~~

-The SDEI dispatcher requires the platform to provide the following macros
+The |SDEI| dispatcher requires the platform to provide the following macros
 and functions, of which some are optional, and some others mandatory.

 Macros
@ -1854,19 +1858,19 @@ Macro: PLAT_SDEI_NORMAL_PRI [mandatory]
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 This macro must be defined to the EL3 exception priority level associated with
-Normal SDEI events on the platform. This must have a higher value (therefore of
-lower priority) than ``PLAT_SDEI_CRITICAL_PRI``.
+Normal |SDEI| events on the platform. This must have a higher value
+(therefore of lower priority) than ``PLAT_SDEI_CRITICAL_PRI``.

 Macro: PLAT_SDEI_CRITICAL_PRI [mandatory]
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 This macro must be defined to the EL3 exception priority level associated with
-Critical SDEI events on the platform. This must have a lower value (therefore of
-higher priority) than ``PLAT_SDEI_NORMAL_PRI``.
+Critical |SDEI| events on the platform. This must have a lower value
+(therefore of higher priority) than ``PLAT_SDEI_NORMAL_PRI``.

-**Note**: SDEI exception priorities must be the lowest among Secure priorities.
-Among the SDEI exceptions, Critical SDEI priority must be higher than Normal
-SDEI priority.
+**Note**: |SDEI| exception priorities must be the lowest among Secure
+priorities. Among the |SDEI| exceptions, Critical |SDEI| priority must
+be higher than Normal |SDEI| priority.

 Functions
 .........
@ -1880,10 +1884,10 @@ Function: int plat_sdei_validate_entry_point(uintptr_t ep) [optional]
  Return: int

 This function validates the address of client entry points provided for both
-event registration and *Complete and Resume* SDEI calls. The function takes one
-argument, which is the address of the handler the SDEI client requested to
-register. The function must return ``0`` for successful validation, or ``-1``
-upon failure.
+event registration and *Complete and Resume* |SDEI| calls. The function
+takes one argument, which is the address of the handler the |SDEI| client
+requested to register. The function must return ``0`` for successful validation,
+or ``-1`` upon failure.

 The default implementation always returns ``0``. On Arm platforms, this function
 is implemented to translate the entry point to physical address, and further to
@ -1898,11 +1902,12 @@ Function: void plat_sdei_handle_masked_trigger(uint64_t mpidr, unsigned int intr
  Argument: unsigned int
  Return: void

-SDEI specification requires that a PE comes out of reset with the events masked.
-The client therefore is expected to call ``PE_UNMASK`` to unmask SDEI events on
-the PE. No SDEI events can be dispatched until such time.
+|SDEI| specification requires that a PE comes out of reset with the events
+masked. The client therefore is expected to call ``PE_UNMASK`` to unmask
+|SDEI| events on the PE. No |SDEI| events can be dispatched until such
+time.

-Should a PE receive an interrupt that was bound to an SDEI event while the
+Should a PE receive an interrupt that was bound to an |SDEI| event while the
 events are masked on the PE, the dispatcher implementation invokes the function
 ``plat_sdei_handle_masked_trigger``. The MPIDR of the PE that received the
 interrupt and the interrupt ID are passed as parameters.
@ -2567,10 +2572,12 @@ makefiles in order to benefit from them. By default, they will cause the crash
 output to be routed over the normal console infrastructure and get printed on
 consoles configured to output in crash state. ``console_set_scope()`` can be
 used to control whether a console is used for crash output.
-NOTE: Platforms are responsible for making sure that they only mark consoles for
-use in the crash scope that are able to support this, i.e. that are written in
-assembly and conform with the register clobber rules for putc() (x0-x2, x16-x17)
-and flush() (x0-x3, x16-x17) crash callbacks.
+
+.. note::
+   Platforms are responsible for making sure that they only mark consoles for
+   use in the crash scope that are able to support this, i.e. that are written
+   in assembly and conform with the register clobber rules for putc()
+   (x0-x2, x16-x17) and flush() (x0-x3, x16-x17) crash callbacks.

 In some cases (such as debugging very early crashes that happen before the
 normal boot console can be set up), platforms may want to control crash output
--- a/docs/getting_started/psci-lib-integration-guide.rst
+++ b/docs/getting_started/psci-lib-integration-guide.rst
@ -1,10 +1,6 @@
 PSCI Library Integration guide for Armv8-A AArch32 systems
 ==========================================================

-
-
-.. contents::
-
 This document describes the PSCI library interface with a focus on how to
 integrate with a suitable Trusted OS for an Armv8-A AArch32 system. The PSCI
 Library implements the PSCI Standard as described in `PSCI spec`_ and is meant
--- a/docs/getting_started/rt-svc-writers-guide.rst
+++ b/docs/getting_started/rt-svc-writers-guide.rst
@ -1,10 +1,6 @@
-Trusted Firmware-A EL3 runtime service writer's guide
+EL3 Runtime Service Writer's Guide
 =====================================================

-
-
-.. contents::
-
 Introduction
 ------------

@ -96,7 +92,7 @@ A runtime service is registered using the ``DECLARE_RT_SVC()`` macro, specifying
 the name of the service, the range of OENs covered, the type of service and
 initialization and call handler functions.

-::
+.. code:: c

    #define DECLARE_RT_SVC(_name, _start, _end, _type, _setup, _smch)

@ -264,7 +260,8 @@ The ``cookie`` parameter to the handler is reserved for future use and can be
 ignored. The ``handle`` is returned by the SMC handler - completion of the
 handler function must always be via one of the ``SMC_RETn()`` macros.

-NOTE: The PSCI and Test Secure-EL1 Payload Dispatcher services do not follow
+.. note::
+   The PSCI and Test Secure-EL1 Payload Dispatcher services do not follow
   all of the above requirements yet.

 Services that contain multiple sub-services
--- a/docs/getting_started/user-guide.rst
+++ b/docs/getting_started/user-guide.rst
@ -1,10 +1,5 @@
-Trusted Firmware-A User Guide
-=============================
-
-
-
-
-.. contents::
+User Guide
+==========

 This document describes how to build Trusted Firmware-A (TF-A) and run it with a
 tested set of other software components using defined configurations on the Juno
@ -49,7 +44,7 @@ Tools

 Install the required packages to build TF-A with the following command:

-::
+.. code:: shell

    sudo apt-get install device-tree-compiler build-essential gcc make git libssl-dev

@ -101,7 +96,8 @@ targets which both utilise the `checkpatch.pl` script that ships with the Linux
 source tree. The project also defines certain *checkpatch* options in the
 ``.checkpatch.conf`` file in the top-level directory.

-**Note:** Checkpatch errors will gate upstream merging of pull requests.
+.. note::
+   Checkpatch errors will gate upstream merging of pull requests.
   Checkpatch warnings will not gate merging but should be reviewed and fixed if
   possible.

@ -111,14 +107,14 @@ in the `Linux master tree`_ *scripts* directory, then set the ``CHECKPATCH``
 environment variable to point to ``checkpatch.pl`` (with the other 2 files in
 the same directory) and build the `checkcodebase` target:

-::
+.. code:: shell

    make CHECKPATCH=<path-to-linux>/linux/scripts/checkpatch.pl checkcodebase

 To just check the style on the files that differ between your local branch and
 the remote master, use:

-::
+.. code:: shell

    make CHECKPATCH=<path-to-linux>/linux/scripts/checkpatch.pl checkpatch

@ -134,13 +130,13 @@ Building TF-A

   For AArch64:

-   ::
+   .. code:: shell

       export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-

   For AArch32:

-   ::
+   .. code:: shell

       export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf-

@ -158,7 +154,7 @@ Building TF-A

   For AArch64 using Arm Compiler 6:

-   ::
+   .. code:: shell

       export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
       make CC=<path-to-armclang>/bin/armclang PLAT=<platform> all
@ -169,7 +165,7 @@ Building TF-A

   For AArch64 using clang:

-   ::
+   .. code:: shell

       export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
       make CC=<path-to-clang>/bin/clang PLAT=<platform> all
@ -178,13 +174,13 @@ Building TF-A

   For AArch64:

-   ::
+   .. code:: shell

       make PLAT=<platform> all

   For AArch32:

-   ::
+   .. code:: shell

       make PLAT=<platform> ARCH=aarch32 AARCH32_SP=sp_min all

@ -227,7 +223,7 @@ Building TF-A

 -  Build products for a specific build variant can be removed using:

-   ::
+   .. code:: shell

       make DEBUG=<D> PLAT=<platform> clean

@ -235,7 +231,7 @@ Building TF-A

   The build tree can be removed completely using:

-   ::
+   .. code:: shell

       make realclean

@ -723,7 +719,8 @@ Common build options
   of certificates in the FIP and FWU_FIP depends upon the value of the
   ``GENERATE_COT`` option.

-   Note: This option depends on ``CREATE_KEYS`` to be enabled. If the keys
+   .. warning::
+      This option depends on ``CREATE_KEYS`` to be enabled. If the keys
      already exist in disk, they will be overwritten without further notice.

 -  ``TRUSTED_WORLD_KEY``: This option is used when ``GENERATE_COT=1``. It
@ -744,7 +741,8 @@ Common build options
   interrupts to TSP allowing it to save its context and hand over
   synchronously to EL3 via an SMC.

-   Note: when ``EL3_EXCEPTION_HANDLING`` is ``1``, ``TSP_NS_INTR_ASYNC_PREEMPT``
+   .. note::
+      When ``EL3_EXCEPTION_HANDLING`` is ``1``, ``TSP_NS_INTR_ASYNC_PREEMPT``
      must also be set to ``1``.

 -  ``USE_ARM_LINK``: This flag determines whether to enable support for ARM
@ -940,7 +938,7 @@ Debugging options

 To compile a debug version and make the build more verbose use

-::
+.. code:: shell

    make PLAT=<platform> DEBUG=1 V=1 all

@ -953,14 +951,15 @@ version to 2 is recommended for DS-5 versions older than 5.16.
 When debugging logic problems it might also be useful to disable all compiler
 optimizations by using ``-O0``.

-NOTE: Using ``-O0`` could cause output images to be larger and base addresses
+.. warning::
+   Using ``-O0`` could cause output images to be larger and base addresses
   might need to be recalculated (see the **Memory layout on Arm development
   platforms** section in the `Firmware Design`_).

 Extra debug options can be passed to the build system by setting ``CFLAGS`` or
 ``LDFLAGS``:

-.. code:: makefile
+.. code:: shell

    CFLAGS='-O0 -gdwarf-2'                                     \
    make PLAT=<platform> DEBUG=1 V=1 all
@ -1001,7 +1000,7 @@ must be recompiled as well. For more information on SPs and SPDs, see the
 First clean the TF-A build directory to get rid of any previous BL31 binary.
 Then to build the TSP image use:

-::
+.. code:: shell

    make PLAT=<platform> SPD=tspd all

@ -1029,13 +1028,13 @@ and BL33 images.

 For AArch64:

-::
+.. code:: shell

    make PLAT=fvp BL33=<path-to>/bl33.bin fip

 For AArch32:

-::
+.. code:: shell

    make PLAT=fvp ARCH=aarch32 AARCH32_SP=sp_min BL33=<path-to>/bl33.bin fip

@ -1051,13 +1050,13 @@ steps:

 It is recommended to remove old artifacts before building the tool:

-::
+.. code:: shell

    make -C tools/fiptool clean

 Build the tool:

-::
+.. code:: shell

    make [DEBUG=1] [V=1] fiptool

@ -1072,7 +1071,7 @@ options.

 Example 1: create a new Firmware package ``fip.bin`` that contains BL2 and BL31:

-::
+.. code:: shell

    ./tools/fiptool/fiptool create \
        --tb-fw build/<platform>/<build-type>/bl2.bin \
@ -1081,13 +1080,13 @@ Example 1: create a new Firmware package ``fip.bin`` that contains BL2 and BL31:

 Example 2: view the contents of an existing Firmware package:

-::
+.. code:: shell

    ./tools/fiptool/fiptool info <path-to>/fip.bin

 Example 3: update the entries of an existing Firmware package:

-::
+.. code:: shell

    # Change the BL2 from Debug to Release version
    ./tools/fiptool/fiptool update \
@ -1096,14 +1095,14 @@ Example 3: update the entries of an existing Firmware package:

 Example 4: unpack all entries from an existing Firmware package:

-::
+.. code:: shell

    # Images will be unpacked to the working directory
    ./tools/fiptool/fiptool unpack <path-to>/fip.bin

 Example 5: remove an entry from an existing Firmware package:

-::
+.. code:: shell

    ./tools/fiptool/fiptool remove \
        --tb-fw build/<platform>/debug/fip.bin
@ -1173,7 +1172,7 @@ images with support for these features:

   Example of command line using RSA development keys:

-   ::
+   .. code:: shell

       MBEDTLS_DIR=<path of the directory containing mbed TLS sources> \
       make PLAT=<platform> TRUSTED_BOARD_BOOT=1 GENERATE_COT=1        \
@ -1210,11 +1209,13 @@ images with support for these features:
       NS_BL2U=<path-to>/<ns_bl2u_image>                               \
       all fip fwu_fip

-   Note: The BL2U image will be built by default and added to the FWU_FIP.
+   .. note::
+      The BL2U image will be built by default and added to the FWU_FIP.
      The user may override this by adding ``BL2U=<path-to>/<bl2u_image>``
      to the command line above.

-   Note: Building and installing the non-secure and SCP FWU images (NS_BL1U,
+   .. note::
+      Building and installing the non-secure and SCP FWU images (NS_BL1U,
      NS_BL2U and SCP_BL2U) is outside the scope of this document.

   The result of this build will be bl1.bin, fip.bin and fwu_fip.bin binaries.
@ -1230,7 +1231,7 @@ The ``cert_create`` tool is built as part of the TF-A build process when the
 previous section), but it can also be built separately with the following
 command:

-::
+.. code:: shell

    make PLAT=<platform> [DEBUG=1] [V=1] certtool

@ -1239,14 +1240,14 @@ For platforms that require their own IDs in certificate files, the generic
 platform must define its IDs within a ``platform_oid.h`` header file for the
 build to succeed.

-::
+.. code:: shell

    make PLAT=<platform> USE_TBBR_DEFS=0 [DEBUG=1] [V=1] certtool

 ``DEBUG=1`` builds the tool in debug mode. ``V=1`` makes the build process more
 verbose. The following command should be used to obtain help about the tool:

-::
+.. code:: shell

    ./tools/cert_create/cert_create -h

@ -1257,25 +1258,30 @@ This section provides Juno and FVP specific instructions to build Trusted
 Firmware, obtain the additional required firmware, and pack it all together in
 a single FIP binary. It assumes that a `Linaro Release`_ has been installed.

-Note: Pre-built binaries for AArch32 are available from Linaro Release 16.12
-onwards. Before that release, pre-built binaries are only available for AArch64.
+.. note::
+   Pre-built binaries for AArch32 are available from Linaro Release 16.12
+   onwards. Before that release, pre-built binaries are only available for
+   AArch64.

-Note: Follow the full instructions for one platform before switching to a
+.. warning::
+   Follow the full instructions for one platform before switching to a
   different one. Mixing instructions for different platforms may result in
   corrupted binaries.

-Note: The uboot image downloaded by the Linaro workspace script does not always
+.. warning::
+   The uboot image downloaded by the Linaro workspace script does not always
   match the uboot image packaged as BL33 in the corresponding fip file. It is
   recommended to use the version that is packaged in the fip file using the
   instructions below.

-Note: For the FVP, the kernel FDT is packaged in FIP during build and loaded
+.. note::
+   For the FVP, the kernel FDT is packaged in FIP during build and loaded
   by the firmware at runtime. See `Obtaining the Flattened Device Trees`_
   section for more info on selecting the right FDT to use.

 #. Clean the working directory

-   ::
+   .. code:: shell

       make realclean

@ -1284,7 +1290,7 @@ section for more info on selecting the right FDT to use.
   Use the fiptool to extract the SCP_BL2 and BL33 images from the FIP
   package included in the Linaro release:

-   ::
+   .. code:: shell

       # Build the fiptool
       make [DEBUG=1] [V=1] fiptool
@ -1296,16 +1302,18 @@ section for more info on selecting the right FDT to use.
   current working directory. The SCP_BL2 image corresponds to
   ``scp-fw.bin`` and BL33 corresponds to ``nt-fw.bin``.

-   Note: The fiptool will complain if the images to be unpacked already
+   .. note::
+      The fiptool will complain if the images to be unpacked already
      exist in the current directory. If that is the case, either delete those
      files or use the ``--force`` option to overwrite.

-   Note: For AArch32, the instructions below assume that nt-fw.bin is a normal
-   world boot loader that supports AArch32.
+   .. note::
+      For AArch32, the instructions below assume that nt-fw.bin is a
+      normal world boot loader that supports AArch32.

 #. Build TF-A images and create a new FIP for FVP

-   ::
+   .. code:: shell

       # AArch64
       make PLAT=fvp BL33=nt-fw.bin all fip
@ -1320,7 +1328,7 @@ section for more info on selecting the right FDT to use.
   Building for AArch64 on Juno simply requires the addition of ``SCP_BL2``
   as a build parameter.

-   ::
+   .. code:: shell

       make PLAT=juno BL33=nt-fw.bin SCP_BL2=scp-fw.bin all fip

@ -1333,13 +1341,13 @@ section for more info on selecting the right FDT to use.
   -  Before building BL32, the environment variable ``CROSS_COMPILE`` must point
      to the AArch32 Linaro cross compiler.

-      ::
+      .. code:: shell

          export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf-

   -  Build BL32 in AArch32.

-      ::
+      .. code:: shell

          make ARCH=aarch32 PLAT=juno AARCH32_SP=sp_min \
          RESET_TO_SP_MIN=1 JUNO_AARCH32_EL3_RUNTIME=1 bl32
@ -1354,14 +1362,14 @@ section for more info on selecting the right FDT to use.
   -  Before building BL1 and BL2, the environment variable ``CROSS_COMPILE``
      must point to the AArch64 Linaro cross compiler.

-      ::
+      .. code:: shell

          export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-

   -  The following parameters should be used to build BL1 and BL2 in AArch64
      and point to the BL32 file.

-      ::
+      .. code:: shell

          make ARCH=aarch64 PLAT=juno JUNO_AARCH32_EL3_RUNTIME=1 \
          BL33=nt-fw.bin SCP_BL2=scp-fw.bin \
@ -1499,7 +1507,7 @@ clear the mailbox at start-up.
 One way to do that is to create an 8-byte file containing all zero bytes using
 the following command:

-::
+.. code:: shell

    dd if=/dev/zero of=mailbox.dat bs=1 count=8

@ -1569,7 +1577,7 @@ used when compiling TF-A. For example, the following command will create a FIP
 without a BL33 and prepare to jump to a BL33 image loaded at address
 0x80000000:

-::
+.. code:: shell

    make PRELOADED_BL33_BASE=0x80000000 PLAT=fvp all fip

@ -1584,7 +1592,7 @@ memory (like in FVP).
 For example, if the kernel is loaded at ``0x80080000`` and the DTB is loaded at
 address ``0x82000000``, the firmware can be built like this:

-::
+.. code:: shell

    CROSS_COMPILE=aarch64-linux-gnu-  \
    make PLAT=fvp DEBUG=1             \
@ -1632,7 +1640,7 @@ offset in ``INITRD_START`` has to be removed.

 And the FVP binary can be run with the following command:

-::
+.. code:: shell

    <path-to>/FVP_Base_AEMv8A-AEMv8A                            \
    -C pctl.startup=0.0.0.0                                     \
@ -1667,6 +1675,7 @@ The latest version of the AArch64 build of TF-A has been tested on the following
 Arm FVPs without shifted affinities, and that do not support threaded CPU cores
 (64-bit host machine only).

+.. note::
   The FVP models used are Version 11.6 Build 45, unless otherwise stated.

 -  ``FVP_Base_AEMv8A-AEMv8A``
@ -1704,30 +1713,36 @@ Arm FVPs without shifted affinities, and that do not support threaded CPU cores
 -  ``FVP_Base_AEMv8A-AEMv8A``
 -  ``FVP_Base_Cortex-A32x4``

-NOTE: The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities, which
+.. note::
+   The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities, which
   is not compatible with legacy GIC configurations. Therefore this FVP does not
   support these legacy GIC configurations.

-NOTE: The build numbers quoted above are those reported by launching the FVP
+.. note::
+   The build numbers quoted above are those reported by launching the FVP
   with the ``--version`` parameter.

-NOTE: Linaro provides a ramdisk image in prebuilt FVP configurations and full
+.. note::
+   Linaro provides a ramdisk image in prebuilt FVP configurations and full
   file systems that can be downloaded separately. To run an FVP with a virtio
   file system image an additional FVP configuration option
   ``-C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>`` can be
   used.

-NOTE: The software will not work on Version 1.0 of the Foundation FVP.
+.. note::
+   The software will not work on Version 1.0 of the Foundation FVP.
   The commands below would report an ``unhandled argument`` error in this case.

-NOTE: FVPs can be launched with ``--cadi-server`` option such that a
-CADI-compliant debugger (for example, Arm DS-5) can connect to and control its
-execution.
+.. note::
+   FVPs can be launched with ``--cadi-server`` option such that a
+   CADI-compliant debugger (for example, Arm DS-5) can connect to and control
+   its execution.

-NOTE: Since FVP model Version 11.0 Build 11.0.34 and Version 8.5 Build 0.8.5202
-the internal synchronisation timings changed compared to older versions of the
-models. The models can be launched with ``-Q 100`` option if they are required
-to match the run time characteristics of the older versions.
+.. warning::
+   Since FVP model Version 11.0 Build 11.0.34 and Version 8.5 Build 0.8.5202
+   the internal synchronisation timings changed compared to older versions of
+   the models. The models can be launched with ``-Q 100`` option if they are
+   required to match the run time characteristics of the older versions.

 The Foundation FVP is a cut down version of the AArch64 Base FVP. It can be
 downloaded for free from `Arm's website`_.
@ -1748,7 +1763,8 @@ be found in the TF-A source directory under ``fdts/``. The Foundation FVP has
 a subset of the Base FVP components. For example, the Foundation FVP lacks
 CLCD and MMC support, and has only one CPU cluster.

-Note: It is not recommended to use the FDTs built along the kernel because not
+.. note::
+   It is not recommended to use the FDTs built along the kernel because not
   all FDTs are available from there.

 The dynamic configuration capability is enabled in the firmware for FVPs.
@ -1806,7 +1822,7 @@ Running on the Foundation FVP with reset to BL1 entrypoint
 The following ``Foundation_Platform`` parameters should be used to boot Linux with
 4 CPUs using the AArch64 build of TF-A.

-::
+.. code:: shell

    <path-to>/Foundation_Platform                   \
    --cores=4                                       \
@ -1842,7 +1858,7 @@ Running on the AEMv8 Base FVP with reset to BL1 entrypoint
 The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
 with 8 CPUs using the AArch64 build of TF-A.

-::
+.. code:: shell

    <path-to>/FVP_Base_RevC-2xAEMv8A                            \
    -C pctl.startup=0.0.0.0                                     \
@ -1856,8 +1872,9 @@ with 8 CPUs using the AArch64 build of TF-A.
    --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \
    --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000

-Note: The ``FVP_Base_RevC-2xAEMv8A`` has shifted affinities and requires a
-specific DTS for all the CPUs to be loaded.
+.. note::
+   The ``FVP_Base_RevC-2xAEMv8A`` has shifted affinities and requires
+   a specific DTS for all the CPUs to be loaded.

 Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -1865,7 +1882,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint
 The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
 with 8 CPUs using the AArch32 build of TF-A.

-::
+.. code:: shell

    <path-to>/FVP_Base_AEMv8A-AEMv8A                            \
    -C pctl.startup=0.0.0.0                                     \
@ -1893,7 +1910,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL1 entrypoint
 The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
 boot Linux with 8 CPUs using the AArch64 build of TF-A.

-::
+.. code:: shell

    <path-to>/FVP_Base_Cortex-A57x4-A53x4                       \
    -C pctl.startup=0.0.0.0                                     \
@ -1911,7 +1928,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to BL1 entrypoint
 The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
 boot Linux with 4 CPUs using the AArch32 build of TF-A.

-::
+.. code:: shell

    <path-to>/FVP_Base_Cortex-A32x4                             \
    -C pctl.startup=0.0.0.0                                     \
@ -1929,7 +1946,7 @@ Running on the AEMv8 Base FVP with reset to BL31 entrypoint
 The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
 with 8 CPUs using the AArch64 build of TF-A.

-::
+.. code:: shell

    <path-to>/FVP_Base_RevC-2xAEMv8A                             \
    -C pctl.startup=0.0.0.0                                      \
@ -1984,7 +2001,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to SP_MIN entrypoint
 The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
 with 8 CPUs using the AArch32 build of TF-A.

-::
+.. code:: shell

    <path-to>/FVP_Base_AEMv8A-AEMv8A                             \
    -C pctl.startup=0.0.0.0                                      \
@ -2015,7 +2032,8 @@ with 8 CPUs using the AArch32 build of TF-A.
    --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000  \
    --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000

-Note: The load address of ``<bl32-binary>`` depends on the value ``BL32_BASE``.
+.. note::
+   The load address of ``<bl32-binary>`` depends on the value ``BL32_BASE``.
   It should match the address programmed into the RVBAR register as well.

 Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint
@ -2024,7 +2042,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint
 The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
 boot Linux with 8 CPUs using the AArch64 build of TF-A.

-::
+.. code:: shell

    <path-to>/FVP_Base_Cortex-A57x4-A53x4                        \
    -C pctl.startup=0.0.0.0                                      \
@ -2052,7 +2070,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to SP_MIN entrypoint
 The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
 boot Linux with 4 CPUs using the AArch32 build of TF-A.

-::
+.. code:: shell

    <path-to>/FVP_Base_Cortex-A32x4                             \
    -C pctl.startup=0.0.0.0                                     \
@ -2101,7 +2119,7 @@ The SYSTEM SUSPEND is a PSCI API which can be used to implement system suspend
 to RAM. For more details refer to section 5.16 of `PSCI`_. To test system suspend
 on Juno, at the linux shell prompt, issue the following command:

-::
+.. code:: shell

    echo +10 > /sys/class/rtc/rtc0/wakealarm
    echo -n mem > /sys/power/state
--- a/docs/global_substitutions.txt
+++ b/docs/global_substitutions.txt
@ -0,0 +1,55 @@
+.. |AArch32| replace:: :term:`AArch32`
+.. |AArch64| replace:: :term:`AArch64`
+.. |API| replace:: :term:`API`
+.. |CoT| replace:: :term:`CoT`
+.. |COT| replace:: :term:`COT`
+.. |CSS| replace:: :term:`CSS`
+.. |CVE| replace:: :term:`CVE`
+.. |DS-5| replace:: :term:`DS-5`
+.. |DT| replace:: :term:`DT`
+.. |EL| replace:: :term:`EL`
+.. |EHF| replace:: :term:`EHF`
+.. |FDT| replace:: :term:`FDT`
+.. |FIP| replace:: :term:`FIP`
+.. |FVP| replace:: :term:`FVP`
+.. |FWU| replace:: :term:`FWU`
+.. |GIC| replace:: :term:`GIC`
+.. |ISA| replace:: :term:`ISA`
+.. |Linaro| replace:: :term:`Linaro`
+.. |MMU| replace:: :term:`MMU`
+.. |MPAM| replace:: :term:`MPAM`
+.. |MPIDR| replace:: :term:`MPIDR`
+.. |OEN| replace:: :term:`OEN`
+.. |OP-TEE| replace:: :term:`OP-TEE`
+.. |OTE| replace:: :term:`OTE`
+.. |PDD| replace:: :term:`PDD`
+.. |PMF| replace:: :term:`PMF`
+.. |PSCI| replace:: :term:`PSCI`
+.. |RAS| replace:: :term:`RAS`
+.. |ROT| replace:: :term:`ROT`
+.. |SCMI| replace:: :term:`SCMI`
+.. |SCP| replace:: :term:`SCP`
+.. |SDEI| replace:: :term:`SDEI`
+.. |SDS| replace:: :term:`SDS`
+.. |SEA| replace:: :term:`SEA`
+.. |SiP| replace:: :term:`SiP`
+.. |SIP| replace:: :term:`SIP`
+.. |SMC| replace:: :term:`SMC`
+.. |SMCCC| replace:: :term:`SMCCC`
+.. |SoC| replace:: :term:`SoC`
+.. |SP| replace:: :term:`SP`
+.. |SPD| replace:: :term:`SPD`
+.. |SPM| replace:: :term:`SPM`
+.. |SVE| replace:: :term:`SVE`
+.. |TBB| replace:: :term:`TBB`
+.. |TBBR| replace:: :term:`TBBR`
+.. |TEE| replace:: :term:`TEE`
+.. |TF-A| replace:: :term:`TF-A`
+.. |TF-M| replace:: :term:`TF-M`
+.. |TLB| replace:: :term:`TLB`
+.. |TLK| replace:: :term:`TLK`
+.. |TSP| replace:: :term:`TSP`
+.. |TZC| replace:: :term:`TZC`
+.. |UEFI| replace:: :term:`UEFI`
+.. |WDOG| replace:: :term:`WDOG`
+.. |XLAT| replace:: :term:`XLAT`
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@ -0,0 +1,177 @@
+Glossary
+========
+
+This glossary provides definitions for terms and abbreviations used in the TF-A
+documentation.
+
+You can find additional definitions in the `Arm Glossary`_.
+
+.. glossary::
+   :sorted:
+
+   AArch32
+      32-bit execution state of the ARMv8 ISA
+
+   AArch64
+      64-bit execution state of the ARMv8 ISA
+
+   API
+      Application Programming Interface
+
+   CoT
+   COT
+      Chain of Trust
+
+   CSS
+      Compute Sub-System
+
+   CVE
+      Common Vulnerabilities and Exposures. A CVE document is commonly used to
+      describe a publicly-known security vulnerability.
+
+   DS-5
+      Arm Development Studio 5
+
+   DT
+      Device Tree
+
+   EL
+      Exception Level
+
+   EHF
+      Exception Handling Framework
+
+   FDT
+      Flattened Device Tree
+
+   FIP
+      Firmware Image Package
+
+   FVP
+      Fixed Virtual Platform
+
+   FWU
+      FirmWare Update
+
+   GIC
+      Generic Interrupt Controller
+
+   ISA
+      Instruction Set Architecture
+
+   Linaro
+      A collaborative engineering organization consolidating
+      and optimizing open source software and tools for the Arm architecture.
+
+   MMU
+      Memory Management Unit
+
+   MPAM
+      Memory Partitioning And Monitoring. An optional Armv8.4 extension.
+
+   MPIDR
+      Multiprocessor Affinity Register
+
+   OEN
+      Owning Entity Number
+
+   OP-TEE
+      Open Portable Trusted Execution Environment. An example of a :term:`TEE`
+
+   OTE
+      Open-source Trusted Execution Environment
+
+   PDD
+      Platform Design Document
+
+   PMF
+      Performance Measurement Framework
+
+   PSCI
+      Power State Coordination Interface
+
+   RAS
+      Reliability, Availability, and Serviceability extensions. A mandatory
+      extension for the Armv8.2 architecture and later. An optional extension to
+      the base Armv8 architecture.
+
+   ROT
+      Root of Trust
+
+   SCMI
+      System Control and Management Interface
+
+   SCP
+      System Control Processor
+
+   SDEI
+      Software Delegated Exception Interface
+
+   SDS
+      Shared Data Storage
+
+   SEA
+      Synchronous External Abort
+
+   SiP
+   SIP
+      Silicon Provider
+
+   SMC
+      Secure Monitor Call
+
+   SMCCC
+      :term:`SMC` Calling Convention
+
+   SoC
+      System on Chip
+
+   SP
+      Secure Partition
+
+   SPD
+      Secure Payload Dispatcher
+
+   SPM
+      Secure Partition Manager
+
+   SVE
+      Scalable Vector Extension
+
+   TBB
+      Trusted Board Boot
+
+   TBBR
+      Trusted Board Boot Requirements
+
+   TEE
+      Trusted Execution Environment
+
+   TF-A
+      Trusted Firmware-A
+
+   TF-M
+      Trusted Firmware-M
+
+   TLB
+      Translation Lookaside Buffer
+
+   TLK
+      Trusted Little Kernel. A Trusted OS from NVIDIA.
+
+   TSP
+      Test Secure Payload
+
+   TZC
+      TrustZone Controller
+
+   UEFI
+      Unified Extensible Firmware Interface
+
+   WDOG
+      Watchdog
+
+   XLAT
+      Translation (abbr.). For example, "XLAT table".
+
+.. _`Arm Glossary`: https://developer.arm.com/support/arm-glossary
--- a/docs/index.rst
+++ b/docs/index.rst
@ -3,7 +3,7 @@ Trusted Firmware-A Documentation

 .. toctree::
   :maxdepth: 1
-   :caption: Contents
+   :hidden:

   Home<self>
   getting_started/index
@ -14,10 +14,14 @@ Trusted Firmware-A Documentation
   perf/index
   security_advisories/index
   change-log
-   maintainers
   acknowledgements
+   glossary
+   maintainers
   license

+.. contents:: On This Page
+    :depth: 3
+
 Trusted Firmware-A (TF-A) provides a reference implementation of secure world
 software for `Armv7-A and Armv8-A`_, including a `Secure Monitor`_ executing
 at Exception Level 3 (EL3). It implements various Arm interface standards,
@ -99,7 +103,7 @@ Functionality
      Secure-EL0, which can be used to implement simple management and
      security services.

-   -  An SDEI dispatcher to route interrupt-based SDEI events.
+   -  An |SDEI| dispatcher to route interrupt-based |SDEI| events.

   -  An Exception Handling Framework (EHF) that allows dispatching of EL3
      interrupts to their registered handlers, to facilitate firmware-first
@ -149,6 +153,7 @@ The latest version of the AArch64 build of TF-A has been tested on the following
 Arm FVPs without shifted affinities, and that do not support threaded CPU cores
 (64-bit host machine only).

+.. note::
   The FVP models used are Version 11.5 Build 33, unless otherwise stated.

 -  ``FVP_Base_AEMv8A-AEMv8A``
@ -186,7 +191,8 @@ Arm FVPs without shifted affinities, and that do not support threaded CPU cores
 -  ``FVP_Base_AEMv8A-AEMv8A``
 -  ``FVP_Base_Cortex-A32x4``

-NOTE: The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities.
+.. note::
+   The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities.

 The Foundation FVP can be downloaded free of charge. The Base FVPs can be
 licensed from Arm. See the `Arm FVP website`_.
--- a/docs/maintainers.rst
+++ b/docs/maintainers.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A maintainers
-==============================
+Maintainers
+===========

 Trusted Firmware-A (TF-A) is an Arm maintained project. All contributions are
 ultimately merged by the maintainers listed below. Technical ownership of some
--- a/docs/perf/psci-performance-juno.rst
+++ b/docs/perf/psci-performance-juno.rst
@ -28,7 +28,7 @@ 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:

-::
+.. code:: shell

    make PLAT=juno ENABLE_RUNTIME_INSTRUMENTATION=1 \
        SCP_BL2=<path/to/scp-fw.bin>                \
--- a/docs/plat/allwinner.rst
+++ b/docs/plat/allwinner.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A for Allwinner ARMv8 SoCs
-===========================================
+Allwinner ARMv8 SoCs
+====================

 Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Allwinner
 SoCs with ARMv8 cores. Only BL31 is used to provide proper EL3 setup and
@ -24,24 +24,23 @@ See the respective `U-Boot documentation`_ for more details.

 To build for machines with an A64 or H5 SoC:

-::
+.. code:: shell

    make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_a64 DEBUG=1 bl31

 To build for machines with an H6 SoC:

-::
+.. code:: shell

    make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h6 DEBUG=1 bl31

 .. _U-Boot documentation: http://git.denx.de/?p=u-boot.git;f=board/sunxi/README.sunxi64;hb=HEAD

 Trusted OS dispatcher
-=====================
+---------------------

 One can boot Trusted OS(OP-TEE OS, bl32 image) along side bl31 image on Allwinner A64.

 In order to include the 'opteed' dispatcher in the image, pass 'SPD=opteed' on the command line
 while compiling the bl31 image and make sure the loader (SPL) loads the Trusted OS binary to
 the beginning of DRAM (0x40000000).
-
--- a/docs/plat/fvp_ve.rst
+++ b/docs/plat/fvp_ve.rst
@ -1,5 +1,5 @@
-Description
-===========
+Arm Versatile Express
+=====================

 Versatile Express (VE) family development platform provides an
 ultra fast environment for prototyping arm-v7 System-on-Chip designs.
@ -9,21 +9,21 @@ and Cortex-A7 VE FVP's. This platform is tested on and only expected to work
 with single core models.

 Boot Sequence
-=============
+-------------

 BL1 --> BL2 --> BL32(sp_min) --> BL33(u-boot) --> Linux kernel

 How to build
-============
+------------

 Code Locations
---------------
+~~~~~~~~~~~~~~
 -  `U-boot <https://git.linaro.org/landing-teams/working/arm/u-boot.git>`__

 -  `arm-trusted-firmware <https://github.com/ARM-software/arm-trusted-firmware>`__

 Build Procedure
---------------
+~~~~~~~~~~~~~~~

 -  Obtain arm toolchain. The software stack has been verified with linaro 6.2
   `arm-linux-gnueabihf <https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/arm-linux-gnueabihf/>`__.
@ -68,7 +68,7 @@ Build Procedure
      BL33=<path_to_u-boot.bin> all fip

 Run Procedure
-------------
+~~~~~~~~~~~~~

 The following model parameters should be used to boot Linux using the build of
 arm-trusted-firmware-a made using the above make commands:
--- a/docs/plat/imx8.rst
+++ b/docs/plat/imx8.rst
@ -1,5 +1,5 @@
-Description
-===========
+NXP i.MX 8 Series
+=================

 The i.MX 8 series of applications processors is a feature- and
 performance-scalable multi-core platform that includes single-,
@ -20,15 +20,15 @@ control for system-level resources on i.MX8. The heart of the system
 controller is a Cortex-M4 that executes system controller firmware.

 Boot Sequence
-=============
+-------------

 Bootrom --> BL31 --> BL33(u-boot) --> Linux kernel

 How to build
-============
+------------

 Build Procedure
---------------
+~~~~~~~~~~~~~~~

 -  Prepare AARCH64 toolchain.

@ -46,7 +46,7 @@ Build Procedure
   Target_SoC should be "imx8qx" for i.MX8QX SoC.

 Deploy TF-A Images
-----------------
+~~~~~~~~~~~~~~~~~~

 TF-A binary(bl31.bin), scfw_tcm.bin and u-boot.bin are combined together
 to generate a binary file called flash.bin, the imx-mkimage tool is used
--- a/docs/plat/imx8m.rst
+++ b/docs/plat/imx8m.rst
@ -1,5 +1,5 @@
-Description
-===========
+NXP i.MX 8M Series
+==================

 The i.MX 8M family of applications processors based on Arm Corte-A53 and Cortex-M4
 cores provide high-performance computing, power efficiency, enhanced system
@ -7,15 +7,15 @@ reliability and embedded security needed to drive the growth of fast-growing
 edge node computing, streaming multimedia, and machine learning applications.

 Boot Sequence
-=============
+-------------

 Bootrom --> SPL --> BL31 --> BL33(u-boot) --> Linux kernel

 How to build
-============
+------------

 Build Procedure
---------------
+~~~~~~~~~~~~~~~

 -  Prepare AARCH64 toolchain.

@ -34,7 +34,7 @@ Build Procedure
   Target_SoC should be "imx8mm" for i.MX8MM SoC.

 Deploy TF-A Images
-----------------
+~~~~~~~~~~~~~~~~~~

 TF-A binary(bl31.bin), u-boot-spl.bin u-boot-nodtb.bin and dtb are combined
 together to generate a binary file called flash.bin, the imx-mkimage tool is
--- a/docs/plat/index.rst
+++ b/docs/plat/index.rst
@ -16,7 +16,6 @@ Platform Ports
   meson-gxl
   mt8183
   nvidia-tegra
-   poplar
   qemu
   rcar-gen3
   rockchip
@ -26,4 +25,5 @@ Platform Ports
   synquacer
   ti-k3
   warp7
+   xilinx-versal
   xilinx-zynqmp
--- a/docs/plat/intel-stratix10.rst
+++ b/docs/plat/intel-stratix10.rst
@ -1,5 +1,5 @@
-Description
-===========
+Intel Stratix 10 SoCFPGA
+========================

 Stratix 10 SoCFPGA is a FPGA with integrated quad-core 64-bit Arm Cortex A53 processor.

@ -11,10 +11,10 @@ the hardware, then loads bl31 and bl33 (UEFI) into DDR and boots to bl33.
    Boot ROM --> Trusted Firmware-A --> UEFI

 How to build
-============
+------------

 Code Locations
--------------
+~~~~~~~~~~~~~~

 -  Trusted Firmware-A:
   `link <https://github.com/ARM-software/arm-trusted-firmware>`__
@ -23,7 +23,7 @@ Code Locations
   `link <https://github.com/altera-opensource/uefi-socfpga>`__

 Build Procedure
---------------
+~~~~~~~~~~~~~~~

 -  Fetch all the above 2 repositories into local host.
   Make all the repositories in the same ${BUILD\_PATH}.
@ -45,7 +45,7 @@ Build Procedure
       BL33=PEI.ROM

 Install Procedure
-----------------
+~~~~~~~~~~~~~~~~~

 - dd fip.bin to a A2 partition on the MMC drive to be booted in Stratix 10
  board.
@ -53,16 +53,18 @@ Install Procedure
 - Generate a SOF containing bl2

 .. code:: bash
+
        aarch64-linux-gnu-objcopy -I binary -O ihex --change-addresses 0xffe00000 bl2.bin bl2.hex
        quartus_cpf --bootloader bl2.hex <quartus_generated_sof> <output_sof_with_bl2>

 - Configure SOF to board

 .. code:: bash
+
        nios2-configure-sof <output_sof_with_bl2>

 Boot trace
-==========
+----------

 ::
         INFO:    DDR: DRAM calibration success.
--- a/docs/plat/ls1043a.rst
+++ b/docs/plat/ls1043a.rst
@ -1,5 +1,5 @@
-Description
-===========
+NXP QorIQ® LS1043A
+==================

 The QorIQ® LS1043A processor is NXP's first quad-core, 64-bit Arm®-based
 processor for embedded networking. The LS1023A (two core version) and the
@ -36,7 +36,7 @@ UART: supports two UARTs up to 115200 bps for console
 More information are listed in `ls1043`_.

 Boot Sequence
-=============
+-------------


 Bootrom --> TF-A BL1 --> TF-A BL2 --> TF-A BL1 --> TF-A BL31
@ -44,10 +44,10 @@ Bootrom --> TF-A BL1 --> TF-A BL2 --> TF-A BL1 --> TF-A BL31


 How to build
-============
+------------

 Build Procedure
---------------
+~~~~~~~~~~~~~~~

 -  Prepare AARCH64 toolchain.

@ -69,7 +69,7 @@ Build Procedure
       BL33=u-boot.bin NEED_BL32=yes BL32=tee.bin SPD=opteed

 Deploy TF-A Images
-----------------
+~~~~~~~~~~~~~~~~~~

 -  Deploy TF-A images on Nor flash Alt Bank.

--- a/docs/plat/meson-gxbb.rst
+++ b/docs/plat/meson-gxbb.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A for Amlogic Meson S905 (GXBB)
-================================================
+Amlogic Meson S905 (GXBB)
+=========================

 The Amlogic Meson S905 is a SoC with a quad core Arm Cortex-A53 running at
 1.5Ghz. It also contains a Cortex-M3 used as SCP.
@ -15,7 +15,7 @@ and Linux:

 In order to build it:

-::
+.. code:: shell

    CROSS_COMPILE=aarch64-linux-gnu- make DEBUG=1 PLAT=gxbb bl31

--- a/docs/plat/meson-gxl.rst
+++ b/docs/plat/meson-gxl.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A for Amlogic Meson S905x (GXL)
-================================================
+Amlogic Meson S905x (GXL)
+=========================

 The Amlogic Meson S905x is a SoC with a quad core Arm Cortex-A53 running at
 1.5Ghz. It also contains a Cortex-M3 used as SCP.
@ -15,7 +15,7 @@ and Linux:

 In order to build it:

-::
+.. code:: shell

    CROSS_COMPILE=aarch64-linux-gnu- make DEBUG=1 PLAT=gxl

--- a/docs/plat/mt8183.rst
+++ b/docs/plat/mt8183.rst
@ -1,19 +1,19 @@
-Description
-===========
+MediaTek 8183
+=============

 MediaTek 8183 (MT8183) is a 64-bit ARM SoC introduced by MediaTek in early 2018.
 The chip incorporates eight cores - four Cortex-A53 little cores and Cortex-A73.
 Both clusters can operate at up to 2 GHz.

 Boot Sequence
-=============
+-------------

 ::

    Boot Rom --> Coreboot --> TF-A BL31 --> Depthcharge --> Linux Kernel

 How to Build
-============
+------------

 .. code:: shell

--- a/docs/plat/nvidia-tegra.rst
+++ b/docs/plat/nvidia-tegra.rst
@ -1,5 +1,5 @@
-Tegra SoCs - Overview
-=====================
+NVIDIA Tegra
+============

 -  .. rubric:: T186
      :name: t186
@ -58,13 +58,13 @@ to extensive power-gating and dynamic voltage and clock scaling based on
 workloads.

 Directory structure
-===================
+-------------------

 -  plat/nvidia/tegra/common - Common code for all Tegra SoCs
 -  plat/nvidia/tegra/soc/txxx - Chip specific code

 Trusted OS dispatcher
-=====================
+---------------------

 Tegra supports multiple Trusted OS'.

@ -83,7 +83,7 @@ Tegra210: TLK and Trusty
 Tegra186: Trusty

 Scatter files
-=============
+-------------

 Tegra platforms currently support scatter files and ld.S scripts. The scatter
 files help support ARMLINK linker to generate BL31 binaries. For now, there
@ -93,7 +93,7 @@ the scatter file to be used. Tegra platforms have verified BL31 image generation
 with ARMCLANG (compilation) and ARMLINK (linking) for the Tegra186 platforms.

 Preparing the BL31 image to run on Tegra SoCs
-=============================================
+---------------------------------------------

 .. code:: shell

@ -125,7 +125,7 @@ uint64\_t boot\_profiler\_shmem\_base;
 } plat\_params\_from\_bl2\_t;

 Power Management
-================
+----------------

 The PSCI implementation expects each platform to expose the 'power state'
 parameter to be used during the 'SYSTEM SUSPEND' call. The state-id field
@ -133,7 +133,7 @@ is implementation defined on Tegra SoCs and is preferably defined by
 tegra\_def.h.

 Tegra configs
-=============
+-------------

 -  'tegra\_enable\_l2\_ecc\_parity\_prot': This flag enables the L2 ECC and Parity
   Protection bit, for Arm Cortex-A57 CPUs, during CPU boot. This flag will
--- a/docs/plat/qemu.rst
+++ b/docs/plat/qemu.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A for QEMU virt Armv8-A
-========================================
+QEMU virt Armv8-A
+=================

 Trusted Firmware-A (TF-A) implements the EL3 firmware layer for QEMU virt
 Armv8-A. BL1 is used as the BootROM, supplied with the -bios argument.
@ -33,13 +33,13 @@ is conveniently achieved with symlinks the local names as:

 To build:

-::
+.. code:: shell

    make CROSS_COMPILE=aarch64-none-elf- PLAT=qemu

 To start (QEMU v2.6.0):

-::
+.. code:: shell

    qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a57  \
        -kernel Image                           \
--- a/docs/plat/rcar-gen3.rst
+++ b/docs/plat/rcar-gen3.rst
@ -1,5 +1,5 @@
-Description
-===========
+Renesas R-Car
+=============

 "R-Car" is the nickname for Renesas' system-on-chip (SoC) family for
 car information systems designed for the next-generation of automotive
@ -97,14 +97,14 @@ program counters.


 How to build
-============
+------------

 The TF-A build options depend on the target board so you will have to
 refer to those specific instructions. What follows is customized to
 the H3 SiP Salvator-X development system used in this port.

 Build Tested:
-------------
+~~~~~~~~~~~~~
 RCAR_OPT="LSI=H3 RCAR_DRAM_SPLIT=1 RCAR_LOSSY_ENABLE=1"
 MBEDTLS_DIR=$mbedtls_src

@ -112,7 +112,7 @@ $ MBEDTLS_DIR=$mbedtls_src_tree make clean bl2 bl31 rcar_layout_tool \
 PLAT=rcar ${RCAR_OPT} SPD=opteed

 System Tested:
--------------------
+~~~~~~~~~~~~~~
 * mbed_tls:
  git@github.com:ARMmbed/mbedtls.git [devel]

@ -150,7 +150,7 @@ System Tested:
  Linux 4.19-rc4

 TF-A Build Procedure
--------------------
+~~~~~~~~~~~~~~~~~~~~

 -  Fetch all the above 4 repositories.

@ -184,7 +184,7 @@ TF-A Build Procedure
       make -j8 PLATFORM="rcar" CFG_ARM64_core=y

 Install Procedure
-----------------
+~~~~~~~~~~~~~~~~~

 - Boot the board in Mini-monitor mode and enable access to the
  Hyperflash.
@ -195,7 +195,7 @@ Install Procedure


 Boot trace
-==========
+----------

 Notice that BL31 traces are not accessible via the console and that in
 order to verbose the BL2 output you will have to compile TF-A with
@ -266,4 +266,3 @@ LOG_LEVEL=50 and DEBUG=1
   Net:   eth0: ethernet@e6800000
   Hit any key to stop autoboot:  0
   =>
-
--- a/docs/plat/rockchip.rst
+++ b/docs/plat/rockchip.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A for Rockchip SoCs
-====================================
+Rockchip SoCs
+=============

 Trusted Firmware-A supports a number of Rockchip ARM SoCs from both
 AARCH32 and AARCH64 fields.
@ -12,7 +12,7 @@ This includes right now:


 Boot Sequence
-=============
+-------------

 For AARCH32:
    Bootrom --> BL1/BL2 --> BL32 --> BL33 --> Linux kernel
@ -26,7 +26,7 @@ BL1/2 and BL33 can currently be supplied from either:


 How to build
-============
+------------

 Rockchip SoCs expect TF-A's BL31 (AARCH64) or BL32 (AARCH32) to get
 integrated with other boot software like U-Boot or Coreboot, so only
@ -46,7 +46,7 @@ compilation toolchain.


 How to deploy
-=============
+-------------

 Both upstream U-Boot and Coreboot projects contain instructions on where
 to put the built images during their respective build process.
--- a/docs/plat/rpi3.rst
+++ b/docs/plat/rpi3.rst
@ -1,9 +1,5 @@
-Trusted Firmware-A for Raspberry Pi 3
-=====================================
-
-
-
-.. contents::
+Raspberry Pi 3
+==============

 The `Raspberry Pi 3`_ is an inexpensive single-board computer that contains four
 Arm Cortex-A53 cores.
@ -167,7 +163,7 @@ Secondary cores
 ~~~~~~~~~~~~~~~

 This port of the Trusted Firmware-A supports ``PSCI_CPU_ON``,
-`PSCI_SYSTEM_RESET`` and ``PSCI_SYSTEM_OFF``. The last one doesn't really turn
+``PSCI_SYSTEM_RESET`` and ``PSCI_SYSTEM_OFF``. The last one doesn't really turn
 the system off, it simply reboots it and asks the VideoCore firmware to keep it
 in a low power mode permanently.

@ -274,11 +270,12 @@ The following build options are supported:
  BL32_EXTRA1=tee-pager_v2.bin  BL32_EXTRA2=tee-pageable_v2.bin``
  to put the binaries into the FIP.

-  Note: If OP-TEE is used it may be needed to add the following options to the
+  .. warning::
+     If OP-TEE is used it may be needed to add the following options to the
     Linux command line so that the USB driver doesn't use FIQs:
     ``dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0 dwc_otg.nak_holdoff=0``.
-  This will unfortunately reduce the performance of the USB driver. It is needed
-  when using Raspbian, for example.
+     This will unfortunately reduce the performance of the USB driver. It is
+     needed when using Raspbian, for example.

 - ``TRUSTED_BOARD_BOOT``: This port supports TBB. Set this option to 1 to enable
  it. In order to use TBB, you might want to set ``GENERATE_COT=1`` to let the
--- a/docs/plat/socionext-uniphier.rst
+++ b/docs/plat/socionext-uniphier.rst
@ -1,6 +1,5 @@
-Trusted Firmware-A for Socionext UniPhier SoCs
-==============================================
-
+Socionext UniPhier
+==================

 Socionext UniPhier Armv8-A SoCs use Trusted Firmware-A (TF-A) as the secure
 world firmware, supporting BL2 and BL31.
--- a/docs/plat/stm32mp1.rst
+++ b/docs/plat/stm32mp1.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A for STM32MP1
-===============================
+STMicroelectronics STM32MP1
+===========================

 STM32MP1 is a microprocessor designed by STMicroelectronics
 based on a dual Arm Cortex-A7.
--- a/docs/plat/synquacer.rst
+++ b/docs/plat/synquacer.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A for Socionext Synquacer SoCs
-===============================================
+Socionext Synquacer
+===================

 Socionext's Synquacer SC2A11 is a multi-core processor with 24 cores of Arm
 Cortex-A53. The Developerbox, of 96boards, is a platform that contains this
@ -9,10 +9,10 @@ the moment.
 More information are listed in `link`_.

 How to build
-============
+------------

 Code Locations
--------------
+~~~~~~~~~~~~~~

 -  Trusted Firmware-A:
   `link <https://github.com/ARM-software/arm-trusted-firmware>`__
@ -27,12 +27,12 @@ Code Locations
   `link <https://github.com/tianocore/edk2-non-osi>`__

 Boot Flow
---------
+~~~~~~~~~

 SCP firmware --> TF-A BL31 --> UEFI(edk2)

 Build Procedure
---------------
+~~~~~~~~~~~~~~~

 -  Firstly, in addition to the “normal” build tools you will also need a
   few specialist tools. On a Debian or Ubuntu operating system try:
@ -98,7 +98,7 @@ Build Procedure
   Note #2: Replace -b RELEASE with -b DEBUG to build a debug.

 Install the System Firmware
---------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~

 -  Providing your Developerbox is fully working and has on operating system
   installed then you can adopt your the newly compiled system firmware using
--- a/docs/plat/ti-k3.rst
+++ b/docs/plat/ti-k3.rst
@ -1,11 +1,13 @@
-Trusted Firmware-A for Texas Instruments K3 SoCs
-================================================
+Texas Instruments K3
+====================

 Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Texas Instruments K3 SoCs.

 Boot Flow
 ---------

+::
+
   R5(U-Boot) --> TF-A BL31 --> BL32(OP-TEE) --> TF-A BL31 --> BL33(U-Boot) --> Linux
                                                       \
                                                   Optional direct to Linux boot
--- a/docs/plat/warp7.rst
+++ b/docs/plat/warp7.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A for i.MX7 WaRP7
-==================================
+NXP i.MX7 WaRP7
+===============

 The Trusted Firmware-A port for the i.MX7Solo WaRP7 implements BL2 at EL3.
 The i.MX7S contains a BootROM with a High Assurance Boot (HAB) functionality.
@ -7,21 +7,23 @@ This functionality provides a mechanism for establishing a root-of-trust from
 the reset vector to the command-line in user-space.

 Boot Flow
-=========
+---------

 BootROM --> TF-A BL2 --> BL32(OP-TEE) --> BL33(U-Boot) --> Linux

 In the WaRP7 port we encapsulate OP-TEE, DTB and U-Boot into a FIP. This FIP is
 expected and required

-# Build Instructions
+Build Instructions
+------------------

 We need to use a file generated by u-boot in order to generate a .imx image the
 BootROM will boot. It is therefore _required_ to build u-boot before TF-A and
 furthermore it is _recommended_ to use the mkimage in the u-boot/tools directory
 to generate the TF-A .imx image.

-## U-Boot:
+U-Boot
+~~~~~~

 https://git.linaro.org/landing-teams/working/mbl/u-boot.git

@ -31,7 +33,8 @@ https://git.linaro.org/landing-teams/working/mbl/u-boot.git
    make warp7_bl33_defconfig;
    make u-boot.imx arch=ARM CROSS_COMPILE=arm-linux-gnueabihf-

-## OP-TEE:
+OP-TEE
+~~~~~~

 https://github.com/OP-TEE/optee_os.git

@ -39,7 +42,8 @@ https://github.com/OP-TEE/optee_os.git

    make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- PLATFORM=imx PLATFORM_FLAVOR=mx7swarp7 ARCH=arm CFG_PAGEABLE_ADDR=0 CFG_DT_ADDR=0x83000000 CFG_NS_ENTRY_ADDR=0x87800000

-## TF-A:
+TF-A
+~~~~

 https://github.com/ARM-software/arm-trusted-firmware.git

@ -75,7 +79,8 @@ It is also assumed copy of mbedtls is available on the path path ../mbedtls

    /path/to/u-boot/tools/mkimage -n /path/to/u-boot/u-boot.cfgout -T imximage -e 0x9df00000 -d ./build/warp7/debug/bl2.bin ./build/warp7/debug/bl2.bin.imx

-## FIP:
+FIP
+~~~

 .. code:: shell

@ -110,8 +115,8 @@ It is also assumed copy of mbedtls is available on the path path ../mbedtls
              --trusted-key-cert fiptool_images/trusted-key-cert.key-crt \
              --tb-fw-cert fiptool_images/trusted-boot-fw.key-crt warp7.fip

-# Deploy Images
-
+Deploy Images
+-------------

 First place the WaRP7 into UMS mode in u-boot this should produce an entry in
 /dev like /dev/disk/by-id/usb-Linux_UMS_disk_0_WaRP7-0xf42400d3000001d4-0\:0
@ -138,7 +143,8 @@ Remember to umount the USB device pefore proceeding
    sudo umount /dev/disk/by-id/usb-Linux_UMS_disk_0_WaRP7-0xf42400d3000001d4-0\:0*


-# Signing BL2
+Signing BL2
+-----------

 A further step is to sign BL2.

--- a/docs/plat/xilinx-versal.rst
+++ b/docs/plat/xilinx-versal.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A for Xilinx Versal
-================================
+Xilinx Versal
+=============

 Trusted Firmware-A implements the EL3 firmware layer for Xilinx Versal.
 The platform only uses the runtime part of TF-A as Xilinx Versal already has a
@ -19,7 +19,9 @@ To build ATF for different platform (for now its just versal virtual "versal_vir
 make RESET_TO_BL31=1 CROSS_COMPILE=aarch64-none-elf- PLAT=versal VERSAL_PLATFORM=versal_virt bl31
 ```

-# Xilinx Versal platform specific build options
+Xilinx Versal platform specific build options
+---------------------------------------------
+
 *   `VERSAL_ATF_MEM_BASE`: Specifies the base address of the bl31 binary.
 *   `VERSAL_ATF_MEM_SIZE`: Specifies the size of the memory region of the bl31 binary.
 *   `VERSAL_BL32_MEM_BASE`: Specifies the base address of the bl32 binary.
--- a/docs/plat/xilinx-zynqmp.rst
+++ b/docs/plat/xilinx-zynqmp.rst
@ -1,5 +1,5 @@
-Trusted Firmware-A for Xilinx Zynq UltraScale+ MPSoC
-====================================================
+Xilinx Zynq UltraScale+ MPSoC
+=============================

 Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Xilinx Zynq
 UltraScale + MPSoC.
@ -23,7 +23,7 @@ To build bl32 TSP you have to rebuild bl31 too:
    make CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp SPD=tspd bl31 bl32

 ZynqMP platform specific build options
-======================================
+--------------------------------------

 -  ``ZYNQMP_ATF_MEM_BASE``: Specifies the base address of the bl31 binary.
 -  ``ZYNQMP_ATF_MEM_SIZE``: Specifies the size of the memory region of the bl31 binary.
@ -36,7 +36,7 @@ ZynqMP platform specific build options
   -  ``cadence1`` : Cadence UART 1

 FSBL->TF-A Parameter Passing
-===========================
+----------------------------

 The FSBL populates a data structure with image information for TF-A. TF-A uses
 that data to hand off to the loaded images. The address of the handoff data
@ -45,7 +45,7 @@ register is free to be used by other software once TF-A has brought up
 further firmware images.

 Power Domain Tree
-=================
+-----------------

 The following power domain tree represents the power domain model used by TF-A
 for ZynqMP:
--- a/docs/process/coding-guidelines.rst
+++ b/docs/process/coding-guidelines.rst
@ -1,9 +1,5 @@
-Trusted Firmware-A Coding Guidelines
-====================================
-
-
-
-.. contents::
+Coding Style & Guidelines
+=========================

 The following sections contain TF coding guidelines. They are continually
 evolving and should not be considered "set in stone". Feel free to question them
@ -11,7 +7,8 @@ and provide feedback.

 Some of the guidelines may also apply to other codebases.

-**Note:** the existing TF codebase does not necessarily comply with all the
+.. note::
+   The existing TF codebase does not necessarily comply with all the
   below guidelines but the intent is for it to do so eventually.

 Checkpatch overrides
@ -296,7 +293,7 @@ of the size of an array is the same.
 If ``MY_STRUCT_SIZE`` in the above example were wrong then the compiler would
 emit an error like this:

-.. code:: c
+::

  my_struct.h:10:1: error: size of array ‘assert_my_struct_size_mismatch’ is negative

--- a/docs/process/contributing.rst
+++ b/docs/process/contributing.rst
@ -1,5 +1,5 @@
-Contributing to Trusted Firmware-A
-==================================
+Contributor's Guide
+===================

 Getting Started
 ---------------
--- a/docs/process/index.rst
+++ b/docs/process/index.rst
@ -7,7 +7,7 @@ Processes & Policies
   :numbered:

   release-information
-   security-center
+   security
   platform-compatibility-policy
   coding-guidelines
   contributing
--- a/docs/process/platform-compatibility-policy.rst
+++ b/docs/process/platform-compatibility-policy.rst
@ -1,12 +1,5 @@
-TF-A Platform Compatibility Policy
-==================================
-
-
-
-
-.. contents::
-
--------------
+Platform Compatibility Policy
+=============================

 Introduction
 ------------
--- a/docs/process/release-information.rst
+++ b/docs/process/release-information.rst
@ -1,12 +1,5 @@
-TF-A Release Information
-========================
-
-.. section-numbering::
-    :suffix: .
-
-.. contents::
-
--------------
+Release Processes
+=================

 Project Release Cadence
 -----------------------
--- a/docs/process/security-center.rst
+++ b/docs/process/security-center.rst
@ -1,5 +1,5 @@
-Security Center
-===============
+Security Handling
+=================

 Security Disclosures
 --------------------
--- a/docs/resources/diagrams/Makefile
+++ b/docs/resources/diagrams/Makefile
--- a/docs/resources/diagrams/default_reset_code.png
+++ b/docs/resources/diagrams/default_reset_code.png
--- a/docs/resources/diagrams/draw.io/ehf.svg
+++ b/docs/resources/diagrams/draw.io/ehf.svg
--- a/docs/resources/diagrams/draw.io/ehf.xml
+++ b/docs/resources/diagrams/draw.io/ehf.xml
--- a/docs/resources/diagrams/draw.io/ras.svg
+++ b/docs/resources/diagrams/draw.io/ras.svg
--- a/docs/resources/diagrams/draw.io/ras.xml
+++ b/docs/resources/diagrams/draw.io/ras.xml
--- a/docs/resources/diagrams/fwu_flow.png
+++ b/docs/resources/diagrams/fwu_flow.png
--- a/docs/resources/diagrams/fwu_states.png
+++ b/docs/resources/diagrams/fwu_states.png
--- a/docs/resources/diagrams/int_handling.dia
+++ b/docs/resources/diagrams/int_handling.dia
--- a/docs/resources/diagrams/non-sec-int-handling.png
+++ b/docs/resources/diagrams/non-sec-int-handling.png
--- a/docs/resources/diagrams/plantuml/plantuml_to_svg.sh
+++ b/docs/resources/diagrams/plantuml/plantuml_to_svg.sh
--- a/docs/resources/diagrams/plantuml/sdei_explicit_dispatch.puml
+++ b/docs/resources/diagrams/plantuml/sdei_explicit_dispatch.puml
--- a/docs/resources/diagrams/plantuml/sdei_explicit_dispatch.svg
+++ b/docs/resources/diagrams/plantuml/sdei_explicit_dispatch.svg
--- a/docs/resources/diagrams/plantuml/sdei_general.puml
+++ b/docs/resources/diagrams/plantuml/sdei_general.puml
--- a/docs/resources/diagrams/plantuml/sdei_general.svg
+++ b/docs/resources/diagrams/plantuml/sdei_general.svg
--- a/docs/resources/diagrams/psci-suspend-sequence.png
+++ b/docs/resources/diagrams/psci-suspend-sequence.png
--- a/docs/resources/diagrams/reset_code_flow.dia
+++ b/docs/resources/diagrams/reset_code_flow.dia
--- a/docs/resources/diagrams/reset_code_no_boot_type_check.png
+++ b/docs/resources/diagrams/reset_code_no_boot_type_check.png
--- a/docs/resources/diagrams/reset_code_no_checks.png
+++ b/docs/resources/diagrams/reset_code_no_checks.png
--- a/docs/resources/diagrams/reset_code_no_cpu_check.png
+++ b/docs/resources/diagrams/reset_code_no_cpu_check.png
--- a/docs/resources/diagrams/romlib_design.dia
+++ b/docs/resources/diagrams/romlib_design.dia
--- a/docs/resources/diagrams/romlib_design.png
+++ b/docs/resources/diagrams/romlib_design.png
--- a/docs/resources/diagrams/romlib_wrapper.dia
+++ b/docs/resources/diagrams/romlib_wrapper.dia
--- a/docs/resources/diagrams/romlib_wrapper.png
+++ b/docs/resources/diagrams/romlib_wrapper.png
--- a/docs/resources/diagrams/rt-svc-descs-layout.png
+++ b/docs/resources/diagrams/rt-svc-descs-layout.png
--- a/docs/resources/diagrams/sec-int-handling.png
+++ b/docs/resources/diagrams/sec-int-handling.png
--- a/docs/resources/diagrams/secure_sw_stack_sp.png
+++ b/docs/resources/diagrams/secure_sw_stack_sp.png
--- a/docs/resources/diagrams/secure_sw_stack_tos.png
+++ b/docs/resources/diagrams/secure_sw_stack_tos.png
--- a/docs/resources/diagrams/xlat_align.dia
+++ b/docs/resources/diagrams/xlat_align.dia
--- a/docs/resources/diagrams/xlat_align.png
+++ b/docs/resources/diagrams/xlat_align.png
--- a/docs/security_advisories/security-advisory-tfv-1.rst
+++ b/docs/security_advisories/security-advisory-tfv-1.rst
@ -1,3 +1,6 @@
+Advisory TFV-1 (CVE-2016-10319)
+===============================
+
 +----------------+-------------------------------------------------------------+
 | Title          | Malformed Firmware Update SMC can result in copy of         |
 |                | unexpectedly large data into secure memory                  |
--- a/docs/security_advisories/security-advisory-tfv-2.rst
+++ b/docs/security_advisories/security-advisory-tfv-2.rst
@ -1,3 +1,6 @@
+Advisory TFV-2 (CVE-2017-7564)
+==============================
+
 +----------------+-------------------------------------------------------------+
 | Title          | Enabled secure self-hosted invasive debug interface can     |
 |                | allow normal world to panic secure world                    |
--- a/docs/security_advisories/security-advisory-tfv-3.rst
+++ b/docs/security_advisories/security-advisory-tfv-3.rst
@ -1,3 +1,6 @@
+Advisory TFV-3 (CVE-2017-7563)
+==============================
+
 +----------------+-------------------------------------------------------------+
 | Title          | RO memory is always executable at AArch64 Secure EL1        |
 +================+=============================================================+
@ -65,7 +68,7 @@ The vulnerability is mitigated by the following factors:
  of the ``XN``, ``UXN`` or ``PXN`` bits in the translation tables. See the
  ``enable_mmu()`` function:

-  .. code:: c
+  ::

      sctlr = read_sctlr_el##_el();               \
      sctlr |= SCTLR_WXN_BIT | SCTLR_M_BIT;       \
--- a/docs/security_advisories/security-advisory-tfv-4.rst
+++ b/docs/security_advisories/security-advisory-tfv-4.rst
@ -1,3 +1,6 @@
+Advisory TFV-4 (CVE-2017-9607)
+==============================
+
 +----------------+-------------------------------------------------------------+
 | Title          | Malformed Firmware Update SMC can result in copy or         |
 |                | authentication of unexpected data in secure memory in       |
--- a/docs/security_advisories/security-advisory-tfv-5.rst
+++ b/docs/security_advisories/security-advisory-tfv-5.rst
@ -1,3 +1,6 @@
+Advisory TFV-5 (CVE-2017-15031)
+===============================
+
 +----------------+-------------------------------------------------------------+
 | Title          | Not initializing or saving/restoring ``PMCR_EL0`` can leak  |
 |                | secure world timing information                             |
--- a/docs/security_advisories/security-advisory-tfv-6.rst
+++ b/docs/security_advisories/security-advisory-tfv-6.rst
@ -1,3 +1,6 @@
+Advisory TFV-6 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754)
+============================================================
+
 +----------------+-------------------------------------------------------------+
 | Title          | Arm Trusted Firmware exposure to speculative processor      |
 |                | vulnerabilities using cache timing side-channels            |
@ -28,13 +31,13 @@ these vulnerabilities on Arm systems, please refer to the `Arm Processor
 Security Update`_.

 Variant 1 (`CVE-2017-5753`_)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------

 At the time of writing, no vulnerable patterns have been observed in upstream TF
 code, therefore no workarounds have been applied or are planned.

 Variant 2 (`CVE-2017-5715`_)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------

 Where possible on vulnerable CPUs, Arm recommends invalidating the branch
 predictor as early as possible on entry into the secure world, before any branch
@ -122,7 +125,7 @@ Cortex-A76, Cortex-A53, Cortex-A55, Cortex-A32, Cortex-A7 and Cortex-A5.
 For more information about non-Arm CPUs, please contact the CPU vendor.

 Variant 3 (`CVE-2017-5754`_)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------

 This variant is only exploitable between Exception Levels within the same
 translation regime, for example between EL0 and EL1, therefore this variant
--- a/docs/security_advisories/security-advisory-tfv-7.rst
+++ b/docs/security_advisories/security-advisory-tfv-7.rst
@ -1,3 +1,6 @@
+Advisory TFV-7 (CVE-2018-3639)
+==============================
+
 +----------------+-------------------------------------------------------------+
 | Title          | Trusted Firmware-A exposure to cache speculation            |
 |                | vulnerability Variant 4                                     |
@ -46,7 +49,7 @@ for platforms that are unaffected or where the risk is deemed low enough.
 Arm CPUs not mentioned below are unaffected.

 Static mitigation
-~~~~~~~~~~~~~~~~~
+-----------------

 For affected CPUs, this approach enables the mitigation during EL3
 initialization, following every PE reset. No mechanism is provided to disable
@ -67,7 +70,7 @@ TF-A implements this approach for the following affected CPUs:
  (``S3_0_C15_C1_0``).

 Dynamic mitigation
-~~~~~~~~~~~~~~~~~~
+------------------

 For affected CPUs, this approach also enables the mitigation during EL3
 initialization, following every PE reset. In addition, this approach implements
--- a/docs/security_advisories/security-advisory-tfv-8.rst
+++ b/docs/security_advisories/security-advisory-tfv-8.rst
@ -1,3 +1,6 @@
+Advisory TFV-8 (CVE-2018-19440)
+===============================
+
 +----------------+-------------------------------------------------------------+
 | Title          | Not saving x0 to x3 registers can leak information from one |
 |                | Normal World SMC client to another                          |
@ -36,7 +39,7 @@ CPU context stored on the stack. This includes registers ``x0`` to ``x3``, as
 can be seen in the ``lib/el3_runtime/aarch64/context.S`` file at line 339
 (referring to the version of the code as of `commit c385955`_):

-.. code:: c
+::

    /*
     * This function restores all general purpose registers except x30 from the
--- a/license.rst
+++ b/license.rst
@ -27,7 +27,7 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 --------------

-Note:
+.. note::
   Individual files contain the following tag instead of the full license text.

 ::