Skip to content

GitLab

Unverified Commit fb45044b authored by davidcunado-arm's avatar davidcunado-arm Committed by GitHub
Browse files

Merge pull request #1312 from davidcunado-arm/dc/update_docs 

Docs: Update various for v1.5 release
parents c3e34a9e 855ac025
Expand all Hide whitespace changes
Inline Side-by-side
docs/psci-pd-tree.rst
View file @ fb45044b
PSCI Library Integration guide for ARMv8-A AArch32 systems
PSCI Library Integration guide for Armv8-A AArch32 systems
==========================================================
......@@ -309,4 +309,4 @@ domain nodes do not need to be identified.
--------------
*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
docs/reset-design.rst
View file @ fb45044b
ARM Trusted Firmware Reset Design
=================================
Trusted Firmware-A reset design
===============================
.. section-numbering::
......@@ -8,9 +8,9 @@ ARM Trusted Firmware Reset Design
.. contents::
This document describes the high-level design of the framework to handle CPU
resets in ARM Trusted Firmware. It also describes how the platform integrator
can tailor this code to the system configuration to some extent, resulting in a
simplified and more optimised boot flow.
resets in Trusted Firmware-A (TF-A). It also describes how the platform
integrator can tailor this code to the system configuration to some extent,
resulting in a simplified and more optimised boot flow.
This document should be used in conjunction with the `Firmware Design`_, which
provides greater implementation details around the reset code, specifically
......@@ -19,8 +19,8 @@ for the cold boot path.
General reset code flow
-----------------------
The ARM Trusted Firmware (TF) reset code is implemented in BL1 by default. The
following high-level diagram illustrates this:
The TF-A reset code is implemented in BL1 by default. The following high-level
diagram illustrates this:
|Default reset code flow|
......@@ -29,15 +29,15 @@ 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 Trusted Firmware entry point instead of BL1, the
diagram above is still relevant, as all these operations will occur in BL31 in
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
------------------------------
By default, the TF assumes that the CPU reset address is not programmable.
By default, TF-A assumes that the CPU reset address is not programmable.
Therefore, all CPUs start at the same address (typically address 0) whenever
they reset. Further logic is then required to identify whether it is a cold or
warm boot to direct CPUs to the right execution path.
......@@ -49,8 +49,8 @@ detection can be skipped, resulting in the following boot flow:
|Reset code flow with programmable reset address|
To enable this boot flow, compile the TF with ``PROGRAMMABLE_RESET_ADDRESS=1``.
This option only affects the TF reset image, which is BL1 by default or BL31 if
To enable this boot flow, compile TF-A with ``PROGRAMMABLE_RESET_ADDRESS=1``.
This option only affects the TF-A reset image, which is BL1 by default or BL31 if
``RESET_TO_BL31=1``.
On both the FVP and Juno platforms, the reset vector address is not programmable
......@@ -59,7 +59,7 @@ so both ports use ``PROGRAMMABLE_RESET_ADDRESS=0``.
Cold boot on a single CPU
-------------------------
By default, the TF assumes that several CPUs may be released out of reset.
By default, TF-A assumes that several CPUs may be released out of reset.
Therefore, the cold boot code has to arbitrate access to hardware resources
shared amongst CPUs. This is done by nominating one of the CPUs as the primary,
which is responsible for initialising shared hardware and coordinating the boot
......@@ -71,8 +71,8 @@ applies. This results in the following boot flow:
|Reset code flow with single CPU released out of reset|
To enable this boot flow, compile the TF with ``COLD_BOOT_SINGLE_CPU=1``. This
option only affects the TF reset image, which is BL1 by default or BL31 if
To enable this boot flow, compile TF-A with ``COLD_BOOT_SINGLE_CPU=1``. This
option only affects the TF-A reset image, which is BL1 by default or BL31 if
``RESET_TO_BL31=1``.
On both the FVP and Juno platforms, although only one core is powered up by
......@@ -89,8 +89,8 @@ This results in the following boot flow:
|Reset code flow with programmable reset address and single CPU released out of reset|
To enable this boot flow, compile the TF with both ``COLD_BOOT_SINGLE_CPU=1``
and ``PROGRAMMABLE_RESET_ADDRESS=1``. These options only affect the TF reset
To enable this boot flow, compile TF-A with both ``COLD_BOOT_SINGLE_CPU=1``
and ``PROGRAMMABLE_RESET_ADDRESS=1``. These options only affect the TF-A reset
image, which is BL1 by default or BL31 if ``RESET_TO_BL31=1``.
Using BL31 entrypoint as the reset address
......@@ -102,7 +102,7 @@ on the SoC, rather than by BL1 and BL2 running on the primary application
processor. For this type of SoC it is desirable for the application processor
to always reset to BL31 which eliminates the need for BL1 and BL2.
TF provides a build-time option ``RESET_TO_BL31`` that includes some additional
TF-A provides a build-time option ``RESET_TO_BL31`` that includes some additional
logic in the BL31 entry point to support this use case.
In this configuration, the platform's Trusted Boot Firmware must ensure that
......@@ -112,10 +112,10 @@ Additionally, platform software is responsible for loading the other BL3x images
required and providing entry point information for them to BL31. Loading these
images might be done by the Trusted Boot Firmware or by platform code in BL31.
Although the ARM FVP platform does not support programming the reset base
Although the Arm FVP platform does not support programming the reset base
address dynamically at run-time, it is possible to set the initial value of the
``RVBAR_EL3`` register at start-up. This feature is provided on the Base FVP only.
It allows the ARM FVP port to support the ``RESET_TO_BL31`` configuration, in
It allows the Arm FVP port to support the ``RESET_TO_BL31`` configuration, in
which case the ``bl31.bin`` image must be loaded to its run address in Trusted
SRAM and all CPU reset vectors be changed from the default ``0x0`` to this run
address. See the `User Guide`_ for details of running the FVP models in this way.
......@@ -155,7 +155,7 @@ This might be done by the Trusted Boot Firmware or by platform code in BL31.
--------------
*Copyright (c) 2015, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.*
.. _Firmware Design: firmware-design.rst
.. _User Guide: user-guide.rst
......
docs/rt-svc-writers-guide.rst
View file @ fb45044b
EL3 Runtime Service Writers Guide for ARM Trusted Firmware
==========================================================
Trusted Firmware-A EL3 runtime service writer's guide
=====================================================
.. section-numbering::
......@@ -13,7 +13,7 @@ Introduction
------------
This document describes how to add a runtime service to the EL3 Runtime
Firmware component of ARM Trusted Firmware (BL31).
Firmware component of Trusted Firmware-A (TF-A), BL31.
Software executing in the normal world and in the trusted world at exception
levels lower than EL3 will request runtime services using the Secure Monitor
......@@ -27,7 +27,7 @@ example a subset of the Function IDs are designated as "OEM Calls" (see `SMCCC`_
for full details). The EL3 runtime services framework in BL31 enables the
independent implementation of services for each group, which are then compiled
into the BL31 image. This simplifies the integration of common software from
ARM to support `PSCI`_, Secure Monitor for a Trusted OS and SoC specific
Arm to support `PSCI`_, Secure Monitor for a Trusted OS and SoC specific
software. The common runtime services framework ensures that SMC Functions are
dispatched to their respective service implementation - the `Firmware Design`_
provides details of how this is achieved.
......@@ -53,7 +53,7 @@ legacy 32-bit software that predates the `SMCCC`_.
::
Type OEN Service
Fast 0 ARM Architecture calls
Fast 0 Arm Architecture calls
Fast 1 CPU Service calls
Fast 2 SiP Service calls
Fast 3 OEM Service calls
......@@ -62,7 +62,7 @@ legacy 32-bit software that predates the `SMCCC`_.
Fast 48-49 Trusted Application calls
Fast 50-63 Trusted OS calls
Yielding 0- 1 Reserved for existing ARMv7 calls
Yielding 0- 1 Reserved for existing Armv7-A calls
Yielding 2-63 Trusted OS Standard Calls
*Table 1: Service types and their corresponding Owning Entity Numbers*
......@@ -72,7 +72,7 @@ range as they need - it is not necessary to coordinate with other entities of
the same type. For example, two SoC providers can use the same Function ID
within the SiP Service calls OEN range to mean different things - as these
calls should be specific to the SoC. The Standard Runtime Calls OEN is used for
services defined by ARM standards, such as `PSCI`_.
services defined by Arm standards, such as `PSCI`_.
The SMC Function ID also indicates whether the call has followed the SMC32
calling convention, where all parameters are 32-bit, or the SMC64 calling
......@@ -87,7 +87,7 @@ handler will be responsible for all SMC Functions within a given service type.
Getting started
---------------
ARM Trusted Firmware has a `services`_ directory in the source tree under which
TF-A has a `services`_ directory in the source tree under which
each owning entity can place the implementation of its runtime service. The
`PSCI`_ implementation is located here in the `lib/psci`_ directory.
......@@ -250,8 +250,7 @@ The handler is responsible for:
UID and Revision Details for each service documented in section 6 of the
`SMCCC`_.
The ARM Trusted Firmware expects owning entities to follow this
recommendation.
TF-A expects owning entities to follow this recommendation.
#. Returning the result to the caller. The `SMCCC`_ allows for up to 256 bits
of return value in SMC64 using X0-X3 and 128 bits in SMC32 using W0-W3. The
......@@ -286,8 +285,8 @@ service which perform independent functions.
In this situation it may be valuable to introduce a second level framework to
enable independent implementation of sub-services. Such a framework might look
very similar to the current runtime services framework, but using a different
part of the SMC Function ID to identify the sub-service. Trusted Firmware does
not provide such a framework at present.
part of the SMC Function ID to identify the sub-service. TF-A does not provide
such a framework at present.
Secure-EL1 Payload Dispatcher service (SPD)
-------------------------------------------
......@@ -304,7 +303,7 @@ provide this information....
--------------
*Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.*
.. _SMCCC: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
......
docs/sdei.rst
View file @ fb45044b
......@@ -8,13 +8,13 @@ Software Delegated Exception Interface
.. contents::
:depth: 2
This document provides an overview of the SDEI dispatcher implementation in ARM
Trusted Firmware.
This document provides an overview of the SDEI dispatcher implementation in
Trusted Firmware-A (TF-A).
Introduction
------------
`Software Delegated Exception Interface`_ (SDEI) is an ARM specification for
`Software Delegated Exception Interface`_ (SDEI) is an Arm specification for
Non-secure world to register handlers with firmware to receive notifications
about system events. Firmware will first receive the system events by way of
asynchronous exceptions and, in response, arranges for the registered handler to
......@@ -52,8 +52,8 @@ SDEI events can be explicitly dispatched in response to other asynchronous
exceptions. See `Explicit dispatch of events`_.
The remainder of this document only discusses the design and implementation of
SDEI dispatcher in ARM Trusted Firmware, and assumes that the reader is familiar
with the SDEI specification, the interfaces, and their requirements.
SDEI dispatcher in TF-A, and assumes that the reader is familiar with the SDEI
specification, the interfaces, and their requirements.
.. [#std-event] Except event 0, which is defined by the SDEI specification as a
standard event.
......@@ -314,7 +314,7 @@ Note on writing SDEI event handlers
-----------------------------------
*This section pertains to SDEI event handlers in general, not just when using
ARM Trusted Firmware SDEI dispatcher.*
the TF-A SDEI dispatcher.*
The SDEI specification requires that event handlers preserve the contents of all
registers except ``x0`` to ``x17``. This has significance if event handler is
......@@ -364,7 +364,7 @@ implemented in assembly, following a similar pattern as below:
----
*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
.. _SDEI specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
.. _SDEI porting requirements: porting-guide.rst#sdei-porting-requirements
docs/secure-partition-manager-design.rst
View file @ fb45044b
......@@ -18,8 +18,8 @@ used by Non-secure world applications to access these services. A Trusted OS
fulfils the requirements of a security service as described above.
Management services are typically implemented at the highest level of privilege
in the system (i.e. EL3 in Arm Trusted Firmware). The service requirements are
fulfilled by the execution environment provided by Arm Trusted Firmware.
in the system, i.e. EL3 in Trusted Firmware-A (TF-A). The service requirements are
fulfilled by the execution environment provided by TF-A.
The following diagram illustrates the corresponding software stack:
......@@ -41,10 +41,10 @@ Introduction
A **Secure Partition** is a software execution environment instantiated in
S-EL0 that can be used to implement simple management and security services.
Since S-EL0 is an unprivileged Exception Level, a Secure Partition relies on
privileged firmware (i.e. Arm Trusted Firmware) to be granted access to system
and processor resources. Essentially, it is a software sandbox in the Secure
world that runs under the control of privileged software, provides one or more
services and accesses the following system resources:
privileged firmware (i.e. TF-A) to be granted access to system and processor
resources. Essentially, it is a software sandbox in the Secure world that runs
under the control of privileged software, provides one or more services and
accesses the following system resources:
- Memory and device regions in the system address map.
......@@ -52,25 +52,24 @@ services and accesses the following system resources:
- A range of synchronous exceptions (e.g. SMC function identifiers).
Note that currently the Arm Trusted Firmware only supports handling one Secure
Partition.
Note that currently TF-A only supports handling one Secure Partition.
A Secure Partition enables Arm Trusted Firmware to implement only the essential
secure services in EL3 and instantiate the rest in a partition in S-EL0.
A Secure Partition enables TF-A to implement only the essential secure
services in EL3 and instantiate the rest in a partition in S-EL0.
Furthermore, multiple Secure Partitions can be used to isolate unrelated
services from each other.
The following diagram illustrates the place of a Secure Partition in a typical
ARMv8-A software stack. A single or multiple Secure Partitions provide secure
Armv8-A software stack. A single or multiple Secure Partitions provide secure
services to software components in the Non-secure world and other Secure
Partitions.
|Image 2|
The Arm Trusted Firmware build system is responsible for including the Secure
Partition image in the FIP. During boot, BL2 includes support to authenticate
and load the Secure Partition image. A BL31 component called **Secure Partition
Manager (SPM)** is responsible for managing the partition. This is semantically
The TF-A build system is responsible for including the Secure Partition image
in the FIP. During boot, BL2 includes support to authenticate and load the
Secure Partition image. A BL31 component called **Secure Partition Manager
(SPM)** is responsible for managing the partition. This is semantically
similar to a hypervisor managing a virtual machine.
The SPM is responsible for the following actions during boot:
......@@ -105,8 +104,8 @@ made in the current implementation of this software architecture. Subsequent
revisions of the implementation will include a richer set of features that
enable a more flexible architecture.
Building Arm Trusted Firmware with Secure Partition support
-----------------------------------------------------------
Building TF-A with Secure Partition support
-------------------------------------------
SPM is supported on the Arm FVP exclusively at the moment. The current
implementation supports inclusion of only a single Secure Partition in which a
......@@ -125,7 +124,7 @@ the UEFI specification (see the PI v1.6 Volume 4: Management Mode Core
Interface). This will be referred to as the *Standalone MM Secure Partition* in
the rest of this document.
To enable SPM support in the TF, the source code must be compiled with the build
To enable SPM support in TF-A, the source code must be compiled with the build
flag ``ENABLE_SPM=1``. On Arm platforms the build option ``ARM_BL31_IN_DRAM``
can be used to select the location of BL31, both SRAM and DRAM are supported.
Also, the location of the binary that contains the BL32 image
......@@ -134,7 +133,7 @@ Also, the location of the binary that contains the BL32 image
First, build the Standalone MM Secure Partition. To build it, refer to the
`instructions in the EDK2 repository`_.
Then build TF with SPM support and include the Standalone MM Secure Partition
Then build TF-A with SPM support and include the Standalone MM Secure Partition
image in the FIP:
::
......@@ -145,10 +144,10 @@ image in the FIP:
Describing Secure Partition resources
-------------------------------------
Arm Trusted Firmware exports a porting interface that enables a platform to
specify the system resources required by the Secure Partition. Some instructions
are given below. However, this interface is under development and it may change
as new features are implemented.
TF-A exports a porting interface that enables a platform to specify the system
resources required by the Secure Partition. Some instructions are given below.
However, this interface is under development and it may change as new features
are implemented.
- A Secure Partition is considered a BL32 image, so the same defines that apply
to BL32 images apply to a Secure Partition: ``BL32_BASE`` and ``BL32_LIMIT``.
......@@ -176,9 +175,9 @@ For an example of all the changes in context, you may refer to commit
Accessing Secure Partition services
-----------------------------------
The `SMC Calling Convention`_ (*ARM DEN 0028B*) describes SMCs as a conduit for
The `SMC Calling Convention`_ (*Arm DEN 0028B*) describes SMCs as a conduit for
accessing services implemented in the Secure world. The ``MM_COMMUNICATE``
interface defined in the `Management Mode Interface Specification`_ (*ARM DEN
interface defined in the `Management Mode Interface Specification`_ (*Arm DEN
0060A*) is used to invoke a Secure Partition service as a Fast Call.
The mechanism used to identify a service within the partition depends on the
......@@ -208,11 +207,11 @@ e.g. ACPI table or device tree. It is possible for the Non-secure world to
exchange data with a partition only if it has been populated in this shared
memory area. The shared memory area is implemented as per the guidelines
specified in Section 3.2.3 of the `Management Mode Interface Specification`_
(*ARM DEN 0060A*).
(*Arm DEN 0060A*).
The format of data structures used to encapsulate data in the shared memory is
agreed between the Non-secure world and the Secure Partition. For example, in
the `Management Mode Interface specification`_ (*ARM DEN 0060A*), Section 4
the `Management Mode Interface specification`_ (*Arm DEN 0060A*), Section 4
describes that the communication buffer shared between the Non-secure world and
the Management Mode (MM) in the Secure world must be of the type
``EFI_MM_COMMUNICATE_HEADER``. This data structure is defined in *Volume 4:
......@@ -246,7 +245,7 @@ interfaces are not accessible from the Non-secure world.
Conduit
^^^^^^^
The `SMC Calling Convention`_ (*ARM DEN 0028B*) specification describes the SMC
The `SMC Calling Convention`_ (*Arm DEN 0028B*) specification describes the SMC
and HVC conduits for accessing firmware services and their availability
depending on the implemented Exception levels. In S-EL0, the Supervisor Call
exception (SVC) is the only architectural mechanism available for unprivileged
......@@ -254,16 +253,16 @@ software to make a request for an operation implemented in privileged software.
Hence, the SVC conduit must be used by the Secure Partition to access interfaces
implemented by the SPM.
A SVC causes an exception to be taken to S-EL1. Arm Trusted Firmware assumes
ownership of S-EL1 and installs a simple exception vector table in S-EL1 that
relays a SVC request from a Secure Partition as a SMC request to the SPM in EL3.
Upon servicing the SMC request, Arm Trusted Firmware returns control directly to
S-EL0 through an ERET instruction.
A SVC causes an exception to be taken to S-EL1. TF-A assumes ownership of S-EL1
and installs a simple exception vector table in S-EL1 that relays a SVC request
from a Secure Partition as a SMC request to the SPM in EL3. Upon servicing the
SMC request, Arm Trusted Firmware returns control directly to S-EL0 through an
ERET instruction.
Calling conventions
^^^^^^^^^^^^^^^^^^^
The `SMC Calling Convention`_ (*ARM DEN 0028B*) specification describes the
The `SMC Calling Convention`_ (*Arm DEN 0028B*) specification describes the
32-bit and 64-bit calling conventions for the SMC and HVC conduits. The SVC
conduit introduces the concept of SVC32 and SVC64 calling conventions. The SVC32
and SVC64 calling conventions are equivalent to the 32-bit (SMC32) and the
......@@ -285,8 +284,8 @@ Communication initiated by Secure Partition
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A request is initiated from the Secure Partition by executing a SVC instruction.
An ERET instruction is used by Arm Trusted Firmware to return to S-EL0 with the
result of the request.
An ERET instruction is used by TF-A to return to S-EL0 with the result of the
request.
For instance, a request to perform privileged operations on behalf of a
partition (e.g. management of memory attributes in the translation tables for
......@@ -296,7 +295,7 @@ Interfaces
^^^^^^^^^^
The current implementation reserves function IDs for Fast Calls in the Standard
Secure Service calls range (see `SMC Calling Convention`_ (*ARM DEN 0028B*)
Secure Service calls range (see `SMC Calling Convention`_ (*Arm DEN 0028B*)
specification) for each API exported by the SPM. This section defines the
function prototypes for each function ID. The function IDs specify whether one
or both of the SVC32 and SVC64 calling conventions can be used to invoke the
......@@ -461,7 +460,7 @@ This transition into S-EL0 is special since it is not in response to a previous
request through a SVC instruction. This is the first entry into S-EL0. The
general purpose register usage at the time of entry will be as specified in the
"Return State" column of Table 3-1 in Section 3.1 "Register use in AArch64 SMC
calls" of the `SMC Calling Convention`_ (*ARM DEN 0028B*) specification. In
calls" of the `SMC Calling Convention`_ (*Arm DEN 0028B*) specification. In
addition, certain other restrictions will be applied as described below.
1. ``SP_EL0``
......@@ -601,7 +600,7 @@ address map from a Secure Partition. This is done by mapping these regions in
the Secure EL1&0 Translation regime with appropriate memory attributes.
Attributes refer to memory type, permission, cacheability and shareability
attributes used in the Translation tables. The definitions of these attributes
and their usage can be found in the `ARMv8 ARM`_ (*ARM DDI 0487*).
and their usage can be found in the `Armv8-A ARM`_ (*Arm DDI 0487*).
All memory required by the Secure Partition is allocated upfront in the SPM,
even before handing over to the Secure Partition for the first time. The initial
......@@ -813,9 +812,9 @@ Error Codes
--------------
*Copyright (c) 2017, Arm Limited and Contributors. All rights reserved.*
*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
.. _ARMv8 ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
.. _Armv8-A ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
.. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64StandaloneMm/HowtoBuild.MD
.. _Management Mode Interface Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf
.. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
......
docs/spd/optee-dispatcher.rst
View file @ fb45044b
......@@ -8,7 +8,7 @@ To build and execute OP-TEE follow the instructions at
--------------
*Copyright (c) 2014-2017, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.*
.. _OP-TEE OS: https://github.com/OP-TEE/build
.. _OP-TEE build.git: https://github.com/OP-TEE/build
docs/spd/tlk-dispatcher.rst
View file @ fb45044b
Trusted Little Kernel (TLK) Dispatcher
======================================
TLK dispatcher adds support for NVIDIA's Trusted Little Kernel (TLK) to work
with the Trusted Firmware. TLK-D can be compiled by including it in the
platform's makefile. TLK is primarily meant to work with Tegra SoCs, so until
Trusted Firmware starts supporting Tegra, the dispatcher code can only be
TLK dispatcher (TLK-D) adds support for NVIDIA's Trusted Little Kernel (TLK)
to work with Trusted Firmware-A (TF-A). TLK-D can be compiled by including it
in the platform's makefile. TLK is primarily meant to work with Tegra SoCs,
so while TF-A only supports TLK on Tegra, the dispatcher code can only be
compiled for other platforms.
In order to compile TLK-D, we need a BL32 image to be present. Since, TLKD
......@@ -20,7 +20,7 @@ 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
extends technology made available with the development of the Little Kernel (LK).
You can download the LK modular embedded preemptive kernel for use on ARM,
You can download the LK modular embedded preemptive kernel for use on Arm,
x86, and AVR32 systems from https://github.com/travisg/lk
NVIDIA implemented its Trusted Little Kernel (TLK) technology, designed as a
......@@ -72,5 +72,5 @@ Example:
::
bl32_ep_info->args.arg0 = TZDRAM size available for BL32
bl32_ep_info->args.arg1 = unused (used only on ARMv7)
bl32_ep_info->args.arg1 = unused (used only on Armv7-A)
bl32_ep_info->args.arg2 = pointer to boot args
docs/spd/trusty-dispatcher.rst
View file @ fb45044b
......@@ -28,5 +28,5 @@ should then be set to the size of that block.
Supported platforms
===================
Out of all the platforms supported by the ARM Trusted Firmware, Trusty is
Out of all the platforms supported by Trusted Firmware-A, Trusty is only
verified and supported by NVIDIA's Tegra SoCs.
docs/trusted-board-boot.rst
View file @ fb45044b
......@@ -12,16 +12,16 @@ the platform by authenticating all firmware images up to and including the
normal world bootloader. It does this by establishing a Chain of Trust using
Public-Key-Cryptography Standards (PKCS).
This document describes the design of ARM Trusted Firmware TBB, which is an
implementation of the Trusted Board Boot Requirements (TBBR) specification,
ARM DEN0006C-1. It should be used in conjunction with the `Firmware Update`_
This document describes the design of Trusted Firmware-A (TF-A) TBB, which is
an implementation of the Trusted Board Boot Requirements (TBBR) specification,
Arm DEN0006C-1. It should be used in conjunction with the `Firmware Update`_
design document, which implements a specific aspect of the TBBR.
Chain of Trust
--------------
A Chain of Trust (CoT) starts with a set of implicitly trusted components. On
the ARM development platforms, these components are:
the Arm development platforms, these components are:
- A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the
trusted root-key storage registers.
......@@ -39,7 +39,7 @@ Certificate Authority (CA) because the CoT is not established by verifying the
validity of a certificate's issuer but by the content of the certificate
extensions. To sign the certificates, the PKCS#1 SHA-256 with RSA Encryption
signature scheme is used with a RSA key length of 2048 bits. Future version of
Trusted Firmware will support additional cryptographic algorithms.
TF-A will support additional cryptographic algorithms.
The certificates are categorised as "Key" and "Content" certificates. Key
certificates are used to verify public keys which have been used to sign content
......@@ -148,7 +148,7 @@ if any of the steps fail.
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.
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
......@@ -196,7 +196,7 @@ enabled through use of specific build flags as described in the `User Guide`_.
On the host machine, a tool generates the certificates, which are included in
the FIP along with the boot loader images. These certificates are loaded in
Trusted SRAM using the IO storage framework. They are then verified by an
Authentication module included in the Trusted Firmware.
Authentication module included in TF-A.
The mechanism used for generating the FIP and the Authentication module are
described in the following sections.
......@@ -204,9 +204,9 @@ described in the following sections.
Authentication Framework
------------------------
The authentication framework included in the Trusted Firmware provides support
to implement the desired trusted boot sequence. ARM platforms use this framework
to implement the boot requirements specified in the TBBR-client document.
The authentication framework included in TF-A provides support to implement
the desired trusted boot sequence. Arm platforms use this framework to
implement the boot requirements specified in the TBBR-client document.
More information about the authentication framework can be found in the
`Auth Framework`_ document.
......@@ -215,8 +215,8 @@ Certificate Generation Tool
---------------------------
The ``cert_create`` tool is built and runs on the host machine as part of the
Trusted Firmware build process when ``GENERATE_COT=1``. It takes the boot loader
images and keys as inputs (keys must be in PEM format) and generates the
TF-A build process when ``GENERATE_COT=1``. It takes the boot loader images
and keys as inputs (keys must be in PEM format) and generates the
certificates (in DER format) required to establish the CoT. New keys can be
generated by the tool in case they are not provided. The certificates are then
passed as inputs to the ``fiptool`` utility for creating the FIP.
......@@ -230,7 +230,7 @@ for building and using the tool can be found in the `User Guide`_.
--------------
*Copyright (c) 2015, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.*
.. _Firmware Update: firmware-update.rst
.. _X.509 v3: http://www.ietf.org/rfc/rfc5280.txt
......
docs/user-guide.rst
View file @ fb45044b
This diff is collapsed.
docs/xlat-tables-lib-v2-design.rst
View file @ fb45044b
......@@ -9,7 +9,7 @@ Translation Tables Library Design
This document describes the design of the translation tables library (version 2)
used by the ARM Trusted Firmware. This library provides APIs to create page
used by Trusted Firmware-A (TF-A). This library provides APIs to create page
tables based on a description of the memory layout, as well as setting up system
registers related to the Memory Management Unit (MMU) and performing the
required Translation Lookaside Buffer (TLB) maintenance operations.
......@@ -329,7 +329,7 @@ The memory mapping algorithm
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The mapping function is implemented as a recursive algorithm. It is however
bound by the level of depth of the translation tables (the ARMv8-A architecture
bound by the level of depth of the translation tables (the Armv8-A architecture
allows up to 4 lookup levels).
By default [#granularity-ref]_, the algorithm will attempt to minimize the
......@@ -376,7 +376,7 @@ changes are visible to subsequent execution, including speculative execution,
that uses the changed translation table entries.
A counter-example is the initialization of translation tables. In this case,
explicit TLB maintenance is not required. The ARMv8-A architecture guarantees
explicit TLB maintenance is not required. The Armv8-A architecture guarantees
that all TLBs are disabled from reset and their contents have no effect on
address translation at reset [#tlb-reset-ref]_. Therefore, the TLBs invalidation
is deferred to the ``enable_mmu*()`` family of functions, just before the MMU is
......@@ -391,9 +391,9 @@ descriptor. Given that the TLBs are not architecturally permitted to hold any
invalid translation table entry [#tlb-no-invalid-entry]_, this means that this
mapping cannot be cached in the TLBs.
.. [#tlb-reset-ref] See section D4.8 `Translation Lookaside Buffers (TLBs)`, subsection `TLB behavior at reset` in ARMv8-A, rev B.a.
.. [#tlb-reset-ref] See section D4.8 `Translation Lookaside Buffers (TLBs)`, subsection `TLB behavior at reset` in Armv8-A, rev B.a.
.. [#tlb-no-invalid-entry] See section D4.9.1 `General TLB maintenance requirements` in ARMv8-A, rev B.a.
.. [#tlb-no-invalid-entry] See section D4.9.1 `General TLB maintenance requirements` in Armv8-A, rev B.a.
Architectural module
~~~~~~~~~~~~~~~~~~~~
......@@ -405,7 +405,7 @@ translation context to work on.
--------------
*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
.. _lib/xlat\_tables\_v2: ../lib/xlat_tables_v2
.. _lib/xlat\_tables: ../lib/xlat_tables
......
license.rst
View file @ fb45044b
Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.
Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
......@@ -10,7 +10,7 @@ are permitted provided that the following conditions are met:
list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution.
- Neither the name of ARM nor the names of its contributors may be used to
- Neither the name of Arm nor the names of its contributors may be used to
endorse or promote products derived from this software without specific prior
written permission.
......
maintainers.rst
View file @ fb45044b
ARM Trusted Firmware Maintainers
================================
Trusted Firmware-A maintainers
==============================
ARM Trusted Firmware is an ARM maintained project. All contributions are
Trusted Firmware-A (TF-A) is an Arm maintained project. All contributions are
ultimately merged by the maintainers listed below. Technical ownership of some
parts of the codebase is delegated to the sub-maintainers listed below. An
acknowledgement from these sub-maintainers may be required before the
......@@ -123,8 +123,8 @@ Files:
- docs/plat/xilinx-zynqmp.rst
- plat/xilinx/\*
ARMv7 architecture sub-maintainer
---------------------------------
Armv7-A architecture sub-maintainer
-----------------------------------
Etienne Carriere (etienne.carriere@linaro.org, `etienne-lms`_)
......
readme.rst
View file @ fb45044b
ARM Trusted Firmware - version 1.4
==================================
Trusted Firmware-A - version 1.4
================================
ARM Trusted Firmware provides a reference implementation of secure world
software for `ARMv8-A`_, including a `Secure Monitor`_ executing at
Exception Level 3 (EL3). It implements various ARM interface standards, such as:
Trusted Firmware-A (TF-A) provides a reference implementation of secure world
software for `Armv8-A`_, including a `Secure Monitor`_ executing at Exception
Level 3 (EL3). It implements various Arm interface standards, such as:
- The `Power State Coordination Interface (PSCI)`_
- Trusted Board Boot Requirements (TBBR, ARM DEN0006C-1)
- Trusted Board Boot Requirements (TBBR, Arm DEN0006C-1)
- `SMC Calling Convention`_
- `System Control and Management Interface`_
As far as possible the code is designed for reuse or porting to other ARMv8-A
As far as possible the code is designed for reuse or porting to other Armv8-A
model and hardware platforms.
ARM will continue development in collaboration with interested parties to
provide a full reference implementation of Secure Monitor code and ARM standards
to the benefit of all developers working with ARMv8-A TrustZone technology.
Arm will continue development in collaboration with interested parties to
provide a full reference implementation of Secure Monitor code and Arm standards
to the benefit of all developers working with Armv8-A TrustZone technology.
License
-------
......@@ -45,7 +45,7 @@ world boot and runtime firmware, in either the AArch32 or AArch64 execution
state.
Users are encouraged to do their own security validation, including penetration
testing, on any secure world code derived from ARM Trusted Firmware.
testing, on any secure world code derived from TF-A.
Functionality
~~~~~~~~~~~~~
......@@ -54,15 +54,15 @@ Functionality
registers and interrupts for the platform.
- Library support for CPU specific reset and power down sequences. This
includes support for errata workarounds and the latest ARM DynamIQ CPUs.
includes support for errata workarounds and the latest Arm DynamIQ CPUs.
- Drivers to enable standard initialization of ARM System IP, for example
- Drivers to enable standard initialization of Arm System IP, for example
Generic Interrupt Controller (GIC), Cache Coherent Interconnect (CCI),
Cache Coherent Network (CCN), Network Interconnect (NIC) and TrustZone
Controller (TZC).
- A generic `SCMI`_ driver to interface with conforming power controllers, for
example the ARM System Control Processor (SCP).
example the Arm System Control Processor (SCP).
- SMC (Secure Monitor Call) handling, conforming to the `SMC Calling
Convention`_ using an EL3 runtime services framework.
......@@ -93,14 +93,14 @@ Functionality
recovery mode), and packaging of the various firmware images into a
Firmware Image Package (FIP).
- Pre-integration of TBB with the ARM TrustZone CryptoCell product, to take
- Pre-integration of TBB with the Arm TrustZone CryptoCell product, to take
advantage of its hardware Root of Trust and crypto acceleration services.
- Support for alternative boot flows, for example to support platforms where
the EL3 Runtime Software is loaded using other firmware or a separate
secure system processor.
- Support for the GCC, LLVM and ARM Compiler 6 toolchains.
- Support for the GCC, LLVM and Arm Compiler 6 toolchains.
For a full description of functionality and implementation details, please
see the `Firmware Design`_ and supporting documentation. The `Change Log`_
......@@ -110,9 +110,9 @@ Platforms
~~~~~~~~~
Various AArch32 and AArch64 builds of this release has been tested on variants
r0, r1 and r2 of the `Juno ARM Development Platform`_.
r0, r1 and r2 of the `Juno Arm Development Platform`_.
Various AArch64 builds of this release have been tested on the following ARM
Various AArch64 builds of this release have been tested on the following Arm
`FVP`_\ s (64-bit host machine only):
NOTE: Unless otherwise stated, the FVP Version is 11.0, Build 11.0.34.
......@@ -129,14 +129,14 @@ NOTE: Unless otherwise stated, the FVP Version is 11.0, Build 11.0.34.
- ``FVP_Base_Cortex-A73x4``
- ``FVP_CSS_SGM-775`` (Version 11.0, Build 11.0.36)
Various AArch32 builds of this release has been tested on the following ARM
Various AArch32 builds of this release has been tested on the following Arm
`FVP`_\ s (64-bit host machine only):
- ``FVP_Base_AEMv8A-AEMv8A`` (Version 8.5, Build 0.8.8502)
- ``FVP_Base_Cortex-A32x4``
The Foundation FVP can be downloaded free of charge. The Base FVPs can be
licensed from ARM. See the `ARM FVP website`_.
licensed from Arm. See the `Arm FVP website`_.
All the above platforms have been tested with `Linaro Release 17.04`_.
......@@ -167,15 +167,15 @@ Log`_ and the `GitHub issue tracker`_.
Getting Started
---------------
Get the Trusted Firmware source code from `GitHub`_.
Get the TF-A source code from `GitHub`_.
See the `User Guide`_ for instructions on how to install, build and use
the Trusted Firmware with the ARM `FVP`_\ s.
the TF-A with the Arm `FVP`_\ s.
See the `Firmware Design`_ for information on how the Trusted Firmware works.
See the `Firmware Design`_ for information on how the TF-A works.
See the `Porting Guide`_ as well for information about how to use this
software on another ARMv8-A platform.
software on another Armv8-A platform.
See the `Contributing Guidelines`_ for information on how to contribute to this
project and the `Acknowledgments`_ file for a list of contributors to the
......@@ -184,26 +184,26 @@ project.
Feedback and support
~~~~~~~~~~~~~~~~~~~~
ARM welcomes any feedback on Trusted Firmware. If you think you have found a
security vulnerability, please report this using the process defined in the
Trusted Firmware `Security Centre`_. For all other feedback, please use the
Arm welcomes any feedback on TF-A. If you think you have found a security
vulnerability, please report this using the process defined in the TF-A
`Security Centre`_. For all other feedback, please use the
`GitHub issue tracker`_.
ARM licensees may contact ARM directly via their partner managers.
Arm licensees may contact Arm directly via their partner managers.
--------------
*Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.*
.. _ARMv8-A: http://www.arm.com/products/processors/armv8-architecture.php
.. _Armv8-A: http://www.arm.com/products/processors/armv8-architecture.php
.. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php
.. _Power State Coordination Interface (PSCI): PSCI_
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
.. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
.. _System Control and Management Interface: SCMI_
.. _SCMI: http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf
.. _Juno ARM Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php
.. _ARM FVP website: FVP_
.. _Juno Arm Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php
.. _Arm FVP website: FVP_
.. _FVP: https://developer.arm.com/products/system-design/fixed-virtual-platforms
.. _Linaro Release 17.04: https://community.arm.com/dev-platforms/b/documents/posts/linaro-release-notes-deprecated#LinaroRelease17.04
.. _OP-TEE Secure OS: https://github.com/OP-TEE/optee_os
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment