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