Skip to content

GitLab

Commit f8e3340c authored by Paul Beesley's avatar Paul Beesley Committed by TrustedFirmware Code Review
Browse files

Merge changes from topic "pb/readthedocs" into integration 

* changes:
  doc: Add guide for building the docs locally
  doc: De-duplicate readme and license files
  doc: Convert internal links to RST format
parents 4fdad60c 862c764a
Show whitespace changes
Inline Side-by-side
docs/change-log.rst
View file @ f8e3340c
...@@ -22,8 +22,8 @@ New Features ...@@ -22,8 +22,8 @@ New Features
and ``CTX_INCLUDE_PAUTH_REGS`` build flags, pointer authentication can be and ``CTX_INCLUDE_PAUTH_REGS`` build flags, pointer authentication can be
enabled in EL3 and S-EL1/0. enabled in EL3 and S-EL1/0.
See the `Firmware Design`_ document for additional details on the use of See the :ref:`Firmware Design` document for additional details on the use
pointer authentication. of pointer authentication.
- Enable Data Independent Timing (DIT) in EL3, where supported - Enable Data Independent Timing (DIT) in EL3, where supported
...@@ -1359,7 +1359,7 @@ New features ...@@ -1359,7 +1359,7 @@ New features
The PSCI library has been refactored to allow integration with **EL3 Runtime The PSCI library has been refactored to allow integration with **EL3 Runtime
Software**. This is software that is executing at the highest secure 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 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 Included is a minimal AArch32 Secure Payload, **SP-MIN**, that illustrates
the usage and integration of the PSCI library with EL3 Runtime Software the usage and integration of the PSCI library with EL3 Runtime Software
...@@ -1402,11 +1402,11 @@ New features ...@@ -1402,11 +1402,11 @@ New features
Commits now must have a 'Signed-off-by:' field to certify that the Commits now must have a 'Signed-off-by:' field to certify that the
contribution has been made under the terms of 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. 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 - Introduced Performance Measurement Framework (PMF) which provides support
for capturing, storing, dumping and retrieving time-stamps to measure the for capturing, storing, dumping and retrieving time-stamps to measure the
...@@ -1620,13 +1620,13 @@ New features ...@@ -1620,13 +1620,13 @@ New features
- Added the following new design documents: - Added the following new design documents:
- `Authentication framework`_ - :ref:`Authentication Framework & Chain of Trust`
- `Firmware Update`_ - :ref:`Firmware Update (FWU)`
- `TF-A Reset Design`_ - :ref:`CPU Reset`
- `Power Domain Topology Design`_ - :ref:`PSCI Power Domain Tree Structure`
- Applied the new image terminology to the code base and documentation, as - 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 - The build system has been reworked to improve readability and facilitate
adding future extensions. adding future extensions.
...@@ -1694,7 +1694,8 @@ Issues resolved since last release ...@@ -1694,7 +1694,8 @@ Issues resolved since last release
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- The Trusted Board Boot implementation has been redesigned to provide greater - 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. All missing mandatory features are now implemented.
- The FVP and Juno ports may now use the hash of the ROTPK stored in the - The FVP and Juno ports may now use the hash of the ROTPK stored in the
...@@ -1826,7 +1827,7 @@ New features ...@@ -1826,7 +1827,7 @@ New features
create mappings only for areas in the memory map that it needs. 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 - 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 Issues resolved since last release
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...@@ -2423,16 +2424,6 @@ releases of TF-A. ...@@ -2423,16 +2424,6 @@ releases of TF-A.
*Copyright (c) 2013-2019, Arm Limited and Contributors. All rights reserved.* *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 .. _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 .. _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 .. _PR#1002: https://github.com/ARM-software/arm-trusted-firmware/pull/1002#issuecomment-312650193
.. _mbed TLS releases: https://tls.mbed.org/tech-updates/releases
docs/components/arm-sip-service.rst
View file @ f8e3340c
...@@ -24,9 +24,9 @@ file. ...@@ -24,9 +24,9 @@ file.
Performance Measurement Framework (PMF) 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 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 Execution State Switching service
--------------------------------- ---------------------------------
...@@ -89,8 +89,6 @@ respectively. ...@@ -89,8 +89,6 @@ respectively.
-------------- --------------
*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 .. _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
docs/components/exception-handling.rst
View file @ f8e3340c
...@@ -26,8 +26,8 @@ Introduction ...@@ -26,8 +26,8 @@ Introduction
Through various control bits in the ``SCR_EL3`` register, the Arm architecture 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 allows for asynchronous exceptions to be routed to EL3. As described in the
`Interrupt Framework Design`_ document, depending on the chosen interrupt :ref:`Interrupt Management Framework` document, depending on the chosen
routing model, TF-A appropriately sets the ``FIQ`` and ``IRQ`` bits of 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 ``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, 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. FIQs and IRQs routed to EL3 are not required to be handled in EL3.
...@@ -143,8 +143,9 @@ Interrupt handling ...@@ -143,8 +143,9 @@ Interrupt handling
------------------ ------------------
The |EHF| is a client of *Interrupt Management Framework*, and registers the 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 top-level handler for interrupts that target EL3, as described in the
Framework Design`_ document. This has the following implications. :ref:`Interrupt Management Framework` document. This has the following
implications:
- On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of - 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 sufficient priority are signalled as FIQs, and therefore will be routed to
...@@ -618,9 +619,8 @@ The |EHF| has the following limitations: ...@@ -618,9 +619,8 @@ The |EHF| has the following limitations:
exception descriptor and the programmed priority of interrupts handled by the exception descriptor and the programmed priority of interrupts handled by the
dispatcher match. The |EHF| cannot verify that this has been followed. 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 .. _SDEI specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
docs/components/firmware-update.rst
View file @ f8e3340c
...@@ -14,8 +14,8 @@ be complemented by other, higher level firmware update software. ...@@ -14,8 +14,8 @@ be complemented by other, higher level firmware update software.
FWU implements a specific part of the Trusted Board Boot Requirements (TBBR) FWU implements a specific part of the Trusted Board Boot Requirements (TBBR)
specification, Arm DEN0006C-1. It should be used in conjunction with the specification, Arm DEN0006C-1. It should be used in conjunction with the
`Trusted Board Boot`_ design document, which describes the image authentication :ref:`Trusted Board Boot` design document, which describes the image
parts of the Trusted Firmware-A (TF-A) TBBR implementation. authentication parts of the Trusted Firmware-A (TF-A) TBBR implementation.
Scope Scope
~~~~~ ~~~~~
...@@ -53,10 +53,11 @@ The primary requirements of the FWU feature are: ...@@ -53,10 +53,11 @@ The primary requirements of the FWU feature are:
at other Exception Levels. at other Exception Levels.
#. Export a platform interface to provide FWU common code with the information #. Export a platform interface to provide FWU common code with the information
it needs, and to enable platform specific FWU functionality. See the 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 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. 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 Arm CSS platforms like Juno have a System Control Processor (SCP), and these
...@@ -70,8 +71,8 @@ Image Identification ...@@ -70,8 +71,8 @@ Image Identification
Each FWU image and certificate is identified by a unique ID, defined by the 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 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 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`_ Chain of Trust (Refer to the :ref:`Authentication Framework & Chain of Trust`
for more information). document for more information).
The image descriptor includes the following information: The image descriptor includes the following information:
...@@ -394,11 +395,6 @@ This is only allowed if the image is not being executed. ...@@ -394,11 +395,6 @@ This is only allowed if the image is not being executed.
*Copyright (c) 2015-2019, Arm Limited and Contributors. All rights reserved.* *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 .. _Universally Unique Identifier: https://tools.ietf.org/rfc/rfc4122.txt
.. |Flow Diagram| image:: ../resources/diagrams/fwu_flow.png .. |Flow Diagram| image:: ../resources/diagrams/fwu_flow.png
.. |FWU state machine| image:: ../resources/diagrams/fwu_states.png .. |FWU state machine| image:: ../resources/diagrams/fwu_states.png
docs/components/platform-interrupt-controller-API.rst
View file @ f8e3340c
...@@ -3,9 +3,8 @@ Platform Interrupt Controller API ...@@ -3,9 +3,8 @@ Platform Interrupt Controller API
This document lists the optional platform interrupt controller API that This document lists the optional platform interrupt controller API that
abstracts the runtime configuration and control of interrupt controller from the abstracts the runtime configuration and control of interrupt controller from the
generic code. The mandatory APIs are described in the `porting guide`__. generic code. The mandatory APIs are described in the
:ref:`Porting Guide <porting_guide_imf_in_bl31>`.
.. __: ../getting_started/porting-guide.rst#interrupt-management-framework-in-bl31
Function: unsigned int plat_ic_get_running_priority(void); [optional] Function: unsigned int plat_ic_get_running_priority(void); [optional]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -303,6 +302,6 @@ should return ``INTR_ID_UNAVAILABLE``. ...@@ -303,6 +302,6 @@ should return ``INTR_ID_UNAVAILABLE``.
In case of Arm standard platforms using GIC, the implementation of the API 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. 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.*
docs/components/ras.rst
View file @ f8e3340c
Reliability, Availability, and Serviceability (RAS) Extensions 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 This document describes |TF-A| support for Arm Reliability, Availability, and
Serviceability (RAS) extensions. RAS is a mandatory extension for Armv8.2 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. later CPUs, and also an optional extension to the base Armv8.0 architecture.
...@@ -247,6 +244,6 @@ explicit using `EHF APIs`__. ...@@ -247,6 +244,6 @@ explicit using `EHF APIs`__.
.. __: exception-handling.rst#non-interrupt-flow .. __: exception-handling.rst#non-interrupt-flow
.. __: exception-handling.rst#activating-and-deactivating-priorities .. __: 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.*
docs/components/sdei.rst
View file @ f8e3340c
...@@ -7,7 +7,7 @@ Trusted Firmware-A (TF-A). ...@@ -7,7 +7,7 @@ Trusted Firmware-A (TF-A).
Introduction 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 Non-secure world to register handlers with firmware to receive notifications
about system events. Firmware will first receive the system events by way of about system events. Firmware will first receive the system events by way of
asynchronous exceptions and, in response, arranges for the registered handler to asynchronous exceptions and, in response, arranges for the registered handler to
...@@ -50,9 +50,6 @@ The remainder of this document only discusses the design and implementation of ...@@ -50,9 +50,6 @@ The remainder of this document only discusses the design and implementation of
SDEI dispatcher in TF-A, and assumes that the reader is familiar with the SDEI SDEI dispatcher in TF-A, and assumes that the reader is familiar with the SDEI
specification, the interfaces, and their requirements. specification, the interfaces, and their requirements.
.. [#std-event] Except event 0, which is defined by the SDEI specification as a
standard event.
Defining events Defining events
--------------- ---------------
...@@ -78,12 +75,10 @@ event descriptors. Both macros take 3 arguments: ...@@ -78,12 +75,10 @@ event descriptors. Both macros take 3 arguments:
To define event 0, the macro ``SDEI_DEFINE_EVENT_0()`` should be used. This 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. 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()`` result of receiving an SDEI interrupt), the macro ``SDEI_EXPLICIT_EVENT()``
should be used. It accepts two parameters: should be used. It accepts two parameters:
.. __: `Explicit dispatch of events`_
- The event number (as above); - The event number (as above);
- Event priority: ``SDEI_MAPF_CRITICAL`` or ``SDEI_MAPF_NORMAL``, as described - Event priority: ``SDEI_MAPF_CRITICAL`` or ``SDEI_MAPF_NORMAL``, as described
...@@ -110,9 +105,7 @@ Regarding event descriptors: ...@@ -110,9 +105,7 @@ Regarding event descriptors:
- Statically bound shared and private interrupts must be bound to shared and - Statically bound shared and private interrupts must be bound to shared and
private interrupts on the platform, respectively. See the section on 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 - Both arrays should be one-dimensional. The ``REGISTER_SDEI_MAP()`` macro
takes care of replicating private events for each PE on the platform. takes care of replicating private events for each PE on the platform.
...@@ -130,9 +123,8 @@ Event flags ...@@ -130,9 +123,8 @@ Event flags
~~~~~~~~~~~ ~~~~~~~~~~~
Event flags describe the properties of the event. They are bit maps that can be 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`__. ``OR``\ ed to form parameters to macros that define events (see
`Defining events`_).
.. __: `Defining events`_
- ``SDEI_MAPF_DYNAMIC``: Marks the event as dynamic. Dynamic events can be - ``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 bound to (or released from) any Non-secure interrupt at runtime via the
...@@ -196,7 +188,7 @@ interrupts for the platform: ...@@ -196,7 +188,7 @@ interrupts for the platform:
be configured as *Group 0*. Additionally, on GICv2 systems, the build option be configured as *Group 0*. Additionally, on GICv2 systems, the build option
``GICV2_G0_FOR_EL3`` must be set to ``1``. ``GICV2_G0_FOR_EL3`` must be set to ``1``.
See also `SDEI porting requirements`_. See also :ref:`porting_guide_sdei_requirements`.
Determining client EL Determining client EL
--------------------- ---------------------
...@@ -250,10 +242,6 @@ rest of the sequence is similar to that in the `general SDEI dispatch`_: the ...@@ -250,10 +242,6 @@ rest of the sequence is similar to that in the `general SDEI dispatch`_: the
requested event is dispatched to the client (assuming all the conditions are requested event is dispatched to the client (assuming all the conditions are
met), and when the handler completes, the preempted execution resumes. 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 Conditions for event dispatch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -307,10 +295,8 @@ dispatcher: ...@@ -307,10 +295,8 @@ dispatcher:
Porting requirements Porting requirements
-------------------- --------------------
The porting requirements of the SDEI dispatcher are outlined in the `porting The porting requirements of the SDEI dispatcher are outlined in the
guide`__. :ref:`Porting Guide <porting_guide_sdei_requirements>`.
.. __: `SDEI porting requirements`_
Note on writing SDEI event handlers Note on writing SDEI event handlers
----------------------------------- -----------------------------------
...@@ -364,10 +350,18 @@ implemented in assembly, following a similar pattern as below: ...@@ -364,10 +350,18 @@ implemented in assembly, following a similar pattern as below:
smc #0 smc #0
b . b .
---- --------------
*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.*
*Copyright (c) 2017-2018, 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 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`_ .. _Software Delegated Exception Interface: `SDEI specification`_
docs/components/xlat-tables-lib-v2-design.rst
View file @ f8e3340c
...@@ -30,8 +30,8 @@ About version 1 and version 2 ...@@ -30,8 +30,8 @@ About version 1 and version 2
----------------------------- -----------------------------
This document focuses on version 2 of the library, whose sources are available 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 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 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 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 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, back-ported to version 1. Therefore, it is recommended to use version 2,
...@@ -62,7 +62,7 @@ map. It is one of the key interfaces to the library. It is identified by: ...@@ -62,7 +62,7 @@ map. It is one of the key interfaces to the library. It is identified by:
- its attributes; - its attributes;
- its mapping granularity (optional). - 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 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 library transpose that in a set of translation tables. As a result, the library
...@@ -73,7 +73,7 @@ normal memory) as well as the memory access permissions (read-only or ...@@ -73,7 +73,7 @@ normal memory) as well as the memory access permissions (read-only or
read-write, executable or not, secure or non-secure, and so on). In the case of 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 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 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. Never attribute is set simultaneously for both EL1 and EL0.
The granularity controls the translation table level to go down to when mapping The granularity controls the translation table level to go down to when mapping
...@@ -162,7 +162,7 @@ coming (for the most part) from platform-specific defines: ...@@ -162,7 +162,7 @@ coming (for the most part) from platform-specific defines:
- size of the virtual address space: ``PLAT_VIRT_ADDR_SPACE_SIZE``; - size of the virtual address space: ``PLAT_VIRT_ADDR_SPACE_SIZE``;
- size of the physical address space: ``PLAT_PHY_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 Static and dynamic memory regions
...@@ -201,7 +201,7 @@ Library APIs ...@@ -201,7 +201,7 @@ Library APIs
------------ ------------
The external APIs exposed by this library are declared and documented in the 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 getting information about the usage of the different APIs this library
provides. This section just provides some extra details and clarifications. provides. This section just provides some extra details and clarifications.
...@@ -284,7 +284,7 @@ The library is divided into 4 modules: ...@@ -284,7 +284,7 @@ The library is divided into 4 modules:
provides functions such as ``mmap_add_region_ctx`` that let the caller specify provides functions such as ``mmap_add_region_ctx`` that let the caller specify
the translation tables context affected by them. the translation tables context affected by them.
See `xlat_tables_core.c`_. See ``xlat_tables_core.c``.
- **Active context module** - **Active context module**
...@@ -293,14 +293,14 @@ The library is divided into 4 modules: ...@@ -293,14 +293,14 @@ The library is divided into 4 modules:
This module provides functions such as ``mmap_add_region``, that directly This module provides functions such as ``mmap_add_region``, that directly
affect the BL image using them. affect the BL image using them.
See `xlat_tables_context.c`_. See ``xlat_tables_context.c``.
- **Utilities module** - **Utilities module**
Provides additional functionality like debug print of the current state of the Provides additional functionality like debug print of the current state of the
translation tables and helpers to query memory attributes and to modify them. translation tables and helpers to query memory attributes and to modify them.
See `xlat_tables_utils.c`_. See ``xlat_tables_utils.c``.
- **Architectural module** - **Architectural module**
...@@ -309,7 +309,7 @@ The library is divided into 4 modules: ...@@ -309,7 +309,7 @@ The library is divided into 4 modules:
MMU, or calculate the Physical Address Space size. They do not need a MMU, or calculate the Physical Address Space size. They do not need a
translation context to work on. 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 From mmap regions to translation tables
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -343,7 +343,7 @@ The mapping function is implemented as a recursive algorithm. It is however ...@@ -343,7 +343,7 @@ The mapping function is implemented as a recursive algorithm. It is however
bound by the level of depth of the translation tables (the Armv8-A architecture bound by the level of depth of the translation tables (the Armv8-A architecture
allows up to 4 lookup levels). 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 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 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 sub-table if it is strictly necessary. This is to reduce the memory footprint of
...@@ -374,9 +374,6 @@ entries in the translation tables are checked to ensure consistency. Please ...@@ -374,9 +374,6 @@ entries in the translation tables are checked to ensure consistency. Please
refer to the comments in the source code of the core module for more details refer to the comments in the source code of the core module for more details
about the sorting algorithm in use. about the sorting algorithm in use.
.. [#granularity-ref] That is, when mmap regions do not enforce their mapping
granularity.
TLB maintenance operations TLB maintenance operations
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -402,20 +399,19 @@ descriptor. Given that the TLBs are not architecturally permitted to hold any ...@@ -402,20 +399,19 @@ descriptor. Given that the TLBs are not architecturally permitted to hold any
invalid translation table entry [#tlb-no-invalid-entry]_, this means that this invalid translation table entry [#tlb-no-invalid-entry]_, this means that this
mapping cannot be cached in the TLBs. 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. .. rubric:: Footnotes
.. [#tlb-no-invalid-entry] See section D4.10.1 `General TLB maintenance requirements` in Armv8-A, rev C.a.
.. [#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 .. |Alignment Example| image:: ../resources/diagrams/xlat_align.png
docs/contents.rst deleted 100644 → 0
View file @ 4fdad60c
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
docs/design/auth-framework.rst
View file @ f8e3340c
...@@ -637,9 +637,9 @@ all CoTs must present: ...@@ -637,9 +637,9 @@ all CoTs must present:
The TBBR specifies the additional certificates that must accompany these images 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 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 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, 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``. these identifiers can be obtained from ``include/common/tbbr/tbbr_img_def.h``.
...@@ -967,6 +967,4 @@ The mbedTLS library algorithm support is configured by both the ...@@ -967,6 +967,4 @@ The mbedTLS library algorithm support is configured by both the
*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.* *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 .. _TBBR-Client specification: https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a
docs/design/cpu-specific-build-macros.rst
View file @ f8e3340c
...@@ -29,6 +29,8 @@ vulnerability workarounds should be applied at runtime. ...@@ -29,6 +29,8 @@ vulnerability workarounds should be applied at runtime.
platform contains at least 1 CPU that requires dynamic mitigation. platform contains at least 1 CPU that requires dynamic mitigation.
Defaults to 0. Defaults to 0.
.. _arm_cpu_macros_errata_workarounds:
CPU Errata Workarounds CPU Errata Workarounds
---------------------- ----------------------
...@@ -47,9 +49,8 @@ errata notice document. The format of the define used to enable/disable the ...@@ -47,9 +49,8 @@ errata notice document. The format of the define used to enable/disable the
errata workaround is ``ERRATA_<Processor name>_<ID>``, where the ``Processor name`` errata workaround is ``ERRATA_<Processor name>_<ID>``, where the ``Processor name``
is for example ``A57`` for the ``Cortex_A57`` CPU. is for example ``A57`` for the ``Cortex_A57`` CPU.
Refer to the section *CPU errata status reporting* in Refer to :ref:`firmware_design_cpu_errata_reporting` for information on how to
`Firmware Design guide`_ for information on how to write errata workaround write errata workaround functions.
functions.
All workarounds are disabled by default. The platform is responsible for All workarounds are disabled by default. The platform is responsible for
enabling these workarounds according to its requirement by defining the enabling these workarounds according to its requirement by defining the
...@@ -326,6 +327,5 @@ architecture that can be enabled by the platform as desired. ...@@ -326,6 +327,5 @@ architecture that can be enabled by the platform as desired.
.. _Cortex-A53 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm048406/index.html .. _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-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 .. _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 .. _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 .. _Arm DSU Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm138168/index.html
docs/design/firmware-design.rst
View file @ f8e3340c
...@@ -2,24 +2,27 @@ Firmware Design ...@@ -2,24 +2,27 @@ Firmware Design
=============== ===============
Trusted Firmware-A (TF-A) implements a subset of the Trusted Board Boot Trusted Firmware-A (TF-A) implements a subset of the Trusted Board Boot
Requirements (TBBR) Platform Design Document (PDD) [1]_ for Arm reference Requirements (TBBR) Platform Design Document (PDD) for Arm reference
platforms. The TBB sequence starts when the platform is powered on and runs up 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 to the stage where it hands-off control to firmware running in the normal
world in DRAM. This is the cold boot path. 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 runtime service. PSCI is the interface from normal world software to firmware
implementing power management use-cases (for example, secondary CPU boot, implementing power management use-cases (for example, secondary CPU boot,
hotplug and idle). Normal world software can access TF-A runtime services via 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 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 TF-A implements a framework for configuring and managing interrupts generated
in either security state. The details of the interrupt management framework 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 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. TF-A can be built to support either AArch64 or AArch32 execution state.
...@@ -34,7 +37,7 @@ executed by the primary CPU, other than essential CPU initialization executed by ...@@ -34,7 +37,7 @@ executed by the primary CPU, other than essential CPU initialization executed by
all CPUs. The secondary CPUs are kept in a safe platform-specific state until all CPUs. The secondary CPUs are kept in a safe platform-specific state until
the primary CPU has performed enough initialization to boot them. 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. ``COLD_BOOT_SINGLE_CPU`` platform build option.
The cold boot path in this implementation of TF-A depends on the execution The cold boot path in this implementation of TF-A depends on the execution
...@@ -136,15 +139,15 @@ Determination of boot path ...@@ -136,15 +139,15 @@ Determination of boot path
Whenever a CPU is released from reset, BL1 needs to distinguish between a warm 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 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 ``plat_get_my_entrypoint()`` function in the :ref:`Porting Guide`). In the case
warm boot, a CPU is expected to continue execution from a separate 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 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 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 the :ref:`Porting Guide`) while the primary CPU executes the remaining cold boot
as described in the following sections. path as described in the following sections.
This step only applies when ``PROGRAMMABLE_RESET_ADDRESS=0``. Refer to the 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. ``PROGRAMMABLE_RESET_ADDRESS`` platform build option.
Architectural initialization Architectural initialization
...@@ -157,8 +160,8 @@ BL1 performs minimal architectural initialization as follows. ...@@ -157,8 +160,8 @@ BL1 performs minimal architectural initialization as follows.
BL1 sets up simple exception vectors for both synchronous and asynchronous BL1 sets up simple exception vectors for both synchronous and asynchronous
exceptions. The default behavior upon receiving an exception is to populate exceptions. The default behavior upon receiving an exception is to populate
a status code in the general purpose register ``X0/R0`` and call the a status code in the general purpose register ``X0/R0`` and call the
``plat_report_exception()`` function (see the `Porting Guide`_). The status ``plat_report_exception()`` function (see the :ref:`Porting Guide`). The
code is one of: status code is one of:
For AArch64: For AArch64:
...@@ -217,7 +220,7 @@ BL1 performs minimal architectural initialization as follows. ...@@ -217,7 +220,7 @@ BL1 performs minimal architectural initialization as follows.
- ``BL1_SMC_RUN_IMAGE``: This SMC is raised by BL2 to make BL1 pass control - ``BL1_SMC_RUN_IMAGE``: This SMC is raised by BL2 to make BL1 pass control
to EL3 Runtime Software. 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 Design Guide are supported for AArch64 only. These SMCs are currently
not supported when BL1 is built for AArch32. not supported when BL1 is built for AArch32.
...@@ -307,14 +310,15 @@ Firmware Update detection and execution ...@@ -307,14 +310,15 @@ Firmware Update detection and execution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
After performing platform setup, BL1 common code calls After performing platform setup, BL1 common code calls
``bl1_plat_get_next_image_id()`` to determine if `Firmware Update`_ is required or ``bl1_plat_get_next_image_id()`` to determine if :ref:`Firmware Update (FWU)` is
to proceed with the normal boot process. If the platform code returns required or to proceed with the normal boot process. If the platform code
``BL2_IMAGE_ID`` then the normal boot sequence is executed as described in the returns ``BL2_IMAGE_ID`` then the normal boot sequence is executed as described
next section, else BL1 assumes that `Firmware Update`_ is required and execution in the next section, else BL1 assumes that :ref:`Firmware Update (FWU)` is
passes to the first image in the `Firmware Update`_ process. In either case, BL1 required and execution passes to the first image in the
retrieves a descriptor of the next image by calling ``bl1_plat_get_image_desc()``. :ref:`Firmware Update (FWU)` process. In either case, BL1 retrieves a descriptor
The image descriptor contains an ``entry_point_info_t`` structure, which BL1 of the next image by calling ``bl1_plat_get_image_desc()``. The image descriptor
uses to initialize the execution state of the next image. contains an ``entry_point_info_t`` structure, which BL1 uses to initialize the
execution state of the next image.
BL2 image load and execution BL2 image load and execution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...@@ -440,7 +444,8 @@ initialization is complete. Hence, BL2 populates a platform-specific area of ...@@ -440,7 +444,8 @@ initialization is complete. Hence, BL2 populates a platform-specific area of
memory with the entrypoint and Saved Program Status Register (``SPSR``) of the 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 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 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 AArch64 BL31 (EL3 Runtime Software) execution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...@@ -539,7 +544,7 @@ It then replaces the exception vectors populated by BL1 with its own. BL31 ...@@ -539,7 +544,7 @@ It then replaces the exception vectors populated by BL1 with its own. BL31
exception vectors implement more elaborate support for handling SMCs since this exception vectors implement more elaborate support for handling SMCs since this
is the only mechanism to access the runtime services implemented by BL31 (PSCI 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 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. handler routine.
BL31 programs the ``CNTFRQ_EL0`` register with the clock frequency of the system BL31 programs the ``CNTFRQ_EL0`` register with the clock frequency of the system
...@@ -812,7 +817,8 @@ data access and all interrupt sources masked: ...@@ -812,7 +817,8 @@ data access and all interrupt sources masked:
The warm boot entrypoint may be implemented by using TF-A The warm boot entrypoint may be implemented by using TF-A
``psci_warmboot_entrypoint()`` function. In that case, the platform must fulfil ``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 EL3 runtime services framework
------------------------------ ------------------------------
...@@ -1051,7 +1057,9 @@ hooks to be registered with the generic PSCI code to be supported. ...@@ -1051,7 +1057,9 @@ hooks to be registered with the generic PSCI code to be supported.
The PSCI implementation in TF-A is a library which can be integrated with 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 AArch64 or AArch32 EL3 Runtime Software for Armv8-A systems. A guide to
integrating PSCI library with AArch32 EL3 Runtime Software can be found 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 Secure-EL1 Payloads and Dispatchers
----------------------------------- -----------------------------------
...@@ -1258,7 +1266,7 @@ handling functions. ...@@ -1258,7 +1266,7 @@ handling functions.
Details for implementing a CPU specific reset handler can be found in Details for implementing a CPU specific reset handler can be found in
Section 8. Details for implementing a platform specific reset handler can be 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 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 reset handling behavior is required between the first and the subsequent
...@@ -1292,6 +1300,8 @@ by the macro ``INTR_PROP_DESC()``. The macro takes the following arguments: ...@@ -1292,6 +1300,8 @@ by the macro ``INTR_PROP_DESC()``. The macro takes the following arguments:
- Interrupt configuration (either ``GIC_INTR_CFG_LEVEL`` or - Interrupt configuration (either ``GIC_INTR_CFG_LEVEL`` or
``GIC_INTR_CFG_EDGE``). ``GIC_INTR_CFG_EDGE``).
.. _firmware_design_cpu_ops_fwk:
CPU specific operations framework CPU specific operations framework
--------------------------------- ---------------------------------
...@@ -1333,7 +1343,7 @@ different CPUs during power down and reset handling. The platform can specify ...@@ -1333,7 +1343,7 @@ different CPUs during power down and reset handling. The platform can specify
any CPU optimization it wants to enable for each CPU. It can also specify 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 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 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 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 needs to be exported for each type of CPU in the platform. It is defined in
...@@ -1399,6 +1409,8 @@ reporting framework calls ``do_cpu_reg_dump`` which retrieves the matching ...@@ -1399,6 +1409,8 @@ reporting framework calls ``do_cpu_reg_dump`` which retrieves the matching
be reported and a pointer to the ASCII list of register names in a format be reported and a pointer to the ASCII list of register names in a format
expected by the crash reporting framework. expected by the crash reporting framework.
.. _firmware_design_cpu_errata_reporting:
CPU errata status reporting CPU errata status reporting
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -1408,8 +1420,8 @@ build options. Some errata workarounds have potential run-time implications; ...@@ -1408,8 +1420,8 @@ build options. Some errata workarounds have potential run-time implications;
therefore some are enabled by default, others not. Platform ports shall therefore some are enabled by default, others not. Platform ports shall
override build options to enable or disable errata as appropriate. The CPU override build options to enable or disable errata as appropriate. The CPU
drivers take care of applying errata workarounds that are enabled and applicable 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`_ to a given CPU. Refer to :ref:`arm_cpu_macros_errata_workarounds` for more
for more information. information.
Functions in CPU drivers that apply errata workaround must follow the Functions in CPU drivers that apply errata workaround must follow the
conventions listed below. conventions listed below.
...@@ -1866,7 +1878,7 @@ BL image during boot. ...@@ -1866,7 +1878,7 @@ BL image during boot.
Library at ROM Library at ROM
--------------- ---------------
Please refer to the `ROMLIB Design`_ document. Please refer to the :ref:`Library at ROM` document.
Firmware Image Package (FIP) Firmware Image Package (FIP)
---------------------------- ----------------------------
...@@ -1978,11 +1990,11 @@ is the smallest possible size of the coherent memory region. ...@@ -1978,11 +1990,11 @@ is the smallest possible size of the coherent memory region.
By default, all data structures which are susceptible to accesses with By default, all data structures which are susceptible to accesses with
mismatched attributes from various CPUs are allocated in a coherent memory mismatched attributes from various CPUs are allocated in a coherent memory
region (refer to section 2.1 of `Porting Guide`_). The coherent memory region region (refer to section 2.1 of :ref:`Porting Guide`). The coherent memory
accesses are Outer Shareable, non-cacheable and they can be accessed region accesses are Outer Shareable, non-cacheable and they can be accessed with
with the Device nGnRE attributes when the MMU is turned on. Hence, at the the Device nGnRE attributes when the MMU is turned on. Hence, at the expense of
expense of at least an extra page of memory, TF-A is able to work around at least an extra page of memory, TF-A is able to work around coherency issues
coherency issues due to mismatched memory attributes. due to mismatched memory attributes.
The alternative to the above approach is to allocate the susceptible data The alternative to the above approach is to allocate the susceptible data
structures in Normal WriteBack WriteAllocate Inner shareable memory. This structures in Normal WriteBack WriteAllocate Inner shareable memory. This
...@@ -2188,7 +2200,7 @@ As mentioned earlier, almost a page of memory can be saved by disabling ...@@ -2188,7 +2200,7 @@ As mentioned earlier, almost a page of memory can be saved by disabling
whether coherent memory should be used. If a platform disables 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 ``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 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 Isolating code and read-only data on separate memory pages
---------------------------------------------------------- ----------------------------------------------------------
...@@ -2381,6 +2393,8 @@ are changed within the ``bl31_plat_runtime_setup`` platform hook. The init ...@@ -2381,6 +2393,8 @@ are changed within the ``bl31_plat_runtime_setup`` platform hook. The init
section section can be reclaimed for any data which is accessed after cold 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. boot initialization and it is upto the platform to make the decision.
.. _firmware_design_pmf:
Performance Measurement Framework Performance Measurement Framework
--------------------------------- ---------------------------------
...@@ -2529,7 +2543,7 @@ Architecture Extension-specific code is included in the build. Otherwise, TF-A ...@@ -2529,7 +2543,7 @@ Architecture Extension-specific code is included in the build. Otherwise, TF-A
targets the base Armv8.0-A architecture; i.e. as if ``ARM_ARCH_MAJOR`` == 8 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. 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 For details on the Architecture Extension and available features, please refer
to the respective Architecture Extension Supplement. to the respective Architecture Extension Supplement.
...@@ -2668,37 +2682,26 @@ linker scripts which have the extension ``.ld``. ...@@ -2668,37 +2682,26 @@ linker scripts which have the extension ``.ld``.
FDTs provide a description of the hardware platform and are used by the Linux 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. 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)`_ - `Trusted Board Boot Requirements CLIENT (TBBR-CLIENT) Armv8-A (ARM DEN0006D)`_
.. [#] `Power State Coordination Interface PDD`_
.. [#] `SMC Calling Convention PDD`_ - `Power State Coordination Interface PDD`_
.. [#] `TF-A Interrupt Management Design guide`_.
- `SMC Calling Convention PDD`_
- :ref:`Interrupt Management Framework`
-------------- --------------
*Copyright (c) 2013-2019, Arm Limited and Contributors. All rights reserved.* *Copyright (c) 2013-2019, Arm Limited and Contributors. All rights reserved.*
.. _Reset Design: ./reset-design.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
.. _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
.. _SMCCC: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.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 .. _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 .. _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 .. _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 .. _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 .. _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 .. |Image 1| image:: ../resources/diagrams/rt-svc-descs-layout.png
docs/design/interrupt-framework-design.rst
View file @ f8e3340c
...@@ -177,10 +177,10 @@ uses this information to determine whether the IRQ or the FIQ bit should be ...@@ -177,10 +177,10 @@ uses this information to determine whether the IRQ or the FIQ bit should be
programmed in ``SCR_EL3`` while applying the routing model for a type of programmed in ``SCR_EL3`` while applying the routing model for a type of
interrupt. The platform provides this information through the interrupt. The platform provides this information through the
``plat_interrupt_type_to_line()`` API (described in 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 :ref:`Porting Guide`). For example, on the FVP port when the platform uses an
interrupt controller, Secure-EL1 interrupts are signaled through the FIQ signal Arm GICv2 interrupt controller, Secure-EL1 interrupts are signaled through the
while Non-secure interrupts are signaled through the IRQ signal. This applies FIQ signal while Non-secure interrupts are signaled through the IRQ signal.
when execution is in either security state. This applies when execution is in either security state.
Effect of mapping of several interrupt types to one signal Effect of mapping of several interrupt types to one signal
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...@@ -255,7 +255,7 @@ is expected to be aware of the secure devices present in the system and their ...@@ -255,7 +255,7 @@ is expected to be aware of the secure devices present in the system and their
associated interrupt numbers. It should configure the interrupt controller to associated interrupt numbers. It should configure the interrupt controller to
enable the secure interrupts, ensure that their priority is always higher than 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 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. handling of interrupts.
In the remainder of this document, for the sake of simplicity a Arm GICv2 system In the remainder of this document, for the sake of simplicity a Arm GICv2 system
...@@ -1013,7 +1013,6 @@ TSP by returning ``SMC_UNK`` error. ...@@ -1013,7 +1013,6 @@ TSP by returning ``SMC_UNK`` error.
*Copyright (c) 2014-2019, Arm Limited and Contributors. All rights reserved.* *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 .. _SMC calling convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
.. |Image 1| image:: ../resources/diagrams/sec-int-handling.png .. |Image 1| image:: ../resources/diagrams/sec-int-handling.png
......
docs/design/reset-design.rst
View file @ f8e3340c
...@@ -6,9 +6,9 @@ resets in Trusted Firmware-A (TF-A). It also describes how the platform ...@@ -6,9 +6,9 @@ resets in Trusted Firmware-A (TF-A). It also describes how the platform
integrator can tailor this code to the system configuration to some extent, integrator can tailor this code to the system configuration to some extent,
resulting in a simplified and more optimised boot flow. resulting in a simplified and more optimised boot flow.
This document should be used in conjunction with the `Firmware Design`_, which This document should be used in conjunction with the :ref:`Firmware Design`
provides greater implementation details around the reset code, specifically document which provides greater implementation details around the reset code,
for the cold boot path. specifically for the cold boot path.
General reset code flow General reset code flow
----------------------- -----------------------
...@@ -109,11 +109,14 @@ images might be done by the Trusted Boot Firmware or by platform code in BL31. ...@@ -109,11 +109,14 @@ images might be done by the Trusted Boot Firmware or by platform code in BL31.
Although the Arm FVP platform does not support programming the reset base 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 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 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 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 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 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 the right support in the SCP firmware, this is currently not implemented so the
...@@ -150,10 +153,7 @@ This might be done by the Trusted Boot Firmware or by platform code in BL31. ...@@ -150,10 +153,7 @@ This might be done by the Trusted Boot Firmware or by platform code in BL31.
-------------- --------------
*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.* *Copyright (c) 2015-2019, Arm Limited and Contributors. All rights reserved.*
.. _Firmware Design: firmware-design.rst
.. _User Guide: ../getting_started/user-guide.rst
.. |Default reset code flow| image:: ../resources/diagrams/default_reset_code.png .. |Default reset code flow| image:: ../resources/diagrams/default_reset_code.png
.. |Reset code flow with programmable reset address| image:: ../resources/diagrams/reset_code_no_boot_type_check.png .. |Reset code flow with programmable reset address| image:: ../resources/diagrams/reset_code_no_boot_type_check.png
......
docs/design/trusted-board-boot.rst
View file @ f8e3340c
...@@ -8,8 +8,9 @@ Public-Key-Cryptography Standards (PKCS). ...@@ -8,8 +8,9 @@ Public-Key-Cryptography Standards (PKCS).
This document describes the design of Trusted Firmware-A (TF-A) TBB, which is an This document describes the design of Trusted Firmware-A (TF-A) TBB, which is an
implementation of the `Trusted Board Boot Requirements (TBBR)`_ specification, implementation of the `Trusted Board Boot Requirements (TBBR)`_ specification,
Arm DEN0006D. It should be used in conjunction with the `Firmware Update`_ Arm DEN0006D. It should be used in conjunction with the
design document, which implements a specific aspect of the TBBR. :ref:`Firmware Update (FWU)` design document, which implements a specific aspect
of the TBBR.
Chain of Trust Chain of Trust
-------------- --------------
...@@ -186,7 +187,8 @@ The next step is executed for all the boot loader images. ...@@ -186,7 +187,8 @@ The next step is executed for all the boot loader images.
The Trusted Board Boot implementation spans both generic and platform-specific 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 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 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 the FIP along with the boot loader images. These certificates are loaded in
...@@ -201,10 +203,11 @@ Authentication Framework ...@@ -201,10 +203,11 @@ Authentication Framework
The authentication framework included in TF-A provides support to implement The authentication framework included in TF-A provides support to implement
the desired trusted boot sequence. Arm platforms use this framework to 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 More information about the authentication framework can be found in the
`Auth Framework`_ document. :ref:`Authentication Framework & Chain of Trust` document.
Certificate Generation Tool Certificate Generation Tool
--------------------------- ---------------------------
...@@ -221,15 +224,11 @@ directory. ...@@ -221,15 +224,11 @@ directory.
The tool resides in the ``tools/cert_create`` directory. It uses OpenSSL SSL 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 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.* *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 .. _X.509 v3: https://tools.ietf.org/rfc/rfc5280.txt
.. _User Guide: ../getting_started/user-guide.rst .. _Trusted Board Boot Requirements (TBBR): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a
.. _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`_
docs/getting_started/docs-build.rst 0 → 100644
View file @ f8e3340c
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/
docs/getting_started/index.rst
View file @ f8e3340c
...@@ -7,6 +7,7 @@ Getting Started ...@@ -7,6 +7,7 @@ Getting Started
:numbered: :numbered:
user-guide user-guide
docs-build
image-terminology image-terminology
porting-guide porting-guide
psci-lib-integration-guide psci-lib-integration-guide
......
docs/getting_started/porting-guide.rst
View file @ f8e3340c
...@@ -13,20 +13,20 @@ Modifications consist of: ...@@ -13,20 +13,20 @@ Modifications consist of:
- Defining certain constants (for example #defines). - Defining certain constants (for example #defines).
The platform-specific functions and variables are declared in The platform-specific functions and variables are declared in
`include/plat/common/platform.h`_. The firmware provides a default implementation ``include/plat/common/platform.h``. The firmware provides a default
of variables and functions to fulfill the optional requirements. These implementation of variables and functions to fulfill the optional requirements.
implementations are all weakly defined; they are provided to ease the porting These implementations are all weakly defined; they are provided to ease the
effort. Each platform port can override them with its own implementation if the porting effort. Each platform port can override them with its own implementation
default implementation is inadequate. if the default implementation is inadequate.
Some modifications are common to all Boot Loader (BL) stages. Section 2 Some modifications are common to all Boot Loader (BL) stages. Section 2
discusses these in detail. The subsequent sections discuss the remaining discusses these in detail. The subsequent sections discuss the remaining
modifications for each BL stage in detail. 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 Please refer to the :ref:`Platform Compatibility Policy` for the policy
compatibility and deprecation of these porting interfaces. regarding compatibility and deprecation of these porting interfaces.
Only Arm development platforms (such as FVP and Juno) may use the Only Arm development platforms (such as FVP and Juno) may use the
functions/definitions in ``include/plat/arm/common/`` and the corresponding functions/definitions in ``include/plat/arm/common/`` and the corresponding
...@@ -98,7 +98,7 @@ Each platform must ensure that a header file of this name is in the system ...@@ -98,7 +98,7 @@ Each platform must ensure that a header file of this name is in the system
include path with the following constants defined. This will require updating include path with the following constants defined. This will require updating
the list of ``PLAT_INCLUDES`` in the ``platform.mk`` file. 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 which provides typical values for some of the constants below. These values are
likely to be suitable for all platform ports. likely to be suitable for all platform ports.
...@@ -115,8 +115,8 @@ likely to be suitable for all platform ports. ...@@ -115,8 +115,8 @@ likely to be suitable for all platform ports.
- **#define : PLATFORM_STACK_SIZE** - **#define : PLATFORM_STACK_SIZE**
Defines the normal stack memory available to each CPU. This constant is used Defines the normal stack memory available to each CPU. This constant is used
by `plat/common/aarch64/platform_mp_stack.S`_ and by ``plat/common/aarch64/platform_mp_stack.S`` and
`plat/common/aarch64/platform_up_stack.S`_. ``plat/common/aarch64/platform_up_stack.S``.
- **define : CACHE_WRITEBACK_GRANULE** - **define : CACHE_WRITEBACK_GRANULE**
...@@ -542,7 +542,7 @@ optionally be defined: ...@@ -542,7 +542,7 @@ optionally be defined:
Maximum number of partition entries required by the platform. This allows Maximum number of partition entries required by the platform. This allows
control how much memory is allocated for partition entries. The default control how much memory is allocated for partition entries. The default
value is 128. 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 PLAT_PARTITION_MAX_ENTRIES := 12
$(eval $(call add_define,PLAT_PARTITION_MAX_ENTRIES)) $(eval $(call add_define,PLAT_PARTITION_MAX_ENTRIES))
...@@ -828,7 +828,8 @@ runtime environment. This function can clobber x0 - x8 and must preserve ...@@ -828,7 +828,8 @@ runtime environment. This function can clobber x0 - x8 and must preserve
x9 - x29. x9 - x29.
This function plays a crucial role in the power domain topology framework in 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() Function : plat_core_pos_by_mpidr()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -844,7 +845,7 @@ case the ``MPIDR`` is invalid, this function returns -1. This function will only ...@@ -844,7 +845,7 @@ case the ``MPIDR`` is invalid, this function returns -1. This function will only
be invoked by BL31 after the power domain topology is initialized and can 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 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 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] Function : plat_get_mbedtls_heap() [when TRUSTED_BOARD_BOOT == 1]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -895,8 +896,8 @@ of the stack allocated to each CPU is specified by the platform defined ...@@ -895,8 +896,8 @@ of the stack allocated to each CPU is specified by the platform defined
constant ``PLATFORM_STACK_SIZE``. constant ``PLATFORM_STACK_SIZE``.
Common implementations of this function for the UP and MP BL images are Common implementations of this function for the UP and MP BL images are
provided in `plat/common/aarch64/platform_up_stack.S`_ and provided in ``plat/common/aarch64/platform_up_stack.S`` and
`plat/common/aarch64/platform_mp_stack.S`_ ``plat/common/aarch64/platform_mp_stack.S``
Function : plat_get_my_stack() Function : plat_get_my_stack()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -913,8 +914,8 @@ of the stack allocated to each CPU is specified by the platform defined ...@@ -913,8 +914,8 @@ of the stack allocated to each CPU is specified by the platform defined
constant ``PLATFORM_STACK_SIZE``. constant ``PLATFORM_STACK_SIZE``.
Common implementations of this function for the UP and MP BL images are Common implementations of this function for the UP and MP BL images are
provided in `plat/common/aarch64/platform_up_stack.S`_ and provided in ``plat/common/aarch64/platform_up_stack.S`` and
`plat/common/aarch64/platform_mp_stack.S`_ ``plat/common/aarch64/platform_mp_stack.S``
Function : plat_report_exception() Function : plat_report_exception()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -937,12 +938,12 @@ about the way the platform displays its status information. ...@@ -937,12 +938,12 @@ about the way the platform displays its status information.
For AArch64, this function receives the exception type as its argument. For AArch64, this function receives the exception type as its argument.
Possible values for exceptions types are listed in the 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. related to any architectural exception code; they are just a TF-A convention.
For AArch32, this function receives the exception mode as its argument. For AArch32, this function receives the exception mode as its argument.
Possible values for exception modes are listed in the 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() Function : plat_reset_handler()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -958,7 +959,7 @@ specific errata workarounds could also be implemented here. The API should ...@@ -958,7 +959,7 @@ specific errata workarounds could also be implemented here. The API should
preserve the values of callee saved registers x19 to x29. 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 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. guidelines.
Function : plat_disable_acp() Function : plat_disable_acp()
...@@ -1475,8 +1476,8 @@ Boot Loader Stage 2 (BL2) at EL3 ...@@ -1475,8 +1476,8 @@ Boot Loader Stage 2 (BL2) at EL3
When the platform has a non-TF-A Boot ROM it is desirable to jump 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 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 execute at EL3 instead of executing at EL1. Refer to the :ref:`Firmware Design`
Design`_ for more information. document for more information.
All mandatory functions of BL2 must be implemented, except the functions All mandatory functions of BL2 must be implemented, except the functions
bl2_early_platform_setup and bl2_el3_plat_arch_setup, because bl2_early_platform_setup and bl2_el3_plat_arch_setup, because
...@@ -1852,6 +1853,8 @@ calculated by the linker then a link time assertion is raised. A compile time ...@@ -1852,6 +1853,8 @@ calculated by the linker then a link time assertion is raised. A compile time
assertion is raised if the value of the constant is not aligned to the cache assertion is raised if the value of the constant is not aligned to the cache
line boundary. line boundary.
.. _porting_guide_sdei_requirements:
SDEI porting requirements SDEI porting requirements
~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -1936,7 +1939,7 @@ example, a CPU) is at level 0. If the *power domain* node above a CPU is a ...@@ -1936,7 +1939,7 @@ example, a CPU) is at level 0. If the *power domain* node above a CPU is a
logical grouping of CPUs that share some state, then level 1 is that group of 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 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 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 BL31's platform initialization code exports a pointer to the platform-specific
power management operations required for the PSCI implementation to function power management operations required for the PSCI implementation to function
...@@ -2048,13 +2051,13 @@ Function : plat_get_power_domain_tree_desc() [mandatory] ...@@ -2048,13 +2051,13 @@ Function : plat_get_power_domain_tree_desc() [mandatory]
This function returns a pointer to the byte array containing the power domain 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 topology tree description. The format and method to construct this array are
described in `Power Domain Topology Design`_. The BL31 PSCI initialization code described in :ref:`PSCI Power Domain Tree Structure`. The BL31 PSCI
requires this array to be described by the platform, either statically or initialization code requires this array to be described by the platform, either
dynamically, to initialize the power domain topology tree. In case the array statically or dynamically, to initialize the power domain topology tree. In case
is populated dynamically, then plat_core_pos_by_mpidr() and 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 plat_my_core_pos() should also be implemented suitably so that the topology tree
tree description matches the CPU indices returned by these APIs. These APIs description matches the CPU indices returned by these APIs. These APIs together
together form the platform interface for the PSCI topology framework. form the platform interface for the PSCI topology framework.
Function : plat_setup_psci_ops() [mandatory] Function : plat_setup_psci_ops() [mandatory]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...@@ -2076,10 +2079,10 @@ pointer with a pointer to BL31's private ``plat_psci_ops`` structure. ...@@ -2076,10 +2079,10 @@ pointer with a pointer to BL31's private ``plat_psci_ops`` structure.
A description of each member of this structure is given below. Please refer to A description of each member of this structure is given below. Please refer to
the Arm FVP specific implementation of these handlers in 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 platform wants to support, the associated operation or operations in this
structure must be provided and implemented (Refer section 4 of 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 function in a platform port, the operation should be removed from this
structure instead of providing an empty implementation. structure instead of providing an empty implementation.
...@@ -2367,13 +2370,15 @@ region defined by a base address ``base`` and with a size of ``length`` ...@@ -2367,13 +2370,15 @@ region defined by a base address ``base`` and with a size of ``length``
bytes is protected by ``MEM_PROTECT``. If the region is protected bytes is protected by ``MEM_PROTECT``. If the region is protected
then it must return 0, otherwise it must return a negative number. then it must return 0, otherwise it must return a negative number.
.. _porting_guide_imf_in_bl31:
Interrupt Management framework (in BL31) Interrupt Management framework (in BL31)
---------------------------------------- ----------------------------------------
BL31 implements an Interrupt Management Framework (IMF) to manage interrupts 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 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 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 A platform should export the following APIs to support the IMF. The following
text briefly describes each API and its implementation in Arm standard text briefly describes each API and its implementation in Arm standard
...@@ -2383,7 +2388,7 @@ present in the platform. Arm standard platform layer supports both ...@@ -2383,7 +2388,7 @@ present in the platform. Arm standard platform layer supports both
and `3.0 (GICv3)`_. Juno builds the Arm platform layer to use GICv2 and the 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 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 ``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`__. See also: `Interrupt Controller Abstraction APIs`__.
...@@ -2405,10 +2410,10 @@ the platform IC uses to signal each type of interrupt supported by the framework ...@@ -2405,10 +2410,10 @@ the platform IC uses to signal each type of interrupt supported by the framework
from a given security state. This API must be invoked at EL3. from a given security state. This API must be invoked at EL3.
The first parameter will be one of the ``INTR_TYPE_*`` values (see 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 :ref:`Interrupt Management Framework`) indicating the target type of the
security state of the originating execution context. The return result is the interrupt, the second parameter is the security state of the originating
bit position in the ``SCR_EL3`` register of the respective interrupt trap: IRQ=1, execution context. The return result is the bit position in the ``SCR_EL3``
FIQ=2. register of the respective interrupt trap: IRQ=1, FIQ=2.
In the case of Arm standard platforms using GICv2, S-EL1 interrupts are 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 configured as FIQs and Non-secure interrupts as IRQs from either security
...@@ -2792,7 +2797,7 @@ storage access is only required by BL1 and BL2 phases and performed inside the ...@@ -2792,7 +2797,7 @@ storage access is only required by BL1 and BL2 phases and performed inside the
It is mandatory to implement at least one storage driver. For the Arm It is mandatory to implement at least one storage driver. For the Arm
development platforms the Firmware Image Package (FIP) driver is provided as development platforms the Firmware Image Package (FIP) driver is provided as
the default means to load data from storage (see the "Firmware Image Package" 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 ``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 is in ``drivers/io/io_storage.c`` and the driver files are located in
``drivers/io/``. ``drivers/io/``.
...@@ -2843,22 +2848,7 @@ amount of open resources per driver. ...@@ -2843,22 +2848,7 @@ amount of open resources per driver.
*Copyright (c) 2013-2019, Arm Limited and Contributors. All rights reserved.* *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 .. _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 .. _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 .. _3.0 (GICv3): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0069b/index.html
.. _FreeBSD: https://www.freebsd.org .. _FreeBSD: https://www.freebsd.org
......
docs/getting_started/psci-lib-integration-guide.rst
View file @ f8e3340c
...@@ -437,13 +437,13 @@ The mandatory platform macros are: ...@@ -437,13 +437,13 @@ The mandatory platform macros are:
- PLAT_MAX_PWR_LVL_STATES (optional) - PLAT_MAX_PWR_LVL_STATES (optional)
- PLAT_PCPU_DATA_SIZE (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 All platform specific operations for power management are done via
``plat_psci_ops_t`` callbacks registered by the platform when ``plat_psci_ops_t`` callbacks registered by the platform when
``plat_setup_psci_ops()`` API is called. The description of each of ``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 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 PSCI API associated with that callback will not be supported by PSCI
library. library.
...@@ -524,12 +524,12 @@ CPU operations ...@@ -524,12 +524,12 @@ CPU operations
~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
The CPU operations (cpu_ops) framework implement power down sequence specific The CPU operations (cpu_ops) framework implement power down sequence specific
to the CPU and the details of which can be found in the to the CPU and the details of which can be found at
``CPU specific operations framework`` section of `Firmware Design`_. The TF-A :ref:`firmware_design_cpu_ops_fwk`. The TF-A tree implements the ``cpu_ops``
tree implements the ``cpu_ops`` for various supported CPUs and the EL3 Runtime for various supported CPUs and the EL3 Runtime Software needs to include the
Software needs to include the required ``cpu_ops`` in its build. The start and required ``cpu_ops`` in its build. The start and end of the ``cpu_ops``
end of the ``cpu_ops`` descriptors must be exported by the EL3 Runtime Software descriptors must be exported by the EL3 Runtime Software via the
via the ``__CPU_OPS_START__`` and ``__CPU_OPS_END__`` linker symbols. ``__CPU_OPS_START__`` and ``__CPU_OPS_END__`` linker symbols.
The ``cpu_ops`` descriptors also include reset sequences and may include errata 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 workarounds for the CPU. The EL3 Runtime Software can choose to call this
...@@ -538,11 +538,9 @@ workarounds. ...@@ -538,11 +538,9 @@ workarounds.
-------------- --------------
*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 .. _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 .. _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
.. _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
docs/getting_started/rt-svc-writers-guide.rst
View file @ f8e3340c
...@@ -21,8 +21,8 @@ independent implementation of services for each group, which are then compiled ...@@ -21,8 +21,8 @@ independent implementation of services for each group, which are then compiled
into the BL31 image. This simplifies the integration of common software from 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 Arm to support `PSCI`_, Secure Monitor for a Trusted OS and SoC specific
software. The common runtime services framework ensures that SMC Functions are software. The common runtime services framework ensures that SMC Functions are
dispatched to their respective service implementation - the `Firmware Design`_ dispatched to their respective service implementation - the
provides details of how this is achieved. :ref:`Firmware Design` document provides details of how this is achieved.
The interface and operation of the runtime services depends heavily on the The interface and operation of the runtime services depends heavily on the
concepts and definitions described in the `SMCCC`_, in particular SMC Function concepts and definitions described in the `SMCCC`_, in particular SMC Function
...@@ -79,11 +79,11 @@ handler will be responsible for all SMC Functions within a given service type. ...@@ -79,11 +79,11 @@ handler will be responsible for all SMC Functions within a given service type.
Getting started 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 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 Registering a runtime service
----------------------------- -----------------------------
...@@ -100,7 +100,7 @@ initialization and call handler functions. ...@@ -100,7 +100,7 @@ initialization and call handler functions.
is also used for diagnostic purposes is also used for diagnostic purposes
- ``_start`` and ``_end`` values must be based on the ``OEN_*`` values defined in - ``_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`` - ``_type`` must be one of ``SMC_TYPE_FAST`` or ``SMC_TYPE_YIELD``
...@@ -132,7 +132,7 @@ to ensure that the following conditions are met: ...@@ -132,7 +132,7 @@ to ensure that the following conditions are met:
#. The ``_type`` is one of ``SMC_TYPE_FAST`` or ``SMC_TYPE_YIELD`` #. The ``_type`` is one of ``SMC_TYPE_FAST`` or ``SMC_TYPE_YIELD``
#. ``_setup`` and ``_smch`` routines have been specified #. ``_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 .. code:: c
...@@ -296,13 +296,7 @@ provide this information.... ...@@ -296,13 +296,7 @@ provide this information....
-------------- --------------
*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 .. _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 .. _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
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment