Merge "Fix documentation" into integration
diff --git a/docs/change-log.rst b/docs/change-log.rst
index 70aafc0..0a89aa6 100644
--- a/docs/change-log.rst
+++ b/docs/change-log.rst
@@ -22,8 +22,8 @@
and ``CTX_INCLUDE_PAUTH_REGS`` build flags, pointer authentication can be
enabled in EL3 and S-EL1/0.
- See the `Firmware Design`_ document for additional details on the use of
- pointer authentication.
+ See the :ref:`Firmware Design` document for additional details on the use
+ of pointer authentication.
- Enable Data Independent Timing (DIT) in EL3, where supported
@@ -1359,7 +1359,7 @@
The PSCI library has been refactored to allow integration with **EL3 Runtime
Software**. This is software that is executing at the highest secure
privilege which is EL3 in AArch64 or Secure SVC/Monitor mode in AArch32. See
- `PSCI Integration Guide`_.
+ :ref:`PSCI Library Integration guide for Armv8-A AArch32 systems`.
Included is a minimal AArch32 Secure Payload, **SP-MIN**, that illustrates
the usage and integration of the PSCI library with EL3 Runtime Software
@@ -1402,11 +1402,11 @@
Commits now must have a 'Signed-off-by:' field to certify that the
contribution has been made under the terms of the
- `Developer Certificate of Origin`_.
+ :download:`Developer Certificate of Origin <../dco.txt>`.
A signed CLA is no longer required.
- The `Contribution Guide`_ has been updated to reflect this change.
+ The :ref:`Contributor's Guide` has been updated to reflect this change.
- Introduced Performance Measurement Framework (PMF) which provides support
for capturing, storing, dumping and retrieving time-stamps to measure the
@@ -1620,13 +1620,13 @@
- Added the following new design documents:
- - `Authentication framework`_
- - `Firmware Update`_
- - `TF-A Reset Design`_
- - `Power Domain Topology Design`_
+ - :ref:`Authentication Framework & Chain of Trust`
+ - :ref:`Firmware Update (FWU)`
+ - :ref:`CPU Reset`
+ - :ref:`PSCI Power Domain Tree Structure`
- Applied the new image terminology to the code base and documentation, as
- described in the `image terminology document`_.
+ described in the :ref:`Image Terminology` document.
- The build system has been reworked to improve readability and facilitate
adding future extensions.
@@ -1694,7 +1694,8 @@
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- The Trusted Board Boot implementation has been redesigned to provide greater
- modularity and scalability. See the `Authentication Framework`_ document.
+ modularity and scalability. See the
+ :ref:`Authentication Framework & Chain of Trust` document.
All missing mandatory features are now implemented.
- The FVP and Juno ports may now use the hash of the ROTPK stored in the
@@ -1826,7 +1827,7 @@
create mappings only for areas in the memory map that it needs.
- A Secure Payload Dispatcher (OPTEED) for the OP-TEE Trusted OS has been
- added. Details of using it with TF-A can be found in `OP-TEE Dispatcher`_
+ added. Details of using it with TF-A can be found in :ref:`OP-TEE Dispatcher`
Issues resolved since last release
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -2423,16 +2424,6 @@
*Copyright (c) 2013-2019, Arm Limited and Contributors. All rights reserved.*
.. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
-.. _PSCI Integration Guide: ./getting_started/psci-lib-integration-guide.rst
-.. _Developer Certificate of Origin: ../dco.txt
-.. _Contribution Guide: ./process/contributing.rst
-.. _Authentication framework: ./design/auth-framework.rst
-.. _Firmware Update: ./design/firmware-update.rst
-.. _Firmware Design: ./design/firmware-design.rst
-.. _TF-A Reset Design: ./design/reset-design.rst
-.. _Power Domain Topology Design: ./design/psci-pd-tree.rst
-.. _image terminology document: ./getting_started/image-terminology.rst
-.. _Authentication Framework: ./design/auth-framework.rst
-.. _OP-TEE Dispatcher: ./spd/optee-dispatcher.rst
.. _tf-issue#501: https://github.com/ARM-software/tf-issues/issues/501
.. _PR#1002: https://github.com/ARM-software/arm-trusted-firmware/pull/1002#issuecomment-312650193
+.. _mbed TLS releases: https://tls.mbed.org/tech-updates/releases
diff --git a/docs/components/arm-sip-service.rst b/docs/components/arm-sip-service.rst
index e450d37..2d58586 100644
--- a/docs/components/arm-sip-service.rst
+++ b/docs/components/arm-sip-service.rst
@@ -24,9 +24,9 @@
Performance Measurement Framework (PMF)
---------------------------------------
-The `Performance Measurement Framework`_
+The :ref:`Performance Measurement Framework <firmware_design_pmf>`
allows callers to retrieve timestamps captured at various paths in TF-A
-execution. It's described in detail in `Firmware Design document`_.
+execution.
Execution State Switching service
---------------------------------
@@ -89,8 +89,6 @@
--------------
-*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.*
.. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
-.. _Performance Measurement Framework: ../design/firmware-design.rst#user-content-performance-measurement-framework
-.. _Firmware Design document: ../design/firmware-design.rst
diff --git a/docs/components/exception-handling.rst b/docs/components/exception-handling.rst
index 0d01733..3f38685 100644
--- a/docs/components/exception-handling.rst
+++ b/docs/components/exception-handling.rst
@@ -26,8 +26,8 @@
Through various control bits in the ``SCR_EL3`` register, the Arm architecture
allows for asynchronous exceptions to be routed to EL3. As described in the
-`Interrupt Framework Design`_ document, depending on the chosen interrupt
-routing model, TF-A appropriately sets the ``FIQ`` and ``IRQ`` bits of
+:ref:`Interrupt Management Framework` document, depending on the chosen
+interrupt routing model, TF-A appropriately sets the ``FIQ`` and ``IRQ`` bits of
``SCR_EL3`` register to effect this routing. For most use cases, other than for
the purpose of facilitating context switch between Normal and Secure worlds,
FIQs and IRQs routed to EL3 are not required to be handled in EL3.
@@ -143,8 +143,9 @@
------------------
The |EHF| is a client of *Interrupt Management Framework*, and registers the
-top-level handler for interrupts that target EL3, as described in the `Interrupt
-Framework Design`_ document. This has the following implications.
+top-level handler for interrupts that target EL3, as described in the
+:ref:`Interrupt Management Framework` document. This has the following
+implications:
- On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of
sufficient priority are signalled as FIQs, and therefore will be routed to
@@ -618,9 +619,8 @@
exception descriptor and the programmed priority of interrupts handled by the
dispatcher match. The |EHF| cannot verify that this has been followed.
-----
+--------------
-*Copyright (c) 2018, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2018-2019, Arm Limited and Contributors. All rights reserved.*
-.. _Interrupt Framework Design: ../design/interrupt-framework-design.rst
.. _SDEI specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
diff --git a/docs/components/firmware-update.rst b/docs/components/firmware-update.rst
index 30bdc24..a591565 100644
--- a/docs/components/firmware-update.rst
+++ b/docs/components/firmware-update.rst
@@ -7,15 +7,15 @@
This document describes the design of the Firmware Update (FWU) feature, which
enables authenticated firmware to update firmware images from external
interfaces such as USB, UART, SD-eMMC, NAND, NOR or Ethernet to SoC Non-Volatile
-memories such as NAND Flash, LPPDR2-NVM or any memory determined by the
+memories such as NAND Flash, LPDDR2-NVM or any memory determined by the
platform. This feature functions even when the current firmware in the system
is corrupt or missing; it therefore may be used as a recovery mode. It may also
be complemented by other, higher level firmware update software.
FWU implements a specific part of the Trusted Board Boot Requirements (TBBR)
specification, Arm DEN0006C-1. It should be used in conjunction with the
-`Trusted Board Boot`_ design document, which describes the image authentication
-parts of the Trusted Firmware-A (TF-A) TBBR implementation.
+:ref:`Trusted Board Boot` design document, which describes the image
+authentication parts of the Trusted Firmware-A (TF-A) TBBR implementation.
Scope
~~~~~
@@ -53,10 +53,11 @@
at other Exception Levels.
#. Export a platform interface to provide FWU common code with the information
it needs, and to enable platform specific FWU functionality. See the
- `Porting Guide`_ for details of this interface.
+ :ref:`Porting Guide` for details of this interface.
TF-A uses abbreviated image terminology for FWU images like for other TF-A
-images. An overview of this terminology can be found `here`_.
+images. See the :ref:`Image Terminology` document for an explanation of these
+terms.
The following diagram shows the FWU boot flow for Arm development platforms.
Arm CSS platforms like Juno have a System Control Processor (SCP), and these
@@ -70,8 +71,8 @@
Each FWU image and certificate is identified by a unique ID, defined by the
platform, which BL1 uses to fetch an image descriptor (``image_desc_t``) via a
call to ``bl1_plat_get_image_desc()``. The same ID is also used to prepare the
-Chain of Trust (Refer to the `Authentication Framework Design`_
-for more information).
+Chain of Trust (Refer to the :ref:`Authentication Framework & Chain of Trust`
+document for more information).
The image descriptor includes the following information:
@@ -394,11 +395,6 @@
*Copyright (c) 2015-2019, Arm Limited and Contributors. All rights reserved.*
-.. _Trusted Board Boot: ../design/trusted-board-boot.rst
-.. _Porting Guide: ../getting_started/porting-guide.rst
-.. _here: ../getting_started/image-terminology.rst
-.. _Authentication Framework Design: ../design/auth-framework.rst
.. _Universally Unique Identifier: https://tools.ietf.org/rfc/rfc4122.txt
-
.. |Flow Diagram| image:: ../resources/diagrams/fwu_flow.png
.. |FWU state machine| image:: ../resources/diagrams/fwu_states.png
diff --git a/docs/components/platform-interrupt-controller-API.rst b/docs/components/platform-interrupt-controller-API.rst
index 7890cd3..9d02f45 100644
--- a/docs/components/platform-interrupt-controller-API.rst
+++ b/docs/components/platform-interrupt-controller-API.rst
@@ -3,9 +3,8 @@
This document lists the optional platform interrupt controller API that
abstracts the runtime configuration and control of interrupt controller from the
-generic code. The mandatory APIs are described in the `porting guide`__.
-
-.. __: ../getting_started/porting-guide.rst#interrupt-management-framework-in-bl31
+generic code. The mandatory APIs are described in the
+:ref:`Porting Guide <porting_guide_imf_in_bl31>`.
Function: unsigned int plat_ic_get_running_priority(void); [optional]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -303,6 +302,6 @@
In case of Arm standard platforms using GIC, the implementation of the API
masks out the interrupt ID field from the acknowledged value from GIC.
-----
+--------------
-*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/components/ras.rst b/docs/components/ras.rst
index 137c0c3..3d81f17 100644
--- a/docs/components/ras.rst
+++ b/docs/components/ras.rst
@@ -1,9 +1,6 @@
Reliability, Availability, and Serviceability (RAS) Extensions
==============================================================
-.. |EHF| replace:: Exception Handling Framework
-.. |TF-A| replace:: Trusted Firmware-A
-
This document describes |TF-A| support for Arm Reliability, Availability, and
Serviceability (RAS) extensions. RAS is a mandatory extension for Armv8.2 and
later CPUs, and also an optional extension to the base Armv8.0 architecture.
@@ -247,6 +244,6 @@
.. __: exception-handling.rst#non-interrupt-flow
.. __: exception-handling.rst#activating-and-deactivating-priorities
-----
+--------------
-*Copyright (c) 2018, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2018-2019, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/components/sdei.rst b/docs/components/sdei.rst
index 2a777b3..c5275a0 100644
--- a/docs/components/sdei.rst
+++ b/docs/components/sdei.rst
@@ -7,7 +7,7 @@
Introduction
------------
-`Software Delegated Exception Interface`_ (SDEI) is an Arm specification for
+Software Delegated Exception Interface (|SDEI|) is an Arm specification for
Non-secure world to register handlers with firmware to receive notifications
about system events. Firmware will first receive the system events by way of
asynchronous exceptions and, in response, arranges for the registered handler to
@@ -50,9 +50,6 @@
SDEI dispatcher in TF-A, and assumes that the reader is familiar with the SDEI
specification, the interfaces, and their requirements.
-.. [#std-event] Except event 0, which is defined by the SDEI specification as a
- standard event.
-
Defining events
---------------
@@ -78,12 +75,10 @@
To define event 0, the macro ``SDEI_DEFINE_EVENT_0()`` should be used. This
macro takes only one parameter: an SGI number to signal other PEs.
-To define an event that's meant to be `explicitly dispatched`__ (i.e., not as a
+To define an event that's meant to be explicitly dispatched (i.e., not as a
result of receiving an SDEI interrupt), the macro ``SDEI_EXPLICIT_EVENT()``
should be used. It accepts two parameters:
-.. __: `Explicit dispatch of events`_
-
- The event number (as above);
- Event priority: ``SDEI_MAPF_CRITICAL`` or ``SDEI_MAPF_NORMAL``, as described
@@ -110,9 +105,7 @@
- Statically bound shared and private interrupts must be bound to shared and
private interrupts on the platform, respectively. See the section on
- `interrupt configuration`__.
-
- .. __: `Configuration within Exception Handling Framework`_
+ `Configuration within Exception Handling Framework`_.
- Both arrays should be one-dimensional. The ``REGISTER_SDEI_MAP()`` macro
takes care of replicating private events for each PE on the platform.
@@ -130,9 +123,8 @@
~~~~~~~~~~~
Event flags describe the properties of the event. They are bit maps that can be
-``OR``\ ed to form parameters to macros that `define events`__.
-
-.. __: `Defining events`_
+``OR``\ ed to form parameters to macros that define events (see
+`Defining events`_).
- ``SDEI_MAPF_DYNAMIC``: Marks the event as dynamic. Dynamic events can be
bound to (or released from) any Non-secure interrupt at runtime via the
@@ -196,7 +188,7 @@
be configured as *Group 0*. Additionally, on GICv2 systems, the build option
``GICV2_G0_FOR_EL3`` must be set to ``1``.
-See also `SDEI porting requirements`_.
+See also :ref:`porting_guide_sdei_requirements`.
Determining client EL
---------------------
@@ -250,10 +242,6 @@
requested event is dispatched to the client (assuming all the conditions are
met), and when the handler completes, the preempted execution resumes.
-.. [#critical-event] Examples of critical event are *SError*, *Synchronous
- External Abort*, *Fault Handling interrupt*, or *Error
- Recovery interrupt* from one of RAS nodes in the system.
-
Conditions for event dispatch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -307,10 +295,8 @@
Porting requirements
--------------------
-The porting requirements of the SDEI dispatcher are outlined in the `porting
-guide`__.
-
-.. __: `SDEI porting requirements`_
+The porting requirements of the SDEI dispatcher are outlined in the
+:ref:`Porting Guide <porting_guide_sdei_requirements>`.
Note on writing SDEI event handlers
-----------------------------------
@@ -364,10 +350,18 @@
smc #0
b .
-----
+--------------
-*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.*
+
+.. rubric:: Footnotes
+
+.. [#std-event] Except event 0, which is defined by the SDEI specification as a
+ standard event.
+
+.. [#critical-event] Examples of critical events are *SError*, *Synchronous
+ External Abort*, *Fault Handling interrupt* or *Error
+ Recovery interrupt* from one of RAS nodes in the system.
.. _SDEI specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
-.. _SDEI porting requirements: ../getting_started/porting-guide.rst#sdei-porting-requirements
.. _Software Delegated Exception Interface: `SDEI specification`_
diff --git a/docs/components/xlat-tables-lib-v2-design.rst b/docs/components/xlat-tables-lib-v2-design.rst
index 786dd3b..af5151f 100644
--- a/docs/components/xlat-tables-lib-v2-design.rst
+++ b/docs/components/xlat-tables-lib-v2-design.rst
@@ -30,8 +30,8 @@
-----------------------------
This document focuses on version 2 of the library, whose sources are available
-in the `lib/xlat_tables_v2`_ directory. Version 1 of the library can still be
-found in `lib/xlat_tables`_ directory but it is less flexible and doesn't
+in the ``lib/xlat_tables_v2`` directory. Version 1 of the library can still be
+found in ``lib/xlat_tables`` directory but it is less flexible and doesn't
support dynamic mapping. Although potential bug fixes will be applied to both
versions, future features enhancements will focus on version 2 and might not be
back-ported to version 1. Therefore, it is recommended to use version 2,
@@ -62,7 +62,7 @@
- its attributes;
- its mapping granularity (optional).
-See the ``struct mmap_region`` type in `xlat_tables_v2.h`_.
+See the ``struct mmap_region`` type in ``xlat_tables_v2.h``.
The user usually provides a list of such mmap regions to map and lets the
library transpose that in a set of translation tables. As a result, the library
@@ -73,7 +73,7 @@
read-write, executable or not, secure or non-secure, and so on). In the case of
the EL1&0 translation regime, the attributes also specify whether the region is
a User region (EL0) or Privileged region (EL1). See the ``MT_xxx`` definitions
-in `xlat_tables_v2.h`_. Note that for the EL1&0 translation regime the Execute
+in ``xlat_tables_v2.h``. Note that for the EL1&0 translation regime the Execute
Never attribute is set simultaneously for both EL1 and EL0.
The granularity controls the translation table level to go down to when mapping
@@ -162,7 +162,7 @@
- size of the virtual address space: ``PLAT_VIRT_ADDR_SPACE_SIZE``;
- size of the physical address space: ``PLAT_PHY_ADDR_SPACE_SIZE``.
-Please refer to the `Porting Guide`_ for more details about these macros.
+Please refer to the :ref:`Porting Guide` for more details about these macros.
Static and dynamic memory regions
@@ -201,7 +201,7 @@
------------
The external APIs exposed by this library are declared and documented in the
-`xlat_tables_v2.h`_ header file. This should be the reference point for
+``xlat_tables_v2.h`` header file. This should be the reference point for
getting information about the usage of the different APIs this library
provides. This section just provides some extra details and clarifications.
@@ -284,7 +284,7 @@
provides functions such as ``mmap_add_region_ctx`` that let the caller specify
the translation tables context affected by them.
- See `xlat_tables_core.c`_.
+ See ``xlat_tables_core.c``.
- **Active context module**
@@ -293,14 +293,14 @@
This module provides functions such as ``mmap_add_region``, that directly
affect the BL image using them.
- See `xlat_tables_context.c`_.
+ See ``xlat_tables_context.c``.
- **Utilities module**
Provides additional functionality like debug print of the current state of the
translation tables and helpers to query memory attributes and to modify them.
- See `xlat_tables_utils.c`_.
+ See ``xlat_tables_utils.c``.
- **Architectural module**
@@ -309,7 +309,7 @@
MMU, or calculate the Physical Address Space size. They do not need a
translation context to work on.
- See `aarch32/xlat_tables_arch.c`_ and `aarch64/xlat_tables_arch.c`_.
+ See ``aarch32/xlat_tables_arch.c`` and ``aarch64/xlat_tables_arch.c``.
From mmap regions to translation tables
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -343,7 +343,7 @@
bound by the level of depth of the translation tables (the Armv8-A architecture
allows up to 4 lookup levels).
-By default [#granularity-ref]_, the algorithm will attempt to minimize the
+By default [#granularity]_, the algorithm will attempt to minimize the
number of translation tables created to satisfy the user's request. It will
favour mapping a region using the biggest possible blocks, only creating a
sub-table if it is strictly necessary. This is to reduce the memory footprint of
@@ -374,9 +374,6 @@
refer to the comments in the source code of the core module for more details
about the sorting algorithm in use.
-.. [#granularity-ref] That is, when mmap regions do not enforce their mapping
- granularity.
-
TLB maintenance operations
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -402,20 +399,19 @@
invalid translation table entry [#tlb-no-invalid-entry]_, this means that this
mapping cannot be cached in the TLBs.
-.. [#tlb-reset-ref] See section D4.9 `Translation Lookaside Buffers (TLBs)`, subsection `TLB behavior at reset` in Armv8-A, rev C.a.
-.. [#tlb-no-invalid-entry] See section D4.10.1 `General TLB maintenance requirements` in Armv8-A, rev C.a.
+.. rubric:: Footnotes
+
+.. [#granularity] That is, when mmap regions do not enforce their mapping
+ granularity.
+
+.. [#tlb-reset-ref] See section D4.9 ``Translation Lookaside Buffers (TLBs)``,
+ subsection ``TLB behavior at reset`` in Armv8-A, rev C.a.
+
+.. [#tlb-no-invalid-entry] See section D4.10.1 ``General TLB maintenance
+ requirements`` in Armv8-A, rev C.a.
--------------
-*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.*
-.. _lib/xlat_tables_v2: ../../lib/xlat_tables_v2
-.. _lib/xlat_tables: ../../lib/xlat_tables
-.. _xlat_tables_v2.h: ../../include/lib/xlat_tables/xlat_tables_v2.h
-.. _xlat_tables_context.c: ../../lib/xlat_tables_v2/xlat_tables_context.c
-.. _xlat_tables_core.c: ../../lib/xlat_tables_v2/xlat_tables_core.c
-.. _xlat_tables_utils.c: ../../lib/xlat_tables_v2/xlat_tables_utils.c
-.. _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:: ../resources/diagrams/xlat_align.png
diff --git a/docs/conf.py b/docs/conf.py
index b267de0..a100241 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -15,9 +15,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
diff --git a/docs/contents.rst b/docs/contents.rst
deleted file mode 100644
index 4909dab..0000000
--- a/docs/contents.rst
+++ /dev/null
@@ -1,165 +0,0 @@
-Trusted Firmware-A Documentation Contents
-=========================================
-
-This document serves as a list of the documentation that is included with the
-Trusted Firmware-A source.
-
-Introduction
-------------
-
-`About Trusted Firmware-A`_
-
-Getting Started
----------------
-
-`Frequently-Asked Questions (FAQ)`_
-
-`Image Terminology`_
-
-`Porting Guide`_
-
-`User Guide`_
-
-Contributing
-------------
-
-`Coding Style and Guidelines`_
-
-`Contributor Acknowledgements`_
-
-`Contributor's Guide`_
-
-`License`_
-
-`Maintainers`_
-
-Processes and Policies
-----------------------
-
-`Platform Compatibility Policy`_
-
-`Release Processes`_
-
-Secure Payload Dispatch
------------------------
-
-`OP-TEE Dispatcher`_
-
-`Trusted Little Kernel (TLK) Dispatcher`_
-
-`Trusty Dispatcher`_
-
-System Design and Components
-----------------------------
-
-`Arm CPU Specific Build Macros`_
-
-`Arm SiP Services`_
-
-`Authentication Framework & Chain of Trust`_
-
-`CPU Reset`_
-
-`EL3 Runtime Service Writer’s Guide`_
-
-`Exception Handling Framework`_
-
-`Firmware Design Overview`_
-
-`Firmware Update (FWU)`_
-
-`Interrupt Management Framework`_
-
-`Library at ROM`_
-
-`Platform Interrupt Controller API`_
-
-`PSCI Library Integration Guide for Armv8-A AArch32 systems`_
-
-`PSCI Power Domain Tree design`_
-
-`Reliability, Availability, and Serviceability (RAS) Extensions`_
-
-`Secure Partition Manager`_
-
-`Software Delegated Exception Interface`_
-
-`Translation (XLAT) Tables Library`_
-
-`Trusted Board Boot Design Guide`_
-
-Performance and Testing
------------------------
-
-`PSCI Performance Measurements on Arm Juno Development Platform`_
-
-Security and Advisories
------------------------
-
-`Security Processes`_
-
-`TFV-1`_
-
-`TFV-2`_
-
-`TFV-3`_
-
-`TFV-4`_
-
-`TFV-5`_
-
-`TFV-6`_
-
-`TFV-7`_
-
-`TFV-8`_
-
-Other Documents
----------------
-
-`Change Log`_
-
-.. _About Trusted Firmware-A: ../readme.rst
-.. _Frequently-Asked Questions (FAQ): ./process/faq.rst
-.. _Image Terminology: ./getting_started/image-terminology.rst
-.. _Porting Guide: ./getting_started/porting-guide.rst
-.. _User Guide: ./getting_started/user-guide.rst
-.. _Coding Style and Guidelines: ./process/coding-guidelines.rst
-.. _Contributor Acknowledgements: ./acknowledgements.rst
-.. _`Contributor's Guide`: ./process/contributing.rst
-.. _License: ../license.rst
-.. _Maintainers: ./maintainers.rst
-.. _Platform Compatibility Policy: ./process/platform-compatibility-policy.rst
-.. _Release Processes: ./process/release-information.rst
-.. _Arm SiP Services: ./components/arm-sip-service.rst
-.. _Exception Handling Framework: ./components/exception-handling.rst
-.. _Firmware Update (FWU): ./components/firmware-update.rst
-.. _Interrupt Management Framework: ./design/interrupt-framework-design.rst
-.. _Library at ROM: ./components/romlib-design.rst
-.. _Platform Interrupt Controller API: ./components/platform-interrupt-controller-API.rst
-.. _`Reliability, Availability, and Serviceability (RAS) Extensions`: ./components/ras.rst
-.. _Secure Partition Manager: ./components/secure-partition-manager-design.rst
-.. _Software Delegated Exception Interface: ./components/sdei.rst
-.. _Translation (XLAT) Tables Library: ./components/xlat-tables-lib-v2-design.rst
-.. _OP-TEE Dispatcher: ./components/spd/optee-dispatcher.rst
-.. _Trusted Little Kernel (TLK) Dispatcher: ./components/spd/tlk-dispatcher.rst
-.. _Trusty Dispatcher: ./components/spd/trusty-dispatcher.rst
-.. _Arm CPU Specific Build Macros: ./design/cpu-specific-build-macros.rst
-.. _`Authentication Framework & Chain of Trust`: ./design/auth-framework.rst
-.. _CPU Reset: ./design/reset-design.rst
-.. _`EL3 Runtime Service Writer’s Guide`: ./getting_started/rt-svc-writers-guide.rst
-.. _Firmware Design Overview: ./design/firmware-design.rst
-.. _PSCI Library Integration Guide for Armv8-A AArch32 systems: ./getting_started/psci-lib-integration-guide.rst
-.. _PSCI Power Domain Tree design: ./design/psci-pd-tree.rst
-.. _Trusted Board Boot Design Guide: ./design/trusted-board-boot.rst
-.. _PSCI Performance Measurements on Arm Juno Development Platform: ./perf/psci-performance-juno.rst
-.. _Security Processes: ./process/security.rst
-.. _Change Log: ./change-log.rst
-.. _TFV-1: ./security_advisories/security-advisory-tfv-1.rst
-.. _TFV-2: ./security_advisories/security-advisory-tfv-2.rst
-.. _TFV-3: ./security_advisories/security-advisory-tfv-3.rst
-.. _TFV-4: ./security_advisories/security-advisory-tfv-4.rst
-.. _TFV-5: ./security_advisories/security-advisory-tfv-5.rst
-.. _TFV-6: ./security_advisories/security-advisory-tfv-6.rst
-.. _TFV-7: ./security_advisories/security-advisory-tfv-7.rst
-.. _TFV-8: ./security_advisories/security-advisory-tfv-8.rst
diff --git a/docs/design/auth-framework.rst b/docs/design/auth-framework.rst
index 7de8ee1..93f691b 100644
--- a/docs/design/auth-framework.rst
+++ b/docs/design/auth-framework.rst
@@ -637,9 +637,9 @@
The TBBR specifies the additional certificates that must accompany these images
for a proper authentication. Details about the TBBR CoT may be found in the
-`Trusted Board Boot`_ document.
+:ref:`Trusted Board Boot` document.
-Following the `Platform Porting Guide`_, a platform must provide unique
+Following the :ref:`Porting Guide`, a platform must provide unique
identifiers for all the images and certificates that will be loaded during the
boot process. If a platform is using the TBBR as a reference for trusted boot,
these identifiers can be obtained from ``include/common/tbbr/tbbr_img_def.h``.
@@ -967,6 +967,4 @@
*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.*
-.. _Trusted Board Boot: ./trusted-board-boot.rst
-.. _Platform Porting Guide: ../getting_started/porting-guide.rst
.. _TBBR-Client specification: https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a
diff --git a/docs/design/cpu-specific-build-macros.rst b/docs/design/cpu-specific-build-macros.rst
index a392eea..891703b 100644
--- a/docs/design/cpu-specific-build-macros.rst
+++ b/docs/design/cpu-specific-build-macros.rst
@@ -29,6 +29,8 @@
platform contains at least 1 CPU that requires dynamic mitigation.
Defaults to 0.
+.. _arm_cpu_macros_errata_workarounds:
+
CPU Errata Workarounds
----------------------
@@ -47,9 +49,8 @@
errata workaround is ``ERRATA_<Processor name>_<ID>``, where the ``Processor name``
is for example ``A57`` for the ``Cortex_A57`` CPU.
-Refer to the section *CPU errata status reporting* in
-`Firmware Design guide`_ for information on how to write errata workaround
-functions.
+Refer to :ref:`firmware_design_cpu_errata_reporting` for information on how to
+write errata workaround functions.
All workarounds are disabled by default. The platform is responsible for
enabling these workarounds according to its requirement by defining the
@@ -326,6 +327,5 @@
.. _Cortex-A53 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm048406/index.html
.. _Cortex-A57 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm049219/index.html
.. _Cortex-A72 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm012079/index.html
-.. _Firmware Design guide: firmware-design.rst
.. _Cortex-A57 Software Optimization Guide: http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/Cortex_A57_Software_Optimization_Guide_external.pdf
.. _Arm DSU Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm138168/index.html
diff --git a/docs/design/firmware-design.rst b/docs/design/firmware-design.rst
index 2cbd9c9..4958fc0 100644
--- a/docs/design/firmware-design.rst
+++ b/docs/design/firmware-design.rst
@@ -2,24 +2,27 @@
===============
Trusted Firmware-A (TF-A) implements a subset of the Trusted Board Boot
-Requirements (TBBR) Platform Design Document (PDD) [1]_ for Arm reference
-platforms. The TBB sequence starts when the platform is powered on and runs up
+Requirements (TBBR) Platform Design Document (PDD) for Arm reference
+platforms.
+
+The TBB sequence starts when the platform is powered on and runs up
to the stage where it hands-off control to firmware running in the normal
world in DRAM. This is the cold boot path.
-TF-A also implements the Power State Coordination Interface PDD [2]_ as a
+TF-A also implements the `Power State Coordination Interface PDD`_ as a
runtime service. PSCI is the interface from normal world software to firmware
implementing power management use-cases (for example, secondary CPU boot,
hotplug and idle). Normal world software can access TF-A runtime services via
the Arm SMC (Secure Monitor Call) instruction. The SMC instruction must be
-used as mandated by the SMC Calling Convention [3]_.
+used as mandated by the SMC Calling Convention (`SMCCC`_).
TF-A implements a framework for configuring and managing interrupts generated
in either security state. The details of the interrupt management framework
-and its design can be found in TF-A Interrupt Management Design guide [4]_.
+and its design can be found in :ref:`Interrupt Management Framework`.
TF-A also implements a library for setting up and managing the translation
-tables. The details of this library can be found in `Translation tables design`_.
+tables. The details of this library can be found in
+:ref:`Translation (XLAT) Tables Library`.
TF-A can be built to support either AArch64 or AArch32 execution state.
@@ -34,7 +37,7 @@
all CPUs. The secondary CPUs are kept in a safe platform-specific state until
the primary CPU has performed enough initialization to boot them.
-Refer to the `Reset Design`_ for more information on the effect of the
+Refer to the :ref:`CPU Reset` for more information on the effect of the
``COLD_BOOT_SINGLE_CPU`` platform build option.
The cold boot path in this implementation of TF-A depends on the execution
@@ -136,15 +139,15 @@
Whenever a CPU is released from reset, BL1 needs to distinguish between a warm
boot and a cold boot. This is done using platform-specific mechanisms (see the
-``plat_get_my_entrypoint()`` function in the `Porting Guide`_). In the case of a
-warm boot, a CPU is expected to continue execution from a separate
+``plat_get_my_entrypoint()`` function in the :ref:`Porting Guide`). In the case
+of a warm boot, a CPU is expected to continue execution from a separate
entrypoint. In the case of a cold boot, the secondary CPUs are placed in a safe
platform-specific state (see the ``plat_secondary_cold_boot_setup()`` function in
-the `Porting Guide`_) while the primary CPU executes the remaining cold boot path
-as described in the following sections.
+the :ref:`Porting Guide`) while the primary CPU executes the remaining cold boot
+path as described in the following sections.
This step only applies when ``PROGRAMMABLE_RESET_ADDRESS=0``. Refer to the
-`Reset Design`_ for more information on the effect of the
+:ref:`CPU Reset` for more information on the effect of the
``PROGRAMMABLE_RESET_ADDRESS`` platform build option.
Architectural initialization
@@ -157,8 +160,8 @@
BL1 sets up simple exception vectors for both synchronous and asynchronous
exceptions. The default behavior upon receiving an exception is to populate
a status code in the general purpose register ``X0/R0`` and call the
- ``plat_report_exception()`` function (see the `Porting Guide`_). The status
- code is one of:
+ ``plat_report_exception()`` function (see the :ref:`Porting Guide`). The
+ status code is one of:
For AArch64:
@@ -217,7 +220,7 @@
- ``BL1_SMC_RUN_IMAGE``: This SMC is raised by BL2 to make BL1 pass control
to EL3 Runtime Software.
- - All SMCs listed in section "BL1 SMC Interface" in the `Firmware Update`_
+ - All SMCs listed in section "BL1 SMC Interface" in the :ref:`Firmware Update (FWU)`
Design Guide are supported for AArch64 only. These SMCs are currently
not supported when BL1 is built for AArch32.
@@ -307,14 +310,15 @@
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
After performing platform setup, BL1 common code calls
-``bl1_plat_get_next_image_id()`` to determine if `Firmware Update`_ is required or
-to proceed with the normal boot process. If the platform code returns
-``BL2_IMAGE_ID`` then the normal boot sequence is executed as described in the
-next section, else BL1 assumes that `Firmware Update`_ is required and execution
-passes to the first image in the `Firmware Update`_ process. In either case, BL1
-retrieves a descriptor of the next image by calling ``bl1_plat_get_image_desc()``.
-The image descriptor contains an ``entry_point_info_t`` structure, which BL1
-uses to initialize the execution state of the next image.
+``bl1_plat_get_next_image_id()`` to determine if :ref:`Firmware Update (FWU)` is
+required or to proceed with the normal boot process. If the platform code
+returns ``BL2_IMAGE_ID`` then the normal boot sequence is executed as described
+in the next section, else BL1 assumes that :ref:`Firmware Update (FWU)` is
+required and execution passes to the first image in the
+:ref:`Firmware Update (FWU)` process. In either case, BL1 retrieves a descriptor
+of the next image by calling ``bl1_plat_get_image_desc()``. The image descriptor
+contains an ``entry_point_info_t`` structure, which BL1 uses to initialize the
+execution state of the next image.
BL2 image load and execution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -440,7 +444,8 @@
memory with the entrypoint and Saved Program Status Register (``SPSR``) of the
normal world software image. The entrypoint is the load address of the BL33
image. The ``SPSR`` is determined as specified in Section 5.13 of the
-`PSCI PDD`_. This information is passed to the EL3 Runtime Software.
+`Power State Coordination Interface PDD`_. This information is passed to the
+EL3 Runtime Software.
AArch64 BL31 (EL3 Runtime Software) execution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -539,7 +544,7 @@
exception vectors implement more elaborate support for handling SMCs since this
is the only mechanism to access the runtime services implemented by BL31 (PSCI
for example). BL31 checks each SMC for validity as specified by the
-`SMC calling convention PDD`_ before passing control to the required SMC
+`SMC Calling Convention PDD`_ before passing control to the required SMC
handler routine.
BL31 programs the ``CNTFRQ_EL0`` register with the clock frequency of the system
@@ -812,7 +817,8 @@
The warm boot entrypoint may be implemented by using TF-A
``psci_warmboot_entrypoint()`` function. In that case, the platform must fulfil
-the pre-requisites mentioned in the `PSCI Library integration guide`_.
+the pre-requisites mentioned in the
+:ref:`PSCI Library Integration guide for Armv8-A AArch32 systems`.
EL3 runtime services framework
------------------------------
@@ -1051,7 +1057,9 @@
The PSCI implementation in TF-A is a library which can be integrated with
AArch64 or AArch32 EL3 Runtime Software for Armv8-A systems. A guide to
integrating PSCI library with AArch32 EL3 Runtime Software can be found
-`here`_.
+at :ref:`PSCI Library Integration guide for Armv8-A AArch32 systems`.
+
+.. _firmware_design_sel1_spd:
Secure-EL1 Payloads and Dispatchers
-----------------------------------
@@ -1258,7 +1266,7 @@
Details for implementing a CPU specific reset handler can be found in
Section 8. Details for implementing a platform specific reset handler can be
-found in the `Porting Guide`_ (see the ``plat_reset_handler()`` function).
+found in the :ref:`Porting Guide` (see the ``plat_reset_handler()`` function).
When adding functionality to a reset handler, keep in mind that if a different
reset handling behavior is required between the first and the subsequent
@@ -1292,6 +1300,8 @@
- Interrupt configuration (either ``GIC_INTR_CFG_LEVEL`` or
``GIC_INTR_CFG_EDGE``).
+.. _firmware_design_cpu_ops_fwk:
+
CPU specific operations framework
---------------------------------
@@ -1333,7 +1343,7 @@
any CPU optimization it wants to enable for each CPU. It can also specify
the CPU errata workarounds to be applied for each CPU type during reset
handling by defining CPU errata compile time macros. Details on these macros
-can be found in `CPU specific build macros`_.
+can be found in the :ref:`Arm CPU Specific Build Macros` document.
The CPU specific operations framework depends on the ``cpu_ops`` structure which
needs to be exported for each type of CPU in the platform. It is defined in
@@ -1399,6 +1409,8 @@
be reported and a pointer to the ASCII list of register names in a format
expected by the crash reporting framework.
+.. _firmware_design_cpu_errata_reporting:
+
CPU errata status reporting
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1408,8 +1420,8 @@
therefore some are enabled by default, others not. Platform ports shall
override build options to enable or disable errata as appropriate. The CPU
drivers take care of applying errata workarounds that are enabled and applicable
-to a given CPU. Refer to the section titled *CPU Errata Workarounds* in `CPUBM`_
-for more information.
+to a given CPU. Refer to :ref:`arm_cpu_macros_errata_workarounds` for more
+information.
Functions in CPU drivers that apply errata workaround must follow the
conventions listed below.
@@ -1660,7 +1672,7 @@
point during a cold boot.
- On Juno, SCP_BL2 is loaded temporarily into the EL3 Runtime Software memory
- region and transfered to the SCP before being overwritten by EL3 Runtime
+ region and transferred to the SCP before being overwritten by EL3 Runtime
Software.
- BL32 (for AArch64) can be loaded in one of the following locations:
@@ -1866,7 +1878,7 @@
Library at ROM
---------------
-Please refer to the `ROMLIB Design`_ document.
+Please refer to the :ref:`Library at ROM` document.
Firmware Image Package (FIP)
----------------------------
@@ -1978,11 +1990,11 @@
By default, all data structures which are susceptible to accesses with
mismatched attributes from various CPUs are allocated in a coherent memory
-region (refer to section 2.1 of `Porting Guide`_). The coherent memory region
-accesses are Outer Shareable, non-cacheable and they can be accessed
-with the Device nGnRE attributes when the MMU is turned on. Hence, at the
-expense of at least an extra page of memory, TF-A is able to work around
-coherency issues due to mismatched memory attributes.
+region (refer to section 2.1 of :ref:`Porting Guide`). The coherent memory
+region accesses are Outer Shareable, non-cacheable and they can be accessed with
+the Device nGnRE attributes when the MMU is turned on. Hence, at the expense of
+at least an extra page of memory, TF-A is able to work around coherency issues
+due to mismatched memory attributes.
The alternative to the above approach is to allocate the susceptible data
structures in Normal WriteBack WriteAllocate Inner shareable memory. This
@@ -2188,7 +2200,7 @@
whether coherent memory should be used. If a platform disables
``USE_COHERENT_MEM`` and needs to use bakery locks in the porting layer, it can
optionally define macro ``PLAT_PERCPU_BAKERY_LOCK_SIZE`` (see the
-`Porting Guide`_). Refer to the reference platform code for examples.
+:ref:`Porting Guide`). Refer to the reference platform code for examples.
Isolating code and read-only data on separate memory pages
----------------------------------------------------------
@@ -2381,6 +2393,8 @@
section section can be reclaimed for any data which is accessed after cold
boot initialization and it is upto the platform to make the decision.
+.. _firmware_design_pmf:
+
Performance Measurement Framework
---------------------------------
@@ -2529,7 +2543,7 @@
targets the base Armv8.0-A architecture; i.e. as if ``ARM_ARCH_MAJOR`` == 8
and ``ARM_ARCH_MINOR`` == 0, which are also their respective default values.
-See also the *Summary of build options* in `User Guide`_.
+See also the *Summary of build options* in :ref:`User Guide`.
For details on the Architecture Extension and available features, please refer
to the respective Architecture Extension Supplement.
@@ -2609,7 +2623,7 @@
Cortex-A15 target.
Platform can also set ``ARM_WITH_NEON=yes`` to enable neon support.
-Note that using neon at runtime has constraints on non secure wolrd context.
+Note that using neon at runtime has constraints on non secure world context.
TF-A does not yet provide VFP context management.
Directive ``ARM_CORTEX_A<x>`` and ``ARM_WITH_NEON`` are used to set
@@ -2668,37 +2682,26 @@
FDTs provide a description of the hardware platform and are used by the Linux
kernel at boot time. These can be found in the ``fdts`` directory.
-References
-----------
+.. rubric:: References
-.. [#] `Trusted Board Boot Requirements CLIENT (TBBR-CLIENT) Armv8-A (ARM DEN0006D)`_
-.. [#] `Power State Coordination Interface PDD`_
-.. [#] `SMC Calling Convention PDD`_
-.. [#] `TF-A Interrupt Management Design guide`_.
+- `Trusted Board Boot Requirements CLIENT (TBBR-CLIENT) Armv8-A (ARM DEN0006D)`_
+
+- `Power State Coordination Interface PDD`_
+
+- `SMC Calling Convention PDD`_
+
+- :ref:`Interrupt Management Framework`
--------------
*Copyright (c) 2013-2019, Arm Limited and Contributors. All rights reserved.*
-.. _Reset Design: ./reset-design.rst
-.. _Porting Guide: ../getting_started/porting-guide.rst
-.. _Firmware Update: ../components/firmware-update.rst
-.. _PSCI PDD: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
-.. _SMC calling convention PDD: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
-.. _PSCI Library integration guide: ../getting_started/psci-lib-integration-guide.rst
+.. _Power State Coordination Interface PDD: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
.. _SMCCC: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
.. _Power State Coordination Interface PDD: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
-.. _here: ../getting_started/psci-lib-integration-guide.rst
-.. _CPU specific build macros: ./cpu-specific-build-macros.rst
-.. _CPUBM: ./cpu-specific-build-macros.rst
.. _Arm ARM: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487a.e/index.html
-.. _User Guide: ../getting_started/user-guide.rst
.. _SMC Calling Convention PDD: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
-.. _TF-A Interrupt Management Design guide: ./interrupt-framework-design.rst
-.. _Translation tables design: ../components/xlat-tables-lib-v2-design.rst
-.. _Exception Handling Framework: ../components/exception-handling.rst
-.. _ROMLIB Design: ../components/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:: ../resources/diagrams/rt-svc-descs-layout.png
diff --git a/docs/design/interrupt-framework-design.rst b/docs/design/interrupt-framework-design.rst
index 4a864f9..d155cb3 100644
--- a/docs/design/interrupt-framework-design.rst
+++ b/docs/design/interrupt-framework-design.rst
@@ -177,10 +177,10 @@
programmed in ``SCR_EL3`` while applying the routing model for a type of
interrupt. The platform provides this information through the
``plat_interrupt_type_to_line()`` API (described in the
-`Porting Guide`_). For example, on the FVP port when the platform uses an Arm GICv2
-interrupt controller, Secure-EL1 interrupts are signaled through the FIQ signal
-while Non-secure interrupts are signaled through the IRQ signal. This applies
-when execution is in either security state.
+:ref:`Porting Guide`). For example, on the FVP port when the platform uses an
+Arm GICv2 interrupt controller, Secure-EL1 interrupts are signaled through the
+FIQ signal while Non-secure interrupts are signaled through the IRQ signal.
+This applies when execution is in either security state.
Effect of mapping of several interrupt types to one signal
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -255,7 +255,7 @@
associated interrupt numbers. It should configure the interrupt controller to
enable the secure interrupts, ensure that their priority is always higher than
the non-secure interrupts and target them to the primary CPU. It should also
-export the interface described in the `Porting Guide`_ to enable
+export the interface described in the :ref:`Porting Guide` to enable
handling of interrupts.
In the remainder of this document, for the sake of simplicity a Arm GICv2 system
@@ -1013,7 +1013,6 @@
*Copyright (c) 2014-2019, Arm Limited and Contributors. All rights reserved.*
-.. _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:: ../resources/diagrams/sec-int-handling.png
diff --git a/docs/design/reset-design.rst b/docs/design/reset-design.rst
index ccd717a..a92ceeb 100644
--- a/docs/design/reset-design.rst
+++ b/docs/design/reset-design.rst
@@ -6,9 +6,9 @@
integrator can tailor this code to the system configuration to some extent,
resulting in a simplified and more optimised boot flow.
-This document should be used in conjunction with the `Firmware Design`_, which
-provides greater implementation details around the reset code, specifically
-for the cold boot path.
+This document should be used in conjunction with the :ref:`Firmware Design`
+document which provides greater implementation details around the reset code,
+specifically for the cold boot path.
General reset code flow
-----------------------
@@ -109,11 +109,14 @@
Although the Arm FVP platform does not support programming the reset base
address dynamically at run-time, it is possible to set the initial value of the
-``RVBAR_EL3`` register at start-up. This feature is provided on the Base FVP only.
+``RVBAR_EL3`` register at start-up. This feature is provided on the Base FVP
+only.
+
It allows the Arm FVP port to support the ``RESET_TO_BL31`` configuration, in
which case the ``bl31.bin`` image must be loaded to its run address in Trusted
SRAM and all CPU reset vectors be changed from the default ``0x0`` to this run
-address. See the `User Guide`_ for details of running the FVP models in this way.
+address. See the :ref:`User Guide` for details of running the FVP models in this
+way.
Although technically it would be possible to program the reset base address with
the right support in the SCP firmware, this is currently not implemented so the
@@ -150,10 +153,7 @@
--------------
-*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.*
-
-.. _Firmware Design: firmware-design.rst
-.. _User Guide: ../getting_started/user-guide.rst
+*Copyright (c) 2015-2019, Arm Limited and Contributors. All rights reserved.*
.. |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
diff --git a/docs/design/trusted-board-boot.rst b/docs/design/trusted-board-boot.rst
index 82be272..f3b1c36 100644
--- a/docs/design/trusted-board-boot.rst
+++ b/docs/design/trusted-board-boot.rst
@@ -8,8 +8,9 @@
This document describes the design of Trusted Firmware-A (TF-A) TBB, which is an
implementation of the `Trusted Board Boot Requirements (TBBR)`_ specification,
-Arm DEN0006D. It should be used in conjunction with the `Firmware Update`_
-design document, which implements a specific aspect of the TBBR.
+Arm DEN0006D. It should be used in conjunction with the
+:ref:`Firmware Update (FWU)` design document, which implements a specific aspect
+of the TBBR.
Chain of Trust
--------------
@@ -186,7 +187,8 @@
The Trusted Board Boot implementation spans both generic and platform-specific
BL1 and BL2 code, and in tool code on the host build machine. The feature is
-enabled through use of specific build flags as described in the `User Guide`_.
+enabled through use of specific build flags as described in the
+:ref:`User Guide`.
On the host machine, a tool generates the certificates, which are included in
the FIP along with the boot loader images. These certificates are loaded in
@@ -201,10 +203,11 @@
The authentication framework included in TF-A provides support to implement
the desired trusted boot sequence. Arm platforms use this framework to
-implement the boot requirements specified in the `TBBR-client`_ document.
+implement the boot requirements specified in the
+`Trusted Board Boot Requirements (TBBR)`_ document.
More information about the authentication framework can be found in the
-`Auth Framework`_ document.
+:ref:`Authentication Framework & Chain of Trust` document.
Certificate Generation Tool
---------------------------
@@ -221,15 +224,11 @@
The tool resides in the ``tools/cert_create`` directory. It uses OpenSSL SSL
library version 1.0.1 or later to generate the X.509 certificates. Instructions
-for building and using the tool can be found in the `User Guide`_.
+for building and using the tool can be found in the :ref:`User Guide`.
--------------
*Copyright (c) 2015-2019, Arm Limited and Contributors. All rights reserved.*
-.. _Firmware Update: ../components/firmware-update.rst
.. _X.509 v3: https://tools.ietf.org/rfc/rfc5280.txt
-.. _User Guide: ../getting_started/user-guide.rst
-.. _Auth Framework: auth-framework.rst
-.. _TBBR-client: https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a
-.. _Trusted Board Boot Requirements (TBBR): `TBBR-client`_
+.. _Trusted Board Boot Requirements (TBBR): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a
diff --git a/docs/getting_started/docs-build.rst b/docs/getting_started/docs-build.rst
new file mode 100644
index 0000000..fa07642
--- /dev/null
+++ b/docs/getting_started/docs-build.rst
@@ -0,0 +1,77 @@
+Building Documentation
+======================
+
+To create a rendered copy of this documentation locally you can use the
+`Sphinx`_ tool to build and package the plain-text documents into HTML-formatted
+pages.
+
+If you are building the documentation for the first time then you will need to
+check that you have the required software packages, as described in the
+*Prerequisites* section that follows.
+
+.. note::
+ An online copy of the documentation is available at
+ https://www.trustedfirmware.org/docs/tf-a, if you want to view a rendered
+ copy without doing a local build.
+
+Prerequisites
+-------------
+
+For building a local copy of the |TF-A| documentation you will need, at minimum:
+
+- Python 3 (3.5 or later)
+- PlantUML (1.2017.15 or later)
+
+You must also install the Python modules that are specified in the
+``requirements.txt`` file in the root of the ``docs`` directory. These modules
+can be installed using ``pip3`` (the Python Package Installer). Passing this
+requirements file as an argument to ``pip3`` automatically installs the specific
+module versions required by |TF-A|.
+
+An example set of installation commands for Ubuntu 18.04 LTS follows, assuming
+that the working directory is ``docs``:
+
+.. code:: shell
+
+ sudo apt install python3 python3-pip plantuml
+ pip3 install [--user] -r requirements.txt
+
+.. note::
+ Several other modules will be installed as dependencies. Please review
+ the list to ensure that there will be no conflicts with other modules already
+ installed in your environment.
+
+Passing the optional ``--user`` argument to ``pip3`` will install the Python
+packages only for the current user. Omitting this argument will attempt to
+install the packages globally and this will likely require the command to be run
+as root or using ``sudo``.
+
+.. note::
+ More advanced usage instructions for *pip* are beyond the scope of this
+ document but you can refer to the `pip homepage`_ for detailed guides.
+
+Building rendered documentation
+-------------------------------
+
+From the ``docs`` directory of the project, run the following commands. It is
+important to note that you will not get the correct result if the commands are
+run from the project root directory, as that would invoke the top-level Makefile
+for |TF-A| itself.
+
+.. code:: shell
+
+ make clean
+ make html
+
+Output from the build process will be placed in:
+
+::
+
+ <tf-a root>/docs/build/html/
+
+--------------
+
+*Copyright (c) 2019, Arm Limited. All rights reserved.*
+
+.. _Sphinx: http://www.sphinx-doc.org/en/master/
+.. _pip homepage: https://pip.pypa.io/en/stable/
diff --git a/docs/getting_started/image-terminology.rst b/docs/getting_started/image-terminology.rst
index d9e08f7..5993d6e 100644
--- a/docs/getting_started/image-terminology.rst
+++ b/docs/getting_started/image-terminology.rst
@@ -7,7 +7,7 @@
General Notes
-------------
-- Some of the names and abbreviated names have changed to accomodate new
+- Some of the names and abbreviated names have changed to accommodate new
requirements. The changed names are as backward compatible as possible to
minimize confusion. Where applicable, the previous names are indicated. Some
code, documentation and build artefacts may still refer to the previous names;
@@ -44,7 +44,7 @@
~~~~~~~~~~~~~~~~~~~~~~~
Typically, this is the first code to execute on the AP and cannot be modified.
-Its primary purpose is to perform the minimum intialization necessary to load
+Its primary purpose is to perform the minimum initialization necessary to load
and authenticate an updateable AP firmware image into an executable RAM
location, then hand-off control to that image.
@@ -96,7 +96,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Typically, this is the first code to execute on the SCP and cannot be modified.
-Its primary purpose is to perform the minimum intialization necessary to load
+Its primary purpose is to perform the minimum initialization necessary to load
and authenticate an updateable SCP firmware image into an executable RAM
location, then hand-off control to that image. This may be performed in
conjunction with other processor firmware (for example, ``AP_BL1`` and
@@ -129,7 +129,7 @@
Typically, this is the first normal world code to execute on the AP during a
firmware update operation, and cannot be modified. Its primary purpose is to
-load subequent firmware update images from an external interface and communicate
+load subsequent firmware update images from an external interface and communicate
with ``AP_BL1`` to authenticate those images.
During firmware update, there are (potentially) multiple transitions between the
diff --git a/docs/getting_started/index.rst b/docs/getting_started/index.rst
index 23608f8..07e3753 100644
--- a/docs/getting_started/index.rst
+++ b/docs/getting_started/index.rst
@@ -7,6 +7,7 @@
:numbered:
user-guide
+ docs-build
image-terminology
porting-guide
psci-lib-integration-guide
diff --git a/docs/getting_started/porting-guide.rst b/docs/getting_started/porting-guide.rst
index 9eb7c17..9cca75e 100644
--- a/docs/getting_started/porting-guide.rst
+++ b/docs/getting_started/porting-guide.rst
@@ -13,20 +13,20 @@
- Defining certain constants (for example #defines).
The platform-specific functions and variables are declared in
-`include/plat/common/platform.h`_. The firmware provides a default implementation
-of variables and functions to fulfill the optional requirements. These
-implementations are all weakly defined; they are provided to ease the porting
-effort. Each platform port can override them with its own implementation if the
-default implementation is inadequate.
+``include/plat/common/platform.h``. The firmware provides a default
+implementation of variables and functions to fulfill the optional requirements.
+These implementations are all weakly defined; they are provided to ease the
+porting effort. Each platform port can override them with its own implementation
+if the default implementation is inadequate.
Some modifications are common to all Boot Loader (BL) stages. Section 2
discusses these in detail. The subsequent sections discuss the remaining
modifications for each BL stage in detail.
-This document should be read in conjunction with the TF-A `User Guide`_.
+This document should be read in conjunction with the TF-A :ref:`User Guide`.
-Please refer to the `Platform compatibility policy`_ for the policy regarding
-compatibility and deprecation of these porting interfaces.
+Please refer to the :ref:`Platform Compatibility Policy` for the policy
+regarding compatibility and deprecation of these porting interfaces.
Only Arm development platforms (such as FVP and Juno) may use the
functions/definitions in ``include/plat/arm/common/`` and the corresponding
@@ -98,7 +98,7 @@
include path with the following constants defined. This will require updating
the list of ``PLAT_INCLUDES`` in the ``platform.mk`` file.
-Platform ports may optionally use the file `include/plat/common/common_def.h`_,
+Platform ports may optionally use the file ``include/plat/common/common_def.h``,
which provides typical values for some of the constants below. These values are
likely to be suitable for all platform ports.
@@ -115,8 +115,8 @@
- **#define : PLATFORM_STACK_SIZE**
Defines the normal stack memory available to each CPU. This constant is used
- by `plat/common/aarch64/platform_mp_stack.S`_ and
- `plat/common/aarch64/platform_up_stack.S`_.
+ by ``plat/common/aarch64/platform_mp_stack.S`` and
+ ``plat/common/aarch64/platform_up_stack.S``.
- **define : CACHE_WRITEBACK_GRANULE**
@@ -542,14 +542,14 @@
Maximum number of partition entries required by the platform. This allows
control how much memory is allocated for partition entries. The default
value is 128.
- `For example, define the build flag in platform.mk`_:
+ For example, define the build flag in ``platform.mk``:
PLAT_PARTITION_MAX_ENTRIES := 12
$(eval $(call add_define,PLAT_PARTITION_MAX_ENTRIES))
- **PLAT_PARTITION_BLOCK_SIZE**
The size of partition block. It could be either 512 bytes or 4096 bytes.
The default value is 512.
- `For example, define the build flag in platform.mk`_:
+ For example, define the build flag in ``platform.mk``:
PLAT_PARTITION_BLOCK_SIZE := 4096
$(eval $(call add_define,PLAT_PARTITION_BLOCK_SIZE))
@@ -828,7 +828,8 @@
x9 - x29.
This function plays a crucial role in the power domain topology framework in
-PSCI and details of this can be found in `Power Domain Topology Design`_.
+PSCI and details of this can be found in
+:ref:`PSCI Power Domain Tree Structure`.
Function : plat_core_pos_by_mpidr()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -844,7 +845,7 @@
be invoked by BL31 after the power domain topology is initialized and can
utilize the C runtime environment. For further details about how TF-A
represents the power domain topology and how this relates to the linear CPU
-index, please refer `Power Domain Topology Design`_.
+index, please refer :ref:`PSCI Power Domain Tree Structure`.
Function : plat_get_mbedtls_heap() [when TRUSTED_BOARD_BOOT == 1]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -895,8 +896,8 @@
constant ``PLATFORM_STACK_SIZE``.
Common implementations of this function for the UP and MP BL images are
-provided in `plat/common/aarch64/platform_up_stack.S`_ and
-`plat/common/aarch64/platform_mp_stack.S`_
+provided in ``plat/common/aarch64/platform_up_stack.S`` and
+``plat/common/aarch64/platform_mp_stack.S``
Function : plat_get_my_stack()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -913,8 +914,8 @@
constant ``PLATFORM_STACK_SIZE``.
Common implementations of this function for the UP and MP BL images are
-provided in `plat/common/aarch64/platform_up_stack.S`_ and
-`plat/common/aarch64/platform_mp_stack.S`_
+provided in ``plat/common/aarch64/platform_up_stack.S`` and
+``plat/common/aarch64/platform_mp_stack.S``
Function : plat_report_exception()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -937,12 +938,12 @@
For AArch64, this function receives the exception type as its argument.
Possible values for exceptions types are listed in the
-`include/common/bl_common.h`_ header file. Note that these constants are not
+``include/common/bl_common.h`` header file. Note that these constants are not
related to any architectural exception code; they are just a TF-A convention.
For AArch32, this function receives the exception mode as its argument.
Possible values for exception modes are listed in the
-`include/lib/aarch32/arch.h`_ header file.
+``include/lib/aarch32/arch.h`` header file.
Function : plat_reset_handler()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -953,12 +954,12 @@
Return : void
A platform may need to do additional initialization after reset. This function
-allows the platform to do the platform specific intializations. Platform
+allows the platform to do the platform specific initializations. Platform
specific errata workarounds could also be implemented here. The API should
preserve the values of callee saved registers x19 to x29.
The default implementation doesn't do anything. If a platform needs to override
-the default implementation, refer to the `Firmware Design`_ for general
+the default implementation, refer to the :ref:`Firmware Design` for general
guidelines.
Function : plat_disable_acp()
@@ -1475,8 +1476,8 @@
When the platform has a non-TF-A Boot ROM it is desirable to jump
directly to BL2 instead of TF-A BL1. In this case BL2 is expected to
-execute at EL3 instead of executing at EL1. Refer to the `Firmware
-Design`_ for more information.
+execute at EL3 instead of executing at EL1. Refer to the :ref:`Firmware Design`
+document for more information.
All mandatory functions of BL2 must be implemented, except the functions
bl2_early_platform_setup and bl2_el3_plat_arch_setup, because
@@ -1852,6 +1853,8 @@
assertion is raised if the value of the constant is not aligned to the cache
line boundary.
+.. _porting_guide_sdei_requirements:
+
SDEI porting requirements
~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1936,7 +1939,7 @@
logical grouping of CPUs that share some state, then level 1 is that group of
CPUs (for example, a cluster), and level 2 is a group of clusters (for
example, the system). More details on the power domain topology and its
-organization can be found in `Power Domain Topology Design`_.
+organization can be found in :ref:`PSCI Power Domain Tree Structure`.
BL31's platform initialization code exports a pointer to the platform-specific
power management operations required for the PSCI implementation to function
@@ -2048,13 +2051,13 @@
This function returns a pointer to the byte array containing the power domain
topology tree description. The format and method to construct this array are
-described in `Power Domain Topology Design`_. The BL31 PSCI initialization code
-requires this array to be described by the platform, either statically or
-dynamically, to initialize the power domain topology tree. In case the array
-is populated dynamically, then plat_core_pos_by_mpidr() and
-plat_my_core_pos() should also be implemented suitably so that the topology
-tree description matches the CPU indices returned by these APIs. These APIs
-together form the platform interface for the PSCI topology framework.
+described in :ref:`PSCI Power Domain Tree Structure`. The BL31 PSCI
+initialization code requires this array to be described by the platform, either
+statically or dynamically, to initialize the power domain topology tree. In case
+the array is populated dynamically, then plat_core_pos_by_mpidr() and
+plat_my_core_pos() should also be implemented suitably so that the topology tree
+description matches the CPU indices returned by these APIs. These APIs together
+form the platform interface for the PSCI topology framework.
Function : plat_setup_psci_ops() [mandatory]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2076,10 +2079,10 @@
A description of each member of this structure is given below. Please refer to
the Arm FVP specific implementation of these handlers in
-`plat/arm/board/fvp/fvp_pm.c`_ as an example. For each PSCI function that the
+``plat/arm/board/fvp/fvp_pm.c`` as an example. For each PSCI function that the
platform wants to support, the associated operation or operations in this
structure must be provided and implemented (Refer section 4 of
-`Firmware Design`_ for the PSCI API supported in TF-A). To disable a PSCI
+:ref:`Firmware Design` for the PSCI API supported in TF-A). To disable a PSCI
function in a platform port, the operation should be removed from this
structure instead of providing an empty implementation.
@@ -2367,13 +2370,15 @@
bytes is protected by ``MEM_PROTECT``. If the region is protected
then it must return 0, otherwise it must return a negative number.
+.. _porting_guide_imf_in_bl31:
+
Interrupt Management framework (in BL31)
----------------------------------------
BL31 implements an Interrupt Management Framework (IMF) to manage interrupts
generated in either security state and targeted to EL1 or EL2 in the non-secure
state or EL3/S-EL1 in the secure state. The design of this framework is
-described in the `IMF Design Guide`_
+described in the :ref:`Interrupt Management Framework`
A platform should export the following APIs to support the IMF. The following
text briefly describes each API and its implementation in Arm standard
@@ -2383,7 +2388,7 @@
and `3.0 (GICv3)`_. Juno builds the Arm platform layer to use GICv2 and the
FVP can be configured to use either GICv2 or GICv3 depending on the build flag
``FVP_USE_GIC_DRIVER`` (See FVP platform specific build options in
-`User Guide`_ for more details).
+:ref:`User Guide` for more details).
See also: `Interrupt Controller Abstraction APIs`__.
@@ -2405,10 +2410,10 @@
from a given security state. This API must be invoked at EL3.
The first parameter will be one of the ``INTR_TYPE_*`` values (see
-`IMF Design Guide`_) indicating the target type of the interrupt, the second parameter is the
-security state of the originating execution context. The return result is the
-bit position in the ``SCR_EL3`` register of the respective interrupt trap: IRQ=1,
-FIQ=2.
+:ref:`Interrupt Management Framework`) indicating the target type of the
+interrupt, the second parameter is the security state of the originating
+execution context. The return result is the bit position in the ``SCR_EL3``
+register of the respective interrupt trap: IRQ=1, FIQ=2.
In the case of Arm standard platforms using GICv2, S-EL1 interrupts are
configured as FIQs and Non-secure interrupts as IRQs from either security
@@ -2772,7 +2777,7 @@
added to the local implementation.
Some C headers have been obtained from `FreeBSD`_ and `SCC`_, while others have
-been written specifically for TF-A. Fome implementation files have been obtained
+been written specifically for TF-A. Some implementation files have been obtained
from `FreeBSD`_, others have been written specifically for TF-A as well. The
files can be found in ``include/lib/libc`` and ``lib/libc``.
@@ -2792,7 +2797,7 @@
It is mandatory to implement at least one storage driver. For the Arm
development platforms the Firmware Image Package (FIP) driver is provided as
the default means to load data from storage (see the "Firmware Image Package"
-section in the `User Guide`_). The storage layer is described in the header file
+section in the :ref:`User Guide`). The storage layer is described in the header file
``include/drivers/io/io_storage.h``. The implementation of the common library
is in ``drivers/io/io_storage.c`` and the driver files are located in
``drivers/io/``.
@@ -2843,22 +2848,7 @@
*Copyright (c) 2013-2019, Arm Limited and Contributors. All rights reserved.*
-.. _include/plat/common/platform.h: ../include/plat/common/platform.h
-.. _include/plat/arm/common/plat_arm.h: ../include/plat/arm/common/plat_arm.h%5D
-.. _User Guide: user-guide.rst
-.. _include/plat/common/common_def.h: ../include/plat/common/common_def.h
-.. _include/plat/arm/common/arm_def.h: ../include/plat/arm/common/arm_def.h
-.. _plat/common/aarch64/platform_mp_stack.S: ../plat/common/aarch64/platform_mp_stack.S
-.. _plat/common/aarch64/platform_up_stack.S: ../plat/common/aarch64/platform_up_stack.S
-.. _For example, define the build flag in platform.mk: PLAT_PL061_MAX_GPIOS%20:=%20160
-.. _Power Domain Topology Design: ../design/psci-pd-tree.rst
-.. _include/common/bl_common.h: ../include/common/bl_common.h
-.. _include/lib/aarch32/arch.h: ../include/lib/aarch32/arch.h
-.. _Firmware Design: ../design/firmware-design.rst
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
-.. _plat/arm/board/fvp/fvp_pm.c: ../plat/arm/board/fvp/fvp_pm.c
-.. _Platform compatibility policy: ../process/platform-compatibility-policy.rst
-.. _IMF Design Guide: ../design/interrupt-framework-design.rst
.. _Arm Generic Interrupt Controller version 2.0 (GICv2): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0048b/index.html
.. _3.0 (GICv3): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0069b/index.html
.. _FreeBSD: https://www.freebsd.org
diff --git a/docs/getting_started/psci-lib-integration-guide.rst b/docs/getting_started/psci-lib-integration-guide.rst
index 25936d9..1351fff 100644
--- a/docs/getting_started/psci-lib-integration-guide.rst
+++ b/docs/getting_started/psci-lib-integration-guide.rst
@@ -437,13 +437,13 @@
- PLAT_MAX_PWR_LVL_STATES (optional)
- PLAT_PCPU_DATA_SIZE (optional)
-The details of these APIs/macros can be found in `Porting Guide`_.
+The details of these APIs/macros can be found in the :ref:`Porting Guide`.
All platform specific operations for power management are done via
``plat_psci_ops_t`` callbacks registered by the platform when
``plat_setup_psci_ops()`` API is called. The description of each of
the callbacks in ``plat_psci_ops_t`` can be found in PSCI section of the
-`Porting Guide`_. If any these callbacks are not registered, then the
+:ref:`Porting Guide`. If any these callbacks are not registered, then the
PSCI API associated with that callback will not be supported by PSCI
library.
@@ -524,12 +524,12 @@
~~~~~~~~~~~~~~
The CPU operations (cpu_ops) framework implement power down sequence specific
-to the CPU and the details of which can be found in the
-``CPU specific operations framework`` section of `Firmware Design`_. The TF-A
-tree implements the ``cpu_ops`` for various supported CPUs and the EL3 Runtime
-Software needs to include the required ``cpu_ops`` in its build. The start and
-end of the ``cpu_ops`` descriptors must be exported by the EL3 Runtime Software
-via the ``__CPU_OPS_START__`` and ``__CPU_OPS_END__`` linker symbols.
+to the CPU and the details of which can be found at
+:ref:`firmware_design_cpu_ops_fwk`. The TF-A tree implements the ``cpu_ops``
+for various supported CPUs and the EL3 Runtime Software needs to include the
+required ``cpu_ops`` in its build. The start and end of the ``cpu_ops``
+descriptors must be exported by the EL3 Runtime Software via the
+``__CPU_OPS_START__`` and ``__CPU_OPS_END__`` linker symbols.
The ``cpu_ops`` descriptors also include reset sequences and may include errata
workarounds for the CPU. The EL3 Runtime Software can choose to call this
@@ -538,11 +538,9 @@
--------------
-*Copyright (c) 2016-2018, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2016-2019, Arm Limited and Contributors. All rights reserved.*
.. _PSCI spec: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
.. _SMCCC: https://silver.arm.com/download/ARM_and_AMBA_Architecture/AR570-DA-80002-r0p0-00rel0/ARM_DEN0028A_SMC_Calling_Convention.pdf
.. _PSCI specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
.. _PSCI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
-.. _Porting Guide: ./porting-guide.rst
-.. _Firmware Design: ../design/firmware-design.rst
diff --git a/docs/getting_started/rt-svc-writers-guide.rst b/docs/getting_started/rt-svc-writers-guide.rst
index 6c17a1f..6a06025 100644
--- a/docs/getting_started/rt-svc-writers-guide.rst
+++ b/docs/getting_started/rt-svc-writers-guide.rst
@@ -21,8 +21,8 @@
into the BL31 image. This simplifies the integration of common software from
Arm to support `PSCI`_, Secure Monitor for a Trusted OS and SoC specific
software. The common runtime services framework ensures that SMC Functions are
-dispatched to their respective service implementation - the `Firmware Design`_
-provides details of how this is achieved.
+dispatched to their respective service implementation - the
+:ref:`Firmware Design` document provides details of how this is achieved.
The interface and operation of the runtime services depends heavily on the
concepts and definitions described in the `SMCCC`_, in particular SMC Function
@@ -79,11 +79,11 @@
Getting started
---------------
-TF-A has a `services`_ directory in the source tree under which
+TF-A has a ``services`` directory in the source tree under which
each owning entity can place the implementation of its runtime service. The
-`PSCI`_ implementation is located here in the `lib/psci`_ directory.
+`PSCI`_ implementation is located here in the ``lib/psci`` directory.
-Runtime service sources will need to include the `runtime_svc.h`_ header file.
+Runtime service sources will need to include the ``runtime_svc.h`` header file.
Registering a runtime service
-----------------------------
@@ -100,7 +100,7 @@
is also used for diagnostic purposes
- ``_start`` and ``_end`` values must be based on the ``OEN_*`` values defined in
- `smccc.h`_
+ ``smccc.h``
- ``_type`` must be one of ``SMC_TYPE_FAST`` or ``SMC_TYPE_YIELD``
@@ -132,7 +132,7 @@
#. The ``_type`` is one of ``SMC_TYPE_FAST`` or ``SMC_TYPE_YIELD``
#. ``_setup`` and ``_smch`` routines have been specified
-`std_svc_setup.c`_ provides an example of registering a runtime service:
+``std_svc_setup.c`` provides an example of registering a runtime service:
.. code:: c
@@ -296,13 +296,7 @@
--------------
-*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2014-2019, Arm Limited and Contributors. All rights reserved.*
.. _SMCCC: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
-.. _Firmware Design: ../design/firmware-design.rst
-.. _services: ../../services
-.. _lib/psci: ../../lib/psci
-.. _runtime_svc.h: ../../include/common/runtime_svc.h
-.. _smccc.h: ../../include/lib/smccc.h
-.. _std_svc_setup.c: ../../services/std_svc/std_svc_setup.c
diff --git a/docs/getting_started/user-guide.rst b/docs/getting_started/user-guide.rst
index a4886c6..3dd23e5 100644
--- a/docs/getting_started/user-guide.rst
+++ b/docs/getting_started/user-guide.rst
@@ -22,7 +22,7 @@
This document also assumes that the user is familiar with the `FVP models`_ and
the different command line options available to launch the model.
-This document should be used in conjunction with the `Firmware Design`_.
+This document should be used in conjunction with the :ref:`Firmware Design`.
Host machine requirements
-------------------------
@@ -86,8 +86,8 @@
source, for submission to the project, the source must be in compliance with
this style guide.
-Additional, project-specific guidelines are defined in the `Trusted Firmware-A
-Coding Guidelines`_ document.
+Additional, project-specific guidelines are defined in the
+:ref:`Coding Style & Guidelines` document.
To assist with coding style compliance, the project Makefile contains two
targets which both utilise the `checkpatch.pl` script that ships with the Linux
@@ -194,7 +194,7 @@
an AArch32 EL3 Runtime Software. Some AArch32 EL3 Runtime Software may
include other runtime services, for example Trusted OS services. A guide
to integrate PSCI library with AArch32 EL3 Runtime Software can be found
- `here`_.
+ at :ref:`PSCI Library Integration guide for Armv8-A AArch32 systems`.
- (AArch64 only) The TSP (Test Secure Payload), corresponding to the BL32
image, is not compiled in by default. Refer to the
@@ -260,11 +260,11 @@
- ``ARM_ARCH_MAJOR``: The major version of Arm Architecture to target when
compiling TF-A. Its value must be numeric, and defaults to 8 . See also,
*Armv8 Architecture Extensions* and *Armv7 Architecture Extensions* in
- `Firmware Design`_.
+ :ref:`Firmware Design`.
- ``ARM_ARCH_MINOR``: The minor version of Arm Architecture to target when
compiling TF-A. Its value must be a numeric, and defaults to 0. See also,
- *Armv8 Architecture Extensions* in `Firmware Design`_.
+ *Armv8 Architecture Extensions* in :ref:`Firmware Design`.
- ``BL2``: This is an optional build option which specifies the path to BL2
image for the ``fip`` target. In this case, the BL2 in the TF-A will not be
@@ -477,7 +477,7 @@
is AArch32.
- ``ENABLE_SPM`` : Boolean option to enable the Secure Partition Manager (SPM).
- Refer to the `Secure Partition Manager Design guide`_ for more details about
+ Refer to :ref:`Secure Partition Manager` for more details about
this feature. Default is 0.
- ``ENABLE_SVE_FOR_NS``: Boolean option to enable Scalable Vector Extension
@@ -525,7 +525,7 @@
- ``GENERATE_COT``: Boolean flag used to build and execute the ``cert_create``
tool to create certificates as per the Chain of Trust described in
- `Trusted Board Boot`_. The build system then calls ``fiptool`` to
+ :ref:`Trusted Board Boot`. The build system then calls ``fiptool`` to
include the certificates in the FIP and FWU_FIP. Default value is '0'.
Specify both ``TRUSTED_BOARD_BOOT=1`` and ``GENERATE_COT=1`` to include support
@@ -743,8 +743,8 @@
- ``SEPARATE_CODE_AND_RODATA``: Whether code and read-only data should be
isolated on separate memory pages. This is a trade-off between security and
memory usage. See "Isolating code and read-only data on separate memory
- pages" section in `Firmware Design`_. This flag is disabled by default and
- affects all BL images.
+ pages" section in :ref:`Firmware Design`. This flag is disabled by default
+ and affects all BL images.
- ``SPD``: Choose a Secure Payload Dispatcher component to be built into TF-A.
This build option is only valid if ``ARCH=aarch64``. The value should be
@@ -782,7 +782,7 @@
- ``TSP_INIT_ASYNC``: Choose BL32 initialization method as asynchronous or
synchronous, (see "Initializing a BL32 Image" section in
- `Firmware Design`_). It can take the value 0 (BL32 is initialized using
+ :ref:`Firmware Design`). It can take the value 0 (BL32 is initialized using
synchronous method) or 1 (BL32 is initialized using asynchronous method).
Default is 0.
@@ -806,14 +806,14 @@
- ``USE_COHERENT_MEM``: This flag determines whether to include the coherent
memory region in the BL memory map or not (see "Use of Coherent memory in
- TF-A" section in `Firmware Design`_). It can take the value 1
+ TF-A" section in :ref:`Firmware Design`). It can take the value 1
(Coherent memory region is included) or 0 (Coherent memory region is
excluded). Default is 1.
- ``USE_ROMLIB``: This flag determines whether library at ROM will be used.
This feature creates a library of functions to be placed in ROM and thus
- reduces SRAM usage. Refer to `Library at ROM`_ for further details. Default
- is 0.
+ reduces SRAM usage. Refer to :ref:`Library at ROM` for further details.
+ Default is 0.
- ``USE_SPINLOCK_CAS``: Setting this build flag to 1 selects the spinlock
implementation variant using the ARMv8.1-LSE compare-and-swap instruction.
@@ -922,7 +922,7 @@
SBROM library must be specified via ``CCSBROM_LIB_PATH`` flag.
For a better understanding of these options, the Arm development platform memory
-map is explained in the `Firmware Design`_.
+map is explained in the :ref:`Firmware Design`.
Arm CSS platform specific build options
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -976,14 +976,14 @@
The default value is 0.
- ``FVP_HW_CONFIG_DTS`` : Specify the path to the DTS file to be compiled
- to DTB and packaged in FIP as the HW_CONFIG. See `Firmware Design`_ for
+ to DTB and packaged in FIP as the HW_CONFIG. See :ref:`Firmware Design` for
details on HW_CONFIG. By default, this is initialized to a sensible DTS
file in ``fdts/`` folder depending on other build options. But some cases,
like shifted affinity format for MPIDR, cannot be detected at build time
and this option is needed to specify the appropriate DTS file.
- ``FVP_HW_CONFIG`` : Specify the path to the HW_CONFIG blob to be packaged in
- FIP. See `Firmware Design`_ for details on HW_CONFIG. This option is
+ FIP. See :ref:`Firmware Design` for details on HW_CONFIG. This option is
similar to the ``FVP_HW_CONFIG_DTS`` option, but it directly specifies the
HW_CONFIG blob instead of the DTS file. This option is useful to override
the default HW_CONFIG selected by the build system.
@@ -1015,7 +1015,7 @@
.. 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`_).
+ platforms** section in the :ref:`Firmware Design`).
Extra debug options can be passed to the build system by setting ``CFLAGS`` or
``LDFLAGS``:
@@ -1056,7 +1056,8 @@
The TSP is coupled with a companion runtime service in the BL31 firmware,
called the TSPD. Therefore, if you intend to use the TSP, the BL31 image
must be recompiled as well. For more information on SPs and SPDs, see the
-`Secure-EL1 Payloads and Dispatchers`_ section in the `Firmware Design`_.
+:ref:`Secure-EL1 Payloads and Dispatchers <firmware_design_sel1_spd>` section
+in the :ref:`Firmware Design` document.
First clean the TF-A build directory to get rid of any previous BL31 binary.
Then to build the TSP image use:
@@ -1174,15 +1175,15 @@
The unpack operation will fail if the images already exist at the
destination. In that case, use -f or --force to continue.
-More information about FIP can be found in the `Firmware Design`_ document.
+More information about FIP can be found in the :ref:`Firmware Design` document.
Building FIP images with support for Trusted Board Boot
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Trusted Board Boot primarily consists of the following two features:
-- Image Authentication, described in `Trusted Board Boot`_, and
-- Firmware Update, described in `Firmware Update`_
+- Image Authentication, described in :ref:`Trusted Board Boot`, and
+- Firmware Update, described in :ref:`Firmware Update (FWU)`
The following steps should be followed to build FIP and (optionally) FWU_FIP
images with support for these features:
@@ -1248,9 +1249,9 @@
in the output build directory.
#. The optional FWU_FIP contains any additional images to be loaded from
- Non-Volatile storage during the `Firmware Update`_ process. To build the
- FWU_FIP, any FWU images required by the platform must be specified on the
- command line. On Arm development platforms like Juno, these are:
+ Non-Volatile storage during the :ref:`Firmware Update (FWU)` process. To
+ build the FWU_FIP, any FWU images required by the platform must be specified
+ on the command line. On Arm development platforms like Juno, these are:
- NS_BL2U. The AP non-secure Firmware Updater image.
- SCP_BL2U. The SCP Firmware Update Configuration image.
@@ -1729,6 +1730,8 @@
above. The process to load binaries to memory is the one explained in
`Booting an EL3 payload on Juno`_.
+.. _user_guide_run_fvp:
+
Running the software on FVP
---------------------------
@@ -1901,7 +1904,7 @@
- BL1 is loaded at the start of the Trusted ROM.
- The Firmware Image Package is loaded at the start of NOR FLASH0.
- The firmware loads the FDT packaged in FIP to the DRAM. The FDT load address
- is specified via the ``hw_config_addr`` property in `TB_FW_CONFIG for FVP`_.
+ is specified via the ``hw_config_addr`` property in ``TB_FW_CONFIG`` for FVP.
- The default use-case for the Foundation FVP is to use the ``--gicv3`` option
and enable the GICv3 device in the model. Note that without this option,
the Foundation FVP defaults to legacy (Versatile Express) memory map which
@@ -2202,18 +2205,9 @@
.. _`Linux Coding Style`: https://www.kernel.org/doc/html/latest/process/coding-style.html
.. _Linux master tree: https://github.com/torvalds/linux/tree/master/
.. _Dia: https://wiki.gnome.org/Apps/Dia/Download
-.. _here: psci-lib-integration-guide.rst
-.. _Trusted Board Boot: ../design/trusted-board-boot.rst
-.. _TB_FW_CONFIG for FVP: ../../plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts
-.. _Secure-EL1 Payloads and Dispatchers: ../design/firmware-design.rst#user-content-secure-el1-payloads-and-dispatchers
-.. _Firmware Update: ../components/firmware-update.rst
-.. _Firmware Design: ../design/firmware-design.rst
.. _mbed TLS Repository: https://github.com/ARMmbed/mbedtls.git
.. _mbed TLS Security Center: https://tls.mbed.org/security
.. _Arm's website: `FVP models`_
.. _FVP models: https://developer.arm.com/products/system-design/fixed-virtual-platforms
.. _Juno Getting Started Guide: http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/DUI0928E_juno_arm_development_platform_gsg.pdf
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
-.. _Secure Partition Manager Design guide: ../components/secure-partition-manager-design.rst
-.. _`Trusted Firmware-A Coding Guidelines`: ../process/coding-guidelines.rst
-.. _Library at ROM: ../components/romlib-design.rst
diff --git a/docs/index.rst b/docs/index.rst
index bf2b873..4cd1798 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -43,10 +43,9 @@
Users are encouraged to do their own security validation, including penetration
testing, on any secure world code derived from TF-A.
-Arm will continue development in collaboration with interested parties to
-provide a full reference implementation of Secure Monitor code and Arm standards
-to the benefit of all developers working with Armv7-A and Armv8-A TrustZone
-technology.
+In collaboration with interested parties, we will continue to enhance |TF-A|
+with reference implementations of Arm standards to benefit developers working
+with Armv7-A and Armv8-A TrustZone technology.
Functionality
-------------
@@ -133,15 +132,16 @@
The use of pointer authentication in the normal world is enabled whenever
architectural support is available, without the need for additional build
flags. Use of pointer authentication in the secure world remains an
- experimental configuration at this time and requires the ``ENABLE_PAUTH``
- build flag to be set.
+ experimental configuration at this time and requires the
+ ``BRANCH_PROTECTION`` option to be set to non-zero.
- Position-Independent Executable (PIE) support. Initially for BL31 only, with
further support to be added in a future release.
For a full description of functionality and implementation details, please
-see the `Firmware Design`_ and supporting documentation. The `Change Log`_
-provides details of changes made since the last release.
+see :ref:`Firmware Design` and supporting documentation. The
+:ref:`Change Log & Release Notes` provides details of changes made since the
+last release.
Platforms
---------
@@ -197,7 +197,7 @@
The Foundation FVP can be downloaded free of charge. The Base FVPs can be
licensed from Arm. See the `Arm FVP website`_.
-All the above platforms have been tested with `Linaro Release 18.04`_.
+All the above platforms have been tested with `Linaro Release 19.06`_.
This release also contains the following platform support:
@@ -242,31 +242,32 @@
- Ongoing security hardening, optimization and quality improvements.
-For a full list of detailed issues in the current code, please see the `Change
-Log`_ and the `issue tracker`_.
+For a full list of detailed issues in the current code, please see the
+:ref:`Change Log & Release Notes` and the `issue tracker`_.
Getting started
---------------
-See the `User Guide`_ for instructions on how to download, install, build and
-use TF-A with the Arm `FVP`_\ s.
+See the :ref:`User Guide` for instructions on how to download, install, build
+and use TF-A with the Arm `FVP`_\ s.
-See the `Firmware Design`_ for information on how TF-A works.
+See the :ref:`Firmware Design` for information on how TF-A works.
-See the `Porting Guide`_ as well for information about how to use this
+See the :ref:`Porting Guide` as well for information about how to use this
software on another Armv7-A or Armv8-A platform.
-See the `Contributing Guidelines`_ for information on how to contribute to this
-project and the `Acknowledgments`_ file for a list of contributors to the
-project.
+See the :ref:`Contributor's Guide` for information on how to contribute to this
+project and the :ref:`Contributor Acknowledgements` file for a list of
+contributors to the project.
-Contact us
+Contact Us
~~~~~~~~~~
We welcome any feedback on TF-A. If you think you have found a security
vulnerability, please report this using the process defined in the TF-A
-`Security Center`_. For all other feedback, you can use either the
-`issue tracker`_ or our `mailing list`_.
+:ref:`Security Handling` document.
+
+For all other feedback, please use the `issue tracker`_ or our `mailing list`_.
Arm licensees may contact Arm directly via their partner managers.
@@ -287,18 +288,10 @@
.. _Juno Arm Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php
.. _Arm FVP website: FVP_
.. _FVP: https://developer.arm.com/products/system-design/fixed-virtual-platforms
-.. _Linaro Release 18.04: https://community.arm.com/dev-platforms/b/documents/posts/linaro-release-notes-deprecated#LinaroRelease18.04
+.. _Linaro Release 19.06: http://releases.linaro.org/members/arm/platforms/19.06
.. _OP-TEE Secure OS: https://github.com/OP-TEE/optee_os
.. _NVIDIA Trusted Little Kernel: http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/ote_partner/tlk.git;a=summary
.. _Trusty Secure OS: https://source.android.com/security/trusty
.. _trustedfirmware.org: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
.. _issue tracker: https://issues.trustedfirmware.org
.. _mailing list: https://lists.trustedfirmware.org/mailman/listinfo/tf-a
-.. _Security Center: ./process/security.rst
-.. _license: ./license.rst
-.. _Contributing Guidelines: ./process/contributing.rst
-.. _Acknowledgments: ./acknowledgements.rst
-.. _Firmware Design: ./design/firmware-design.rst
-.. _Change Log: ./change-log.rst
-.. _User Guide: ./getting_started/user-guide.rst
-.. _Porting Guide: ./getting_started/porting-guide.rst
diff --git a/docs/license.rst b/docs/license.rst
index b62286f..2f97043 100644
--- a/docs/license.rst
+++ b/docs/license.rst
@@ -3,7 +3,7 @@
The software is provided under a BSD-3-Clause license (below). Contributions to
this project are accepted under the same license with developer sign-off as
-described in the :ref:`contributor_guide`.
+described in the :ref:`Contributor's Guide`.
::
@@ -77,4 +77,4 @@
terms of both licenses.
.. _FreeBSD: http://www.freebsd.org
-.. _SCC: http://www.simple-cc.org/
\ No newline at end of file
+.. _SCC: http://www.simple-cc.org/
diff --git a/docs/maintainers.rst b/docs/maintainers.rst
index d997baa..86e445a 100644
--- a/docs/maintainers.rst
+++ b/docs/maintainers.rst
@@ -49,9 +49,9 @@
:F: plat/amlogic/gxl/
Amlogic Meson S905X2 (G12A) platform port
----------------------------------------
+-----------------------------------------
:M: Carlo Caione <ccaione@baylibre.com>
-:G: `carlo.caione`_
+:G: `carlocaione`_
:F: docs/plat/meson-g12a.rst
:F: drivers/amlogic/g12a
:F: plat/amlogic/g12a/
@@ -122,7 +122,7 @@
:M: Tien Hock Loh <tien.hock.loh@intel.com>
:G: `thloh85-intel`_
:M: Hadi Asyrafi <muhammad.hadi.asyrafi.abdul.halim@intel.com>
-:G: `mabdulha`_
+:G: mabdulha
:F: plat/intel/soc
:F: drivers/intel/soc/
@@ -282,6 +282,7 @@
.. _Anson-Huang: https://github.com/Anson-Huang
.. _bryanodonoghue: https://github.com/bryanodonoghue
.. _b49020: https://github.com/b49020
+.. _carlocaione: https://github.com/carlocaione
.. _danh-arm: https://github.com/danh-arm
.. _etienne-lms: https://github.com/etienne-lms
.. _glneo: https://github.com/glneo
@@ -308,6 +309,7 @@
.. _sivadur: https://github.com/sivadur
.. _smaeul: https://github.com/smaeul
.. _soby-mathew: https://github.com/soby-mathew
+.. _thloh85-intel: https://github.com/thloh85-intel
.. _thomas-arm: https://github.com/thomas-arm
.. _TonyXie06: https://github.com/TonyXie06
.. _vwadekar: https://github.com/vwadekar
diff --git a/docs/perf/psci-performance-juno.rst b/docs/perf/psci-performance-juno.rst
index 4cc4302..c127c1c 100644
--- a/docs/perf/psci-performance-juno.rst
+++ b/docs/perf/psci-performance-juno.rst
@@ -168,7 +168,7 @@
| 5 | 21 | 17 | 6 |
+-------+---------------------+--------------------+--------------------------+
-The ``CLUSH_OVERHEAD`` times for lead CPU 4 and all CPUs in the non-lead cluster
+The ``CFLUSH_OVERHEAD`` times for lead CPU 4 and all CPUs in the non-lead cluster
are large because all other CPUs in the cluster are powered down during the
test. The ``CPU_SUSPEND`` call powers down to the cluster level, requiring a
flush of both L1 and L2 caches.
diff --git a/docs/plat/marvell/porting.rst b/docs/plat/marvell/porting.rst
index 8fc1c1f..0a71dbd 100644
--- a/docs/plat/marvell/porting.rst
+++ b/docs/plat/marvell/porting.rst
@@ -112,7 +112,7 @@
.. seealso::
For XFI/SFI comphy type there is procedure "rx_training" which eases
- process of suiting some of the parameters. Please see :ref:`uboot_cmd`
+ process of suiting some of the parameters. Please see *uboot_cmd*
section: rx_training.
The PHY porting layer simplifies updating static values per board type,
diff --git a/docs/plat/meson-g12a.rst b/docs/plat/meson-g12a.rst
index 1021da4..7cd1bf7 100644
--- a/docs/plat/meson-g12a.rst
+++ b/docs/plat/meson-g12a.rst
@@ -1,5 +1,5 @@
Amlogic Meson S905X2 (G12A)
-==========================
+===========================
The Amlogic Meson S905X2 is a SoC with a quad core Arm Cortex-A53 running at
~1.8GHz. It also contains a Cortex-M3 used as SCP.
diff --git a/docs/plat/socionext-uniphier.rst b/docs/plat/socionext-uniphier.rst
index 82b9b50..964dd1d 100644
--- a/docs/plat/socionext-uniphier.rst
+++ b/docs/plat/socionext-uniphier.rst
@@ -8,10 +8,11 @@
image from a non-volatile storage to the on-chip SRAM, and jumps over to it.
TF-A provides a special mode, BL2-AT-EL3, which enables BL2 to execute at EL3.
It is useful for platforms with non-TF-A boot ROM, like UniPhier. Here, a
-problem is BL2 does not fit in the 64KB limit if `Trusted Board Boot`_ (TBB)
-is enabled. To solve this issue, Socionext provides a first stage loader
-called `UniPhier BL`_. This loader runs in the on-chip SRAM, initializes the
-DRAM, expands BL2 there, and hands the control over to it. Therefore, all images
+problem is BL2 does not fit in the 64KB limit if
+:ref:`Trusted Board Boot (TBB) <Trusted Board Boot>` is enabled.
+To solve this issue, Socionext provides a first stage loader called
+`UniPhier BL`_. This loader runs in the on-chip SRAM, initializes the DRAM,
+expands BL2 there, and hands the control over to it. Therefore, all images
of TF-A run in DRAM.
The UniPhier platform works with/without TBB. See below for the build process
@@ -50,7 +51,7 @@
4. BL31, BL32, and BL33
- They all run in the DRAM. See `Firmware Design`_ for details.
+ They all run in the DRAM. See :ref:`Firmware Design` for details.
Basic Build
@@ -79,7 +80,7 @@
- Trusted Board Boot
`mbed TLS`_ is needed as the cryptographic and image parser modules.
- Refer to the `User Guide`_ for the appropriate version of mbed TLS.
+ Refer to the :ref:`User Guide` for the appropriate version of mbed TLS.
To enable TBB, add the following options to the build command::
@@ -109,9 +110,6 @@
.. [1] Some SoCs can load 80KB, but the software implementation must be aligned
to the lowest common denominator.
-.. _Trusted Board Boot: ../trusted-board-boot.rst
.. _UniPhier BL: https://github.com/uniphier/uniphier-bl
-.. _Firmware Design: ../firmware-design.rst
.. _U-Boot: https://www.denx.de/wiki/U-Boot
.. _mbed TLS: https://tls.mbed.org/
-.. _User Guide: ../user-guide.rst
diff --git a/docs/process/coding-guidelines.rst b/docs/process/coding-guidelines.rst
index a53da77..cb8b892 100644
--- a/docs/process/coding-guidelines.rst
+++ b/docs/process/coding-guidelines.rst
@@ -23,8 +23,8 @@
- ``**WARNING: Use of volatile is usually wrong``: see
`Why the “volatile” type class should not be used`_ . Although this document
- contains some very useful information, there are several legimate uses of the
- volatile keyword within the TF codebase.
+ contains some very useful information, there are several legitimate uses of
+ the volatile keyword within the TF codebase.
Headers and inclusion
---------------------
diff --git a/docs/process/contributing.rst b/docs/process/contributing.rst
index 66b282c..fdb702f 100644
--- a/docs/process/contributing.rst
+++ b/docs/process/contributing.rst
@@ -13,8 +13,8 @@
raise a separate `issue`_ for this and ensure that the changes that
include Third Party IP are made on a separate topic branch.
-- Clone `Trusted Firmware-A`_ on your own machine as suggested on the
- `User Guide`_.
+- Clone `Trusted Firmware-A`_ on your own machine as suggested in the
+ :ref:`User Guide`.
- Create a local topic branch based on the `Trusted Firmware-A`_ ``master``
branch.
@@ -23,11 +23,11 @@
- Make commits of logical units. See these general `Git guidelines`_ for
contributing to a project.
-- Follow the `Coding Guidelines`_.
+- Follow the :ref:`Coding Style & Guidelines`.
- Use the checkpatch.pl script provided with the Linux source tree. A
Makefile target is provided for convenience (see the "Checking source code
- style" section in the `User Guide`_).
+ style" section in the :ref:`User Guide`).
- Keep the commits on topic. If you need to fix another bug or make another
enhancement, please create a separate `issue`_ and address it on a separate
@@ -38,12 +38,12 @@
an `issue`_, include a reference.
- Where appropriate, please update the documentation.
- - Consider whether the `User Guide`_, `Porting Guide`_, `Firmware Design`_
- or other in-source documentation needs updating.
+ - Consider whether the :ref:`User Guide`, :ref:`Porting Guide`,
+ :ref:`Firmware Design` or other in-source documentation needs updating.
- Ensure that each changed file has the correct copyright and license
information. Files that entirely consist of contributions to this
project should have a copyright notice and BSD-3-Clause SPDX license
- identifier of the form as shown in `license.rst`_. Files that contain
+ identifier of the form as shown in :ref:`license`. Files that contain
changes to imported Third Party IP files should retain their original
copyright and license notices. For significant contributions you may
add your own copyright notice in following format:
@@ -57,13 +57,13 @@
your company name.
- If you are submitting new files that you intend to be the technical
sub-maintainer for (for example, a new platform port), then also update
- the `Maintainers`_ file.
+ the :ref:`maintainers` file.
- For topics with multiple commits, you should make all documentation
changes (and nothing else) in the last commit of the series. Otherwise,
include the documentation changes within the single commit.
- Please test your changes. As a minimum, ensure that Linux boots on the
- Foundation FVP. See `Running the software on FVP`_ for more information. For
+ Foundation FVP. See :ref:`user_guide_run_fvp` for more information. For
more extensive testing, consider running the `TF-A Tests`_ against your
patches.
@@ -75,13 +75,14 @@
``Signed-off-by:`` and ``Author:`` lines must match. If anyone else
contributes to the commit, they must also add their own ``Signed-off-by:``
line. By adding this line the contributor certifies the contribution is made
- under the terms of the `Developer Certificate of Origin (DCO)`_.
+ under the terms of the
+ :download:`Developer Certificate of Origin <../../dco.txt>`.
More details may be found in the `Gerrit Signed-off-by Lines guidelines`_.
- Ensure that each commit also has a unique ``Change-Id:`` line. If you have
cloned the repository with the "`Clone with commit-msg hook`" clone method
- (as advised on the `User Guide`_), this should already be the case.
+ (as advised on the :ref:`User Guide`), this should already be the case.
More details may be found in the `Gerrit Change-Ids documentation`_.
@@ -89,22 +90,22 @@
targeting the ``integration`` branch.
- The changes will then undergo further review and testing by the
- `Maintainers`_. Any review comments will be made directly on your patch.
- This may require you to do some rework.
+ :ref:`maintainers`. Any review comments will be made directly on your
+ patch. This may require you to do some rework.
Refer to the `Gerrit Uploading Changes documentation`_ for more details.
-- When the changes are accepted, the `Maintainers`_ will integrate them.
+- When the changes are accepted, the :ref:`maintainers` will integrate them.
- - Typically, the `Maintainers`_ will merge the changes into the
+ - Typically, the :ref:`maintainers` will merge the changes into the
``integration`` branch.
- If the changes are not based on a sufficiently-recent commit, or if they
- cannot be automatically rebased, then the `Maintainers`_ may rebase it on
- the ``master`` branch or ask you to do so.
+ cannot be automatically rebased, then the :ref:`maintainers` may rebase it
+ on the ``master`` branch or ask you to do so.
- After final integration testing, the changes will make their way into the
``master`` branch. If a problem is found during integration, the merge
commit will be removed from the ``integration`` branch and the
- `Maintainers`_ will ask you to create a new patch set to resolve the
+ :ref:`maintainers` will ask you to create a new patch set to resolve the
problem.
Binary Components
@@ -132,15 +133,6 @@
.. _issue: https://developer.trustedfirmware.org/project/board/1/
.. _Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
.. _Git guidelines: http://git-scm.com/book/ch5-2.html
-.. _Coding Guidelines: ./coding-guidelines.rst
-.. _User Guide: ../getting_started/user-guide.rst
-.. _Porting Guide: ../getting_started/porting-guide.rst
-.. _Firmware Design: ../design/firmware-design.rst
-.. _license.rst: ../license.rst
-.. _Acknowledgements: ../acknowledgements.rst
-.. _Maintainers: ../maintainers.rst
-.. _Running the software on FVP: ../getting_started/user-guide.rst#user-content-running-the-software-on-fvp
-.. _Developer Certificate of Origin (DCO): ../../dco.txt
.. _Gerrit Uploading Changes documentation: https://review.trustedfirmware.org/Documentation/user-upload.html
.. _Gerrit Signed-off-by Lines guidelines: https://review.trustedfirmware.org/Documentation/user-signedoffby.html
.. _Gerrit Change-Ids documentation: https://review.trustedfirmware.org/Documentation/user-changeid.html
diff --git a/docs/process/faq.rst b/docs/process/faq.rst
index 6aa04f0..2c36584 100644
--- a/docs/process/faq.rst
+++ b/docs/process/faq.rst
@@ -37,7 +37,7 @@
conflict between the topics.
* If there is a code freeze in place in preparation for the release. Please
- refer the `release information`_ for more details.
+ refer the :ref:`Release Processes` document for more details.
* The workload of the TF maintainers.
@@ -55,9 +55,9 @@
patches will be merged onto ``integration``, which will temporarily diverge from
the release branch. The ``integration`` branch will be rebased onto ``master``
after the release, and then ``master`` will be fast-forwarded to ``integration``
-1-2 days later. This whole process could take up 4 weeks. Please refer the
-`release information`_ for code freeze dates. The TF maintainers will inform the
-patch owner if this is going to happen.
+1-2 days later. This whole process could take up 4 weeks. Please refer to the
+:ref:`Release Processes` document for code freeze dates. The TF maintainers
+will inform the patch owner if this is going to happen.
It is OK to create a patch based on commits that are only available in
``integration`` or another patch set, rather than ``master``. There is a risk
@@ -73,7 +73,10 @@
Please refer to https://github.com/ARM-software/tf-issues/issues/681 for more
details on the timelines.
-.. _release information: release-information.rst
+--------------
+
+*Copyright (c) 2019, Arm Limited. All rights reserved.*
+
.. _Gerrit Upload Patch Set documentation: https://review.trustedfirmware.org/Documentation/intro-user.html#upload-patch-set
.. _Gerrit Replace Changes documentation: https://review.trustedfirmware.org/Documentation/user-upload.html#push_replace
.. _trustedfirmware.org: https://www.trustedfirmware.org/
diff --git a/docs/process/platform-compatibility-policy.rst b/docs/process/platform-compatibility-policy.rst
index a11ba38..be1f9ba 100644
--- a/docs/process/platform-compatibility-policy.rst
+++ b/docs/process/platform-compatibility-policy.rst
@@ -11,7 +11,7 @@
-----------------------------
Platform compatibility is mainly affected by changes to Platform APIs (as
-documented in the `Porting Guide`_), driver APIs (like the GICv3 drivers) or
+documented in the :ref:`Porting Guide`), driver APIs (like the GICv3 drivers) or
library interfaces (like xlat_table library). The project will try to maintain
compatibility for upstream platforms. Due to evolving requirements and
enhancements, there might be changes affecting platform compatibility which
@@ -20,7 +20,7 @@
the contributor of the change is expected to make good effort to migrate the
upstream platforms to the new interface.
-The deprecated interfaces are listed inside `Release information`_ as well as
+The deprecated interfaces are listed inside :ref:`Release Processes` as well as
the release after which each one will be removed. When an interface is
deprecated, the page must be updated to indicate the release after which the
interface will be removed. This must be at least 1 full release cycle in future.
@@ -33,6 +33,4 @@
*Copyright (c) 2018-2019, Arm Limited and Contributors. All rights reserved.*
-.. _Porting Guide: ../getting_started/porting-guide.rst
-.. _Release information: ./release-information.rst#removal-of-deprecated-interfaces
.. _TF-A public mailing list: https://lists.trustedfirmware.org/mailman/listinfo/tf-a
diff --git a/docs/process/release-information.rst b/docs/process/release-information.rst
index b81d42d..e264e51 100644
--- a/docs/process/release-information.rst
+++ b/docs/process/release-information.rst
@@ -42,9 +42,9 @@
Removal of Deprecated Interfaces
--------------------------------
-As mentioned in the `Platform compatibility policy`_, this is a live document
-cataloging all the deprecated interfaces in TF-A project and the Release version
-after which it will be removed.
+As mentioned in the :ref:`Platform Compatibility Policy`, this is a live
+document cataloging all the deprecated interfaces in TF-A project and the
+Release version after which it will be removed.
+--------------------------------+-------------+---------+---------------------------------------------------------+
| Interface | Deprecation | Removed | Comments |
@@ -54,7 +54,7 @@
| Legacy Console API | Jan '18 | v2.1 | Deprecated in favour of ``MULTI_CONSOLE_API`` |
+--------------------------------+-------------+---------+---------------------------------------------------------+
| Weak default | Oct '18 | v2.1 | The default implementations are defined in |
-| ``plat_crash_console_*`` | | | `crash_console_helpers.S`_. The platforms have to |
+| ``plat_crash_console_*`` | | | ``crash_console_helpers.S``. The platforms have to |
| APIs | | | define ``plat_crash_console_*``. |
+--------------------------------+-------------+---------+---------------------------------------------------------+
| ``finish_console_register`` | Oct '18 | v2.1 | The old version of the macro is deprecated. See commit |
@@ -74,9 +74,9 @@
| Makefile in ``INCLUDES``. | | | header files. More information in commit 09d40e0e0828_. |
+--------------------------------+-------------+---------+---------------------------------------------------------+
+--------------
+
*Copyright (c) 2018-2019, Arm Limited and Contributors. All rights reserved.*
-.. _Platform compatibility policy: platform-compatibility-policy.rst
-.. _crash_console_helpers.S: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/common/aarch64/crash_console_helpers.S
.. _cc5859c: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=cc5859ca19ff546c35eb0331000dae090b6eabcf
.. _09d40e0e0828: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=09d40e0e08283a249e7dce0e106c07c5141f9b7e
diff --git a/docs/process/security-hardening.rst b/docs/process/security-hardening.rst
index e2c68b8..1a5524f 100644
--- a/docs/process/security-hardening.rst
+++ b/docs/process/security-hardening.rst
@@ -9,7 +9,7 @@
-------------
Several build options can be used to check for security issues. Refer to the
-`user guide`_ for detailed information on the specific build options.
+:ref:`User Guide` for detailed information on the specific build options.
- The ``BRANCH_PROTECTION`` build flag can be used to enable Pointer
Authentication and Branch Target Identification.
@@ -53,6 +53,6 @@
NB: The ``Werror`` flag is enabled by default in TF-A and can be disabled by
setting the ``E`` build flag to 0.
-*Copyright (c) 2019, Arm Limited. All rights reserved.*
+--------------
-.. _user guide: ../getting_started/user-guide.rst
+*Copyright (c) 2019, Arm Limited. All rights reserved.*
diff --git a/docs/process/security.rst b/docs/process/security.rst
index 94eb9c3..c3935da 100644
--- a/docs/process/security.rst
+++ b/docs/process/security.rst
@@ -38,9 +38,11 @@
- Any additional software or tools required
-We recommend using `this PGP/GPG key`_ for encrypting the information. This key
-is also available at http://keyserver.pgp.com and LDAP port 389 of the same
-server. The fingerprint for this key is:
+We recommend using :download:`this PGP/GPG key <./security-reporting.asc>` for
+encrypting the information. This key is also available at
+http://keyserver.pgp.com and LDAP port 389 of the same server.
+
+The fingerprint for this key is:
::
@@ -59,7 +61,7 @@
Attribution
-----------
-We will name and thank you in the ``change-log.rst`` distributed with the source
+We will name and thank you in the :ref:`Change Log & Release Notes` distributed with the source
code and in any published security advisory.
Security Advisories
@@ -68,38 +70,43 @@
+-----------+------------------------------------------------------------------+
| ID | Title |
+===========+==================================================================+
-| `TFV-1`_ | Malformed Firmware Update SMC can result in copy of unexpectedly |
+| |TFV-1| | Malformed Firmware Update SMC can result in copy of unexpectedly |
| | large data into secure memory |
+-----------+------------------------------------------------------------------+
-| `TFV-2`_ | Enabled secure self-hosted invasive debug interface can allow |
+| |TFV-2| | Enabled secure self-hosted invasive debug interface can allow |
| | normal world to panic secure world |
+-----------+------------------------------------------------------------------+
-| `TFV-3`_ | RO memory is always executable at AArch64 Secure EL1 |
+| |TFV-3| | RO memory is always executable at AArch64 Secure EL1 |
+-----------+------------------------------------------------------------------+
-| `TFV-4`_ | Malformed Firmware Update SMC can result in copy or |
+| |TFV-4| | Malformed Firmware Update SMC can result in copy or |
| | authentication of unexpected data in secure memory in AArch32 |
| | state |
+-----------+------------------------------------------------------------------+
-| `TFV-5`_ | Not initializing or saving/restoring PMCR_EL0 can leak secure |
+| |TFV-5| | Not initializing or saving/restoring PMCR_EL0 can leak secure |
| | world timing information |
+-----------+------------------------------------------------------------------+
-| `TFV-6`_ | Trusted Firmware-A exposure to speculative processor |
+| |TFV-6| | Trusted Firmware-A exposure to speculative processor |
| | vulnerabilities using cache timing side-channels |
+-----------+------------------------------------------------------------------+
-| `TFV-7`_ | Trusted Firmware-A exposure to cache speculation vulnerability |
+| |TFV-7| | Trusted Firmware-A exposure to cache speculation vulnerability |
| | Variant 4 |
+-----------+------------------------------------------------------------------+
-| `TFV-8`_ | Not saving x0 to x3 registers can leak information from one |
+| |TFV-8| | Not saving x0 to x3 registers can leak information from one |
| | Normal World SMC client to another |
+-----------+------------------------------------------------------------------+
.. _issue tracker: https://developer.trustedfirmware.org/project/board/1/
.. _this PGP/GPG key: security-reporting.asc
-.. _TFV-1: ../security_advisories/security-advisory-tfv-1.rst
-.. _TFV-2: ../security_advisories/security-advisory-tfv-2.rst
-.. _TFV-3: ../security_advisories/security-advisory-tfv-3.rst
-.. _TFV-4: ../security_advisories/security-advisory-tfv-4.rst
-.. _TFV-5: ../security_advisories/security-advisory-tfv-5.rst
-.. _TFV-6: ../security_advisories/security-advisory-tfv-6.rst
-.. _TFV-7: ../security_advisories/security-advisory-tfv-7.rst
-.. _TFV-8: ../security_advisories/security-advisory-tfv-8.rst
+
+.. |TFV-1| replace:: :ref:`Advisory TFV-1 (CVE-2016-10319)`
+.. |TFV-2| replace:: :ref:`Advisory TFV-2 (CVE-2017-7564)`
+.. |TFV-3| replace:: :ref:`Advisory TFV-3 (CVE-2017-7563)`
+.. |TFV-4| replace:: :ref:`Advisory TFV-4 (CVE-2017-9607)`
+.. |TFV-5| replace:: :ref:`Advisory TFV-5 (CVE-2017-15031)`
+.. |TFV-6| replace:: :ref:`Advisory TFV-6 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754)`
+.. |TFV-7| replace:: :ref:`Advisory TFV-7 (CVE-2018-3639)`
+.. |TFV-8| replace:: :ref:`Advisory TFV-8 (CVE-2018-19440)`
+
+--------------
+
+*Copyright (c) 2019, Arm Limited. All rights reserved.*
diff --git a/docs/security_advisories/security-advisory-tfv-6.rst b/docs/security_advisories/security-advisory-tfv-6.rst
index 495eddd..9eeaeec 100644
--- a/docs/security_advisories/security-advisory-tfv-6.rst
+++ b/docs/security_advisories/security-advisory-tfv-6.rst
@@ -51,7 +51,7 @@
For Cortex-A73 and Cortex-A75 CPUs, the PRs in this advisory invalidate the
branch predictor when entering EL3 by temporarily dropping into AArch32
Secure-EL1 and executing the ``BPIALL`` instruction. This workaround is
-signifiantly more complex than the "MMU disable/enable" workaround. The latter
+significantly more complex than the "MMU disable/enable" workaround. The latter
is not effective at invalidating the branch predictor on Cortex-A73/Cortex-A75.
Note that if other privileged software, for example a Rich OS kernel, implements
diff --git a/drivers/arm/pl011/aarch32/pl011_console.S b/drivers/arm/pl011/aarch32/pl011_console.S
index e1e346c..05c8250 100644
--- a/drivers/arm/pl011/aarch32/pl011_console.S
+++ b/drivers/arm/pl011/aarch32/pl011_console.S
@@ -57,7 +57,7 @@
#if (ARM_ARCH_MAJOR == 7) && !defined(ARMV7_SUPPORTS_VIRTUALIZATION)
push {r0,r3}
softudiv r0,r1,r2,r3
- mov r1, r0
+ mov r2, r0
pop {r0,r3}
#else
udiv r2, r1, r2
diff --git a/license.rst b/license.rst
index 9743134..3ec3b74 100644
--- a/license.rst
+++ b/license.rst
@@ -1,38 +1 @@
-Copyright (c) [XXXX-]YYYY, <OWNER>. All rights reserved.
-
-Redistribution and use in source and binary forms, with or without modification,
-are permitted provided that the following conditions are met:
-
-- Redistributions of source code must retain the above copyright notice, this
- list of conditions and the following disclaimer.
-
-- Redistributions in binary form must reproduce the above copyright notice, this
- list of conditions and the following disclaimer in the documentation and/or
- other materials provided with the distribution.
-
-- Neither the name of Arm nor the names of its contributors may be used to
- endorse or promote products derived from this software without specific prior
- written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
-WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
-ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
-(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
-LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
-ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
-SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
---------------
-
-.. note::
- Individual files contain the following tag instead of the full license text.
-
-::
-
- SPDX-License-Identifier: BSD-3-Clause
-
-This enables machine processing of license information based on the SPDX
-License Identifiers that are here available: http://spdx.org/licenses/
+See docs/license.rst
diff --git a/readme.rst b/readme.rst
index b503808..148d477 100644
--- a/readme.rst
+++ b/readme.rst
@@ -1,309 +1,35 @@
-Trusted Firmware-A - version 2.1
-================================
+Trusted Firmware-A
+==================
-.. section-numbering::
- :suffix: .
+Trusted Firmware-A (TF-A) is a reference implementation of secure world software
+for `Arm A-Profile architectures`_ (Armv8-A and Armv7-A), including an Exception
+Level 3 (EL3) `Secure Monitor`_. It provides a suitable starting point for
+productization of secure world boot and runtime firmware, in either the AArch32
+or AArch64 execution states.
-.. contents::
+TF-A implements Arm interface standards, including:
-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,
-such as:
-
-- The `Power State Coordination Interface (PSCI)`_
+- `Power State Coordination Interface (PSCI)`_
- `Trusted Board Boot Requirements CLIENT (TBBR-CLIENT)`_
- `SMC Calling Convention`_
- `System Control and Management Interface (SCMI)`_
- `Software Delegated Exception Interface (SDEI)`_
-Where possible, the code is designed for reuse or porting to other Armv7-A and
-Armv8-A model and hardware platforms.
+The code is designed to be portable and reusable across hardware platforms and
+software models that are based on the Armv8-A and Armv7-A architectures.
-This release provides a suitable starting point for productization of secure
-world boot and runtime firmware, in either the AArch32 or AArch64 execution
-states.
+In collaboration with interested parties, we will continue to enhance TF-A
+with reference implementations of Arm standards to benefit developers working
+with Armv7-A and Armv8-A TrustZone technology.
Users are encouraged to do their own security validation, including penetration
testing, on any secure world code derived from TF-A.
-Arm will continue development in collaboration with interested parties to
-provide a full reference implementation of Secure Monitor code and Arm standards
-to the benefit of all developers working with Armv7-A and Armv8-A TrustZone
-technology.
+More Info and Documentation
+---------------------------
-Documentation contents
-----------------------
-
-The `Trusted Firmware-A Documentation Contents`_ page contains an overview of
-the documentation that is available, with links to facilitate easier browsing.
-
-License
--------
-
-The software is provided under a BSD-3-Clause `license`_. Contributions to this
-project are accepted under the same license with developer sign-off as
-described in the `Contributing Guidelines`_.
-
-This project contains code from other projects as listed below. The original
-license text is included in those source files.
-
-- The libc source code is derived from `FreeBSD`_ and `SCC`_. FreeBSD uses
- various BSD licenses, including BSD-3-Clause and BSD-2-Clause. The SCC code
- is used under the BSD-3-Clause license with the author's permission.
-
-- The libfdt source code is disjunctively dual licensed
- (GPL-2.0+ OR BSD-2-Clause). It is used by this project under the terms of
- the BSD-2-Clause license. Any contributions to this code must be made under
- the terms of both licenses.
-
-- The LLVM compiler-rt source code is disjunctively dual licensed
- (NCSA OR MIT). It is used by this project under the terms of the NCSA
- license (also known as the University of Illinois/NCSA Open Source License),
- which is a permissive license compatible with BSD-3-Clause. Any
- contributions to this code must be made under the terms of both licenses.
-
-- The zlib source code is licensed under the Zlib license, which is a
- permissive license compatible with BSD-3-Clause.
-
-- Some STMicroelectronics platform source code is disjunctively dual licensed
- (GPL-2.0+ OR BSD-3-Clause). It is used by this project under the terms of the
- BSD-3-Clause license. Any contributions to this code must be made under the
- terms of both licenses.
-
-Functionality
--------------
-
-- Initialization of the secure world, for example exception vectors, control
- registers and interrupts for the platform.
-
-- Library support for CPU specific reset and power down sequences. This
- includes support for errata workarounds and the latest Arm DynamIQ CPUs.
-
-- Drivers to enable standard initialization of Arm System IP, for example
- Generic Interrupt Controller (GIC), Cache Coherent Interconnect (CCI),
- Cache Coherent Network (CCN), Network Interconnect (NIC) and TrustZone
- Controller (TZC).
-
-- A generic `SCMI`_ driver to interface with conforming power controllers, for
- example the Arm System Control Processor (SCP).
-
-- SMC (Secure Monitor Call) handling, conforming to the `SMC Calling
- Convention`_ using an EL3 runtime services framework.
-
-- `PSCI`_ library support for CPU, cluster and system power management
- use-cases.
- This library is pre-integrated with the AArch64 EL3 Runtime Software, and
- is also suitable for integration with other AArch32 EL3 Runtime Software,
- for example an AArch32 Secure OS.
-
-- A minimal AArch32 Secure Payload (SP\_MIN) to demonstrate `PSCI`_ library
- integration with AArch32 EL3 Runtime Software.
-
-- Secure Monitor library code such as world switching, EL1 context management
- and interrupt routing.
- When a Secure-EL1 Payload (SP) is present, for example a Secure OS, the
- AArch64 EL3 Runtime Software must be integrated with a Secure Payload
- Dispatcher (SPD) component to customize the interaction with the SP.
-
-- A Test SP and SPD to demonstrate AArch64 Secure Monitor functionality and SP
- interaction with PSCI.
-
-- SPDs for the `OP-TEE Secure OS`_, `NVIDIA Trusted Little Kernel`_
- and `Trusty Secure OS`_.
-
-- A Trusted Board Boot implementation, conforming to all mandatory TBBR
- requirements. This includes image authentication, Firmware Update (or
- recovery mode), and packaging of the various firmware images into a
- Firmware Image Package (FIP).
-
-- Pre-integration of TBB with the Arm CryptoCell product, to take advantage of
- its hardware Root of Trust and crypto acceleration services.
-
-- Reliability, Availability, and Serviceability (RAS) functionality, including
-
- - A Secure Partition Manager (SPM) to manage Secure Partitions in
- Secure-EL0, which can be used to implement simple management and
- security services.
-
- - 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
- error handling.
-
-- A dynamic configuration framework that enables each of the firmware images
- to be configured at runtime if required by the platform. It also enables
- loading of a hardware configuration (for example, a kernel device tree)
- as part of the FIP, to be passed through the firmware stages.
-
-- Support for alternative boot flows, for example to support platforms where
- the EL3 Runtime Software is loaded using other firmware or a separate
- secure system processor, or where a non-TF-A ROM expects BL2 to be loaded
- at EL3.
-
-- Support for the GCC, LLVM and Arm Compiler 6 toolchains.
-
-- Support for combining several libraries into a "romlib" image that may be
- shared across images to reduce memory footprint. The romlib image is stored
- in ROM but is accessed through a jump-table that may be stored
- in read-write memory, allowing for the library code to be patched.
-
-- A prototype implementation of a Secure Partition Manager (SPM) that is based
- on the SPCI Alpha 1 and SPRT draft specifications.
-
-- Support for ARMv8.3 pointer authentication in the normal and secure worlds.
- The use of pointer authentication in the normal world is enabled whenever
- architectural support is available, without the need for additional build
- flags. Use of pointer authentication in the secure world remains an
- experimental configuration at this time and requires the
- ``BRANCH_PROTECTION`` option to be set to non-zero.
-
-- Position-Independent Executable (PIE) support. Initially for BL31 only, with
- further support to be added in a future release.
-
-For a full description of functionality and implementation details, please
-see the `Firmware Design`_ and supporting documentation. The `Change Log`_
-provides details of changes made since the last release.
-
-Platforms
----------
-
-Various AArch32 and AArch64 builds of this release have been tested on r0, r1
-and r2 variants of the `Juno Arm Development Platform`_.
-
-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).
-
-The FVP models used are Version 11.6 Build 45, unless otherwise stated.
-
-- ``FVP_Base_AEMv8A-AEMv8A``
-- ``FVP_Base_AEMv8A-AEMv8A-AEMv8A-AEMv8A-CCN502``
-- ``FVP_Base_RevC-2xAEMv8A``
-- ``FVP_Base_Cortex-A32x4``
-- ``FVP_Base_Cortex-A35x4``
-- ``FVP_Base_Cortex-A53x4``
-- ``FVP_Base_Cortex-A55x4+Cortex-A75x4``
-- ``FVP_Base_Cortex-A55x4``
-- ``FVP_Base_Cortex-A57x1-A53x1``
-- ``FVP_Base_Cortex-A57x2-A53x4``
-- ``FVP_Base_Cortex-A57x4-A53x4``
-- ``FVP_Base_Cortex-A57x4``
-- ``FVP_Base_Cortex-A72x4-A53x4``
-- ``FVP_Base_Cortex-A72x4``
-- ``FVP_Base_Cortex-A73x4-A53x4``
-- ``FVP_Base_Cortex-A73x4``
-- ``FVP_Base_Cortex-A75x4``
-- ``FVP_Base_Cortex-A76x4``
-- ``FVP_Base_Cortex-A76AEx4``
-- ``FVP_Base_Cortex-A76AEx8``
-- ``FVP_Base_Cortex-A77x4`` (Version 11.7 build 36)
-- ``FVP_Base_Neoverse-N1x4``
-- ``FVP_CSS_SGI-575`` (Version 11.3 build 42)
-- ``FVP_CSS_SGM-775`` (Version 11.3 build 42)
-- ``FVP_RD_E1Edge`` (Version 11.3 build 42)
-- ``FVP_RD_N1Edge``
-- ``Foundation_Platform``
-
-The latest version of the AArch32 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).
-
-- ``FVP_Base_AEMv8A-AEMv8A``
-- ``FVP_Base_Cortex-A32x4``
-
-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`_.
-
-All the above platforms have been tested with `Linaro Release 18.04`_.
-
-This release also contains the following platform support:
-
-- Allwinner sun50i (A64, H5, and H6) SoCs
-- Amlogic Meson S905 (GXBB)
-- Amlogic Meson S905x (GXL)
-- Arm Juno Software Development Platform
-- Arm Neoverse N1 System Development Platform (N1SDP)
-- Arm Neoverse Reference Design N1 Edge (RD-N1-Edge) FVP
-- Arm Neoverse Reference Design E1 Edge (RD-E1-Edge) FVP
-- Arm SGI-575 and SGM-775
-- Arm Versatile Express FVP
-- HiKey, HiKey960 and Poplar boards
-- Intel Stratix 10 SoC FPGA
-- Marvell Armada 3700 and 8K
-- MediaTek MT6795 and MT8173 SoCs
-- NVIDIA T132, T186 and T210 SoCs
-- NXP QorIQ LS1043A, i.MX8MM, i.MX8MQ, i.MX8QX, i.MX8QM and i.MX7Solo WaRP7
-- QEMU
-- Raspberry Pi 3
-- Renesas R-Car Generation 3
-- RockChip RK3328, RK3368 and RK3399 SoCs
-- Socionext UniPhier SoC family and SynQuacer SC2A11 SoCs
-- STMicroelectronics STM32MP1
-- Texas Instruments K3 SoCs
-- Xilinx Versal and Zynq UltraScale + MPSoC
-
-Still to come
--------------
-
-- Support for additional platforms.
-
-- Refinements to Position Independent Executable (PIE) support.
-
-- Refinements to the SPCI-based SPM implementation as the draft SPCI and SPRT
- specifications continue to evolve.
-
-- Documentation enhancements.
-
-- Ongoing support for new architectural features, CPUs and System IP.
-
-- Ongoing support for new Arm system architecture specifications.
-
-- Ongoing security hardening, optimization and quality improvements.
-
-For a full list of detailed issues in the current code, please see the `Change
-Log`_ and the `issue tracker`_.
-
-Getting started
----------------
-
-See the `User Guide`_ for instructions on how to download, install, build and
-use TF-A with the Arm `FVP`_\ s.
-
-See the `Firmware Design`_ for information on how TF-A works.
-
-See the `Porting Guide`_ as well for information about how to use this
-software on another Armv7-A or Armv8-A platform.
-
-See the `Contributing Guidelines`_ for information on how to contribute to this
-project and the `Acknowledgments`_ file for a list of contributors to the
-project.
-
-Contact us
-~~~~~~~~~~
-
-We welcome any feedback on TF-A. If you think you have found a security
-vulnerability, please report this using the process defined in the TF-A
-`Security Center`_. For all other feedback, you can use either the
-`issue tracker`_ or our `mailing list`_.
-
-Arm licensees may contact Arm directly via their partner managers.
-
-Security advisories
--------------------
-
-- `Security Advisory TFV-1`_
-- `Security Advisory TFV-2`_
-- `Security Advisory TFV-3`_
-- `Security Advisory TFV-4`_
-- `Security Advisory TFV-5`_
-- `Security Advisory TFV-6`_
-- `Security Advisory TFV-7`_
-- `Security Advisory TFV-8`_
-
+To find out more about Trusted Firmware-A, please `view the full documentation`_
+that is available through `trustedfirmware.org`_.
--------------
@@ -319,32 +45,7 @@
.. _SCMI: http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf
.. _Software Delegated Exception Interface (SDEI): SDEI_
.. _SDEI: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
-.. _Juno Arm Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php
-.. _Arm FVP website: FVP_
-.. _FVP: https://developer.arm.com/products/system-design/fixed-virtual-platforms
-.. _Linaro Release 18.04: https://community.arm.com/dev-platforms/b/documents/posts/linaro-release-notes-deprecated#LinaroRelease18.04
-.. _OP-TEE Secure OS: https://github.com/OP-TEE/optee_os
-.. _NVIDIA Trusted Little Kernel: http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/ote_partner/tlk.git;a=summary
-.. _Trusty Secure OS: https://source.android.com/security/trusty
-.. _trustedfirmware.org: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
-.. _issue tracker: https://developer.trustedfirmware.org/project/board/1/
-.. _mailing list: https://lists.trustedfirmware.org/mailman/listinfo/tf-a
-.. _Security Center: ./docs/process/security.rst
-.. _license: ./license.rst
-.. _Contributing Guidelines: ./docs/process/contributing.rst
-.. _Acknowledgments: ./docs/acknowledgements.rst
-.. _Firmware Design: ./docs/design/firmware-design.rst
-.. _Change Log: ./docs/change-log.rst
-.. _User Guide: ./docs/getting_started/user-guide.rst
-.. _Porting Guide: ./docs/getting_started/porting-guide.rst
-.. _FreeBSD: http://www.freebsd.org
-.. _SCC: http://www.simple-cc.org/
-.. _Security Advisory TFV-1: ./docs/security_advisories/security-advisory-tfv-1.rst
-.. _Security Advisory TFV-2: ./docs/security_advisories/security-advisory-tfv-2.rst
-.. _Security Advisory TFV-3: ./docs/security_advisories/security-advisory-tfv-3.rst
-.. _Security Advisory TFV-4: ./docs/security_advisories/security-advisory-tfv-4.rst
-.. _Security Advisory TFV-5: ./docs/security_advisories/security-advisory-tfv-5.rst
-.. _Security Advisory TFV-6: ./docs/security_advisories/security-advisory-tfv-6.rst
-.. _Security Advisory TFV-7: ./docs/security_advisories/security-advisory-tfv-7.rst
-.. _Security Advisory TFV-8: ./docs/security_advisories/security-advisory-tfv-8.rst
-.. _Trusted Firmware-A Documentation Contents: ./docs/contents.rst
+.. _Arm A-Profile architectures: https://developer.arm.com/architectures/cpu-architecture/a-profile
+.. _view the full documentation: https://www.trustedfirmware.org/docs/tf-a
+.. _trustedfirmware.org: http://www.trustedfirmware.org
+
