mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2025-04-19 02:54:24 +00:00
Merge changes from topic "pb/sphinx-doc" into integration
* changes: doc: Use proper note and warning annotations doc: Refactor contributor acknowledgements doc: Reorganise images and update links doc: Set correct syntax highlighting style doc: Add minimal glossary doc: Remove per-page contents lists doc: Make checkpatch ignore rst files doc: Format security advisory titles and headings doc: Reformat platform port documents doc: Normalise section numbering and headings doc: Reword document titles
This commit is contained in:
Sandrine Bailleux
TrustedFirmware Code Review
commit
ced1711297
100 changed files with 750 additions and 559 deletions
6
Makefile
6
Makefile
|
|
@ -55,7 +55,7 @@ ROOT_DIRS_TO_CHECK := $(sort $(filter-out \
|
||||||
lib \
|
lib \
|
||||||
include \
|
include \
|
||||||
docs \
|
docs \
|
||||||
%.md, \
|
%.rst, \
|
||||||
$(wildcard *)))
|
$(wildcard *)))
|
||||||
CHECK_PATHS := ${ROOT_DIRS_TO_CHECK} \
|
CHECK_PATHS := ${ROOT_DIRS_TO_CHECK} \
|
||||||
${INC_DIRS_TO_CHECK} \
|
${INC_DIRS_TO_CHECK} \
|
||||||
|
|
@ -815,7 +815,7 @@ realclean distclean:
|
||||||
checkcodebase: locate-checkpatch
|
checkcodebase: locate-checkpatch
|
||||||
@echo " CHECKING STYLE"
|
@echo " CHECKING STYLE"
|
||||||
@if test -d .git ; then \
|
@if test -d .git ; then \
|
||||||
git ls-files | grep -E -v 'libfdt|libc|docs|\.md' | \
|
git ls-files | grep -E -v 'libfdt|libc|docs|\.rst' | \
|
||||||
while read GIT_FILE ; \
|
while read GIT_FILE ; \
|
||||||
do ${CHECKPATCH} ${CHECKCODE_ARGS} -f $$GIT_FILE ; \
|
do ${CHECKPATCH} ${CHECKCODE_ARGS} -f $$GIT_FILE ; \
|
||||||
done ; \
|
done ; \
|
||||||
|
|
@ -825,7 +825,7 @@ checkcodebase: locate-checkpatch
|
||||||
-not -iwholename "*libfdt*" \
|
-not -iwholename "*libfdt*" \
|
||||||
-not -iwholename "*libc*" \
|
-not -iwholename "*libc*" \
|
||||||
-not -iwholename "*docs*" \
|
-not -iwholename "*docs*" \
|
||||||
-not -iwholename "*.md" \
|
-not -iwholename "*.rst" \
|
||||||
-exec ${CHECKPATCH} ${CHECKCODE_ARGS} -f {} \; ; \
|
-exec ${CHECKPATCH} ${CHECKCODE_ARGS} -f {} \; ; \
|
||||||
fi
|
fi
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,28 +1,17 @@
|
||||||
**Note: This file is only relevant for legacy contributions, to acknowledge the
|
|
||||||
specific contributors referred to in "Arm Limited and Contributors" copyright
|
|
||||||
notices. As contributors are now encouraged to put their name or company name
|
|
||||||
directly into the copyright notices, this file is not relevant for new
|
|
||||||
contributions.**
|
|
||||||
|
|
||||||
Contributor Acknowledgements
|
Contributor Acknowledgements
|
||||||
============================
|
============================
|
||||||
|
|
||||||
Companies
|
.. note::
|
||||||
---------
|
This file is only relevant for legacy contributions, to acknowledge the
|
||||||
|
specific contributors referred to in "Arm Limited and Contributors" copyright
|
||||||
|
notices. As contributors are now encouraged to put their name or company name
|
||||||
|
directly into the copyright notices, this file is not relevant for new
|
||||||
|
contributions.
|
||||||
|
|
||||||
Linaro Limited
|
- Linaro Limited
|
||||||
|
- Marvell International Ltd.
|
||||||
NVIDIA Corporation
|
- NVIDIA Corporation
|
||||||
|
- NXP Semiconductors
|
||||||
Socionext Inc.
|
- Socionext Inc.
|
||||||
|
- STMicroelectronics
|
||||||
Xilinx, Inc.
|
- Xilinx, Inc.
|
||||||
|
|
||||||
NXP Semiconductors
|
|
||||||
|
|
||||||
Marvell International Ltd.
|
|
||||||
|
|
||||||
STMicroelectronics
|
|
||||||
|
|
||||||
Individuals
|
|
||||||
-----------
|
|
||||||
|
|
|
||||||
|
|
@ -1,11 +1,9 @@
|
||||||
Trusted Firmware-A Release Notes
|
Change Log & Release Notes
|
||||||
================================
|
==========================
|
||||||
|
|
||||||
This document contains a summary of the new features, changes, fixes and known
|
This document contains a summary of the new features, changes, fixes and known
|
||||||
issues in each release of Trusted Firmware-A.
|
issues in each release of Trusted Firmware-A.
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
Version 2.1
|
Version 2.1
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
|
|
@ -296,12 +294,12 @@ Changed
|
||||||
|
|
||||||
- SDEI
|
- SDEI
|
||||||
- Added support for unconditionally resuming secure world execution after
|
- Added support for unconditionally resuming secure world execution after
|
||||||
SDEI event processing completes
|
|SDEI| event processing completes
|
||||||
|
|
||||||
SDEI interrupts, although targeting EL3, occur on behalf of the non-secure
|
|SDEI| interrupts, although targeting EL3, occur on behalf of the non-secure
|
||||||
world, and may have higher priority than secure world
|
world, and may have higher priority than secure world
|
||||||
interrupts. Therefore they might preempt secure execution and yield
|
interrupts. Therefore they might preempt secure execution and yield
|
||||||
execution to the non-secure SDEI handler. Upon completion of SDEI event
|
execution to the non-secure |SDEI| handler. Upon completion of |SDEI| event
|
||||||
handling, resume secure execution if it was preempted.
|
handling, resume secure execution if it was preempted.
|
||||||
|
|
||||||
- Translation Tables (XLAT)
|
- Translation Tables (XLAT)
|
||||||
|
|
@ -503,7 +501,7 @@ New Features
|
||||||
|
|
||||||
- Implement dynamic mitigation for CVE-2018-3639 on Cortex-A76
|
- Implement dynamic mitigation for CVE-2018-3639 on Cortex-A76
|
||||||
|
|
||||||
- Ensure SDEI handler executes with CVE-2018-3639 mitigation enabled
|
- Ensure |SDEI| handler executes with CVE-2018-3639 mitigation enabled
|
||||||
|
|
||||||
- Introduce RAS handling on AArch64
|
- Introduce RAS handling on AArch64
|
||||||
|
|
||||||
|
|
@ -623,7 +621,7 @@ New Features
|
||||||
|
|
||||||
- Introduce jump primitives for BL31
|
- Introduce jump primitives for BL31
|
||||||
|
|
||||||
- Mask events after CPU wakeup in SDEI dispatcher to conform to the
|
- Mask events after CPU wakeup in |SDEI| dispatcher to conform to the
|
||||||
specification
|
specification
|
||||||
|
|
||||||
- Misc TF-A Core Common Code Enhancements
|
- Misc TF-A Core Common Code Enhancements
|
||||||
|
|
@ -787,8 +785,8 @@ New features
|
||||||
management and security services. The SPM is the firmware component that
|
management and security services. The SPM is the firmware component that
|
||||||
is responsible for managing a Secure Partition.
|
is responsible for managing a Secure Partition.
|
||||||
|
|
||||||
- SDEI dispatcher: Support for interrupt-based SDEI events and all
|
- SDEI dispatcher: Support for interrupt-based |SDEI| events and all
|
||||||
interfaces as defined by the SDEI specification v1.0, see
|
interfaces as defined by the |SDEI| specification v1.0, see
|
||||||
`SDEI Specification`_
|
`SDEI Specification`_
|
||||||
|
|
||||||
- Exception Handling Framework (EHF): Framework that allows dispatching of
|
- Exception Handling Framework (EHF): Framework that allows dispatching of
|
||||||
|
|
@ -1188,7 +1186,8 @@ New features
|
||||||
- Migrated to use SPDX[0] license identifiers to make software license
|
- Migrated to use SPDX[0] license identifiers to make software license
|
||||||
auditing simpler.
|
auditing simpler.
|
||||||
|
|
||||||
*NOTE:* Files that have been imported by FreeBSD have not been modified.
|
.. note::
|
||||||
|
Files that have been imported by FreeBSD have not been modified.
|
||||||
|
|
||||||
[0]: https://spdx.org/
|
[0]: https://spdx.org/
|
||||||
|
|
||||||
|
|
@ -2207,7 +2206,8 @@ New features
|
||||||
be used on the AEMv8 and Cortex-A57-A53 Base FVPs, as well as the Foundation
|
be used on the AEMv8 and Cortex-A57-A53 Base FVPs, as well as the Foundation
|
||||||
FVP.
|
FVP.
|
||||||
|
|
||||||
NOTE: The software will not work on Version 1.0 of the Foundation FVP.
|
.. note::
|
||||||
|
The software will not work on Version 1.0 of the Foundation FVP.
|
||||||
|
|
||||||
- Enabled third party contributions. Added a new contributing.md containing
|
- Enabled third party contributions. Added a new contributing.md containing
|
||||||
instructions for how to contribute and updated copyright text in all files
|
instructions for how to contribute and updated copyright text in all files
|
||||||
|
|
@ -2238,15 +2238,18 @@ New features
|
||||||
FIP from NOR flash, although some support for image loading using semi-
|
FIP from NOR flash, although some support for image loading using semi-
|
||||||
hosting is retained.
|
hosting is retained.
|
||||||
|
|
||||||
NOTE: Building a FIP by default is a non-backwards-compatible change.
|
.. note::
|
||||||
|
Building a FIP by default is a non-backwards-compatible change.
|
||||||
|
|
||||||
NOTE: Generic BL2 code now loads a BL3-3 (non-trusted firmware) image into
|
.. note::
|
||||||
DRAM instead of expecting this to be pre-loaded at known location. This is
|
Generic BL2 code now loads a BL3-3 (non-trusted firmware) image into
|
||||||
also a non-backwards-compatible change.
|
DRAM instead of expecting this to be pre-loaded at known location. This is
|
||||||
|
also a non-backwards-compatible change.
|
||||||
|
|
||||||
NOTE: Some non-trusted firmware (e.g. UEFI) will need to be rebuilt so that
|
.. note::
|
||||||
it knows the new location to execute from and no longer needs to copy
|
Some non-trusted firmware (e.g. UEFI) will need to be rebuilt so that
|
||||||
particular code modules to DRAM itself.
|
it knows the new location to execute from and no longer needs to copy
|
||||||
|
particular code modules to DRAM itself.
|
||||||
|
|
||||||
- Reworked BL2 to BL3-1 handover interface. A new composite structure
|
- Reworked BL2 to BL3-1 handover interface. A new composite structure
|
||||||
(bl31_args) holds the superset of information that needs to be passed from
|
(bl31_args) holds the superset of information that needs to be passed from
|
||||||
|
|
@ -2272,8 +2275,11 @@ New features
|
||||||
Dispatcher (TSPD), which is loaded as an EL3 runtime service. The TSPD
|
Dispatcher (TSPD), which is loaded as an EL3 runtime service. The TSPD
|
||||||
implements Secure Monitor functionality such as world switching and
|
implements Secure Monitor functionality such as world switching and
|
||||||
EL1 context management, and is responsible for communication with the TSP.
|
EL1 context management, and is responsible for communication with the TSP.
|
||||||
NOTE: The TSPD does not yet contain support for secure world interrupts.
|
|
||||||
NOTE: The TSP/TSPD is not built by default.
|
.. note::
|
||||||
|
The TSPD does not yet contain support for secure world interrupts.
|
||||||
|
.. note::
|
||||||
|
The TSP/TSPD is not built by default.
|
||||||
|
|
||||||
Issues resolved since last release
|
Issues resolved since last release
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Arm SiP Service
|
Arm SiP Services
|
||||||
===============
|
================
|
||||||
|
|
||||||
This document enumerates and describes the Arm SiP (Silicon Provider) services.
|
This document enumerates and describes the Arm SiP (Silicon Provider) services.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,14 +1,5 @@
|
||||||
Exception Handling Framework in Trusted Firmware-A
|
Exception Handling Framework
|
||||||
==================================================
|
============================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
:depth: 2
|
|
||||||
|
|
||||||
.. |EHF| replace:: Exception Handling Framework
|
|
||||||
.. |TF-A| replace:: Trusted Firmware-A
|
|
||||||
|
|
||||||
This document describes various aspects of handling exceptions by Runtime
|
This document describes various aspects of handling exceptions by Runtime
|
||||||
Firmware (BL31) that are targeted at EL3, other than SMCs. The |EHF| takes care
|
Firmware (BL31) that are targeted at EL3, other than SMCs. The |EHF| takes care
|
||||||
|
|
@ -54,11 +45,11 @@ exceptions are targeted at and handled in EL3. For instance:
|
||||||
|
|
||||||
- The Arm `SDEI specification`_ defines interfaces through which Normal world
|
- The Arm `SDEI specification`_ defines interfaces through which Normal world
|
||||||
interacts with the Runtime Firmware in order to request notification of
|
interacts with the Runtime Firmware in order to request notification of
|
||||||
system events. The SDEI specification requires that these events are notified
|
system events. The |SDEI| specification requires that these events are
|
||||||
even when the Normal world executes with the exceptions masked. This too
|
notified even when the Normal world executes with the exceptions masked. This
|
||||||
implies that firmware-first handling is required, where the events are first
|
too implies that firmware-first handling is required, where the events are
|
||||||
received by the EL3 firmware, and then dispatched to Normal world through
|
first received by the EL3 firmware, and then dispatched to Normal world
|
||||||
purely software mechanism.
|
through purely software mechanism.
|
||||||
|
|
||||||
For |TF-A|, firmware-first handling means that asynchronous exceptions are
|
For |TF-A|, firmware-first handling means that asynchronous exceptions are
|
||||||
suitably routed to EL3, and the Runtime Firmware (BL31) is extended to include
|
suitably routed to EL3, and the Runtime Firmware (BL31) is extended to include
|
||||||
|
|
@ -79,8 +70,8 @@ choose to:
|
||||||
processing of the error to dedicated software stack running at lower secure
|
processing of the error to dedicated software stack running at lower secure
|
||||||
ELs (as above); additionally, the Normal world may also be required to
|
ELs (as above); additionally, the Normal world may also be required to
|
||||||
participate in the handling, or be notified of such events (for example, as
|
participate in the handling, or be notified of such events (for example, as
|
||||||
an SDEI event). In this scheme, exception handling potentially and maximally
|
an |SDEI| event). In this scheme, exception handling potentially and
|
||||||
spans all ELs in both Secure and Normal worlds.
|
maximally spans all ELs in both Secure and Normal worlds.
|
||||||
|
|
||||||
On any given system, all of the above handling models may be employed
|
On any given system, all of the above handling models may be employed
|
||||||
independently depending on platform choice and the nature of the exception
|
independently depending on platform choice and the nature of the exception
|
||||||
|
|
@ -116,7 +107,7 @@ for more than one priority level.
|
||||||
|
|
||||||
.. _ehf-figure:
|
.. _ehf-figure:
|
||||||
|
|
||||||
.. image:: ../draw.io/ehf.svg
|
.. image:: ../resources/diagrams/draw.io/ehf.svg
|
||||||
|
|
||||||
A priority level is *active* when a handler at that priority level is currently
|
A priority level is *active* when a handler at that priority level is currently
|
||||||
executing in EL3, or has delegated the execution to a lower EL. For interrupts,
|
executing in EL3, or has delegated the execution to a lower EL. For interrupts,
|
||||||
|
|
@ -202,7 +193,7 @@ priority assignment:
|
||||||
6 and 5), the platform can partition into 4 secure priority ranges: ``0x0``,
|
6 and 5), the platform can partition into 4 secure priority ranges: ``0x0``,
|
||||||
``0x20``, ``0x40``, and ``0x60``. See `Interrupt handling example`_.
|
``0x20``, ``0x40``, and ``0x60``. See `Interrupt handling example`_.
|
||||||
|
|
||||||
Note:
|
.. note::
|
||||||
|
|
||||||
The Arm GIC architecture requires that a GIC implementation that supports two
|
The Arm GIC architecture requires that a GIC implementation that supports two
|
||||||
security states must implement at least 32 priority levels; i.e., at least 5
|
security states must implement at least 32 priority levels; i.e., at least 5
|
||||||
|
|
@ -224,7 +215,7 @@ priority level descriptors. Each entry in the array is of type
|
||||||
``ehf_pri_desc_t``, and declares a priority level, and shall be populated by the
|
``ehf_pri_desc_t``, and declares a priority level, and shall be populated by the
|
||||||
``EHF_PRI_DESC()`` macro.
|
``EHF_PRI_DESC()`` macro.
|
||||||
|
|
||||||
Note:
|
.. warning::
|
||||||
|
|
||||||
The macro ``EHF_PRI_DESC()`` installs the descriptors in the array at a
|
The macro ``EHF_PRI_DESC()`` installs the descriptors in the array at a
|
||||||
computed index, and not necessarily where the macro is placed in the array.
|
computed index, and not necessarily where the macro is placed in the array.
|
||||||
|
|
@ -609,8 +600,8 @@ should carefully consider the assignment of priorities to dispatchers integrated
|
||||||
into runtime firmware. The platform should sensibly delineate priority to
|
into runtime firmware. The platform should sensibly delineate priority to
|
||||||
various dispatchers according to their nature. In particular, dispatchers of
|
various dispatchers according to their nature. In particular, dispatchers of
|
||||||
critical nature (RAS, for example) should be assigned higher priority than
|
critical nature (RAS, for example) should be assigned higher priority than
|
||||||
others (SDEI, for example); and within SDEI, Critical priority SDEI should be
|
others (|SDEI|, for example); and within |SDEI|, Critical priority
|
||||||
assigned higher priority than Normal ones.
|
|SDEI| should be assigned higher priority than Normal ones.
|
||||||
|
|
||||||
Limitations
|
Limitations
|
||||||
-----------
|
-----------
|
||||||
|
|
|
||||||
|
|
@ -1,12 +1,5 @@
|
||||||
Trusted Firmware-A - Firmware Update design guide
|
Firmware Update (FWU)
|
||||||
=================================================
|
=====================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
--------------
|
|
||||||
|
|
||||||
Introduction
|
Introduction
|
||||||
------------
|
------------
|
||||||
|
|
@ -407,5 +400,5 @@ This is only allowed if the image is not being executed.
|
||||||
.. _Authentication Framework Design: ./auth-framework.rst
|
.. _Authentication Framework 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:: diagrams/fwu_flow.png?raw=true
|
.. |Flow Diagram| image:: ../resources/diagrams/fwu_flow.png
|
||||||
.. |FWU state machine| image:: diagrams/fwu_states.png?raw=true
|
.. |FWU state machine| image:: ../resources/diagrams/fwu_states.png
|
||||||
|
|
|
||||||
|
|
@ -1,9 +1,5 @@
|
||||||
Platform Interrupt Controller API documentation
|
Platform Interrupt Controller API
|
||||||
===============================================
|
=================================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
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
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,5 @@
|
||||||
RAS support in Trusted Firmware-A
|
Reliability, Availability, and Serviceability (RAS) Extensions
|
||||||
=================================
|
==============================================================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
:depth: 2
|
|
||||||
|
|
||||||
.. |EHF| replace:: Exception Handling Framework
|
.. |EHF| replace:: Exception Handling Framework
|
||||||
.. |TF-A| replace:: Trusted Firmware-A
|
.. |TF-A| replace:: Trusted Firmware-A
|
||||||
|
|
@ -44,7 +39,7 @@ be set ``1``.
|
||||||
|
|
||||||
.. _ras-figure:
|
.. _ras-figure:
|
||||||
|
|
||||||
.. image:: ../draw.io/ras.svg
|
.. image:: ../resources/diagrams/draw.io/ras.svg
|
||||||
|
|
||||||
See more on `Engaging the RAS framework`_.
|
See more on `Engaging the RAS framework`_.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,11 +1,6 @@
|
||||||
Library at ROM
|
Library at ROM
|
||||||
==============
|
==============
|
||||||
|
|
||||||
.. section-numbering::
|
|
||||||
:suffix: .
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
This document provides an overview of the "library at ROM" implementation in
|
This document provides an overview of the "library at ROM" implementation in
|
||||||
Trusted Firmware-A (TF-A).
|
Trusted Firmware-A (TF-A).
|
||||||
|
|
||||||
|
|
@ -28,7 +23,7 @@ are placed in ROM. The capabilities of the "library at ROM" are:
|
||||||
Index file
|
Index file
|
||||||
~~~~~~~~~~
|
~~~~~~~~~~
|
||||||
|
|
||||||
.. image:: diagrams/romlib_design.png
|
.. image:: ../resources/diagrams/romlib_design.png
|
||||||
:width: 600
|
:width: 600
|
||||||
|
|
||||||
Library at ROM is described by an index file with the list of functions to be
|
Library at ROM is described by an index file with the list of functions to be
|
||||||
|
|
@ -59,7 +54,7 @@ For an index file example, refer to ``lib/romlib/jmptbl.i``.
|
||||||
Wrapper functions
|
Wrapper functions
|
||||||
~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. image:: diagrams/romlib_wrapper.png
|
.. image:: ../resources/diagrams/romlib_wrapper.png
|
||||||
:width: 600
|
:width: 600
|
||||||
|
|
||||||
When invoking a function of the "library at ROM", the calling sequence is as
|
When invoking a function of the "library at ROM", the calling sequence is as
|
||||||
|
|
@ -111,7 +106,7 @@ The environment variable ``CROSS_COMPILE`` must be set as per the user guide.
|
||||||
In the below example the usage of ROMLIB together with mbed TLS is demonstrated
|
In the below example the usage of ROMLIB together with mbed TLS is demonstrated
|
||||||
to showcase the benefits of library at ROM - it's not mandatory.
|
to showcase the benefits of library at ROM - it's not mandatory.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=fvp \
|
make PLAT=fvp \
|
||||||
MBEDTLS_DIR=</path/to/mbedtls/> \
|
MBEDTLS_DIR=</path/to/mbedtls/> \
|
||||||
|
|
|
||||||
|
|
@ -1,9 +1,6 @@
|
||||||
SDEI: Software Delegated Exception Interface
|
SDEI: Software Delegated Exception Interface
|
||||||
============================================
|
============================================
|
||||||
|
|
||||||
.. contents::
|
|
||||||
:depth: 2
|
|
||||||
|
|
||||||
This document provides an overview of the SDEI dispatcher implementation in
|
This document provides an overview of the SDEI dispatcher implementation in
|
||||||
Trusted Firmware-A (TF-A).
|
Trusted Firmware-A (TF-A).
|
||||||
|
|
||||||
|
|
@ -29,7 +26,7 @@ The following figure depicts a general sequence involving SDEI client executing
|
||||||
at EL2 and an event dispatch resulting from the triggering of a bound interrupt.
|
at EL2 and an event dispatch resulting from the triggering of a bound interrupt.
|
||||||
A commentary is provided below:
|
A commentary is provided below:
|
||||||
|
|
||||||
.. image:: ../plantuml/sdei_general.svg
|
.. image:: ../resources/diagrams/plantuml/sdei_general.svg
|
||||||
|
|
||||||
As part of initialisation, the SDEI client binds a Non-secure interrupt [1], and
|
As part of initialisation, the SDEI client binds a Non-secure interrupt [1], and
|
||||||
the SDEI dispatcher returns a platform dynamic event number [2]. The client then
|
the SDEI dispatcher returns a platform dynamic event number [2]. The client then
|
||||||
|
|
@ -227,7 +224,7 @@ activity, such as receiving a Secure interrupt or an exception.
|
||||||
The SDEI dispatcher implementation provides ``sdei_dispatch_event()`` API for
|
The SDEI dispatcher implementation provides ``sdei_dispatch_event()`` API for
|
||||||
this purpose. The API has the following signature:
|
this purpose. The API has the following signature:
|
||||||
|
|
||||||
::
|
.. code:: c
|
||||||
|
|
||||||
int sdei_dispatch_event(int ev_num);
|
int sdei_dispatch_event(int ev_num);
|
||||||
|
|
||||||
|
|
@ -237,7 +234,7 @@ on success, or ``-1`` on failure.
|
||||||
The following figure depicts a scenario involving explicit dispatch of SDEI
|
The following figure depicts a scenario involving explicit dispatch of SDEI
|
||||||
event. A commentary is provided below:
|
event. A commentary is provided below:
|
||||||
|
|
||||||
.. image:: ../plantuml/sdei_explicit_dispatch.svg
|
.. image:: ../resources/diagrams/plantuml/sdei_explicit_dispatch.svg
|
||||||
|
|
||||||
As part of initialisation, the SDEI client registers a handler for a platform
|
As part of initialisation, the SDEI client registers a handler for a platform
|
||||||
event [1], enables the event [3], and unmasks the current PE [5]. Note that,
|
event [1], enables the event [3], and unmasks the current PE [5]. Note that,
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,5 @@
|
||||||
*******************************
|
Secure Partition Manager
|
||||||
Secure Partition Manager Design
|
************************
|
||||||
*******************************
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
Background
|
Background
|
||||||
==========
|
==========
|
||||||
|
|
@ -135,7 +130,7 @@ First, build the Standalone MM Secure Partition. To build it, refer to the
|
||||||
Then build TF-A with SPM support and include the Standalone MM Secure Partition
|
Then build TF-A with SPM support and include the Standalone MM Secure Partition
|
||||||
image in the FIP:
|
image in the FIP:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
BL32=path/to/standalone/mm/sp BL33=path/to/bl33.bin \
|
BL32=path/to/standalone/mm/sp BL33=path/to/bl33.bin \
|
||||||
make PLAT=fvp ENABLE_SPM=1 ARM_BL31_IN_DRAM=1 fip all
|
make PLAT=fvp ENABLE_SPM=1 ARM_BL31_IN_DRAM=1 fip all
|
||||||
|
|
@ -819,5 +814,5 @@ Error Codes
|
||||||
.. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
|
.. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
|
||||||
.. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
|
.. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
|
||||||
|
|
||||||
.. |Image 1| image:: ../diagrams/secure_sw_stack_tos.png
|
.. |Image 1| image:: ../resources/diagrams/secure_sw_stack_tos.png
|
||||||
.. |Image 2| image:: ../diagrams/secure_sw_stack_sp.png
|
.. |Image 2| image:: ../resources/diagrams/secure_sw_stack_sp.png
|
||||||
|
|
|
||||||
|
|
@ -4,7 +4,6 @@ Secure Payload Dispatcher (SPD)
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
:caption: Contents
|
:caption: Contents
|
||||||
:numbered:
|
|
||||||
|
|
||||||
optee-dispatcher
|
optee-dispatcher
|
||||||
tlk-dispatcher
|
tlk-dispatcher
|
||||||
|
|
|
||||||
|
|
@ -15,7 +15,7 @@ Once a BL32 is ready, TLKD can be included in the image by adding "SPD=tlkd"
|
||||||
to the build command.
|
to the build command.
|
||||||
|
|
||||||
Trusted Little Kernel (TLK)
|
Trusted Little Kernel (TLK)
|
||||||
===========================
|
---------------------------
|
||||||
|
|
||||||
TLK is a Trusted OS running as Secure EL1. It is a Free Open Source Software
|
TLK is a Trusted OS running as Secure EL1. It is a Free Open Source Software
|
||||||
(FOSS) release of the NVIDIA® Trusted Little Kernel (TLK) technology, which
|
(FOSS) release of the NVIDIA® Trusted Little Kernel (TLK) technology, which
|
||||||
|
|
@ -54,20 +54,20 @@ TLK and OTE can be found in the Tegra\_BSP\_for\_Android\_TLK\_FOSS\_Reference.p
|
||||||
manual located under the "documentation" directory\_.
|
manual located under the "documentation" directory\_.
|
||||||
|
|
||||||
Build TLK
|
Build TLK
|
||||||
=========
|
---------
|
||||||
|
|
||||||
To build and execute TLK, follow the instructions from "Building a TLK Device"
|
To build and execute TLK, follow the instructions from "Building a TLK Device"
|
||||||
section from Tegra\_BSP\_for\_Android\_TLK\_FOSS\_Reference.pdf manual.
|
section from Tegra\_BSP\_for\_Android\_TLK\_FOSS\_Reference.pdf manual.
|
||||||
|
|
||||||
Input parameters to TLK
|
Input parameters to TLK
|
||||||
=======================
|
-----------------------
|
||||||
|
|
||||||
TLK expects the TZDRAM size and a structure containing the boot arguments. BL2
|
TLK expects the TZDRAM size and a structure containing the boot arguments. BL2
|
||||||
passes this information to the EL3 software as members of the bl32\_ep\_info
|
passes this information to the EL3 software as members of the bl32\_ep\_info
|
||||||
struct, where bl32\_ep\_info is part of bl31\_params\_t (passed by BL2 in X0)
|
struct, where bl32\_ep\_info is part of bl31\_params\_t (passed by BL2 in X0)
|
||||||
|
|
||||||
Example:
|
Example
|
||||||
--------
|
~~~~~~~
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -9,7 +9,7 @@ Open Source Project (AOSP) webpage for Trusty hosted at
|
||||||
https://source.android.com/security/trusty
|
https://source.android.com/security/trusty
|
||||||
|
|
||||||
Boot parameters
|
Boot parameters
|
||||||
===============
|
---------------
|
||||||
|
|
||||||
Custom boot parameters can be passed to Trusty by providing a platform
|
Custom boot parameters can be passed to Trusty by providing a platform
|
||||||
specific function:
|
specific function:
|
||||||
|
|
@ -26,7 +26,7 @@ can be set to a platform specific parameter block, and ``args->arg2``
|
||||||
should then be set to the size of that block.
|
should then be set to the size of that block.
|
||||||
|
|
||||||
Supported platforms
|
Supported platforms
|
||||||
===================
|
-------------------
|
||||||
|
|
||||||
Out of all the platforms supported by Trusted Firmware-A, Trusty is only
|
Out of all the platforms supported by Trusted Firmware-A, Trusty is only
|
||||||
verified and supported by NVIDIA's Tegra SoCs.
|
verified and supported by NVIDIA's Tegra SoCs.
|
||||||
|
|
|
||||||
|
|
@ -1,12 +1,6 @@
|
||||||
Translation Tables Library Design
|
Translation (XLAT) Tables Library
|
||||||
=================================
|
=================================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
|
|
||||||
This document describes the design of the translation tables library (version 2)
|
This document describes the design of the translation tables library (version 2)
|
||||||
used by Trusted Firmware-A (TF-A). This library provides APIs to create page
|
used by Trusted Firmware-A (TF-A). This library provides APIs to create page
|
||||||
tables based on a description of the memory layout, as well as setting up system
|
tables based on a description of the memory layout, as well as setting up system
|
||||||
|
|
@ -424,4 +418,4 @@ mapping cannot be cached in the TLBs.
|
||||||
.. _aarch32/xlat_tables_arch.c: ../../lib/xlat_tables_v2/aarch32/xlat_tables_arch.c
|
.. _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
|
.. _aarch64/xlat_tables_arch.c: ../../lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
|
||||||
.. _Porting Guide: ../getting_started/porting-guide.rst
|
.. _Porting Guide: ../getting_started/porting-guide.rst
|
||||||
.. |Alignment Example| image:: ../diagrams/xlat_align.png?raw=true
|
.. |Alignment Example| image:: ../resources/diagrams/xlat_align.png
|
||||||
|
|
|
||||||
|
|
@ -9,6 +9,8 @@
|
||||||
#
|
#
|
||||||
# See the options documentation at http://www.sphinx-doc.org/en/master/config
|
# See the options documentation at http://www.sphinx-doc.org/en/master/config
|
||||||
|
|
||||||
|
import os
|
||||||
|
|
||||||
# -- Project information -----------------------------------------------------
|
# -- Project information -----------------------------------------------------
|
||||||
|
|
||||||
project = 'Trusted Firmware-A'
|
project = 'Trusted Firmware-A'
|
||||||
|
|
@ -16,7 +18,6 @@ project = 'Trusted Firmware-A'
|
||||||
version = '2.1'
|
version = '2.1'
|
||||||
release = version # We don't need these to be distinct
|
release = version # We don't need these to be distinct
|
||||||
|
|
||||||
|
|
||||||
# -- General configuration ---------------------------------------------------
|
# -- General configuration ---------------------------------------------------
|
||||||
|
|
||||||
# Add any Sphinx extension module names here, as strings. They can be
|
# Add any Sphinx extension module names here, as strings. They can be
|
||||||
|
|
@ -48,6 +49,10 @@ exclude_patterns = []
|
||||||
# The name of the Pygments (syntax highlighting) style to use.
|
# The name of the Pygments (syntax highlighting) style to use.
|
||||||
pygments_style = 'sphinx'
|
pygments_style = 'sphinx'
|
||||||
|
|
||||||
|
# Load the contents of the global substitutions file into the 'rst_prolog'
|
||||||
|
# variable. This ensures that the substitutions are all inserted into each page.
|
||||||
|
with open('global_substitutions.txt', 'r') as subs:
|
||||||
|
rst_prolog = subs.read()
|
||||||
|
|
||||||
# -- Options for HTML output -------------------------------------------------
|
# -- Options for HTML output -------------------------------------------------
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,5 @@
|
||||||
Abstracting a Chain of Trust
|
Authentication Framework & Chain of Trust
|
||||||
============================
|
=========================================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
The aim of this document is to describe the authentication framework
|
The aim of this document is to describe the authentication framework
|
||||||
implemented in Trusted Firmware-A (TF-A). This framework fulfills the
|
implemented in Trusted Firmware-A (TF-A). This framework fulfills the
|
||||||
|
|
@ -413,7 +408,7 @@ An IPL must provide functions with the following prototypes:
|
||||||
|
|
||||||
An IPL for each type must be registered using the following macro:
|
An IPL for each type must be registered using the following macro:
|
||||||
|
|
||||||
::
|
.. code:: c
|
||||||
|
|
||||||
REGISTER_IMG_PARSER_LIB(_type, _name, _init, _check_int, _get_param)
|
REGISTER_IMG_PARSER_LIB(_type, _name, _init, _check_int, _get_param)
|
||||||
|
|
||||||
|
|
@ -958,9 +953,11 @@ sources in the build for the various algorithms. Setting the variable to
|
||||||
`rsa+ecdsa` enables support for both rsa and ecdsa algorithms in the mbedTLS
|
`rsa+ecdsa` enables support for both rsa and ecdsa algorithms in the mbedTLS
|
||||||
library.
|
library.
|
||||||
|
|
||||||
Note: If code size is a concern, the build option ``MBEDTLS_SHA256_SMALLER`` can
|
.. note::
|
||||||
be defined in the platform Makefile. It will make mbed TLS use an implementation
|
If code size is a concern, the build option ``MBEDTLS_SHA256_SMALLER`` can
|
||||||
of SHA-256 with smaller memory footprint (~1.5 KB less) but slower (~30%).
|
be defined in the platform Makefile. It will make mbed TLS use an
|
||||||
|
implementation of SHA-256 with smaller memory footprint (~1.5 KB less) but
|
||||||
|
slower (~30%).
|
||||||
|
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,11 +1,6 @@
|
||||||
Arm CPU Specific Build Macros
|
Arm CPU Specific Build Macros
|
||||||
=============================
|
=============================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
This document describes the various build options present in the CPU specific
|
This document describes the various build options present in the CPU specific
|
||||||
operations framework to enable errata workarounds and to enable optimizations
|
operations framework to enable errata workarounds and to enable optimizations
|
||||||
for a specific CPU on a platform.
|
for a specific CPU on a platform.
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,5 @@
|
||||||
Trusted Firmware-A design
|
Firmware Design
|
||||||
=========================
|
===============
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
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) [1]_ for Arm reference
|
||||||
|
|
@ -1146,8 +1141,10 @@ returning through EL3 and running the non-trusted firmware (BL33):
|
||||||
``bl31_register_bl32_init()`` which provides a SPD-defined mechanism to
|
``bl31_register_bl32_init()`` which provides a SPD-defined mechanism to
|
||||||
invoke a 'world-switch synchronous call' to Secure-EL1 to run the BL32
|
invoke a 'world-switch synchronous call' to Secure-EL1 to run the BL32
|
||||||
entrypoint.
|
entrypoint.
|
||||||
NOTE: The Test SPD service included with TF-A provides one implementation
|
|
||||||
of such a mechanism.
|
.. note::
|
||||||
|
The Test SPD service included with TF-A provides one implementation
|
||||||
|
of such a mechanism.
|
||||||
|
|
||||||
On completion BL32 returns control to BL31 via a SMC, and on receipt the
|
On completion BL32 returns control to BL31 via a SMC, and on receipt the
|
||||||
SPD service handler invokes the synchronous call return mechanism to return
|
SPD service handler invokes the synchronous call return mechanism to return
|
||||||
|
|
@ -1680,8 +1677,9 @@ The location of the BL32 image will result in different memory maps. This is
|
||||||
illustrated for both FVP and Juno in the following diagrams, using the TSP as
|
illustrated for both FVP and Juno in the following diagrams, using the TSP as
|
||||||
an example.
|
an example.
|
||||||
|
|
||||||
Note: Loading the BL32 image in TZC secured DRAM doesn't change the memory
|
.. note::
|
||||||
layout of the other images in Trusted SRAM.
|
Loading the BL32 image in TZC secured DRAM doesn't change the memory
|
||||||
|
layout of the other images in Trusted SRAM.
|
||||||
|
|
||||||
CONFIG section in memory layouts shown below contains:
|
CONFIG section in memory layouts shown below contains:
|
||||||
|
|
||||||
|
|
@ -2220,8 +2218,9 @@ The default memory layout for each BL image is as follows:
|
||||||
| Code |
|
| Code |
|
||||||
+-------------------+ BLx_BASE
|
+-------------------+ BLx_BASE
|
||||||
|
|
||||||
Note: The 2KB alignment for the exception vectors is an architectural
|
.. note::
|
||||||
requirement.
|
The 2KB alignment for the exception vectors is an architectural
|
||||||
|
requirement.
|
||||||
|
|
||||||
The read-write data start on a new memory page so that they can be mapped with
|
The read-write data start on a new memory page so that they can be mapped with
|
||||||
read-write permissions, whereas the code and read-only data below are configured
|
read-write permissions, whereas the code and read-only data below are configured
|
||||||
|
|
@ -2309,7 +2308,7 @@ result in build error. Subscribing to an undefined event however won't.
|
||||||
Subscribed handlers must be of type ``pubsub_cb_t``, with following function
|
Subscribed handlers must be of type ``pubsub_cb_t``, with following function
|
||||||
signature:
|
signature:
|
||||||
|
|
||||||
::
|
.. code:: c
|
||||||
|
|
||||||
typedef void* (*pubsub_cb_t)(const void *arg);
|
typedef void* (*pubsub_cb_t)(const void *arg);
|
||||||
|
|
||||||
|
|
@ -2336,7 +2335,7 @@ A publisher that wants to publish event ``foo`` would:
|
||||||
|
|
||||||
- Define the event ``foo`` in the ``pubsub_events.h``.
|
- Define the event ``foo`` in the ``pubsub_events.h``.
|
||||||
|
|
||||||
::
|
.. code:: c
|
||||||
|
|
||||||
REGISTER_PUBSUB_EVENT(foo);
|
REGISTER_PUBSUB_EVENT(foo);
|
||||||
|
|
||||||
|
|
@ -2472,7 +2471,7 @@ respectively.
|
||||||
From outside TF-A, timestamps for individual CPUs can be retrieved by calling
|
From outside TF-A, timestamps for individual CPUs can be retrieved by calling
|
||||||
into ``pmf_smc_handler()``.
|
into ``pmf_smc_handler()``.
|
||||||
|
|
||||||
.. code:: c
|
::
|
||||||
|
|
||||||
Interface : pmf_smc_handler()
|
Interface : pmf_smc_handler()
|
||||||
Argument : unsigned int smc_fid, u_register_t x1,
|
Argument : unsigned int smc_fid, u_register_t x1,
|
||||||
|
|
@ -2602,7 +2601,7 @@ Platform may choose to not define straight the toolchain target architecture
|
||||||
directive by defining ``MARCH32_DIRECTIVE``.
|
directive by defining ``MARCH32_DIRECTIVE``.
|
||||||
I.e:
|
I.e:
|
||||||
|
|
||||||
::
|
.. code:: make
|
||||||
|
|
||||||
MARCH32_DIRECTIVE := -mach=armv7-a
|
MARCH32_DIRECTIVE := -mach=armv7-a
|
||||||
|
|
||||||
|
|
@ -2684,4 +2683,4 @@ References
|
||||||
.. _ROMLIB Design: romlib-design.rst
|
.. _ROMLIB Design: romlib-design.rst
|
||||||
.. _Trusted Board Boot Requirements CLIENT (TBBR-CLIENT) Armv8-A (ARM DEN0006D): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a
|
.. _Trusted Board Boot Requirements CLIENT (TBBR-CLIENT) Armv8-A (ARM DEN0006D): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a
|
||||||
|
|
||||||
.. |Image 1| image:: diagrams/rt-svc-descs-layout.png?raw=true
|
.. |Image 1| image:: ../resources/diagrams/rt-svc-descs-layout.png
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,5 @@
|
||||||
Trusted Firmware-A interrupt management design guide
|
Interrupt Management Framework
|
||||||
====================================================
|
==============================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
This framework is responsible for managing interrupts routed to EL3. It also
|
This framework is responsible for managing interrupts routed to EL3. It also
|
||||||
allows EL3 software to configure the interrupt routing behavior. Its main
|
allows EL3 software to configure the interrupt routing behavior. Its main
|
||||||
|
|
@ -53,7 +48,7 @@ the exception level(s) it is handled in.
|
||||||
The following constants define the various interrupt types in the framework
|
The following constants define the various interrupt types in the framework
|
||||||
implementation.
|
implementation.
|
||||||
|
|
||||||
::
|
.. code:: c
|
||||||
|
|
||||||
#define INTR_TYPE_S_EL1 0
|
#define INTR_TYPE_S_EL1 0
|
||||||
#define INTR_TYPE_EL3 1
|
#define INTR_TYPE_EL3 1
|
||||||
|
|
@ -421,8 +416,9 @@ runtime.
|
||||||
Test secure payload dispatcher behavior
|
Test secure payload dispatcher behavior
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
**Note:** where this document discusses ``TSP_NS_INTR_ASYNC_PREEMPT`` as being
|
.. note::
|
||||||
``1``, the same results also apply when ``EL3_EXCEPTION_HANDLING`` is ``1``.
|
Where this document discusses ``TSP_NS_INTR_ASYNC_PREEMPT`` as being
|
||||||
|
``1``, the same results also apply when ``EL3_EXCEPTION_HANDLING`` is ``1``.
|
||||||
|
|
||||||
The TSPD only handles Secure-EL1 interrupts and is provided with the following
|
The TSPD only handles Secure-EL1 interrupts and is provided with the following
|
||||||
routing model at build time.
|
routing model at build time.
|
||||||
|
|
@ -1020,5 +1016,5 @@ TSP by returning ``SMC_UNK`` error.
|
||||||
.. _Porting Guide: ../getting_started/porting-guide.rst
|
.. _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:: diagrams/sec-int-handling.png?raw=true
|
.. |Image 1| image:: ../resources/diagrams/sec-int-handling.png
|
||||||
.. |Image 2| image:: diagrams/non-sec-int-handling.png?raw=true
|
.. |Image 2| image:: ../resources/diagrams/non-sec-int-handling.png
|
||||||
|
|
|
||||||
|
|
@ -1,12 +1,5 @@
|
||||||
PSCI Power Domain Tree design
|
PSCI Power Domain Tree Structure
|
||||||
=============================
|
================================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
--------------
|
|
||||||
|
|
||||||
Requirements
|
Requirements
|
||||||
------------
|
------------
|
||||||
|
|
@ -116,7 +109,7 @@ separately.
|
||||||
|
|
||||||
This tree is defined by the platform as the array described above as follows:
|
This tree is defined by the platform as the array described above as follows:
|
||||||
|
|
||||||
::
|
.. code:: c
|
||||||
|
|
||||||
#define PLAT_NUM_POWER_DOMAINS 20
|
#define PLAT_NUM_POWER_DOMAINS 20
|
||||||
#define PLATFORM_CORE_COUNT 13
|
#define PLATFORM_CORE_COUNT 13
|
||||||
|
|
@ -226,7 +219,7 @@ to represent leaf and non-leaf power domain nodes in the tree.
|
||||||
The power domain tree is implemented as a combination of the following data
|
The power domain tree is implemented as a combination of the following data
|
||||||
structures.
|
structures.
|
||||||
|
|
||||||
::
|
.. code:: c
|
||||||
|
|
||||||
non_cpu_pd_node_t psci_non_cpu_pd_nodes[PSCI_NUM_NON_CPU_PWR_DOMAINS];
|
non_cpu_pd_node_t psci_non_cpu_pd_nodes[PSCI_NUM_NON_CPU_PWR_DOMAINS];
|
||||||
cpu_pd_node_t psci_cpu_pd_nodes[PLATFORM_CORE_COUNT];
|
cpu_pd_node_t psci_cpu_pd_nodes[PLATFORM_CORE_COUNT];
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,5 @@
|
||||||
Trusted Firmware-A reset design
|
CPU Reset
|
||||||
===============================
|
=========
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
This document describes the high-level design of the framework to handle CPU
|
This document describes the high-level design of the framework to handle CPU
|
||||||
resets in Trusted Firmware-A (TF-A). It also describes how the platform
|
resets in Trusted Firmware-A (TF-A). It also describes how the platform
|
||||||
|
|
@ -28,10 +23,11 @@ configuration, some of these steps might be unnecessary. The following sections
|
||||||
guide the platform integrator by indicating which build options exclude which
|
guide the platform integrator by indicating which build options exclude which
|
||||||
steps, depending on the capability of the platform.
|
steps, depending on the capability of the platform.
|
||||||
|
|
||||||
Note: If BL31 is used as the TF-A entry point instead of BL1, the diagram
|
.. note::
|
||||||
above is still relevant, as all these operations will occur in BL31 in
|
If BL31 is used as the TF-A entry point instead of BL1, the diagram
|
||||||
this case. Please refer to section 6 "Using BL31 entrypoint as the reset
|
above is still relevant, as all these operations will occur in BL31 in
|
||||||
address" for more information.
|
this case. Please refer to section 6 "Using BL31 entrypoint as the reset
|
||||||
|
address" for more information.
|
||||||
|
|
||||||
Programmable CPU reset address
|
Programmable CPU reset address
|
||||||
------------------------------
|
------------------------------
|
||||||
|
|
@ -159,7 +155,7 @@ This might be done by the Trusted Boot Firmware or by platform code in BL31.
|
||||||
.. _Firmware Design: firmware-design.rst
|
.. _Firmware Design: firmware-design.rst
|
||||||
.. _User Guide: ../getting_started/user-guide.rst
|
.. _User Guide: ../getting_started/user-guide.rst
|
||||||
|
|
||||||
.. |Default reset code flow| image:: ../diagrams/default_reset_code.png?raw=true
|
.. |Default reset code flow| image:: ../resources/diagrams/default_reset_code.png
|
||||||
.. |Reset code flow with programmable reset address| image:: ../diagrams/reset_code_no_boot_type_check.png?raw=true
|
.. |Reset code flow with programmable reset address| image:: ../resources/diagrams/reset_code_no_boot_type_check.png
|
||||||
.. |Reset code flow with single CPU released out of reset| image:: ../diagrams/reset_code_no_cpu_check.png?raw=true
|
.. |Reset code flow with single CPU released out of reset| image:: ../resources/diagrams/reset_code_no_cpu_check.png
|
||||||
.. |Reset code flow with programmable reset address and single CPU released out of reset| image:: ../diagrams/reset_code_no_checks.png?raw=true
|
.. |Reset code flow with programmable reset address and single CPU released out of reset| image:: ../resources/diagrams/reset_code_no_checks.png
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,5 @@
|
||||||
Trusted Board Boot Design Guide
|
Trusted Board Boot
|
||||||
===============================
|
==================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
The Trusted Board Boot (TBB) feature prevents malicious firmware from running on
|
The Trusted Board Boot (TBB) feature prevents malicious firmware from running on
|
||||||
the platform by authenticating all firmware images up to and including the
|
the platform by authenticating all firmware images up to and including the
|
||||||
|
|
@ -146,8 +141,9 @@ if any of the steps fail.
|
||||||
compared with the hash of the ROTPK read from the trusted root-key storage
|
compared with the hash of the ROTPK read from the trusted root-key storage
|
||||||
registers. If they match, the BL2 hash is read from the certificate.
|
registers. If they match, the BL2 hash is read from the certificate.
|
||||||
|
|
||||||
Note: the matching operation is platform specific and is currently
|
.. note::
|
||||||
unimplemented on the Arm development platforms.
|
The matching operation is platform specific and is currently
|
||||||
|
unimplemented on the Arm development platforms.
|
||||||
|
|
||||||
- BL1 loads the BL2 image. Its hash is calculated and compared with the hash
|
- BL1 loads the BL2 image. Its hash is calculated and compared with the hash
|
||||||
read from the certificate. Control is transferred to the BL2 image if all
|
read from the certificate. Control is transferred to the BL2 image if all
|
||||||
|
|
|
||||||
|
|
@ -1,11 +1,6 @@
|
||||||
Image Terminology
|
Image Terminology
|
||||||
=================
|
=================
|
||||||
|
|
||||||
.. section-numbering::
|
|
||||||
:suffix: .
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
This page contains the current name, abbreviated name and purpose of the various
|
This page contains the current name, abbreviated name and purpose of the various
|
||||||
images referred to in the Trusted Firmware project.
|
images referred to in the Trusted Firmware project.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,9 +1,5 @@
|
||||||
Trusted Firmware-A Porting Guide
|
Porting Guide
|
||||||
================================
|
=============
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
Introduction
|
Introduction
|
||||||
------------
|
------------
|
||||||
|
|
@ -335,7 +331,9 @@ must also be defined:
|
||||||
|
|
||||||
SCP_BL2U image identifier, used by BL1 to fetch an image descriptor
|
SCP_BL2U image identifier, used by BL1 to fetch an image descriptor
|
||||||
corresponding to SCP_BL2U.
|
corresponding to SCP_BL2U.
|
||||||
NOTE: TF-A does not provide source code for this image.
|
|
||||||
|
.. note::
|
||||||
|
TF-A does not provide source code for this image.
|
||||||
|
|
||||||
If the Non-Secure Firmware Updater ROM, NS_BL1U is used, the following must
|
If the Non-Secure Firmware Updater ROM, NS_BL1U is used, the following must
|
||||||
also be defined:
|
also be defined:
|
||||||
|
|
@ -344,7 +342,9 @@ also be defined:
|
||||||
|
|
||||||
Defines the base address in non-secure ROM where NS_BL1U executes.
|
Defines the base address in non-secure ROM where NS_BL1U executes.
|
||||||
Must be aligned on a page-size boundary.
|
Must be aligned on a page-size boundary.
|
||||||
NOTE: TF-A does not provide source code for this image.
|
|
||||||
|
.. note::
|
||||||
|
TF-A does not provide source code for this image.
|
||||||
|
|
||||||
- **#define : NS_BL1U_IMAGE_ID**
|
- **#define : NS_BL1U_IMAGE_ID**
|
||||||
|
|
||||||
|
|
@ -358,7 +358,9 @@ be defined:
|
||||||
|
|
||||||
Defines the base address in non-secure memory where NS_BL2U executes.
|
Defines the base address in non-secure memory where NS_BL2U executes.
|
||||||
Must be aligned on a page-size boundary.
|
Must be aligned on a page-size boundary.
|
||||||
NOTE: TF-A does not provide source code for this image.
|
|
||||||
|
.. note::
|
||||||
|
TF-A does not provide source code for this image.
|
||||||
|
|
||||||
- **#define : NS_BL2U_IMAGE_ID**
|
- **#define : NS_BL2U_IMAGE_ID**
|
||||||
|
|
||||||
|
|
@ -1004,8 +1006,9 @@ situation from which it cannot recover. This function must not return,
|
||||||
and must be implemented in assembly because it may be called before the C
|
and must be implemented in assembly because it may be called before the C
|
||||||
environment is initialized.
|
environment is initialized.
|
||||||
|
|
||||||
Note: The address from where it was called is stored in x30 (Link Register).
|
.. note::
|
||||||
The default implementation simply spins.
|
The address from where it was called is stored in x30 (Link Register).
|
||||||
|
The default implementation simply spins.
|
||||||
|
|
||||||
Function : plat_get_bl_image_load_info()
|
Function : plat_get_bl_image_load_info()
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
@ -1046,9 +1049,10 @@ value will weaken the protection as the attacker could easily write the right
|
||||||
value as part of the attack most of the time. Therefore, it should return a
|
value as part of the attack most of the time. Therefore, it should return a
|
||||||
true random number.
|
true random number.
|
||||||
|
|
||||||
Note: For the protection to be effective, the global data need to be placed at
|
.. warning::
|
||||||
a lower address than the stack bases. Failure to do so would allow an attacker
|
For the protection to be effective, the global data need to be placed at
|
||||||
to overwrite the canary as part of the stack buffer overflow attack.
|
a lower address than the stack bases. Failure to do so would allow an
|
||||||
|
attacker to overwrite the canary as part of the stack buffer overflow attack.
|
||||||
|
|
||||||
Function : plat_flush_next_bl_params()
|
Function : plat_flush_next_bl_params()
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
@ -1844,7 +1848,7 @@ line boundary.
|
||||||
SDEI porting requirements
|
SDEI porting requirements
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
The SDEI dispatcher requires the platform to provide the following macros
|
The |SDEI| dispatcher requires the platform to provide the following macros
|
||||||
and functions, of which some are optional, and some others mandatory.
|
and functions, of which some are optional, and some others mandatory.
|
||||||
|
|
||||||
Macros
|
Macros
|
||||||
|
|
@ -1854,19 +1858,19 @@ Macro: PLAT_SDEI_NORMAL_PRI [mandatory]
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
This macro must be defined to the EL3 exception priority level associated with
|
This macro must be defined to the EL3 exception priority level associated with
|
||||||
Normal SDEI events on the platform. This must have a higher value (therefore of
|
Normal |SDEI| events on the platform. This must have a higher value
|
||||||
lower priority) than ``PLAT_SDEI_CRITICAL_PRI``.
|
(therefore of lower priority) than ``PLAT_SDEI_CRITICAL_PRI``.
|
||||||
|
|
||||||
Macro: PLAT_SDEI_CRITICAL_PRI [mandatory]
|
Macro: PLAT_SDEI_CRITICAL_PRI [mandatory]
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
This macro must be defined to the EL3 exception priority level associated with
|
This macro must be defined to the EL3 exception priority level associated with
|
||||||
Critical SDEI events on the platform. This must have a lower value (therefore of
|
Critical |SDEI| events on the platform. This must have a lower value
|
||||||
higher priority) than ``PLAT_SDEI_NORMAL_PRI``.
|
(therefore of higher priority) than ``PLAT_SDEI_NORMAL_PRI``.
|
||||||
|
|
||||||
**Note**: SDEI exception priorities must be the lowest among Secure priorities.
|
**Note**: |SDEI| exception priorities must be the lowest among Secure
|
||||||
Among the SDEI exceptions, Critical SDEI priority must be higher than Normal
|
priorities. Among the |SDEI| exceptions, Critical |SDEI| priority must
|
||||||
SDEI priority.
|
be higher than Normal |SDEI| priority.
|
||||||
|
|
||||||
Functions
|
Functions
|
||||||
.........
|
.........
|
||||||
|
|
@ -1880,10 +1884,10 @@ Function: int plat_sdei_validate_entry_point(uintptr_t ep) [optional]
|
||||||
Return: int
|
Return: int
|
||||||
|
|
||||||
This function validates the address of client entry points provided for both
|
This function validates the address of client entry points provided for both
|
||||||
event registration and *Complete and Resume* SDEI calls. The function takes one
|
event registration and *Complete and Resume* |SDEI| calls. The function
|
||||||
argument, which is the address of the handler the SDEI client requested to
|
takes one argument, which is the address of the handler the |SDEI| client
|
||||||
register. The function must return ``0`` for successful validation, or ``-1``
|
requested to register. The function must return ``0`` for successful validation,
|
||||||
upon failure.
|
or ``-1`` upon failure.
|
||||||
|
|
||||||
The default implementation always returns ``0``. On Arm platforms, this function
|
The default implementation always returns ``0``. On Arm platforms, this function
|
||||||
is implemented to translate the entry point to physical address, and further to
|
is implemented to translate the entry point to physical address, and further to
|
||||||
|
|
@ -1898,11 +1902,12 @@ Function: void plat_sdei_handle_masked_trigger(uint64_t mpidr, unsigned int intr
|
||||||
Argument: unsigned int
|
Argument: unsigned int
|
||||||
Return: void
|
Return: void
|
||||||
|
|
||||||
SDEI specification requires that a PE comes out of reset with the events masked.
|
|SDEI| specification requires that a PE comes out of reset with the events
|
||||||
The client therefore is expected to call ``PE_UNMASK`` to unmask SDEI events on
|
masked. The client therefore is expected to call ``PE_UNMASK`` to unmask
|
||||||
the PE. No SDEI events can be dispatched until such time.
|
|SDEI| events on the PE. No |SDEI| events can be dispatched until such
|
||||||
|
time.
|
||||||
|
|
||||||
Should a PE receive an interrupt that was bound to an SDEI event while the
|
Should a PE receive an interrupt that was bound to an |SDEI| event while the
|
||||||
events are masked on the PE, the dispatcher implementation invokes the function
|
events are masked on the PE, the dispatcher implementation invokes the function
|
||||||
``plat_sdei_handle_masked_trigger``. The MPIDR of the PE that received the
|
``plat_sdei_handle_masked_trigger``. The MPIDR of the PE that received the
|
||||||
interrupt and the interrupt ID are passed as parameters.
|
interrupt and the interrupt ID are passed as parameters.
|
||||||
|
|
@ -2567,10 +2572,12 @@ makefiles in order to benefit from them. By default, they will cause the crash
|
||||||
output to be routed over the normal console infrastructure and get printed on
|
output to be routed over the normal console infrastructure and get printed on
|
||||||
consoles configured to output in crash state. ``console_set_scope()`` can be
|
consoles configured to output in crash state. ``console_set_scope()`` can be
|
||||||
used to control whether a console is used for crash output.
|
used to control whether a console is used for crash output.
|
||||||
NOTE: Platforms are responsible for making sure that they only mark consoles for
|
|
||||||
use in the crash scope that are able to support this, i.e. that are written in
|
.. note::
|
||||||
assembly and conform with the register clobber rules for putc() (x0-x2, x16-x17)
|
Platforms are responsible for making sure that they only mark consoles for
|
||||||
and flush() (x0-x3, x16-x17) crash callbacks.
|
use in the crash scope that are able to support this, i.e. that are written
|
||||||
|
in assembly and conform with the register clobber rules for putc()
|
||||||
|
(x0-x2, x16-x17) and flush() (x0-x3, x16-x17) crash callbacks.
|
||||||
|
|
||||||
In some cases (such as debugging very early crashes that happen before the
|
In some cases (such as debugging very early crashes that happen before the
|
||||||
normal boot console can be set up), platforms may want to control crash output
|
normal boot console can be set up), platforms may want to control crash output
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,6 @@
|
||||||
PSCI Library Integration guide for Armv8-A AArch32 systems
|
PSCI Library Integration guide for Armv8-A AArch32 systems
|
||||||
==========================================================
|
==========================================================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
This document describes the PSCI library interface with a focus on how to
|
This document describes the PSCI library interface with a focus on how to
|
||||||
integrate with a suitable Trusted OS for an Armv8-A AArch32 system. The PSCI
|
integrate with a suitable Trusted OS for an Armv8-A AArch32 system. The PSCI
|
||||||
Library implements the PSCI Standard as described in `PSCI spec`_ and is meant
|
Library implements the PSCI Standard as described in `PSCI spec`_ and is meant
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,6 @@
|
||||||
Trusted Firmware-A EL3 runtime service writer's guide
|
EL3 Runtime Service Writer's Guide
|
||||||
=====================================================
|
=====================================================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
Introduction
|
Introduction
|
||||||
------------
|
------------
|
||||||
|
|
||||||
|
|
@ -96,7 +92,7 @@ A runtime service is registered using the ``DECLARE_RT_SVC()`` macro, specifying
|
||||||
the name of the service, the range of OENs covered, the type of service and
|
the name of the service, the range of OENs covered, the type of service and
|
||||||
initialization and call handler functions.
|
initialization and call handler functions.
|
||||||
|
|
||||||
::
|
.. code:: c
|
||||||
|
|
||||||
#define DECLARE_RT_SVC(_name, _start, _end, _type, _setup, _smch)
|
#define DECLARE_RT_SVC(_name, _start, _end, _type, _setup, _smch)
|
||||||
|
|
||||||
|
|
@ -264,8 +260,9 @@ The ``cookie`` parameter to the handler is reserved for future use and can be
|
||||||
ignored. The ``handle`` is returned by the SMC handler - completion of the
|
ignored. The ``handle`` is returned by the SMC handler - completion of the
|
||||||
handler function must always be via one of the ``SMC_RETn()`` macros.
|
handler function must always be via one of the ``SMC_RETn()`` macros.
|
||||||
|
|
||||||
NOTE: The PSCI and Test Secure-EL1 Payload Dispatcher services do not follow
|
.. note::
|
||||||
all of the above requirements yet.
|
The PSCI and Test Secure-EL1 Payload Dispatcher services do not follow
|
||||||
|
all of the above requirements yet.
|
||||||
|
|
||||||
Services that contain multiple sub-services
|
Services that contain multiple sub-services
|
||||||
-------------------------------------------
|
-------------------------------------------
|
||||||
|
|
|
||||||
|
|
@ -1,10 +1,5 @@
|
||||||
Trusted Firmware-A User Guide
|
User Guide
|
||||||
=============================
|
==========
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
This document describes how to build Trusted Firmware-A (TF-A) and run it with a
|
This document describes how to build Trusted Firmware-A (TF-A) and run it with a
|
||||||
tested set of other software components using defined configurations on the Juno
|
tested set of other software components using defined configurations on the Juno
|
||||||
|
|
@ -49,7 +44,7 @@ Tools
|
||||||
|
|
||||||
Install the required packages to build TF-A with the following command:
|
Install the required packages to build TF-A with the following command:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
sudo apt-get install device-tree-compiler build-essential gcc make git libssl-dev
|
sudo apt-get install device-tree-compiler build-essential gcc make git libssl-dev
|
||||||
|
|
||||||
|
|
@ -101,9 +96,10 @@ targets which both utilise the `checkpatch.pl` script that ships with the Linux
|
||||||
source tree. The project also defines certain *checkpatch* options in the
|
source tree. The project also defines certain *checkpatch* options in the
|
||||||
``.checkpatch.conf`` file in the top-level directory.
|
``.checkpatch.conf`` file in the top-level directory.
|
||||||
|
|
||||||
**Note:** Checkpatch errors will gate upstream merging of pull requests.
|
.. note::
|
||||||
Checkpatch warnings will not gate merging but should be reviewed and fixed if
|
Checkpatch errors will gate upstream merging of pull requests.
|
||||||
possible.
|
Checkpatch warnings will not gate merging but should be reviewed and fixed if
|
||||||
|
possible.
|
||||||
|
|
||||||
To check the entire source tree, you must first download copies of
|
To check the entire source tree, you must first download copies of
|
||||||
``checkpatch.pl``, ``spelling.txt`` and ``const_structs.checkpatch`` available
|
``checkpatch.pl``, ``spelling.txt`` and ``const_structs.checkpatch`` available
|
||||||
|
|
@ -111,14 +107,14 @@ in the `Linux master tree`_ *scripts* directory, then set the ``CHECKPATCH``
|
||||||
environment variable to point to ``checkpatch.pl`` (with the other 2 files in
|
environment variable to point to ``checkpatch.pl`` (with the other 2 files in
|
||||||
the same directory) and build the `checkcodebase` target:
|
the same directory) and build the `checkcodebase` target:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make CHECKPATCH=<path-to-linux>/linux/scripts/checkpatch.pl checkcodebase
|
make CHECKPATCH=<path-to-linux>/linux/scripts/checkpatch.pl checkcodebase
|
||||||
|
|
||||||
To just check the style on the files that differ between your local branch and
|
To just check the style on the files that differ between your local branch and
|
||||||
the remote master, use:
|
the remote master, use:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make CHECKPATCH=<path-to-linux>/linux/scripts/checkpatch.pl checkpatch
|
make CHECKPATCH=<path-to-linux>/linux/scripts/checkpatch.pl checkpatch
|
||||||
|
|
||||||
|
|
@ -134,13 +130,13 @@ Building TF-A
|
||||||
|
|
||||||
For AArch64:
|
For AArch64:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
|
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
|
||||||
|
|
||||||
For AArch32:
|
For AArch32:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf-
|
export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf-
|
||||||
|
|
||||||
|
|
@ -158,7 +154,7 @@ Building TF-A
|
||||||
|
|
||||||
For AArch64 using Arm Compiler 6:
|
For AArch64 using Arm Compiler 6:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
|
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
|
||||||
make CC=<path-to-armclang>/bin/armclang PLAT=<platform> all
|
make CC=<path-to-armclang>/bin/armclang PLAT=<platform> all
|
||||||
|
|
@ -169,7 +165,7 @@ Building TF-A
|
||||||
|
|
||||||
For AArch64 using clang:
|
For AArch64 using clang:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
|
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
|
||||||
make CC=<path-to-clang>/bin/clang PLAT=<platform> all
|
make CC=<path-to-clang>/bin/clang PLAT=<platform> all
|
||||||
|
|
@ -178,13 +174,13 @@ Building TF-A
|
||||||
|
|
||||||
For AArch64:
|
For AArch64:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=<platform> all
|
make PLAT=<platform> all
|
||||||
|
|
||||||
For AArch32:
|
For AArch32:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=<platform> ARCH=aarch32 AARCH32_SP=sp_min all
|
make PLAT=<platform> ARCH=aarch32 AARCH32_SP=sp_min all
|
||||||
|
|
||||||
|
|
@ -227,7 +223,7 @@ Building TF-A
|
||||||
|
|
||||||
- Build products for a specific build variant can be removed using:
|
- Build products for a specific build variant can be removed using:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make DEBUG=<D> PLAT=<platform> clean
|
make DEBUG=<D> PLAT=<platform> clean
|
||||||
|
|
||||||
|
|
@ -235,7 +231,7 @@ Building TF-A
|
||||||
|
|
||||||
The build tree can be removed completely using:
|
The build tree can be removed completely using:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make realclean
|
make realclean
|
||||||
|
|
||||||
|
|
@ -723,8 +719,9 @@ Common build options
|
||||||
of certificates in the FIP and FWU_FIP depends upon the value of the
|
of certificates in the FIP and FWU_FIP depends upon the value of the
|
||||||
``GENERATE_COT`` option.
|
``GENERATE_COT`` option.
|
||||||
|
|
||||||
Note: This option depends on ``CREATE_KEYS`` to be enabled. If the keys
|
.. warning::
|
||||||
already exist in disk, they will be overwritten without further notice.
|
This option depends on ``CREATE_KEYS`` to be enabled. If the keys
|
||||||
|
already exist in disk, they will be overwritten without further notice.
|
||||||
|
|
||||||
- ``TRUSTED_WORLD_KEY``: This option is used when ``GENERATE_COT=1``. It
|
- ``TRUSTED_WORLD_KEY``: This option is used when ``GENERATE_COT=1``. It
|
||||||
specifies the file that contains the Trusted World private key in PEM
|
specifies the file that contains the Trusted World private key in PEM
|
||||||
|
|
@ -744,8 +741,9 @@ Common build options
|
||||||
interrupts to TSP allowing it to save its context and hand over
|
interrupts to TSP allowing it to save its context and hand over
|
||||||
synchronously to EL3 via an SMC.
|
synchronously to EL3 via an SMC.
|
||||||
|
|
||||||
Note: when ``EL3_EXCEPTION_HANDLING`` is ``1``, ``TSP_NS_INTR_ASYNC_PREEMPT``
|
.. note::
|
||||||
must also be set to ``1``.
|
When ``EL3_EXCEPTION_HANDLING`` is ``1``, ``TSP_NS_INTR_ASYNC_PREEMPT``
|
||||||
|
must also be set to ``1``.
|
||||||
|
|
||||||
- ``USE_ARM_LINK``: This flag determines whether to enable support for ARM
|
- ``USE_ARM_LINK``: This flag determines whether to enable support for ARM
|
||||||
linker. When the ``LINKER`` build variable points to the armlink linker,
|
linker. When the ``LINKER`` build variable points to the armlink linker,
|
||||||
|
|
@ -940,7 +938,7 @@ Debugging options
|
||||||
|
|
||||||
To compile a debug version and make the build more verbose use
|
To compile a debug version and make the build more verbose use
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=<platform> DEBUG=1 V=1 all
|
make PLAT=<platform> DEBUG=1 V=1 all
|
||||||
|
|
||||||
|
|
@ -953,14 +951,15 @@ version to 2 is recommended for DS-5 versions older than 5.16.
|
||||||
When debugging logic problems it might also be useful to disable all compiler
|
When debugging logic problems it might also be useful to disable all compiler
|
||||||
optimizations by using ``-O0``.
|
optimizations by using ``-O0``.
|
||||||
|
|
||||||
NOTE: Using ``-O0`` could cause output images to be larger and base addresses
|
.. warning::
|
||||||
might need to be recalculated (see the **Memory layout on Arm development
|
Using ``-O0`` could cause output images to be larger and base addresses
|
||||||
platforms** section in the `Firmware Design`_).
|
might need to be recalculated (see the **Memory layout on Arm development
|
||||||
|
platforms** section in the `Firmware Design`_).
|
||||||
|
|
||||||
Extra debug options can be passed to the build system by setting ``CFLAGS`` or
|
Extra debug options can be passed to the build system by setting ``CFLAGS`` or
|
||||||
``LDFLAGS``:
|
``LDFLAGS``:
|
||||||
|
|
||||||
.. code:: makefile
|
.. code:: shell
|
||||||
|
|
||||||
CFLAGS='-O0 -gdwarf-2' \
|
CFLAGS='-O0 -gdwarf-2' \
|
||||||
make PLAT=<platform> DEBUG=1 V=1 all
|
make PLAT=<platform> DEBUG=1 V=1 all
|
||||||
|
|
@ -1001,7 +1000,7 @@ must be recompiled as well. For more information on SPs and SPDs, see the
|
||||||
First clean the TF-A build directory to get rid of any previous BL31 binary.
|
First clean the TF-A build directory to get rid of any previous BL31 binary.
|
||||||
Then to build the TSP image use:
|
Then to build the TSP image use:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=<platform> SPD=tspd all
|
make PLAT=<platform> SPD=tspd all
|
||||||
|
|
||||||
|
|
@ -1029,13 +1028,13 @@ and BL33 images.
|
||||||
|
|
||||||
For AArch64:
|
For AArch64:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=fvp BL33=<path-to>/bl33.bin fip
|
make PLAT=fvp BL33=<path-to>/bl33.bin fip
|
||||||
|
|
||||||
For AArch32:
|
For AArch32:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=fvp ARCH=aarch32 AARCH32_SP=sp_min BL33=<path-to>/bl33.bin fip
|
make PLAT=fvp ARCH=aarch32 AARCH32_SP=sp_min BL33=<path-to>/bl33.bin fip
|
||||||
|
|
||||||
|
|
@ -1051,13 +1050,13 @@ steps:
|
||||||
|
|
||||||
It is recommended to remove old artifacts before building the tool:
|
It is recommended to remove old artifacts before building the tool:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make -C tools/fiptool clean
|
make -C tools/fiptool clean
|
||||||
|
|
||||||
Build the tool:
|
Build the tool:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make [DEBUG=1] [V=1] fiptool
|
make [DEBUG=1] [V=1] fiptool
|
||||||
|
|
||||||
|
|
@ -1072,7 +1071,7 @@ options.
|
||||||
|
|
||||||
Example 1: create a new Firmware package ``fip.bin`` that contains BL2 and BL31:
|
Example 1: create a new Firmware package ``fip.bin`` that contains BL2 and BL31:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
./tools/fiptool/fiptool create \
|
./tools/fiptool/fiptool create \
|
||||||
--tb-fw build/<platform>/<build-type>/bl2.bin \
|
--tb-fw build/<platform>/<build-type>/bl2.bin \
|
||||||
|
|
@ -1081,13 +1080,13 @@ Example 1: create a new Firmware package ``fip.bin`` that contains BL2 and BL31:
|
||||||
|
|
||||||
Example 2: view the contents of an existing Firmware package:
|
Example 2: view the contents of an existing Firmware package:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
./tools/fiptool/fiptool info <path-to>/fip.bin
|
./tools/fiptool/fiptool info <path-to>/fip.bin
|
||||||
|
|
||||||
Example 3: update the entries of an existing Firmware package:
|
Example 3: update the entries of an existing Firmware package:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
# Change the BL2 from Debug to Release version
|
# Change the BL2 from Debug to Release version
|
||||||
./tools/fiptool/fiptool update \
|
./tools/fiptool/fiptool update \
|
||||||
|
|
@ -1096,14 +1095,14 @@ Example 3: update the entries of an existing Firmware package:
|
||||||
|
|
||||||
Example 4: unpack all entries from an existing Firmware package:
|
Example 4: unpack all entries from an existing Firmware package:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
# Images will be unpacked to the working directory
|
# Images will be unpacked to the working directory
|
||||||
./tools/fiptool/fiptool unpack <path-to>/fip.bin
|
./tools/fiptool/fiptool unpack <path-to>/fip.bin
|
||||||
|
|
||||||
Example 5: remove an entry from an existing Firmware package:
|
Example 5: remove an entry from an existing Firmware package:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
./tools/fiptool/fiptool remove \
|
./tools/fiptool/fiptool remove \
|
||||||
--tb-fw build/<platform>/debug/fip.bin
|
--tb-fw build/<platform>/debug/fip.bin
|
||||||
|
|
@ -1173,7 +1172,7 @@ images with support for these features:
|
||||||
|
|
||||||
Example of command line using RSA development keys:
|
Example of command line using RSA development keys:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
MBEDTLS_DIR=<path of the directory containing mbed TLS sources> \
|
MBEDTLS_DIR=<path of the directory containing mbed TLS sources> \
|
||||||
make PLAT=<platform> TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 \
|
make PLAT=<platform> TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 \
|
||||||
|
|
@ -1210,12 +1209,14 @@ images with support for these features:
|
||||||
NS_BL2U=<path-to>/<ns_bl2u_image> \
|
NS_BL2U=<path-to>/<ns_bl2u_image> \
|
||||||
all fip fwu_fip
|
all fip fwu_fip
|
||||||
|
|
||||||
Note: The BL2U image will be built by default and added to the FWU_FIP.
|
.. note::
|
||||||
The user may override this by adding ``BL2U=<path-to>/<bl2u_image>``
|
The BL2U image will be built by default and added to the FWU_FIP.
|
||||||
to the command line above.
|
The user may override this by adding ``BL2U=<path-to>/<bl2u_image>``
|
||||||
|
to the command line above.
|
||||||
|
|
||||||
Note: Building and installing the non-secure and SCP FWU images (NS_BL1U,
|
.. note::
|
||||||
NS_BL2U and SCP_BL2U) is outside the scope of this document.
|
Building and installing the non-secure and SCP FWU images (NS_BL1U,
|
||||||
|
NS_BL2U and SCP_BL2U) is outside the scope of this document.
|
||||||
|
|
||||||
The result of this build will be bl1.bin, fip.bin and fwu_fip.bin binaries.
|
The result of this build will be bl1.bin, fip.bin and fwu_fip.bin binaries.
|
||||||
Both the FIP and FWU_FIP will include the certificates corresponding to the
|
Both the FIP and FWU_FIP will include the certificates corresponding to the
|
||||||
|
|
@ -1230,7 +1231,7 @@ The ``cert_create`` tool is built as part of the TF-A build process when the
|
||||||
previous section), but it can also be built separately with the following
|
previous section), but it can also be built separately with the following
|
||||||
command:
|
command:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=<platform> [DEBUG=1] [V=1] certtool
|
make PLAT=<platform> [DEBUG=1] [V=1] certtool
|
||||||
|
|
||||||
|
|
@ -1239,14 +1240,14 @@ For platforms that require their own IDs in certificate files, the generic
|
||||||
platform must define its IDs within a ``platform_oid.h`` header file for the
|
platform must define its IDs within a ``platform_oid.h`` header file for the
|
||||||
build to succeed.
|
build to succeed.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=<platform> USE_TBBR_DEFS=0 [DEBUG=1] [V=1] certtool
|
make PLAT=<platform> USE_TBBR_DEFS=0 [DEBUG=1] [V=1] certtool
|
||||||
|
|
||||||
``DEBUG=1`` builds the tool in debug mode. ``V=1`` makes the build process more
|
``DEBUG=1`` builds the tool in debug mode. ``V=1`` makes the build process more
|
||||||
verbose. The following command should be used to obtain help about the tool:
|
verbose. The following command should be used to obtain help about the tool:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
./tools/cert_create/cert_create -h
|
./tools/cert_create/cert_create -h
|
||||||
|
|
||||||
|
|
@ -1257,25 +1258,30 @@ This section provides Juno and FVP specific instructions to build Trusted
|
||||||
Firmware, obtain the additional required firmware, and pack it all together in
|
Firmware, obtain the additional required firmware, and pack it all together in
|
||||||
a single FIP binary. It assumes that a `Linaro Release`_ has been installed.
|
a single FIP binary. It assumes that a `Linaro Release`_ has been installed.
|
||||||
|
|
||||||
Note: Pre-built binaries for AArch32 are available from Linaro Release 16.12
|
.. note::
|
||||||
onwards. Before that release, pre-built binaries are only available for AArch64.
|
Pre-built binaries for AArch32 are available from Linaro Release 16.12
|
||||||
|
onwards. Before that release, pre-built binaries are only available for
|
||||||
|
AArch64.
|
||||||
|
|
||||||
Note: Follow the full instructions for one platform before switching to a
|
.. warning::
|
||||||
different one. Mixing instructions for different platforms may result in
|
Follow the full instructions for one platform before switching to a
|
||||||
corrupted binaries.
|
different one. Mixing instructions for different platforms may result in
|
||||||
|
corrupted binaries.
|
||||||
|
|
||||||
Note: The uboot image downloaded by the Linaro workspace script does not always
|
.. warning::
|
||||||
match the uboot image packaged as BL33 in the corresponding fip file. It is
|
The uboot image downloaded by the Linaro workspace script does not always
|
||||||
recommended to use the version that is packaged in the fip file using the
|
match the uboot image packaged as BL33 in the corresponding fip file. It is
|
||||||
instructions below.
|
recommended to use the version that is packaged in the fip file using the
|
||||||
|
instructions below.
|
||||||
|
|
||||||
Note: For the FVP, the kernel FDT is packaged in FIP during build and loaded
|
.. note::
|
||||||
by the firmware at runtime. See `Obtaining the Flattened Device Trees`_
|
For the FVP, the kernel FDT is packaged in FIP during build and loaded
|
||||||
section for more info on selecting the right FDT to use.
|
by the firmware at runtime. See `Obtaining the Flattened Device Trees`_
|
||||||
|
section for more info on selecting the right FDT to use.
|
||||||
|
|
||||||
#. Clean the working directory
|
#. Clean the working directory
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make realclean
|
make realclean
|
||||||
|
|
||||||
|
|
@ -1284,7 +1290,7 @@ section for more info on selecting the right FDT to use.
|
||||||
Use the fiptool to extract the SCP_BL2 and BL33 images from the FIP
|
Use the fiptool to extract the SCP_BL2 and BL33 images from the FIP
|
||||||
package included in the Linaro release:
|
package included in the Linaro release:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
# Build the fiptool
|
# Build the fiptool
|
||||||
make [DEBUG=1] [V=1] fiptool
|
make [DEBUG=1] [V=1] fiptool
|
||||||
|
|
@ -1296,16 +1302,18 @@ section for more info on selecting the right FDT to use.
|
||||||
current working directory. The SCP_BL2 image corresponds to
|
current working directory. The SCP_BL2 image corresponds to
|
||||||
``scp-fw.bin`` and BL33 corresponds to ``nt-fw.bin``.
|
``scp-fw.bin`` and BL33 corresponds to ``nt-fw.bin``.
|
||||||
|
|
||||||
Note: The fiptool will complain if the images to be unpacked already
|
.. note::
|
||||||
exist in the current directory. If that is the case, either delete those
|
The fiptool will complain if the images to be unpacked already
|
||||||
files or use the ``--force`` option to overwrite.
|
exist in the current directory. If that is the case, either delete those
|
||||||
|
files or use the ``--force`` option to overwrite.
|
||||||
|
|
||||||
Note: For AArch32, the instructions below assume that nt-fw.bin is a normal
|
.. note::
|
||||||
world boot loader that supports AArch32.
|
For AArch32, the instructions below assume that nt-fw.bin is a
|
||||||
|
normal world boot loader that supports AArch32.
|
||||||
|
|
||||||
#. Build TF-A images and create a new FIP for FVP
|
#. Build TF-A images and create a new FIP for FVP
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
# AArch64
|
# AArch64
|
||||||
make PLAT=fvp BL33=nt-fw.bin all fip
|
make PLAT=fvp BL33=nt-fw.bin all fip
|
||||||
|
|
@ -1320,7 +1328,7 @@ section for more info on selecting the right FDT to use.
|
||||||
Building for AArch64 on Juno simply requires the addition of ``SCP_BL2``
|
Building for AArch64 on Juno simply requires the addition of ``SCP_BL2``
|
||||||
as a build parameter.
|
as a build parameter.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=juno BL33=nt-fw.bin SCP_BL2=scp-fw.bin all fip
|
make PLAT=juno BL33=nt-fw.bin SCP_BL2=scp-fw.bin all fip
|
||||||
|
|
||||||
|
|
@ -1333,13 +1341,13 @@ section for more info on selecting the right FDT to use.
|
||||||
- Before building BL32, the environment variable ``CROSS_COMPILE`` must point
|
- Before building BL32, the environment variable ``CROSS_COMPILE`` must point
|
||||||
to the AArch32 Linaro cross compiler.
|
to the AArch32 Linaro cross compiler.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf-
|
export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf-
|
||||||
|
|
||||||
- Build BL32 in AArch32.
|
- Build BL32 in AArch32.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make ARCH=aarch32 PLAT=juno AARCH32_SP=sp_min \
|
make ARCH=aarch32 PLAT=juno AARCH32_SP=sp_min \
|
||||||
RESET_TO_SP_MIN=1 JUNO_AARCH32_EL3_RUNTIME=1 bl32
|
RESET_TO_SP_MIN=1 JUNO_AARCH32_EL3_RUNTIME=1 bl32
|
||||||
|
|
@ -1354,14 +1362,14 @@ section for more info on selecting the right FDT to use.
|
||||||
- Before building BL1 and BL2, the environment variable ``CROSS_COMPILE``
|
- Before building BL1 and BL2, the environment variable ``CROSS_COMPILE``
|
||||||
must point to the AArch64 Linaro cross compiler.
|
must point to the AArch64 Linaro cross compiler.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
|
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
|
||||||
|
|
||||||
- The following parameters should be used to build BL1 and BL2 in AArch64
|
- The following parameters should be used to build BL1 and BL2 in AArch64
|
||||||
and point to the BL32 file.
|
and point to the BL32 file.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make ARCH=aarch64 PLAT=juno JUNO_AARCH32_EL3_RUNTIME=1 \
|
make ARCH=aarch64 PLAT=juno JUNO_AARCH32_EL3_RUNTIME=1 \
|
||||||
BL33=nt-fw.bin SCP_BL2=scp-fw.bin \
|
BL33=nt-fw.bin SCP_BL2=scp-fw.bin \
|
||||||
|
|
@ -1499,7 +1507,7 @@ clear the mailbox at start-up.
|
||||||
One way to do that is to create an 8-byte file containing all zero bytes using
|
One way to do that is to create an 8-byte file containing all zero bytes using
|
||||||
the following command:
|
the following command:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
dd if=/dev/zero of=mailbox.dat bs=1 count=8
|
dd if=/dev/zero of=mailbox.dat bs=1 count=8
|
||||||
|
|
||||||
|
|
@ -1569,7 +1577,7 @@ used when compiling TF-A. For example, the following command will create a FIP
|
||||||
without a BL33 and prepare to jump to a BL33 image loaded at address
|
without a BL33 and prepare to jump to a BL33 image loaded at address
|
||||||
0x80000000:
|
0x80000000:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PRELOADED_BL33_BASE=0x80000000 PLAT=fvp all fip
|
make PRELOADED_BL33_BASE=0x80000000 PLAT=fvp all fip
|
||||||
|
|
||||||
|
|
@ -1584,7 +1592,7 @@ memory (like in FVP).
|
||||||
For example, if the kernel is loaded at ``0x80080000`` and the DTB is loaded at
|
For example, if the kernel is loaded at ``0x80080000`` and the DTB is loaded at
|
||||||
address ``0x82000000``, the firmware can be built like this:
|
address ``0x82000000``, the firmware can be built like this:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
CROSS_COMPILE=aarch64-linux-gnu- \
|
CROSS_COMPILE=aarch64-linux-gnu- \
|
||||||
make PLAT=fvp DEBUG=1 \
|
make PLAT=fvp DEBUG=1 \
|
||||||
|
|
@ -1632,7 +1640,7 @@ offset in ``INITRD_START`` has to be removed.
|
||||||
|
|
||||||
And the FVP binary can be run with the following command:
|
And the FVP binary can be run with the following command:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
<path-to>/FVP_Base_AEMv8A-AEMv8A \
|
<path-to>/FVP_Base_AEMv8A-AEMv8A \
|
||||||
-C pctl.startup=0.0.0.0 \
|
-C pctl.startup=0.0.0.0 \
|
||||||
|
|
@ -1667,7 +1675,8 @@ The latest version of the AArch64 build of TF-A has been tested on the following
|
||||||
Arm FVPs without shifted affinities, and that do not support threaded CPU cores
|
Arm FVPs without shifted affinities, and that do not support threaded CPU cores
|
||||||
(64-bit host machine only).
|
(64-bit host machine only).
|
||||||
|
|
||||||
The FVP models used are Version 11.6 Build 45, unless otherwise stated.
|
.. note::
|
||||||
|
The FVP models used are Version 11.6 Build 45, unless otherwise stated.
|
||||||
|
|
||||||
- ``FVP_Base_AEMv8A-AEMv8A``
|
- ``FVP_Base_AEMv8A-AEMv8A``
|
||||||
- ``FVP_Base_AEMv8A-AEMv8A-AEMv8A-AEMv8A-CCN502``
|
- ``FVP_Base_AEMv8A-AEMv8A-AEMv8A-AEMv8A-CCN502``
|
||||||
|
|
@ -1704,30 +1713,36 @@ Arm FVPs without shifted affinities, and that do not support threaded CPU cores
|
||||||
- ``FVP_Base_AEMv8A-AEMv8A``
|
- ``FVP_Base_AEMv8A-AEMv8A``
|
||||||
- ``FVP_Base_Cortex-A32x4``
|
- ``FVP_Base_Cortex-A32x4``
|
||||||
|
|
||||||
NOTE: The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities, which
|
.. note::
|
||||||
is not compatible with legacy GIC configurations. Therefore this FVP does not
|
The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities, which
|
||||||
support these legacy GIC configurations.
|
is not compatible with legacy GIC configurations. Therefore this FVP does not
|
||||||
|
support these legacy GIC configurations.
|
||||||
|
|
||||||
NOTE: The build numbers quoted above are those reported by launching the FVP
|
.. note::
|
||||||
with the ``--version`` parameter.
|
The build numbers quoted above are those reported by launching the FVP
|
||||||
|
with the ``--version`` parameter.
|
||||||
|
|
||||||
NOTE: Linaro provides a ramdisk image in prebuilt FVP configurations and full
|
.. note::
|
||||||
file systems that can be downloaded separately. To run an FVP with a virtio
|
Linaro provides a ramdisk image in prebuilt FVP configurations and full
|
||||||
file system image an additional FVP configuration option
|
file systems that can be downloaded separately. To run an FVP with a virtio
|
||||||
``-C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>`` can be
|
file system image an additional FVP configuration option
|
||||||
used.
|
``-C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>`` can be
|
||||||
|
used.
|
||||||
|
|
||||||
NOTE: The software will not work on Version 1.0 of the Foundation FVP.
|
.. note::
|
||||||
The commands below would report an ``unhandled argument`` error in this case.
|
The software will not work on Version 1.0 of the Foundation FVP.
|
||||||
|
The commands below would report an ``unhandled argument`` error in this case.
|
||||||
|
|
||||||
NOTE: FVPs can be launched with ``--cadi-server`` option such that a
|
.. note::
|
||||||
CADI-compliant debugger (for example, Arm DS-5) can connect to and control its
|
FVPs can be launched with ``--cadi-server`` option such that a
|
||||||
execution.
|
CADI-compliant debugger (for example, Arm DS-5) can connect to and control
|
||||||
|
its execution.
|
||||||
|
|
||||||
NOTE: Since FVP model Version 11.0 Build 11.0.34 and Version 8.5 Build 0.8.5202
|
.. warning::
|
||||||
the internal synchronisation timings changed compared to older versions of the
|
Since FVP model Version 11.0 Build 11.0.34 and Version 8.5 Build 0.8.5202
|
||||||
models. The models can be launched with ``-Q 100`` option if they are required
|
the internal synchronisation timings changed compared to older versions of
|
||||||
to match the run time characteristics of the older versions.
|
the models. The models can be launched with ``-Q 100`` option if they are
|
||||||
|
required to match the run time characteristics of the older versions.
|
||||||
|
|
||||||
The Foundation FVP is a cut down version of the AArch64 Base FVP. It can be
|
The Foundation FVP is a cut down version of the AArch64 Base FVP. It can be
|
||||||
downloaded for free from `Arm's website`_.
|
downloaded for free from `Arm's website`_.
|
||||||
|
|
@ -1748,8 +1763,9 @@ be found in the TF-A source directory under ``fdts/``. The Foundation FVP has
|
||||||
a subset of the Base FVP components. For example, the Foundation FVP lacks
|
a subset of the Base FVP components. For example, the Foundation FVP lacks
|
||||||
CLCD and MMC support, and has only one CPU cluster.
|
CLCD and MMC support, and has only one CPU cluster.
|
||||||
|
|
||||||
Note: It is not recommended to use the FDTs built along the kernel because not
|
.. note::
|
||||||
all FDTs are available from there.
|
It is not recommended to use the FDTs built along the kernel because not
|
||||||
|
all FDTs are available from there.
|
||||||
|
|
||||||
The dynamic configuration capability is enabled in the firmware for FVPs.
|
The dynamic configuration capability is enabled in the firmware for FVPs.
|
||||||
This means that the firmware can authenticate and load the FDT if present in
|
This means that the firmware can authenticate and load the FDT if present in
|
||||||
|
|
@ -1806,7 +1822,7 @@ Running on the Foundation FVP with reset to BL1 entrypoint
|
||||||
The following ``Foundation_Platform`` parameters should be used to boot Linux with
|
The following ``Foundation_Platform`` parameters should be used to boot Linux with
|
||||||
4 CPUs using the AArch64 build of TF-A.
|
4 CPUs using the AArch64 build of TF-A.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
<path-to>/Foundation_Platform \
|
<path-to>/Foundation_Platform \
|
||||||
--cores=4 \
|
--cores=4 \
|
||||||
|
|
@ -1842,7 +1858,7 @@ Running on the AEMv8 Base FVP with reset to BL1 entrypoint
|
||||||
The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
|
The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
|
||||||
with 8 CPUs using the AArch64 build of TF-A.
|
with 8 CPUs using the AArch64 build of TF-A.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
<path-to>/FVP_Base_RevC-2xAEMv8A \
|
<path-to>/FVP_Base_RevC-2xAEMv8A \
|
||||||
-C pctl.startup=0.0.0.0 \
|
-C pctl.startup=0.0.0.0 \
|
||||||
|
|
@ -1856,8 +1872,9 @@ with 8 CPUs using the AArch64 build of TF-A.
|
||||||
--data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \
|
--data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \
|
||||||
--data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000
|
--data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000
|
||||||
|
|
||||||
Note: The ``FVP_Base_RevC-2xAEMv8A`` has shifted affinities and requires a
|
.. note::
|
||||||
specific DTS for all the CPUs to be loaded.
|
The ``FVP_Base_RevC-2xAEMv8A`` has shifted affinities and requires
|
||||||
|
a specific DTS for all the CPUs to be loaded.
|
||||||
|
|
||||||
Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint
|
Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
@ -1865,7 +1882,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint
|
||||||
The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
|
The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
|
||||||
with 8 CPUs using the AArch32 build of TF-A.
|
with 8 CPUs using the AArch32 build of TF-A.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
<path-to>/FVP_Base_AEMv8A-AEMv8A \
|
<path-to>/FVP_Base_AEMv8A-AEMv8A \
|
||||||
-C pctl.startup=0.0.0.0 \
|
-C pctl.startup=0.0.0.0 \
|
||||||
|
|
@ -1893,7 +1910,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL1 entrypoint
|
||||||
The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
|
The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
|
||||||
boot Linux with 8 CPUs using the AArch64 build of TF-A.
|
boot Linux with 8 CPUs using the AArch64 build of TF-A.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
<path-to>/FVP_Base_Cortex-A57x4-A53x4 \
|
<path-to>/FVP_Base_Cortex-A57x4-A53x4 \
|
||||||
-C pctl.startup=0.0.0.0 \
|
-C pctl.startup=0.0.0.0 \
|
||||||
|
|
@ -1911,7 +1928,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to BL1 entrypoint
|
||||||
The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
|
The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
|
||||||
boot Linux with 4 CPUs using the AArch32 build of TF-A.
|
boot Linux with 4 CPUs using the AArch32 build of TF-A.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
<path-to>/FVP_Base_Cortex-A32x4 \
|
<path-to>/FVP_Base_Cortex-A32x4 \
|
||||||
-C pctl.startup=0.0.0.0 \
|
-C pctl.startup=0.0.0.0 \
|
||||||
|
|
@ -1929,7 +1946,7 @@ Running on the AEMv8 Base FVP with reset to BL31 entrypoint
|
||||||
The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
|
The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
|
||||||
with 8 CPUs using the AArch64 build of TF-A.
|
with 8 CPUs using the AArch64 build of TF-A.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
<path-to>/FVP_Base_RevC-2xAEMv8A \
|
<path-to>/FVP_Base_RevC-2xAEMv8A \
|
||||||
-C pctl.startup=0.0.0.0 \
|
-C pctl.startup=0.0.0.0 \
|
||||||
|
|
@ -1984,7 +2001,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to SP_MIN entrypoint
|
||||||
The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
|
The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
|
||||||
with 8 CPUs using the AArch32 build of TF-A.
|
with 8 CPUs using the AArch32 build of TF-A.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
<path-to>/FVP_Base_AEMv8A-AEMv8A \
|
<path-to>/FVP_Base_AEMv8A-AEMv8A \
|
||||||
-C pctl.startup=0.0.0.0 \
|
-C pctl.startup=0.0.0.0 \
|
||||||
|
|
@ -2015,8 +2032,9 @@ with 8 CPUs using the AArch32 build of TF-A.
|
||||||
--data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \
|
--data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \
|
||||||
--data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000
|
--data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000
|
||||||
|
|
||||||
Note: The load address of ``<bl32-binary>`` depends on the value ``BL32_BASE``.
|
.. note::
|
||||||
It should match the address programmed into the RVBAR register as well.
|
The load address of ``<bl32-binary>`` depends on the value ``BL32_BASE``.
|
||||||
|
It should match the address programmed into the RVBAR register as well.
|
||||||
|
|
||||||
Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint
|
Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
@ -2024,7 +2042,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint
|
||||||
The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
|
The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
|
||||||
boot Linux with 8 CPUs using the AArch64 build of TF-A.
|
boot Linux with 8 CPUs using the AArch64 build of TF-A.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
<path-to>/FVP_Base_Cortex-A57x4-A53x4 \
|
<path-to>/FVP_Base_Cortex-A57x4-A53x4 \
|
||||||
-C pctl.startup=0.0.0.0 \
|
-C pctl.startup=0.0.0.0 \
|
||||||
|
|
@ -2052,7 +2070,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to SP_MIN entrypoint
|
||||||
The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
|
The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
|
||||||
boot Linux with 4 CPUs using the AArch32 build of TF-A.
|
boot Linux with 4 CPUs using the AArch32 build of TF-A.
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
<path-to>/FVP_Base_Cortex-A32x4 \
|
<path-to>/FVP_Base_Cortex-A32x4 \
|
||||||
-C pctl.startup=0.0.0.0 \
|
-C pctl.startup=0.0.0.0 \
|
||||||
|
|
@ -2101,7 +2119,7 @@ The SYSTEM SUSPEND is a PSCI API which can be used to implement system suspend
|
||||||
to RAM. For more details refer to section 5.16 of `PSCI`_. To test system suspend
|
to RAM. For more details refer to section 5.16 of `PSCI`_. To test system suspend
|
||||||
on Juno, at the linux shell prompt, issue the following command:
|
on Juno, at the linux shell prompt, issue the following command:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
echo +10 > /sys/class/rtc/rtc0/wakealarm
|
echo +10 > /sys/class/rtc/rtc0/wakealarm
|
||||||
echo -n mem > /sys/power/state
|
echo -n mem > /sys/power/state
|
||||||
|
|
|
||||||
55
docs/global_substitutions.txt
Normal file
55
docs/global_substitutions.txt
Normal file
|
|
@ -0,0 +1,55 @@
|
||||||
|
.. |AArch32| replace:: :term:`AArch32`
|
||||||
|
.. |AArch64| replace:: :term:`AArch64`
|
||||||
|
.. |API| replace:: :term:`API`
|
||||||
|
.. |CoT| replace:: :term:`CoT`
|
||||||
|
.. |COT| replace:: :term:`COT`
|
||||||
|
.. |CSS| replace:: :term:`CSS`
|
||||||
|
.. |CVE| replace:: :term:`CVE`
|
||||||
|
.. |DS-5| replace:: :term:`DS-5`
|
||||||
|
.. |DT| replace:: :term:`DT`
|
||||||
|
.. |EL| replace:: :term:`EL`
|
||||||
|
.. |EHF| replace:: :term:`EHF`
|
||||||
|
.. |FDT| replace:: :term:`FDT`
|
||||||
|
.. |FIP| replace:: :term:`FIP`
|
||||||
|
.. |FVP| replace:: :term:`FVP`
|
||||||
|
.. |FWU| replace:: :term:`FWU`
|
||||||
|
.. |GIC| replace:: :term:`GIC`
|
||||||
|
.. |ISA| replace:: :term:`ISA`
|
||||||
|
.. |Linaro| replace:: :term:`Linaro`
|
||||||
|
.. |MMU| replace:: :term:`MMU`
|
||||||
|
.. |MPAM| replace:: :term:`MPAM`
|
||||||
|
.. |MPIDR| replace:: :term:`MPIDR`
|
||||||
|
.. |OEN| replace:: :term:`OEN`
|
||||||
|
.. |OP-TEE| replace:: :term:`OP-TEE`
|
||||||
|
.. |OTE| replace:: :term:`OTE`
|
||||||
|
.. |PDD| replace:: :term:`PDD`
|
||||||
|
.. |PMF| replace:: :term:`PMF`
|
||||||
|
.. |PSCI| replace:: :term:`PSCI`
|
||||||
|
.. |RAS| replace:: :term:`RAS`
|
||||||
|
.. |ROT| replace:: :term:`ROT`
|
||||||
|
.. |SCMI| replace:: :term:`SCMI`
|
||||||
|
.. |SCP| replace:: :term:`SCP`
|
||||||
|
.. |SDEI| replace:: :term:`SDEI`
|
||||||
|
.. |SDS| replace:: :term:`SDS`
|
||||||
|
.. |SEA| replace:: :term:`SEA`
|
||||||
|
.. |SiP| replace:: :term:`SiP`
|
||||||
|
.. |SIP| replace:: :term:`SIP`
|
||||||
|
.. |SMC| replace:: :term:`SMC`
|
||||||
|
.. |SMCCC| replace:: :term:`SMCCC`
|
||||||
|
.. |SoC| replace:: :term:`SoC`
|
||||||
|
.. |SP| replace:: :term:`SP`
|
||||||
|
.. |SPD| replace:: :term:`SPD`
|
||||||
|
.. |SPM| replace:: :term:`SPM`
|
||||||
|
.. |SVE| replace:: :term:`SVE`
|
||||||
|
.. |TBB| replace:: :term:`TBB`
|
||||||
|
.. |TBBR| replace:: :term:`TBBR`
|
||||||
|
.. |TEE| replace:: :term:`TEE`
|
||||||
|
.. |TF-A| replace:: :term:`TF-A`
|
||||||
|
.. |TF-M| replace:: :term:`TF-M`
|
||||||
|
.. |TLB| replace:: :term:`TLB`
|
||||||
|
.. |TLK| replace:: :term:`TLK`
|
||||||
|
.. |TSP| replace:: :term:`TSP`
|
||||||
|
.. |TZC| replace:: :term:`TZC`
|
||||||
|
.. |UEFI| replace:: :term:`UEFI`
|
||||||
|
.. |WDOG| replace:: :term:`WDOG`
|
||||||
|
.. |XLAT| replace:: :term:`XLAT`
|
||||||
177
docs/glossary.rst
Normal file
177
docs/glossary.rst
Normal file
|
|
@ -0,0 +1,177 @@
|
||||||
|
Glossary
|
||||||
|
========
|
||||||
|
|
||||||
|
This glossary provides definitions for terms and abbreviations used in the TF-A
|
||||||
|
documentation.
|
||||||
|
|
||||||
|
You can find additional definitions in the `Arm Glossary`_.
|
||||||
|
|
||||||
|
.. glossary::
|
||||||
|
:sorted:
|
||||||
|
|
||||||
|
AArch32
|
||||||
|
32-bit execution state of the ARMv8 ISA
|
||||||
|
|
||||||
|
AArch64
|
||||||
|
64-bit execution state of the ARMv8 ISA
|
||||||
|
|
||||||
|
API
|
||||||
|
Application Programming Interface
|
||||||
|
|
||||||
|
CoT
|
||||||
|
COT
|
||||||
|
Chain of Trust
|
||||||
|
|
||||||
|
CSS
|
||||||
|
Compute Sub-System
|
||||||
|
|
||||||
|
CVE
|
||||||
|
Common Vulnerabilities and Exposures. A CVE document is commonly used to
|
||||||
|
describe a publicly-known security vulnerability.
|
||||||
|
|
||||||
|
DS-5
|
||||||
|
Arm Development Studio 5
|
||||||
|
|
||||||
|
DT
|
||||||
|
Device Tree
|
||||||
|
|
||||||
|
EL
|
||||||
|
Exception Level
|
||||||
|
|
||||||
|
EHF
|
||||||
|
Exception Handling Framework
|
||||||
|
|
||||||
|
FDT
|
||||||
|
Flattened Device Tree
|
||||||
|
|
||||||
|
FIP
|
||||||
|
Firmware Image Package
|
||||||
|
|
||||||
|
FVP
|
||||||
|
Fixed Virtual Platform
|
||||||
|
|
||||||
|
FWU
|
||||||
|
FirmWare Update
|
||||||
|
|
||||||
|
GIC
|
||||||
|
Generic Interrupt Controller
|
||||||
|
|
||||||
|
ISA
|
||||||
|
Instruction Set Architecture
|
||||||
|
|
||||||
|
Linaro
|
||||||
|
A collaborative engineering organization consolidating
|
||||||
|
and optimizing open source software and tools for the Arm architecture.
|
||||||
|
|
||||||
|
MMU
|
||||||
|
Memory Management Unit
|
||||||
|
|
||||||
|
MPAM
|
||||||
|
Memory Partitioning And Monitoring. An optional Armv8.4 extension.
|
||||||
|
|
||||||
|
MPIDR
|
||||||
|
Multiprocessor Affinity Register
|
||||||
|
|
||||||
|
OEN
|
||||||
|
Owning Entity Number
|
||||||
|
|
||||||
|
OP-TEE
|
||||||
|
Open Portable Trusted Execution Environment. An example of a :term:`TEE`
|
||||||
|
|
||||||
|
OTE
|
||||||
|
Open-source Trusted Execution Environment
|
||||||
|
|
||||||
|
PDD
|
||||||
|
Platform Design Document
|
||||||
|
|
||||||
|
PMF
|
||||||
|
Performance Measurement Framework
|
||||||
|
|
||||||
|
PSCI
|
||||||
|
Power State Coordination Interface
|
||||||
|
|
||||||
|
RAS
|
||||||
|
Reliability, Availability, and Serviceability extensions. A mandatory
|
||||||
|
extension for the Armv8.2 architecture and later. An optional extension to
|
||||||
|
the base Armv8 architecture.
|
||||||
|
|
||||||
|
ROT
|
||||||
|
Root of Trust
|
||||||
|
|
||||||
|
SCMI
|
||||||
|
System Control and Management Interface
|
||||||
|
|
||||||
|
SCP
|
||||||
|
System Control Processor
|
||||||
|
|
||||||
|
SDEI
|
||||||
|
Software Delegated Exception Interface
|
||||||
|
|
||||||
|
SDS
|
||||||
|
Shared Data Storage
|
||||||
|
|
||||||
|
SEA
|
||||||
|
Synchronous External Abort
|
||||||
|
|
||||||
|
SiP
|
||||||
|
SIP
|
||||||
|
Silicon Provider
|
||||||
|
|
||||||
|
SMC
|
||||||
|
Secure Monitor Call
|
||||||
|
|
||||||
|
SMCCC
|
||||||
|
:term:`SMC` Calling Convention
|
||||||
|
|
||||||
|
SoC
|
||||||
|
System on Chip
|
||||||
|
|
||||||
|
SP
|
||||||
|
Secure Partition
|
||||||
|
|
||||||
|
SPD
|
||||||
|
Secure Payload Dispatcher
|
||||||
|
|
||||||
|
SPM
|
||||||
|
Secure Partition Manager
|
||||||
|
|
||||||
|
SVE
|
||||||
|
Scalable Vector Extension
|
||||||
|
|
||||||
|
TBB
|
||||||
|
Trusted Board Boot
|
||||||
|
|
||||||
|
TBBR
|
||||||
|
Trusted Board Boot Requirements
|
||||||
|
|
||||||
|
TEE
|
||||||
|
Trusted Execution Environment
|
||||||
|
|
||||||
|
TF-A
|
||||||
|
Trusted Firmware-A
|
||||||
|
|
||||||
|
TF-M
|
||||||
|
Trusted Firmware-M
|
||||||
|
|
||||||
|
TLB
|
||||||
|
Translation Lookaside Buffer
|
||||||
|
|
||||||
|
TLK
|
||||||
|
Trusted Little Kernel. A Trusted OS from NVIDIA.
|
||||||
|
|
||||||
|
TSP
|
||||||
|
Test Secure Payload
|
||||||
|
|
||||||
|
TZC
|
||||||
|
TrustZone Controller
|
||||||
|
|
||||||
|
UEFI
|
||||||
|
Unified Extensible Firmware Interface
|
||||||
|
|
||||||
|
WDOG
|
||||||
|
Watchdog
|
||||||
|
|
||||||
|
XLAT
|
||||||
|
Translation (abbr.). For example, "XLAT table".
|
||||||
|
|
||||||
|
.. _`Arm Glossary`: https://developer.arm.com/support/arm-glossary
|
||||||
|
|
@ -3,7 +3,7 @@ Trusted Firmware-A Documentation
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
:caption: Contents
|
:hidden:
|
||||||
|
|
||||||
Home<self>
|
Home<self>
|
||||||
getting_started/index
|
getting_started/index
|
||||||
|
|
@ -14,10 +14,14 @@ Trusted Firmware-A Documentation
|
||||||
perf/index
|
perf/index
|
||||||
security_advisories/index
|
security_advisories/index
|
||||||
change-log
|
change-log
|
||||||
maintainers
|
|
||||||
acknowledgements
|
acknowledgements
|
||||||
|
glossary
|
||||||
|
maintainers
|
||||||
license
|
license
|
||||||
|
|
||||||
|
.. contents:: On This Page
|
||||||
|
:depth: 3
|
||||||
|
|
||||||
Trusted Firmware-A (TF-A) provides a reference implementation of secure world
|
Trusted Firmware-A (TF-A) provides a reference implementation of secure world
|
||||||
software for `Armv7-A and Armv8-A`_, including a `Secure Monitor`_ executing
|
software for `Armv7-A and Armv8-A`_, including a `Secure Monitor`_ executing
|
||||||
at Exception Level 3 (EL3). It implements various Arm interface standards,
|
at Exception Level 3 (EL3). It implements various Arm interface standards,
|
||||||
|
|
@ -99,7 +103,7 @@ Functionality
|
||||||
Secure-EL0, which can be used to implement simple management and
|
Secure-EL0, which can be used to implement simple management and
|
||||||
security services.
|
security services.
|
||||||
|
|
||||||
- An SDEI dispatcher to route interrupt-based SDEI events.
|
- An |SDEI| dispatcher to route interrupt-based |SDEI| events.
|
||||||
|
|
||||||
- An Exception Handling Framework (EHF) that allows dispatching of EL3
|
- An Exception Handling Framework (EHF) that allows dispatching of EL3
|
||||||
interrupts to their registered handlers, to facilitate firmware-first
|
interrupts to their registered handlers, to facilitate firmware-first
|
||||||
|
|
@ -149,7 +153,8 @@ The latest version of the AArch64 build of TF-A has been tested on the following
|
||||||
Arm FVPs without shifted affinities, and that do not support threaded CPU cores
|
Arm FVPs without shifted affinities, and that do not support threaded CPU cores
|
||||||
(64-bit host machine only).
|
(64-bit host machine only).
|
||||||
|
|
||||||
The FVP models used are Version 11.5 Build 33, unless otherwise stated.
|
.. note::
|
||||||
|
The FVP models used are Version 11.5 Build 33, unless otherwise stated.
|
||||||
|
|
||||||
- ``FVP_Base_AEMv8A-AEMv8A``
|
- ``FVP_Base_AEMv8A-AEMv8A``
|
||||||
- ``FVP_Base_AEMv8A-AEMv8A-AEMv8A-AEMv8A-CCN502``
|
- ``FVP_Base_AEMv8A-AEMv8A-AEMv8A-AEMv8A-CCN502``
|
||||||
|
|
@ -186,7 +191,8 @@ Arm FVPs without shifted affinities, and that do not support threaded CPU cores
|
||||||
- ``FVP_Base_AEMv8A-AEMv8A``
|
- ``FVP_Base_AEMv8A-AEMv8A``
|
||||||
- ``FVP_Base_Cortex-A32x4``
|
- ``FVP_Base_Cortex-A32x4``
|
||||||
|
|
||||||
NOTE: The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities.
|
.. note::
|
||||||
|
The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities.
|
||||||
|
|
||||||
The Foundation FVP can be downloaded free of charge. The Base FVPs can be
|
The Foundation FVP can be downloaded free of charge. The Base FVPs can be
|
||||||
licensed from Arm. See the `Arm FVP website`_.
|
licensed from Arm. See the `Arm FVP website`_.
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A maintainers
|
Maintainers
|
||||||
==============================
|
===========
|
||||||
|
|
||||||
Trusted Firmware-A (TF-A) is an Arm maintained project. All contributions are
|
Trusted Firmware-A (TF-A) is an Arm maintained project. All contributions are
|
||||||
ultimately merged by the maintainers listed below. Technical ownership of some
|
ultimately merged by the maintainers listed below. Technical ownership of some
|
||||||
|
|
|
||||||
|
|
@ -28,7 +28,7 @@ levels 0, 1 and 2 respectively. It does not support any retention states.
|
||||||
We used the upstream `TF master as of 31/01/2017`_, building the platform using
|
We used the upstream `TF master as of 31/01/2017`_, building the platform using
|
||||||
the ``ENABLE_RUNTIME_INSTRUMENTATION`` option:
|
the ``ENABLE_RUNTIME_INSTRUMENTATION`` option:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make PLAT=juno ENABLE_RUNTIME_INSTRUMENTATION=1 \
|
make PLAT=juno ENABLE_RUNTIME_INSTRUMENTATION=1 \
|
||||||
SCP_BL2=<path/to/scp-fw.bin> \
|
SCP_BL2=<path/to/scp-fw.bin> \
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A for Allwinner ARMv8 SoCs
|
Allwinner ARMv8 SoCs
|
||||||
===========================================
|
====================
|
||||||
|
|
||||||
Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Allwinner
|
Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Allwinner
|
||||||
SoCs with ARMv8 cores. Only BL31 is used to provide proper EL3 setup and
|
SoCs with ARMv8 cores. Only BL31 is used to provide proper EL3 setup and
|
||||||
|
|
@ -24,24 +24,23 @@ See the respective `U-Boot documentation`_ for more details.
|
||||||
|
|
||||||
To build for machines with an A64 or H5 SoC:
|
To build for machines with an A64 or H5 SoC:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_a64 DEBUG=1 bl31
|
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_a64 DEBUG=1 bl31
|
||||||
|
|
||||||
To build for machines with an H6 SoC:
|
To build for machines with an H6 SoC:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h6 DEBUG=1 bl31
|
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h6 DEBUG=1 bl31
|
||||||
|
|
||||||
.. _U-Boot documentation: http://git.denx.de/?p=u-boot.git;f=board/sunxi/README.sunxi64;hb=HEAD
|
.. _U-Boot documentation: http://git.denx.de/?p=u-boot.git;f=board/sunxi/README.sunxi64;hb=HEAD
|
||||||
|
|
||||||
Trusted OS dispatcher
|
Trusted OS dispatcher
|
||||||
=====================
|
---------------------
|
||||||
|
|
||||||
One can boot Trusted OS(OP-TEE OS, bl32 image) along side bl31 image on Allwinner A64.
|
One can boot Trusted OS(OP-TEE OS, bl32 image) along side bl31 image on Allwinner A64.
|
||||||
|
|
||||||
In order to include the 'opteed' dispatcher in the image, pass 'SPD=opteed' on the command line
|
In order to include the 'opteed' dispatcher in the image, pass 'SPD=opteed' on the command line
|
||||||
while compiling the bl31 image and make sure the loader (SPL) loads the Trusted OS binary to
|
while compiling the bl31 image and make sure the loader (SPL) loads the Trusted OS binary to
|
||||||
the beginning of DRAM (0x40000000).
|
the beginning of DRAM (0x40000000).
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Description
|
Arm Versatile Express
|
||||||
===========
|
=====================
|
||||||
|
|
||||||
Versatile Express (VE) family development platform provides an
|
Versatile Express (VE) family development platform provides an
|
||||||
ultra fast environment for prototyping arm-v7 System-on-Chip designs.
|
ultra fast environment for prototyping arm-v7 System-on-Chip designs.
|
||||||
|
|
@ -9,21 +9,21 @@ and Cortex-A7 VE FVP's. This platform is tested on and only expected to work
|
||||||
with single core models.
|
with single core models.
|
||||||
|
|
||||||
Boot Sequence
|
Boot Sequence
|
||||||
=============
|
-------------
|
||||||
|
|
||||||
BL1 --> BL2 --> BL32(sp_min) --> BL33(u-boot) --> Linux kernel
|
BL1 --> BL2 --> BL32(sp_min) --> BL33(u-boot) --> Linux kernel
|
||||||
|
|
||||||
How to build
|
How to build
|
||||||
============
|
------------
|
||||||
|
|
||||||
Code Locations
|
Code Locations
|
||||||
---------------
|
~~~~~~~~~~~~~~
|
||||||
- `U-boot <https://git.linaro.org/landing-teams/working/arm/u-boot.git>`__
|
- `U-boot <https://git.linaro.org/landing-teams/working/arm/u-boot.git>`__
|
||||||
|
|
||||||
- `arm-trusted-firmware <https://github.com/ARM-software/arm-trusted-firmware>`__
|
- `arm-trusted-firmware <https://github.com/ARM-software/arm-trusted-firmware>`__
|
||||||
|
|
||||||
Build Procedure
|
Build Procedure
|
||||||
---------------
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Obtain arm toolchain. The software stack has been verified with linaro 6.2
|
- Obtain arm toolchain. The software stack has been verified with linaro 6.2
|
||||||
`arm-linux-gnueabihf <https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/arm-linux-gnueabihf/>`__.
|
`arm-linux-gnueabihf <https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/arm-linux-gnueabihf/>`__.
|
||||||
|
|
@ -68,7 +68,7 @@ Build Procedure
|
||||||
BL33=<path_to_u-boot.bin> all fip
|
BL33=<path_to_u-boot.bin> all fip
|
||||||
|
|
||||||
Run Procedure
|
Run Procedure
|
||||||
-------------
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
The following model parameters should be used to boot Linux using the build of
|
The following model parameters should be used to boot Linux using the build of
|
||||||
arm-trusted-firmware-a made using the above make commands:
|
arm-trusted-firmware-a made using the above make commands:
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Description
|
NXP i.MX 8 Series
|
||||||
===========
|
=================
|
||||||
|
|
||||||
The i.MX 8 series of applications processors is a feature- and
|
The i.MX 8 series of applications processors is a feature- and
|
||||||
performance-scalable multi-core platform that includes single-,
|
performance-scalable multi-core platform that includes single-,
|
||||||
|
|
@ -20,15 +20,15 @@ control for system-level resources on i.MX8. The heart of the system
|
||||||
controller is a Cortex-M4 that executes system controller firmware.
|
controller is a Cortex-M4 that executes system controller firmware.
|
||||||
|
|
||||||
Boot Sequence
|
Boot Sequence
|
||||||
=============
|
-------------
|
||||||
|
|
||||||
Bootrom --> BL31 --> BL33(u-boot) --> Linux kernel
|
Bootrom --> BL31 --> BL33(u-boot) --> Linux kernel
|
||||||
|
|
||||||
How to build
|
How to build
|
||||||
============
|
------------
|
||||||
|
|
||||||
Build Procedure
|
Build Procedure
|
||||||
---------------
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Prepare AARCH64 toolchain.
|
- Prepare AARCH64 toolchain.
|
||||||
|
|
||||||
|
|
@ -46,7 +46,7 @@ Build Procedure
|
||||||
Target_SoC should be "imx8qx" for i.MX8QX SoC.
|
Target_SoC should be "imx8qx" for i.MX8QX SoC.
|
||||||
|
|
||||||
Deploy TF-A Images
|
Deploy TF-A Images
|
||||||
-----------------
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
TF-A binary(bl31.bin), scfw_tcm.bin and u-boot.bin are combined together
|
TF-A binary(bl31.bin), scfw_tcm.bin and u-boot.bin are combined together
|
||||||
to generate a binary file called flash.bin, the imx-mkimage tool is used
|
to generate a binary file called flash.bin, the imx-mkimage tool is used
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Description
|
NXP i.MX 8M Series
|
||||||
===========
|
==================
|
||||||
|
|
||||||
The i.MX 8M family of applications processors based on Arm Corte-A53 and Cortex-M4
|
The i.MX 8M family of applications processors based on Arm Corte-A53 and Cortex-M4
|
||||||
cores provide high-performance computing, power efficiency, enhanced system
|
cores provide high-performance computing, power efficiency, enhanced system
|
||||||
|
|
@ -7,15 +7,15 @@ reliability and embedded security needed to drive the growth of fast-growing
|
||||||
edge node computing, streaming multimedia, and machine learning applications.
|
edge node computing, streaming multimedia, and machine learning applications.
|
||||||
|
|
||||||
Boot Sequence
|
Boot Sequence
|
||||||
=============
|
-------------
|
||||||
|
|
||||||
Bootrom --> SPL --> BL31 --> BL33(u-boot) --> Linux kernel
|
Bootrom --> SPL --> BL31 --> BL33(u-boot) --> Linux kernel
|
||||||
|
|
||||||
How to build
|
How to build
|
||||||
============
|
------------
|
||||||
|
|
||||||
Build Procedure
|
Build Procedure
|
||||||
---------------
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Prepare AARCH64 toolchain.
|
- Prepare AARCH64 toolchain.
|
||||||
|
|
||||||
|
|
@ -34,7 +34,7 @@ Build Procedure
|
||||||
Target_SoC should be "imx8mm" for i.MX8MM SoC.
|
Target_SoC should be "imx8mm" for i.MX8MM SoC.
|
||||||
|
|
||||||
Deploy TF-A Images
|
Deploy TF-A Images
|
||||||
-----------------
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
TF-A binary(bl31.bin), u-boot-spl.bin u-boot-nodtb.bin and dtb are combined
|
TF-A binary(bl31.bin), u-boot-spl.bin u-boot-nodtb.bin and dtb are combined
|
||||||
together to generate a binary file called flash.bin, the imx-mkimage tool is
|
together to generate a binary file called flash.bin, the imx-mkimage tool is
|
||||||
|
|
|
||||||
|
|
@ -16,7 +16,6 @@ Platform Ports
|
||||||
meson-gxl
|
meson-gxl
|
||||||
mt8183
|
mt8183
|
||||||
nvidia-tegra
|
nvidia-tegra
|
||||||
poplar
|
|
||||||
qemu
|
qemu
|
||||||
rcar-gen3
|
rcar-gen3
|
||||||
rockchip
|
rockchip
|
||||||
|
|
@ -26,4 +25,5 @@ Platform Ports
|
||||||
synquacer
|
synquacer
|
||||||
ti-k3
|
ti-k3
|
||||||
warp7
|
warp7
|
||||||
|
xilinx-versal
|
||||||
xilinx-zynqmp
|
xilinx-zynqmp
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Description
|
Intel Stratix 10 SoCFPGA
|
||||||
===========
|
========================
|
||||||
|
|
||||||
Stratix 10 SoCFPGA is a FPGA with integrated quad-core 64-bit Arm Cortex A53 processor.
|
Stratix 10 SoCFPGA is a FPGA with integrated quad-core 64-bit Arm Cortex A53 processor.
|
||||||
|
|
||||||
|
|
@ -11,10 +11,10 @@ the hardware, then loads bl31 and bl33 (UEFI) into DDR and boots to bl33.
|
||||||
Boot ROM --> Trusted Firmware-A --> UEFI
|
Boot ROM --> Trusted Firmware-A --> UEFI
|
||||||
|
|
||||||
How to build
|
How to build
|
||||||
============
|
------------
|
||||||
|
|
||||||
Code Locations
|
Code Locations
|
||||||
--------------
|
~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Trusted Firmware-A:
|
- Trusted Firmware-A:
|
||||||
`link <https://github.com/ARM-software/arm-trusted-firmware>`__
|
`link <https://github.com/ARM-software/arm-trusted-firmware>`__
|
||||||
|
|
@ -23,7 +23,7 @@ Code Locations
|
||||||
`link <https://github.com/altera-opensource/uefi-socfpga>`__
|
`link <https://github.com/altera-opensource/uefi-socfpga>`__
|
||||||
|
|
||||||
Build Procedure
|
Build Procedure
|
||||||
---------------
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Fetch all the above 2 repositories into local host.
|
- Fetch all the above 2 repositories into local host.
|
||||||
Make all the repositories in the same ${BUILD\_PATH}.
|
Make all the repositories in the same ${BUILD\_PATH}.
|
||||||
|
|
@ -45,7 +45,7 @@ Build Procedure
|
||||||
BL33=PEI.ROM
|
BL33=PEI.ROM
|
||||||
|
|
||||||
Install Procedure
|
Install Procedure
|
||||||
-----------------
|
~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- dd fip.bin to a A2 partition on the MMC drive to be booted in Stratix 10
|
- dd fip.bin to a A2 partition on the MMC drive to be booted in Stratix 10
|
||||||
board.
|
board.
|
||||||
|
|
@ -53,16 +53,18 @@ Install Procedure
|
||||||
- Generate a SOF containing bl2
|
- Generate a SOF containing bl2
|
||||||
|
|
||||||
.. code:: bash
|
.. code:: bash
|
||||||
|
|
||||||
aarch64-linux-gnu-objcopy -I binary -O ihex --change-addresses 0xffe00000 bl2.bin bl2.hex
|
aarch64-linux-gnu-objcopy -I binary -O ihex --change-addresses 0xffe00000 bl2.bin bl2.hex
|
||||||
quartus_cpf --bootloader bl2.hex <quartus_generated_sof> <output_sof_with_bl2>
|
quartus_cpf --bootloader bl2.hex <quartus_generated_sof> <output_sof_with_bl2>
|
||||||
|
|
||||||
- Configure SOF to board
|
- Configure SOF to board
|
||||||
|
|
||||||
.. code:: bash
|
.. code:: bash
|
||||||
|
|
||||||
nios2-configure-sof <output_sof_with_bl2>
|
nios2-configure-sof <output_sof_with_bl2>
|
||||||
|
|
||||||
Boot trace
|
Boot trace
|
||||||
==========
|
----------
|
||||||
|
|
||||||
::
|
::
|
||||||
INFO: DDR: DRAM calibration success.
|
INFO: DDR: DRAM calibration success.
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Description
|
NXP QorIQ® LS1043A
|
||||||
===========
|
==================
|
||||||
|
|
||||||
The QorIQ® LS1043A processor is NXP's first quad-core, 64-bit Arm®-based
|
The QorIQ® LS1043A processor is NXP's first quad-core, 64-bit Arm®-based
|
||||||
processor for embedded networking. The LS1023A (two core version) and the
|
processor for embedded networking. The LS1023A (two core version) and the
|
||||||
|
|
@ -36,7 +36,7 @@ UART: supports two UARTs up to 115200 bps for console
|
||||||
More information are listed in `ls1043`_.
|
More information are listed in `ls1043`_.
|
||||||
|
|
||||||
Boot Sequence
|
Boot Sequence
|
||||||
=============
|
-------------
|
||||||
|
|
||||||
|
|
||||||
Bootrom --> TF-A BL1 --> TF-A BL2 --> TF-A BL1 --> TF-A BL31
|
Bootrom --> TF-A BL1 --> TF-A BL2 --> TF-A BL1 --> TF-A BL31
|
||||||
|
|
@ -44,10 +44,10 @@ Bootrom --> TF-A BL1 --> TF-A BL2 --> TF-A BL1 --> TF-A BL31
|
||||||
|
|
||||||
|
|
||||||
How to build
|
How to build
|
||||||
============
|
------------
|
||||||
|
|
||||||
Build Procedure
|
Build Procedure
|
||||||
---------------
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Prepare AARCH64 toolchain.
|
- Prepare AARCH64 toolchain.
|
||||||
|
|
||||||
|
|
@ -69,7 +69,7 @@ Build Procedure
|
||||||
BL33=u-boot.bin NEED_BL32=yes BL32=tee.bin SPD=opteed
|
BL33=u-boot.bin NEED_BL32=yes BL32=tee.bin SPD=opteed
|
||||||
|
|
||||||
Deploy TF-A Images
|
Deploy TF-A Images
|
||||||
-----------------
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Deploy TF-A images on Nor flash Alt Bank.
|
- Deploy TF-A images on Nor flash Alt Bank.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A for Amlogic Meson S905 (GXBB)
|
Amlogic Meson S905 (GXBB)
|
||||||
================================================
|
=========================
|
||||||
|
|
||||||
The Amlogic Meson S905 is a SoC with a quad core Arm Cortex-A53 running at
|
The Amlogic Meson S905 is a SoC with a quad core Arm Cortex-A53 running at
|
||||||
1.5Ghz. It also contains a Cortex-M3 used as SCP.
|
1.5Ghz. It also contains a Cortex-M3 used as SCP.
|
||||||
|
|
@ -15,7 +15,7 @@ and Linux:
|
||||||
|
|
||||||
In order to build it:
|
In order to build it:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
CROSS_COMPILE=aarch64-linux-gnu- make DEBUG=1 PLAT=gxbb bl31
|
CROSS_COMPILE=aarch64-linux-gnu- make DEBUG=1 PLAT=gxbb bl31
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A for Amlogic Meson S905x (GXL)
|
Amlogic Meson S905x (GXL)
|
||||||
================================================
|
=========================
|
||||||
|
|
||||||
The Amlogic Meson S905x is a SoC with a quad core Arm Cortex-A53 running at
|
The Amlogic Meson S905x is a SoC with a quad core Arm Cortex-A53 running at
|
||||||
1.5Ghz. It also contains a Cortex-M3 used as SCP.
|
1.5Ghz. It also contains a Cortex-M3 used as SCP.
|
||||||
|
|
@ -15,7 +15,7 @@ and Linux:
|
||||||
|
|
||||||
In order to build it:
|
In order to build it:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
CROSS_COMPILE=aarch64-linux-gnu- make DEBUG=1 PLAT=gxl
|
CROSS_COMPILE=aarch64-linux-gnu- make DEBUG=1 PLAT=gxl
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,19 +1,19 @@
|
||||||
Description
|
MediaTek 8183
|
||||||
===========
|
=============
|
||||||
|
|
||||||
MediaTek 8183 (MT8183) is a 64-bit ARM SoC introduced by MediaTek in early 2018.
|
MediaTek 8183 (MT8183) is a 64-bit ARM SoC introduced by MediaTek in early 2018.
|
||||||
The chip incorporates eight cores - four Cortex-A53 little cores and Cortex-A73.
|
The chip incorporates eight cores - four Cortex-A53 little cores and Cortex-A73.
|
||||||
Both clusters can operate at up to 2 GHz.
|
Both clusters can operate at up to 2 GHz.
|
||||||
|
|
||||||
Boot Sequence
|
Boot Sequence
|
||||||
=============
|
-------------
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
Boot Rom --> Coreboot --> TF-A BL31 --> Depthcharge --> Linux Kernel
|
Boot Rom --> Coreboot --> TF-A BL31 --> Depthcharge --> Linux Kernel
|
||||||
|
|
||||||
How to Build
|
How to Build
|
||||||
============
|
------------
|
||||||
|
|
||||||
.. code:: shell
|
.. code:: shell
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Tegra SoCs - Overview
|
NVIDIA Tegra
|
||||||
=====================
|
============
|
||||||
|
|
||||||
- .. rubric:: T186
|
- .. rubric:: T186
|
||||||
:name: t186
|
:name: t186
|
||||||
|
|
@ -58,13 +58,13 @@ to extensive power-gating and dynamic voltage and clock scaling based on
|
||||||
workloads.
|
workloads.
|
||||||
|
|
||||||
Directory structure
|
Directory structure
|
||||||
===================
|
-------------------
|
||||||
|
|
||||||
- plat/nvidia/tegra/common - Common code for all Tegra SoCs
|
- plat/nvidia/tegra/common - Common code for all Tegra SoCs
|
||||||
- plat/nvidia/tegra/soc/txxx - Chip specific code
|
- plat/nvidia/tegra/soc/txxx - Chip specific code
|
||||||
|
|
||||||
Trusted OS dispatcher
|
Trusted OS dispatcher
|
||||||
=====================
|
---------------------
|
||||||
|
|
||||||
Tegra supports multiple Trusted OS'.
|
Tegra supports multiple Trusted OS'.
|
||||||
|
|
||||||
|
|
@ -83,7 +83,7 @@ Tegra210: TLK and Trusty
|
||||||
Tegra186: Trusty
|
Tegra186: Trusty
|
||||||
|
|
||||||
Scatter files
|
Scatter files
|
||||||
=============
|
-------------
|
||||||
|
|
||||||
Tegra platforms currently support scatter files and ld.S scripts. The scatter
|
Tegra platforms currently support scatter files and ld.S scripts. The scatter
|
||||||
files help support ARMLINK linker to generate BL31 binaries. For now, there
|
files help support ARMLINK linker to generate BL31 binaries. For now, there
|
||||||
|
|
@ -93,7 +93,7 @@ the scatter file to be used. Tegra platforms have verified BL31 image generation
|
||||||
with ARMCLANG (compilation) and ARMLINK (linking) for the Tegra186 platforms.
|
with ARMCLANG (compilation) and ARMLINK (linking) for the Tegra186 platforms.
|
||||||
|
|
||||||
Preparing the BL31 image to run on Tegra SoCs
|
Preparing the BL31 image to run on Tegra SoCs
|
||||||
=============================================
|
---------------------------------------------
|
||||||
|
|
||||||
.. code:: shell
|
.. code:: shell
|
||||||
|
|
||||||
|
|
@ -125,7 +125,7 @@ uint64\_t boot\_profiler\_shmem\_base;
|
||||||
} plat\_params\_from\_bl2\_t;
|
} plat\_params\_from\_bl2\_t;
|
||||||
|
|
||||||
Power Management
|
Power Management
|
||||||
================
|
----------------
|
||||||
|
|
||||||
The PSCI implementation expects each platform to expose the 'power state'
|
The PSCI implementation expects each platform to expose the 'power state'
|
||||||
parameter to be used during the 'SYSTEM SUSPEND' call. The state-id field
|
parameter to be used during the 'SYSTEM SUSPEND' call. The state-id field
|
||||||
|
|
@ -133,7 +133,7 @@ is implementation defined on Tegra SoCs and is preferably defined by
|
||||||
tegra\_def.h.
|
tegra\_def.h.
|
||||||
|
|
||||||
Tegra configs
|
Tegra configs
|
||||||
=============
|
-------------
|
||||||
|
|
||||||
- 'tegra\_enable\_l2\_ecc\_parity\_prot': This flag enables the L2 ECC and Parity
|
- 'tegra\_enable\_l2\_ecc\_parity\_prot': This flag enables the L2 ECC and Parity
|
||||||
Protection bit, for Arm Cortex-A57 CPUs, during CPU boot. This flag will
|
Protection bit, for Arm Cortex-A57 CPUs, during CPU boot. This flag will
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A for QEMU virt Armv8-A
|
QEMU virt Armv8-A
|
||||||
========================================
|
=================
|
||||||
|
|
||||||
Trusted Firmware-A (TF-A) implements the EL3 firmware layer for QEMU virt
|
Trusted Firmware-A (TF-A) implements the EL3 firmware layer for QEMU virt
|
||||||
Armv8-A. BL1 is used as the BootROM, supplied with the -bios argument.
|
Armv8-A. BL1 is used as the BootROM, supplied with the -bios argument.
|
||||||
|
|
@ -33,13 +33,13 @@ is conveniently achieved with symlinks the local names as:
|
||||||
|
|
||||||
To build:
|
To build:
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
make CROSS_COMPILE=aarch64-none-elf- PLAT=qemu
|
make CROSS_COMPILE=aarch64-none-elf- PLAT=qemu
|
||||||
|
|
||||||
To start (QEMU v2.6.0):
|
To start (QEMU v2.6.0):
|
||||||
|
|
||||||
::
|
.. code:: shell
|
||||||
|
|
||||||
qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a57 \
|
qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a57 \
|
||||||
-kernel Image \
|
-kernel Image \
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Description
|
Renesas R-Car
|
||||||
===========
|
=============
|
||||||
|
|
||||||
"R-Car" is the nickname for Renesas' system-on-chip (SoC) family for
|
"R-Car" is the nickname for Renesas' system-on-chip (SoC) family for
|
||||||
car information systems designed for the next-generation of automotive
|
car information systems designed for the next-generation of automotive
|
||||||
|
|
@ -97,14 +97,14 @@ program counters.
|
||||||
|
|
||||||
|
|
||||||
How to build
|
How to build
|
||||||
============
|
------------
|
||||||
|
|
||||||
The TF-A build options depend on the target board so you will have to
|
The TF-A build options depend on the target board so you will have to
|
||||||
refer to those specific instructions. What follows is customized to
|
refer to those specific instructions. What follows is customized to
|
||||||
the H3 SiP Salvator-X development system used in this port.
|
the H3 SiP Salvator-X development system used in this port.
|
||||||
|
|
||||||
Build Tested:
|
Build Tested:
|
||||||
-------------
|
~~~~~~~~~~~~~
|
||||||
RCAR_OPT="LSI=H3 RCAR_DRAM_SPLIT=1 RCAR_LOSSY_ENABLE=1"
|
RCAR_OPT="LSI=H3 RCAR_DRAM_SPLIT=1 RCAR_LOSSY_ENABLE=1"
|
||||||
MBEDTLS_DIR=$mbedtls_src
|
MBEDTLS_DIR=$mbedtls_src
|
||||||
|
|
||||||
|
|
@ -112,7 +112,7 @@ $ MBEDTLS_DIR=$mbedtls_src_tree make clean bl2 bl31 rcar_layout_tool \
|
||||||
PLAT=rcar ${RCAR_OPT} SPD=opteed
|
PLAT=rcar ${RCAR_OPT} SPD=opteed
|
||||||
|
|
||||||
System Tested:
|
System Tested:
|
||||||
--------------------
|
~~~~~~~~~~~~~~
|
||||||
* mbed_tls:
|
* mbed_tls:
|
||||||
git@github.com:ARMmbed/mbedtls.git [devel]
|
git@github.com:ARMmbed/mbedtls.git [devel]
|
||||||
|
|
||||||
|
|
@ -150,7 +150,7 @@ System Tested:
|
||||||
Linux 4.19-rc4
|
Linux 4.19-rc4
|
||||||
|
|
||||||
TF-A Build Procedure
|
TF-A Build Procedure
|
||||||
--------------------
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Fetch all the above 4 repositories.
|
- Fetch all the above 4 repositories.
|
||||||
|
|
||||||
|
|
@ -184,7 +184,7 @@ TF-A Build Procedure
|
||||||
make -j8 PLATFORM="rcar" CFG_ARM64_core=y
|
make -j8 PLATFORM="rcar" CFG_ARM64_core=y
|
||||||
|
|
||||||
Install Procedure
|
Install Procedure
|
||||||
-----------------
|
~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Boot the board in Mini-monitor mode and enable access to the
|
- Boot the board in Mini-monitor mode and enable access to the
|
||||||
Hyperflash.
|
Hyperflash.
|
||||||
|
|
@ -195,7 +195,7 @@ Install Procedure
|
||||||
|
|
||||||
|
|
||||||
Boot trace
|
Boot trace
|
||||||
==========
|
----------
|
||||||
|
|
||||||
Notice that BL31 traces are not accessible via the console and that in
|
Notice that BL31 traces are not accessible via the console and that in
|
||||||
order to verbose the BL2 output you will have to compile TF-A with
|
order to verbose the BL2 output you will have to compile TF-A with
|
||||||
|
|
@ -266,4 +266,3 @@ LOG_LEVEL=50 and DEBUG=1
|
||||||
Net: eth0: ethernet@e6800000
|
Net: eth0: ethernet@e6800000
|
||||||
Hit any key to stop autoboot: 0
|
Hit any key to stop autoboot: 0
|
||||||
=>
|
=>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A for Rockchip SoCs
|
Rockchip SoCs
|
||||||
====================================
|
=============
|
||||||
|
|
||||||
Trusted Firmware-A supports a number of Rockchip ARM SoCs from both
|
Trusted Firmware-A supports a number of Rockchip ARM SoCs from both
|
||||||
AARCH32 and AARCH64 fields.
|
AARCH32 and AARCH64 fields.
|
||||||
|
|
@ -12,7 +12,7 @@ This includes right now:
|
||||||
|
|
||||||
|
|
||||||
Boot Sequence
|
Boot Sequence
|
||||||
=============
|
-------------
|
||||||
|
|
||||||
For AARCH32:
|
For AARCH32:
|
||||||
Bootrom --> BL1/BL2 --> BL32 --> BL33 --> Linux kernel
|
Bootrom --> BL1/BL2 --> BL32 --> BL33 --> Linux kernel
|
||||||
|
|
@ -26,7 +26,7 @@ BL1/2 and BL33 can currently be supplied from either:
|
||||||
|
|
||||||
|
|
||||||
How to build
|
How to build
|
||||||
============
|
------------
|
||||||
|
|
||||||
Rockchip SoCs expect TF-A's BL31 (AARCH64) or BL32 (AARCH32) to get
|
Rockchip SoCs expect TF-A's BL31 (AARCH64) or BL32 (AARCH32) to get
|
||||||
integrated with other boot software like U-Boot or Coreboot, so only
|
integrated with other boot software like U-Boot or Coreboot, so only
|
||||||
|
|
@ -46,7 +46,7 @@ compilation toolchain.
|
||||||
|
|
||||||
|
|
||||||
How to deploy
|
How to deploy
|
||||||
=============
|
-------------
|
||||||
|
|
||||||
Both upstream U-Boot and Coreboot projects contain instructions on where
|
Both upstream U-Boot and Coreboot projects contain instructions on where
|
||||||
to put the built images during their respective build process.
|
to put the built images during their respective build process.
|
||||||
|
|
|
||||||
|
|
@ -1,9 +1,5 @@
|
||||||
Trusted Firmware-A for Raspberry Pi 3
|
Raspberry Pi 3
|
||||||
=====================================
|
==============
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
The `Raspberry Pi 3`_ is an inexpensive single-board computer that contains four
|
The `Raspberry Pi 3`_ is an inexpensive single-board computer that contains four
|
||||||
Arm Cortex-A53 cores.
|
Arm Cortex-A53 cores.
|
||||||
|
|
@ -167,7 +163,7 @@ Secondary cores
|
||||||
~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
This port of the Trusted Firmware-A supports ``PSCI_CPU_ON``,
|
This port of the Trusted Firmware-A supports ``PSCI_CPU_ON``,
|
||||||
`PSCI_SYSTEM_RESET`` and ``PSCI_SYSTEM_OFF``. The last one doesn't really turn
|
``PSCI_SYSTEM_RESET`` and ``PSCI_SYSTEM_OFF``. The last one doesn't really turn
|
||||||
the system off, it simply reboots it and asks the VideoCore firmware to keep it
|
the system off, it simply reboots it and asks the VideoCore firmware to keep it
|
||||||
in a low power mode permanently.
|
in a low power mode permanently.
|
||||||
|
|
||||||
|
|
@ -274,11 +270,12 @@ The following build options are supported:
|
||||||
BL32_EXTRA1=tee-pager_v2.bin BL32_EXTRA2=tee-pageable_v2.bin``
|
BL32_EXTRA1=tee-pager_v2.bin BL32_EXTRA2=tee-pageable_v2.bin``
|
||||||
to put the binaries into the FIP.
|
to put the binaries into the FIP.
|
||||||
|
|
||||||
Note: If OP-TEE is used it may be needed to add the following options to the
|
.. warning::
|
||||||
Linux command line so that the USB driver doesn't use FIQs:
|
If OP-TEE is used it may be needed to add the following options to the
|
||||||
``dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0 dwc_otg.nak_holdoff=0``.
|
Linux command line so that the USB driver doesn't use FIQs:
|
||||||
This will unfortunately reduce the performance of the USB driver. It is needed
|
``dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0 dwc_otg.nak_holdoff=0``.
|
||||||
when using Raspbian, for example.
|
This will unfortunately reduce the performance of the USB driver. It is
|
||||||
|
needed when using Raspbian, for example.
|
||||||
|
|
||||||
- ``TRUSTED_BOARD_BOOT``: This port supports TBB. Set this option to 1 to enable
|
- ``TRUSTED_BOARD_BOOT``: This port supports TBB. Set this option to 1 to enable
|
||||||
it. In order to use TBB, you might want to set ``GENERATE_COT=1`` to let the
|
it. In order to use TBB, you might want to set ``GENERATE_COT=1`` to let the
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,5 @@
|
||||||
Trusted Firmware-A for Socionext UniPhier SoCs
|
Socionext UniPhier
|
||||||
==============================================
|
==================
|
||||||
|
|
||||||
|
|
||||||
Socionext UniPhier Armv8-A SoCs use Trusted Firmware-A (TF-A) as the secure
|
Socionext UniPhier Armv8-A SoCs use Trusted Firmware-A (TF-A) as the secure
|
||||||
world firmware, supporting BL2 and BL31.
|
world firmware, supporting BL2 and BL31.
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A for STM32MP1
|
STMicroelectronics STM32MP1
|
||||||
===============================
|
===========================
|
||||||
|
|
||||||
STM32MP1 is a microprocessor designed by STMicroelectronics
|
STM32MP1 is a microprocessor designed by STMicroelectronics
|
||||||
based on a dual Arm Cortex-A7.
|
based on a dual Arm Cortex-A7.
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A for Socionext Synquacer SoCs
|
Socionext Synquacer
|
||||||
===============================================
|
===================
|
||||||
|
|
||||||
Socionext's Synquacer SC2A11 is a multi-core processor with 24 cores of Arm
|
Socionext's Synquacer SC2A11 is a multi-core processor with 24 cores of Arm
|
||||||
Cortex-A53. The Developerbox, of 96boards, is a platform that contains this
|
Cortex-A53. The Developerbox, of 96boards, is a platform that contains this
|
||||||
|
|
@ -9,10 +9,10 @@ the moment.
|
||||||
More information are listed in `link`_.
|
More information are listed in `link`_.
|
||||||
|
|
||||||
How to build
|
How to build
|
||||||
============
|
------------
|
||||||
|
|
||||||
Code Locations
|
Code Locations
|
||||||
--------------
|
~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Trusted Firmware-A:
|
- Trusted Firmware-A:
|
||||||
`link <https://github.com/ARM-software/arm-trusted-firmware>`__
|
`link <https://github.com/ARM-software/arm-trusted-firmware>`__
|
||||||
|
|
@ -27,12 +27,12 @@ Code Locations
|
||||||
`link <https://github.com/tianocore/edk2-non-osi>`__
|
`link <https://github.com/tianocore/edk2-non-osi>`__
|
||||||
|
|
||||||
Boot Flow
|
Boot Flow
|
||||||
---------
|
~~~~~~~~~
|
||||||
|
|
||||||
SCP firmware --> TF-A BL31 --> UEFI(edk2)
|
SCP firmware --> TF-A BL31 --> UEFI(edk2)
|
||||||
|
|
||||||
Build Procedure
|
Build Procedure
|
||||||
---------------
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Firstly, in addition to the “normal” build tools you will also need a
|
- Firstly, in addition to the “normal” build tools you will also need a
|
||||||
few specialist tools. On a Debian or Ubuntu operating system try:
|
few specialist tools. On a Debian or Ubuntu operating system try:
|
||||||
|
|
@ -98,7 +98,7 @@ Build Procedure
|
||||||
Note #2: Replace -b RELEASE with -b DEBUG to build a debug.
|
Note #2: Replace -b RELEASE with -b DEBUG to build a debug.
|
||||||
|
|
||||||
Install the System Firmware
|
Install the System Firmware
|
||||||
---------------------------
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
- Providing your Developerbox is fully working and has on operating system
|
- Providing your Developerbox is fully working and has on operating system
|
||||||
installed then you can adopt your the newly compiled system firmware using
|
installed then you can adopt your the newly compiled system firmware using
|
||||||
|
|
|
||||||
|
|
@ -1,15 +1,17 @@
|
||||||
Trusted Firmware-A for Texas Instruments K3 SoCs
|
Texas Instruments K3
|
||||||
================================================
|
====================
|
||||||
|
|
||||||
Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Texas Instruments K3 SoCs.
|
Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Texas Instruments K3 SoCs.
|
||||||
|
|
||||||
Boot Flow
|
Boot Flow
|
||||||
---------
|
---------
|
||||||
|
|
||||||
R5(U-Boot) --> TF-A BL31 --> BL32(OP-TEE) --> TF-A BL31 --> BL33(U-Boot) --> Linux
|
::
|
||||||
|
|
||||||
|
R5(U-Boot) --> TF-A BL31 --> BL32(OP-TEE) --> TF-A BL31 --> BL33(U-Boot) --> Linux
|
||||||
\
|
\
|
||||||
Optional direct to Linux boot
|
Optional direct to Linux boot
|
||||||
\
|
\
|
||||||
--> BL33(Linux)
|
--> BL33(Linux)
|
||||||
|
|
||||||
Texas Instruments K3 SoCs contain an R5 processor used as the boot master, it
|
Texas Instruments K3 SoCs contain an R5 processor used as the boot master, it
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A for i.MX7 WaRP7
|
NXP i.MX7 WaRP7
|
||||||
==================================
|
===============
|
||||||
|
|
||||||
The Trusted Firmware-A port for the i.MX7Solo WaRP7 implements BL2 at EL3.
|
The Trusted Firmware-A port for the i.MX7Solo WaRP7 implements BL2 at EL3.
|
||||||
The i.MX7S contains a BootROM with a High Assurance Boot (HAB) functionality.
|
The i.MX7S contains a BootROM with a High Assurance Boot (HAB) functionality.
|
||||||
|
|
@ -7,21 +7,23 @@ This functionality provides a mechanism for establishing a root-of-trust from
|
||||||
the reset vector to the command-line in user-space.
|
the reset vector to the command-line in user-space.
|
||||||
|
|
||||||
Boot Flow
|
Boot Flow
|
||||||
=========
|
---------
|
||||||
|
|
||||||
BootROM --> TF-A BL2 --> BL32(OP-TEE) --> BL33(U-Boot) --> Linux
|
BootROM --> TF-A BL2 --> BL32(OP-TEE) --> BL33(U-Boot) --> Linux
|
||||||
|
|
||||||
In the WaRP7 port we encapsulate OP-TEE, DTB and U-Boot into a FIP. This FIP is
|
In the WaRP7 port we encapsulate OP-TEE, DTB and U-Boot into a FIP. This FIP is
|
||||||
expected and required
|
expected and required
|
||||||
|
|
||||||
# Build Instructions
|
Build Instructions
|
||||||
|
------------------
|
||||||
|
|
||||||
We need to use a file generated by u-boot in order to generate a .imx image the
|
We need to use a file generated by u-boot in order to generate a .imx image the
|
||||||
BootROM will boot. It is therefore _required_ to build u-boot before TF-A and
|
BootROM will boot. It is therefore _required_ to build u-boot before TF-A and
|
||||||
furthermore it is _recommended_ to use the mkimage in the u-boot/tools directory
|
furthermore it is _recommended_ to use the mkimage in the u-boot/tools directory
|
||||||
to generate the TF-A .imx image.
|
to generate the TF-A .imx image.
|
||||||
|
|
||||||
## U-Boot:
|
U-Boot
|
||||||
|
~~~~~~
|
||||||
|
|
||||||
https://git.linaro.org/landing-teams/working/mbl/u-boot.git
|
https://git.linaro.org/landing-teams/working/mbl/u-boot.git
|
||||||
|
|
||||||
|
|
@ -31,7 +33,8 @@ https://git.linaro.org/landing-teams/working/mbl/u-boot.git
|
||||||
make warp7_bl33_defconfig;
|
make warp7_bl33_defconfig;
|
||||||
make u-boot.imx arch=ARM CROSS_COMPILE=arm-linux-gnueabihf-
|
make u-boot.imx arch=ARM CROSS_COMPILE=arm-linux-gnueabihf-
|
||||||
|
|
||||||
## OP-TEE:
|
OP-TEE
|
||||||
|
~~~~~~
|
||||||
|
|
||||||
https://github.com/OP-TEE/optee_os.git
|
https://github.com/OP-TEE/optee_os.git
|
||||||
|
|
||||||
|
|
@ -39,7 +42,8 @@ https://github.com/OP-TEE/optee_os.git
|
||||||
|
|
||||||
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- PLATFORM=imx PLATFORM_FLAVOR=mx7swarp7 ARCH=arm CFG_PAGEABLE_ADDR=0 CFG_DT_ADDR=0x83000000 CFG_NS_ENTRY_ADDR=0x87800000
|
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- PLATFORM=imx PLATFORM_FLAVOR=mx7swarp7 ARCH=arm CFG_PAGEABLE_ADDR=0 CFG_DT_ADDR=0x83000000 CFG_NS_ENTRY_ADDR=0x87800000
|
||||||
|
|
||||||
## TF-A:
|
TF-A
|
||||||
|
~~~~
|
||||||
|
|
||||||
https://github.com/ARM-software/arm-trusted-firmware.git
|
https://github.com/ARM-software/arm-trusted-firmware.git
|
||||||
|
|
||||||
|
|
@ -75,7 +79,8 @@ It is also assumed copy of mbedtls is available on the path path ../mbedtls
|
||||||
|
|
||||||
/path/to/u-boot/tools/mkimage -n /path/to/u-boot/u-boot.cfgout -T imximage -e 0x9df00000 -d ./build/warp7/debug/bl2.bin ./build/warp7/debug/bl2.bin.imx
|
/path/to/u-boot/tools/mkimage -n /path/to/u-boot/u-boot.cfgout -T imximage -e 0x9df00000 -d ./build/warp7/debug/bl2.bin ./build/warp7/debug/bl2.bin.imx
|
||||||
|
|
||||||
## FIP:
|
FIP
|
||||||
|
~~~
|
||||||
|
|
||||||
.. code:: shell
|
.. code:: shell
|
||||||
|
|
||||||
|
|
@ -110,8 +115,8 @@ It is also assumed copy of mbedtls is available on the path path ../mbedtls
|
||||||
--trusted-key-cert fiptool_images/trusted-key-cert.key-crt \
|
--trusted-key-cert fiptool_images/trusted-key-cert.key-crt \
|
||||||
--tb-fw-cert fiptool_images/trusted-boot-fw.key-crt warp7.fip
|
--tb-fw-cert fiptool_images/trusted-boot-fw.key-crt warp7.fip
|
||||||
|
|
||||||
# Deploy Images
|
Deploy Images
|
||||||
|
-------------
|
||||||
|
|
||||||
First place the WaRP7 into UMS mode in u-boot this should produce an entry in
|
First place the WaRP7 into UMS mode in u-boot this should produce an entry in
|
||||||
/dev like /dev/disk/by-id/usb-Linux_UMS_disk_0_WaRP7-0xf42400d3000001d4-0\:0
|
/dev like /dev/disk/by-id/usb-Linux_UMS_disk_0_WaRP7-0xf42400d3000001d4-0\:0
|
||||||
|
|
@ -138,7 +143,8 @@ Remember to umount the USB device pefore proceeding
|
||||||
sudo umount /dev/disk/by-id/usb-Linux_UMS_disk_0_WaRP7-0xf42400d3000001d4-0\:0*
|
sudo umount /dev/disk/by-id/usb-Linux_UMS_disk_0_WaRP7-0xf42400d3000001d4-0\:0*
|
||||||
|
|
||||||
|
|
||||||
# Signing BL2
|
Signing BL2
|
||||||
|
-----------
|
||||||
|
|
||||||
A further step is to sign BL2.
|
A further step is to sign BL2.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A for Xilinx Versal
|
Xilinx Versal
|
||||||
================================
|
=============
|
||||||
|
|
||||||
Trusted Firmware-A implements the EL3 firmware layer for Xilinx Versal.
|
Trusted Firmware-A implements the EL3 firmware layer for Xilinx Versal.
|
||||||
The platform only uses the runtime part of TF-A as Xilinx Versal already has a
|
The platform only uses the runtime part of TF-A as Xilinx Versal already has a
|
||||||
|
|
@ -19,7 +19,9 @@ To build ATF for different platform (for now its just versal virtual "versal_vir
|
||||||
make RESET_TO_BL31=1 CROSS_COMPILE=aarch64-none-elf- PLAT=versal VERSAL_PLATFORM=versal_virt bl31
|
make RESET_TO_BL31=1 CROSS_COMPILE=aarch64-none-elf- PLAT=versal VERSAL_PLATFORM=versal_virt bl31
|
||||||
```
|
```
|
||||||
|
|
||||||
# Xilinx Versal platform specific build options
|
Xilinx Versal platform specific build options
|
||||||
|
---------------------------------------------
|
||||||
|
|
||||||
* `VERSAL_ATF_MEM_BASE`: Specifies the base address of the bl31 binary.
|
* `VERSAL_ATF_MEM_BASE`: Specifies the base address of the bl31 binary.
|
||||||
* `VERSAL_ATF_MEM_SIZE`: Specifies the size of the memory region of the bl31 binary.
|
* `VERSAL_ATF_MEM_SIZE`: Specifies the size of the memory region of the bl31 binary.
|
||||||
* `VERSAL_BL32_MEM_BASE`: Specifies the base address of the bl32 binary.
|
* `VERSAL_BL32_MEM_BASE`: Specifies the base address of the bl32 binary.
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Trusted Firmware-A for Xilinx Zynq UltraScale+ MPSoC
|
Xilinx Zynq UltraScale+ MPSoC
|
||||||
====================================================
|
=============================
|
||||||
|
|
||||||
Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Xilinx Zynq
|
Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Xilinx Zynq
|
||||||
UltraScale + MPSoC.
|
UltraScale + MPSoC.
|
||||||
|
|
@ -23,7 +23,7 @@ To build bl32 TSP you have to rebuild bl31 too:
|
||||||
make CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp SPD=tspd bl31 bl32
|
make CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp SPD=tspd bl31 bl32
|
||||||
|
|
||||||
ZynqMP platform specific build options
|
ZynqMP platform specific build options
|
||||||
======================================
|
--------------------------------------
|
||||||
|
|
||||||
- ``ZYNQMP_ATF_MEM_BASE``: Specifies the base address of the bl31 binary.
|
- ``ZYNQMP_ATF_MEM_BASE``: Specifies the base address of the bl31 binary.
|
||||||
- ``ZYNQMP_ATF_MEM_SIZE``: Specifies the size of the memory region of the bl31 binary.
|
- ``ZYNQMP_ATF_MEM_SIZE``: Specifies the size of the memory region of the bl31 binary.
|
||||||
|
|
@ -36,7 +36,7 @@ ZynqMP platform specific build options
|
||||||
- ``cadence1`` : Cadence UART 1
|
- ``cadence1`` : Cadence UART 1
|
||||||
|
|
||||||
FSBL->TF-A Parameter Passing
|
FSBL->TF-A Parameter Passing
|
||||||
===========================
|
----------------------------
|
||||||
|
|
||||||
The FSBL populates a data structure with image information for TF-A. TF-A uses
|
The FSBL populates a data structure with image information for TF-A. TF-A uses
|
||||||
that data to hand off to the loaded images. The address of the handoff data
|
that data to hand off to the loaded images. The address of the handoff data
|
||||||
|
|
@ -45,7 +45,7 @@ register is free to be used by other software once TF-A has brought up
|
||||||
further firmware images.
|
further firmware images.
|
||||||
|
|
||||||
Power Domain Tree
|
Power Domain Tree
|
||||||
=================
|
-----------------
|
||||||
|
|
||||||
The following power domain tree represents the power domain model used by TF-A
|
The following power domain tree represents the power domain model used by TF-A
|
||||||
for ZynqMP:
|
for ZynqMP:
|
||||||
|
|
|
||||||
|
|
@ -1,9 +1,5 @@
|
||||||
Trusted Firmware-A Coding Guidelines
|
Coding Style & Guidelines
|
||||||
====================================
|
=========================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
The following sections contain TF coding guidelines. They are continually
|
The following sections contain TF coding guidelines. They are continually
|
||||||
evolving and should not be considered "set in stone". Feel free to question them
|
evolving and should not be considered "set in stone". Feel free to question them
|
||||||
|
|
@ -11,8 +7,9 @@ and provide feedback.
|
||||||
|
|
||||||
Some of the guidelines may also apply to other codebases.
|
Some of the guidelines may also apply to other codebases.
|
||||||
|
|
||||||
**Note:** the existing TF codebase does not necessarily comply with all the
|
.. note::
|
||||||
below guidelines but the intent is for it to do so eventually.
|
The existing TF codebase does not necessarily comply with all the
|
||||||
|
below guidelines but the intent is for it to do so eventually.
|
||||||
|
|
||||||
Checkpatch overrides
|
Checkpatch overrides
|
||||||
--------------------
|
--------------------
|
||||||
|
|
@ -296,7 +293,7 @@ of the size of an array is the same.
|
||||||
If ``MY_STRUCT_SIZE`` in the above example were wrong then the compiler would
|
If ``MY_STRUCT_SIZE`` in the above example were wrong then the compiler would
|
||||||
emit an error like this:
|
emit an error like this:
|
||||||
|
|
||||||
.. code:: c
|
::
|
||||||
|
|
||||||
my_struct.h:10:1: error: size of array ‘assert_my_struct_size_mismatch’ is negative
|
my_struct.h:10:1: error: size of array ‘assert_my_struct_size_mismatch’ is negative
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Contributing to Trusted Firmware-A
|
Contributor's Guide
|
||||||
==================================
|
===================
|
||||||
|
|
||||||
Getting Started
|
Getting Started
|
||||||
---------------
|
---------------
|
||||||
|
|
|
||||||
|
|
@ -7,7 +7,7 @@ Processes & Policies
|
||||||
:numbered:
|
:numbered:
|
||||||
|
|
||||||
release-information
|
release-information
|
||||||
security-center
|
security
|
||||||
platform-compatibility-policy
|
platform-compatibility-policy
|
||||||
coding-guidelines
|
coding-guidelines
|
||||||
contributing
|
contributing
|
||||||
|
|
|
||||||
|
|
@ -1,12 +1,5 @@
|
||||||
TF-A Platform Compatibility Policy
|
Platform Compatibility Policy
|
||||||
==================================
|
=============================
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
--------------
|
|
||||||
|
|
||||||
Introduction
|
Introduction
|
||||||
------------
|
------------
|
||||||
|
|
|
||||||
|
|
@ -1,12 +1,5 @@
|
||||||
TF-A Release Information
|
Release Processes
|
||||||
========================
|
=================
|
||||||
|
|
||||||
.. section-numbering::
|
|
||||||
:suffix: .
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
--------------
|
|
||||||
|
|
||||||
Project Release Cadence
|
Project Release Cadence
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
Security Center
|
Security Handling
|
||||||
===============
|
=================
|
||||||
|
|
||||||
Security Disclosures
|
Security Disclosures
|
||||||
--------------------
|
--------------------
|
||||||
|
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 41 KiB |
|
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 27 KiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 163 KiB After Width: | Height: | Size: 163 KiB |
|
Before Width: | Height: | Size: 112 KiB After Width: | Height: | Size: 112 KiB |
|
Before Width: | Height: | Size: 214 KiB After Width: | Height: | Size: 214 KiB |
0
docs/plantuml/plantuml_to_svg.sh → docs/resources/diagrams/plantuml/plantuml_to_svg.sh
Executable file → Normal file
0
docs/plantuml/plantuml_to_svg.sh → docs/resources/diagrams/plantuml/plantuml_to_svg.sh
Executable file → Normal file
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 418 KiB After Width: | Height: | Size: 418 KiB |
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
|
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 39 KiB |
|
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
0
docs/diagrams/romlib_design.dia → docs/resources/diagrams/romlib_design.dia
Executable file → Normal file
0
docs/diagrams/romlib_design.dia → docs/resources/diagrams/romlib_design.dia
Executable file → Normal file
0
docs/diagrams/romlib_design.png → docs/resources/diagrams/romlib_design.png
Executable file → Normal file
0
docs/diagrams/romlib_design.png → docs/resources/diagrams/romlib_design.png
Executable file → Normal file
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
0
docs/diagrams/romlib_wrapper.dia → docs/resources/diagrams/romlib_wrapper.dia
Executable file → Normal file
0
docs/diagrams/romlib_wrapper.dia → docs/resources/diagrams/romlib_wrapper.dia
Executable file → Normal file
0
docs/diagrams/romlib_wrapper.png → docs/resources/diagrams/romlib_wrapper.png
Executable file → Normal file
0
docs/diagrams/romlib_wrapper.png → docs/resources/diagrams/romlib_wrapper.png
Executable file → Normal file
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 76 KiB After Width: | Height: | Size: 76 KiB |
|
Before Width: | Height: | Size: 169 KiB After Width: | Height: | Size: 169 KiB |
|
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 33 KiB |
|
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 46 KiB |
|
|
@ -1,3 +1,6 @@
|
||||||
|
Advisory TFV-1 (CVE-2016-10319)
|
||||||
|
===============================
|
||||||
|
|
||||||
+----------------+-------------------------------------------------------------+
|
+----------------+-------------------------------------------------------------+
|
||||||
| Title | Malformed Firmware Update SMC can result in copy of |
|
| Title | Malformed Firmware Update SMC can result in copy of |
|
||||||
| | unexpectedly large data into secure memory |
|
| | unexpectedly large data into secure memory |
|
||||||
|
|
|
||||||
|
|
@ -1,3 +1,6 @@
|
||||||
|
Advisory TFV-2 (CVE-2017-7564)
|
||||||
|
==============================
|
||||||
|
|
||||||
+----------------+-------------------------------------------------------------+
|
+----------------+-------------------------------------------------------------+
|
||||||
| Title | Enabled secure self-hosted invasive debug interface can |
|
| Title | Enabled secure self-hosted invasive debug interface can |
|
||||||
| | allow normal world to panic secure world |
|
| | allow normal world to panic secure world |
|
||||||
|
|
|
||||||
|
|
@ -1,3 +1,6 @@
|
||||||
|
Advisory TFV-3 (CVE-2017-7563)
|
||||||
|
==============================
|
||||||
|
|
||||||
+----------------+-------------------------------------------------------------+
|
+----------------+-------------------------------------------------------------+
|
||||||
| Title | RO memory is always executable at AArch64 Secure EL1 |
|
| Title | RO memory is always executable at AArch64 Secure EL1 |
|
||||||
+================+=============================================================+
|
+================+=============================================================+
|
||||||
|
|
@ -65,7 +68,7 @@ The vulnerability is mitigated by the following factors:
|
||||||
of the ``XN``, ``UXN`` or ``PXN`` bits in the translation tables. See the
|
of the ``XN``, ``UXN`` or ``PXN`` bits in the translation tables. See the
|
||||||
``enable_mmu()`` function:
|
``enable_mmu()`` function:
|
||||||
|
|
||||||
.. code:: c
|
::
|
||||||
|
|
||||||
sctlr = read_sctlr_el##_el(); \
|
sctlr = read_sctlr_el##_el(); \
|
||||||
sctlr |= SCTLR_WXN_BIT | SCTLR_M_BIT; \
|
sctlr |= SCTLR_WXN_BIT | SCTLR_M_BIT; \
|
||||||
|
|
|
||||||
|
|
@ -1,3 +1,6 @@
|
||||||
|
Advisory TFV-4 (CVE-2017-9607)
|
||||||
|
==============================
|
||||||
|
|
||||||
+----------------+-------------------------------------------------------------+
|
+----------------+-------------------------------------------------------------+
|
||||||
| Title | Malformed Firmware Update SMC can result in copy or |
|
| Title | Malformed Firmware Update SMC can result in copy or |
|
||||||
| | authentication of unexpected data in secure memory in |
|
| | authentication of unexpected data in secure memory in |
|
||||||
|
|
|
||||||
|
|
@ -1,3 +1,6 @@
|
||||||
|
Advisory TFV-5 (CVE-2017-15031)
|
||||||
|
===============================
|
||||||
|
|
||||||
+----------------+-------------------------------------------------------------+
|
+----------------+-------------------------------------------------------------+
|
||||||
| Title | Not initializing or saving/restoring ``PMCR_EL0`` can leak |
|
| Title | Not initializing or saving/restoring ``PMCR_EL0`` can leak |
|
||||||
| | secure world timing information |
|
| | secure world timing information |
|
||||||
|
|
|
||||||
|
|
@ -1,3 +1,6 @@
|
||||||
|
Advisory TFV-6 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754)
|
||||||
|
============================================================
|
||||||
|
|
||||||
+----------------+-------------------------------------------------------------+
|
+----------------+-------------------------------------------------------------+
|
||||||
| Title | Arm Trusted Firmware exposure to speculative processor |
|
| Title | Arm Trusted Firmware exposure to speculative processor |
|
||||||
| | vulnerabilities using cache timing side-channels |
|
| | vulnerabilities using cache timing side-channels |
|
||||||
|
|
@ -28,13 +31,13 @@ these vulnerabilities on Arm systems, please refer to the `Arm Processor
|
||||||
Security Update`_.
|
Security Update`_.
|
||||||
|
|
||||||
Variant 1 (`CVE-2017-5753`_)
|
Variant 1 (`CVE-2017-5753`_)
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
----------------------------
|
||||||
|
|
||||||
At the time of writing, no vulnerable patterns have been observed in upstream TF
|
At the time of writing, no vulnerable patterns have been observed in upstream TF
|
||||||
code, therefore no workarounds have been applied or are planned.
|
code, therefore no workarounds have been applied or are planned.
|
||||||
|
|
||||||
Variant 2 (`CVE-2017-5715`_)
|
Variant 2 (`CVE-2017-5715`_)
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
----------------------------
|
||||||
|
|
||||||
Where possible on vulnerable CPUs, Arm recommends invalidating the branch
|
Where possible on vulnerable CPUs, Arm recommends invalidating the branch
|
||||||
predictor as early as possible on entry into the secure world, before any branch
|
predictor as early as possible on entry into the secure world, before any branch
|
||||||
|
|
@ -122,7 +125,7 @@ Cortex-A76, Cortex-A53, Cortex-A55, Cortex-A32, Cortex-A7 and Cortex-A5.
|
||||||
For more information about non-Arm CPUs, please contact the CPU vendor.
|
For more information about non-Arm CPUs, please contact the CPU vendor.
|
||||||
|
|
||||||
Variant 3 (`CVE-2017-5754`_)
|
Variant 3 (`CVE-2017-5754`_)
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
----------------------------
|
||||||
|
|
||||||
This variant is only exploitable between Exception Levels within the same
|
This variant is only exploitable between Exception Levels within the same
|
||||||
translation regime, for example between EL0 and EL1, therefore this variant
|
translation regime, for example between EL0 and EL1, therefore this variant
|
||||||
|
|
|
||||||
|
|
@ -1,3 +1,6 @@
|
||||||
|
Advisory TFV-7 (CVE-2018-3639)
|
||||||
|
==============================
|
||||||
|
|
||||||
+----------------+-------------------------------------------------------------+
|
+----------------+-------------------------------------------------------------+
|
||||||
| Title | Trusted Firmware-A exposure to cache speculation |
|
| Title | Trusted Firmware-A exposure to cache speculation |
|
||||||
| | vulnerability Variant 4 |
|
| | vulnerability Variant 4 |
|
||||||
|
|
@ -46,7 +49,7 @@ for platforms that are unaffected or where the risk is deemed low enough.
|
||||||
Arm CPUs not mentioned below are unaffected.
|
Arm CPUs not mentioned below are unaffected.
|
||||||
|
|
||||||
Static mitigation
|
Static mitigation
|
||||||
~~~~~~~~~~~~~~~~~
|
-----------------
|
||||||
|
|
||||||
For affected CPUs, this approach enables the mitigation during EL3
|
For affected CPUs, this approach enables the mitigation during EL3
|
||||||
initialization, following every PE reset. No mechanism is provided to disable
|
initialization, following every PE reset. No mechanism is provided to disable
|
||||||
|
|
@ -67,7 +70,7 @@ TF-A implements this approach for the following affected CPUs:
|
||||||
(``S3_0_C15_C1_0``).
|
(``S3_0_C15_C1_0``).
|
||||||
|
|
||||||
Dynamic mitigation
|
Dynamic mitigation
|
||||||
~~~~~~~~~~~~~~~~~~
|
------------------
|
||||||
|
|
||||||
For affected CPUs, this approach also enables the mitigation during EL3
|
For affected CPUs, this approach also enables the mitigation during EL3
|
||||||
initialization, following every PE reset. In addition, this approach implements
|
initialization, following every PE reset. In addition, this approach implements
|
||||||
|
|
|
||||||
|
|
@ -1,3 +1,6 @@
|
||||||
|
Advisory TFV-8 (CVE-2018-19440)
|
||||||
|
===============================
|
||||||
|
|
||||||
+----------------+-------------------------------------------------------------+
|
+----------------+-------------------------------------------------------------+
|
||||||
| Title | Not saving x0 to x3 registers can leak information from one |
|
| Title | Not saving x0 to x3 registers can leak information from one |
|
||||||
| | Normal World SMC client to another |
|
| | Normal World SMC client to another |
|
||||||
|
|
@ -36,7 +39,7 @@ CPU context stored on the stack. This includes registers ``x0`` to ``x3``, as
|
||||||
can be seen in the ``lib/el3_runtime/aarch64/context.S`` file at line 339
|
can be seen in the ``lib/el3_runtime/aarch64/context.S`` file at line 339
|
||||||
(referring to the version of the code as of `commit c385955`_):
|
(referring to the version of the code as of `commit c385955`_):
|
||||||
|
|
||||||
.. code:: c
|
::
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* This function restores all general purpose registers except x30 from the
|
* This function restores all general purpose registers except x30 from the
|
||||||
|
|
|
||||||
|
|
@ -27,8 +27,8 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||||
|
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
Note:
|
.. note::
|
||||||
Individual files contain the following tag instead of the full license text.
|
Individual files contain the following tag instead of the full license text.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue