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
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. ...@@ -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:: .. section-numbering::
...@@ -8,9 +8,9 @@ ARM Trusted Firmware Reset Design ...@@ -8,9 +8,9 @@ ARM Trusted Firmware Reset Design
.. contents:: .. contents::
This document describes the high-level design of the framework to handle CPU This document describes the high-level design of the framework to handle CPU
resets in ARM Trusted Firmware. It also describes how the platform integrator resets in Trusted Firmware-A (TF-A). It also describes how the platform
can tailor this code to the system configuration to some extent, resulting in a integrator can tailor this code to the system configuration to some extent,
simplified and more optimised boot flow. resulting in a simplified and more optimised boot flow.
This document should be used in conjunction with the `Firmware Design`_, which This document should be used in conjunction with the `Firmware Design`_, which
provides greater implementation details around the reset code, specifically provides greater implementation details around the reset code, specifically
...@@ -19,8 +19,8 @@ for the cold boot path. ...@@ -19,8 +19,8 @@ for the cold boot path.
General reset code flow General reset code flow
----------------------- -----------------------
The ARM Trusted Firmware (TF) reset code is implemented in BL1 by default. The The TF-A reset code is implemented in BL1 by default. The following high-level
following high-level diagram illustrates this: diagram illustrates this:
|Default reset code flow| |Default reset code flow|
...@@ -29,15 +29,15 @@ configuration, some of these steps might be unnecessary. The following sections ...@@ -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 guide the platform integrator by indicating which build options exclude which
steps, depending on the capability of the platform. steps, depending on the capability of the platform.
Note: If BL31 is used as the Trusted Firmware entry point instead of BL1, the Note: If BL31 is used as the TF-A entry point instead of BL1, the diagram
diagram above is still relevant, as all these operations will occur in BL31 in 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 this case. Please refer to section 6 "Using BL31 entrypoint as the reset
address" for more information. address" for more information.
Programmable CPU reset address 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 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 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. warm boot to direct CPUs to the right execution path.
...@@ -49,8 +49,8 @@ detection can be skipped, resulting in the following boot flow: ...@@ -49,8 +49,8 @@ detection can be skipped, resulting in the following boot flow:
|Reset code flow with programmable reset address| |Reset code flow with programmable reset address|
To enable this boot flow, compile the TF with ``PROGRAMMABLE_RESET_ADDRESS=1``. To enable this boot flow, compile TF-A with ``PROGRAMMABLE_RESET_ADDRESS=1``.
This option only affects the TF reset image, which is BL1 by default or BL31 if This option only affects the TF-A reset image, which is BL1 by default or BL31 if
``RESET_TO_BL31=1``. ``RESET_TO_BL31=1``.
On both the FVP and Juno platforms, the reset vector address is not programmable 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``. ...@@ -59,7 +59,7 @@ so both ports use ``PROGRAMMABLE_RESET_ADDRESS=0``.
Cold boot on a single CPU 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 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, 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 which is responsible for initialising shared hardware and coordinating the boot
...@@ -71,8 +71,8 @@ applies. This results in the following boot flow: ...@@ -71,8 +71,8 @@ applies. This results in the following boot flow:
|Reset code flow with single CPU released out of reset| |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 To enable this boot flow, compile TF-A with ``COLD_BOOT_SINGLE_CPU=1``. This
option only affects the TF reset image, which is BL1 by default or BL31 if option only affects the TF-A reset image, which is BL1 by default or BL31 if
``RESET_TO_BL31=1``. ``RESET_TO_BL31=1``.
On both the FVP and Juno platforms, although only one core is powered up by 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: ...@@ -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| |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`` 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 reset 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``. image, which is BL1 by default or BL31 if ``RESET_TO_BL31=1``.
Using BL31 entrypoint as the reset address 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 ...@@ -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 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. 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. logic in the BL31 entry point to support this use case.
In this configuration, the platform's Trusted Boot Firmware must ensure that 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 ...@@ -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 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. images might be done by the Trusted Boot Firmware or by platform code in BL31.
Although the ARM FVP platform does not support programming the reset base Although the Arm FVP platform does not support programming the reset base
address dynamically at run-time, it is possible to set the initial value of the address dynamically at run-time, it is possible to set the initial value of the
``RVBAR_EL3`` register at start-up. This feature is provided on the Base FVP only. ``RVBAR_EL3`` register at start-up. This feature is provided on the Base FVP only.
It allows the ARM FVP port to support the ``RESET_TO_BL31`` configuration, in It allows the Arm FVP port to support the ``RESET_TO_BL31`` configuration, in
which case the ``bl31.bin`` image must be loaded to its run address in Trusted which case the ``bl31.bin`` image must be loaded to its run address in Trusted
SRAM and all CPU reset vectors be changed from the default ``0x0`` to this run SRAM and all CPU reset vectors be changed from the default ``0x0`` to this run
address. See the `User Guide`_ for details of running the FVP models in this way. address. See the `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. ...@@ -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 .. _Firmware Design: firmware-design.rst
.. _User Guide: user-guide.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:: .. section-numbering::
...@@ -13,7 +13,7 @@ Introduction ...@@ -13,7 +13,7 @@ Introduction
------------ ------------
This document describes how to add a runtime service to the EL3 Runtime 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 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 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`_ ...@@ -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 for full details). The EL3 runtime services framework in BL31 enables the
independent implementation of services for each group, which are then compiled independent implementation of services for each group, which are then compiled
into the BL31 image. This simplifies the integration of common software from into the BL31 image. This simplifies the integration of common software from
ARM to support `PSCI`_, Secure Monitor for a Trusted OS and SoC specific Arm to support `PSCI`_, Secure Monitor for a Trusted OS and SoC specific
software. The common runtime services framework ensures that SMC Functions are software. The common runtime services framework ensures that SMC Functions are
dispatched to their respective service implementation - the `Firmware Design`_ dispatched to their respective service implementation - the `Firmware Design`_
provides details of how this is achieved. provides details of how this is achieved.
...@@ -53,7 +53,7 @@ legacy 32-bit software that predates the `SMCCC`_. ...@@ -53,7 +53,7 @@ legacy 32-bit software that predates the `SMCCC`_.
:: ::
Type OEN Service Type OEN Service
Fast 0 ARM Architecture calls Fast 0 Arm Architecture calls
Fast 1 CPU Service calls Fast 1 CPU Service calls
Fast 2 SiP Service calls Fast 2 SiP Service calls
Fast 3 OEM Service calls Fast 3 OEM Service calls
...@@ -62,7 +62,7 @@ legacy 32-bit software that predates the `SMCCC`_. ...@@ -62,7 +62,7 @@ legacy 32-bit software that predates the `SMCCC`_.
Fast 48-49 Trusted Application calls Fast 48-49 Trusted Application calls
Fast 50-63 Trusted OS 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 Yielding 2-63 Trusted OS Standard Calls
*Table 1: Service types and their corresponding Owning Entity Numbers* *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 ...@@ -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 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 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 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 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 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. ...@@ -87,7 +87,7 @@ handler will be responsible for all SMC Functions within a given service type.
Getting started 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 each owning entity can place the implementation of its runtime service. The
`PSCI`_ implementation is located here in the `lib/psci`_ directory. `PSCI`_ implementation is located here in the `lib/psci`_ directory.
...@@ -250,8 +250,7 @@ The handler is responsible for: ...@@ -250,8 +250,7 @@ The handler is responsible for:
UID and Revision Details for each service documented in section 6 of the UID and Revision Details for each service documented in section 6 of the
`SMCCC`_. `SMCCC`_.
The ARM Trusted Firmware expects owning entities to follow this TF-A expects owning entities to follow this recommendation.
recommendation.
#. Returning the result to the caller. The `SMCCC`_ allows for up to 256 bits #. 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 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. ...@@ -286,8 +285,8 @@ service which perform independent functions.
In this situation it may be valuable to introduce a second level framework to 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 enable independent implementation of sub-services. Such a framework might look
very similar to the current runtime services framework, but using a different 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 part of the SMC Function ID to identify the sub-service. TF-A does not provide
not provide such a framework at present. such a framework at present.
Secure-EL1 Payload Dispatcher service (SPD) Secure-EL1 Payload Dispatcher service (SPD)
------------------------------------------- -------------------------------------------
...@@ -304,7 +303,7 @@ provide this information.... ...@@ -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 .. _SMCCC: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
......
docs/sdei.rst
View file @ fb45044b
...@@ -8,13 +8,13 @@ Software Delegated Exception Interface ...@@ -8,13 +8,13 @@ Software Delegated Exception Interface
.. contents:: .. contents::
:depth: 2 :depth: 2
This document provides an overview of the SDEI dispatcher implementation in ARM This document provides an overview of the SDEI dispatcher implementation in
Trusted Firmware. Trusted Firmware-A (TF-A).
Introduction Introduction
------------ ------------
`Software Delegated Exception Interface`_ (SDEI) is an ARM specification for `Software Delegated Exception Interface`_ (SDEI) is an Arm specification for
Non-secure world to register handlers with firmware to receive notifications Non-secure world to register handlers with firmware to receive notifications
about system events. Firmware will first receive the system events by way of about system events. Firmware will first receive the system events by way of
asynchronous exceptions and, in response, arranges for the registered handler to asynchronous exceptions and, in response, arranges for the registered handler to
...@@ -52,8 +52,8 @@ SDEI events can be explicitly dispatched in response to other asynchronous ...@@ -52,8 +52,8 @@ SDEI events can be explicitly dispatched in response to other asynchronous
exceptions. See `Explicit dispatch of events`_. exceptions. See `Explicit dispatch of events`_.
The remainder of this document only discusses the design and implementation of 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 SDEI dispatcher in TF-A, and assumes that the reader is familiar with the SDEI
with the SDEI specification, the interfaces, and their requirements. specification, the interfaces, and their requirements.
.. [#std-event] Except event 0, which is defined by the SDEI specification as a .. [#std-event] Except event 0, which is defined by the SDEI specification as a
standard event. standard event.
...@@ -314,7 +314,7 @@ Note on writing SDEI event handlers ...@@ -314,7 +314,7 @@ Note on writing SDEI event handlers
----------------------------------- -----------------------------------
*This section pertains to SDEI event handlers in general, not just when using *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 The SDEI specification requires that event handlers preserve the contents of all
registers except ``x0`` to ``x17``. This has significance if event handler is 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: ...@@ -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 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 .. _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 ...@@ -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. fulfils the requirements of a security service as described above.
Management services are typically implemented at the highest level of privilege 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 in the system, i.e. EL3 in Trusted Firmware-A (TF-A). The service requirements are
fulfilled by the execution environment provided by Arm Trusted Firmware. fulfilled by the execution environment provided by TF-A.
The following diagram illustrates the corresponding software stack: The following diagram illustrates the corresponding software stack:
...@@ -41,10 +41,10 @@ Introduction ...@@ -41,10 +41,10 @@ Introduction
A **Secure Partition** is a software execution environment instantiated in A **Secure Partition** is a software execution environment instantiated in
S-EL0 that can be used to implement simple management and security services. 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 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 privileged firmware (i.e. TF-A) to be granted access to system and processor
and processor resources. Essentially, it is a software sandbox in the Secure resources. Essentially, it is a software sandbox in the Secure world that runs
world that runs under the control of privileged software, provides one or more under the control of privileged software, provides one or more services and
services and accesses the following system resources: accesses the following system resources:
- Memory and device regions in the system address map. - Memory and device regions in the system address map.
...@@ -52,25 +52,24 @@ services and accesses the following system resources: ...@@ -52,25 +52,24 @@ services and accesses the following system resources:
- A range of synchronous exceptions (e.g. SMC function identifiers). - A range of synchronous exceptions (e.g. SMC function identifiers).
Note that currently the Arm Trusted Firmware only supports handling one Secure Note that currently TF-A only supports handling one Secure Partition.
Partition.
A Secure Partition enables Arm Trusted Firmware to implement only the essential A Secure Partition enables TF-A to implement only the essential secure
secure services in EL3 and instantiate the rest in a partition in S-EL0. services in EL3 and instantiate the rest in a partition in S-EL0.
Furthermore, multiple Secure Partitions can be used to isolate unrelated Furthermore, multiple Secure Partitions can be used to isolate unrelated
services from each other. services from each other.
The following diagram illustrates the place of a Secure Partition in a typical 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 services to software components in the Non-secure world and other Secure
Partitions. Partitions.
|Image 2| |Image 2|
The Arm Trusted Firmware build system is responsible for including the Secure The TF-A build system is responsible for including the Secure Partition image
Partition image in the FIP. During boot, BL2 includes support to authenticate in the FIP. During boot, BL2 includes support to authenticate and load the
and load the Secure Partition image. A BL31 component called **Secure Partition Secure Partition image. A BL31 component called **Secure Partition Manager
Manager (SPM)** is responsible for managing the partition. This is semantically (SPM)** is responsible for managing the partition. This is semantically
similar to a hypervisor managing a virtual machine. similar to a hypervisor managing a virtual machine.
The SPM is responsible for the following actions during boot: The SPM is responsible for the following actions during boot:
...@@ -105,8 +104,8 @@ made in the current implementation of this software architecture. Subsequent ...@@ -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 revisions of the implementation will include a richer set of features that
enable a more flexible architecture. 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 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 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 ...@@ -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 Interface). This will be referred to as the *Standalone MM Secure Partition* in
the rest of this document. 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`` 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. 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 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 ...@@ -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 First, build the Standalone MM Secure Partition. To build it, refer to the
`instructions in the EDK2 repository`_. `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: image in the FIP:
:: ::
...@@ -145,10 +144,10 @@ image in the FIP: ...@@ -145,10 +144,10 @@ image in the FIP:
Describing Secure Partition resources Describing Secure Partition resources
------------------------------------- -------------------------------------
Arm Trusted Firmware exports a porting interface that enables a platform to TF-A exports a porting interface that enables a platform to specify the system
specify the system resources required by the Secure Partition. Some instructions resources required by the Secure Partition. Some instructions are given below.
are given below. However, this interface is under development and it may change However, this interface is under development and it may change as new features
as new features are implemented. are implemented.
- A Secure Partition is considered a BL32 image, so the same defines that apply - 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``. 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 ...@@ -176,9 +175,9 @@ For an example of all the changes in context, you may refer to commit
Accessing Secure Partition services 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`` 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. 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 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 ...@@ -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 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 memory area. The shared memory area is implemented as per the guidelines
specified in Section 3.2.3 of the `Management Mode Interface Specification`_ 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 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 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 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 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: ``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. ...@@ -246,7 +245,7 @@ interfaces are not accessible from the Non-secure world.
Conduit 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 and HVC conduits for accessing firmware services and their availability
depending on the implemented Exception levels. In S-EL0, the Supervisor Call depending on the implemented Exception levels. In S-EL0, the Supervisor Call
exception (SVC) is the only architectural mechanism available for unprivileged 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. ...@@ -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 Hence, the SVC conduit must be used by the Secure Partition to access interfaces
implemented by the SPM. implemented by the SPM.
A SVC causes an exception to be taken to S-EL1. Arm Trusted Firmware assumes A SVC causes an exception to be taken to S-EL1. TF-A assumes ownership of S-EL1
ownership of S-EL1 and installs a simple exception vector table in S-EL1 that and installs a simple exception vector table in S-EL1 that relays a SVC request
relays a SVC request from a Secure Partition as a SMC request to the SPM in EL3. from a Secure Partition as a SMC request to the SPM in EL3. Upon servicing the
Upon servicing the SMC request, Arm Trusted Firmware returns control directly to SMC request, Arm Trusted Firmware returns control directly to S-EL0 through an
S-EL0 through an ERET instruction. ERET instruction.
Calling conventions 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 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 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 and SVC64 calling conventions are equivalent to the 32-bit (SMC32) and the
...@@ -285,8 +284,8 @@ Communication initiated by Secure Partition ...@@ -285,8 +284,8 @@ Communication initiated by Secure Partition
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A request is initiated from the Secure Partition by executing a SVC instruction. 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 An ERET instruction is used by TF-A to return to S-EL0 with the result of the
result of the request. request.
For instance, a request to perform privileged operations on behalf of a For instance, a request to perform privileged operations on behalf of a
partition (e.g. management of memory attributes in the translation tables for partition (e.g. management of memory attributes in the translation tables for
...@@ -296,7 +295,7 @@ Interfaces ...@@ -296,7 +295,7 @@ Interfaces
^^^^^^^^^^ ^^^^^^^^^^
The current implementation reserves function IDs for Fast Calls in the Standard 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 specification) for each API exported by the SPM. This section defines the
function prototypes for each function ID. The function IDs specify whether one 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 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 ...@@ -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 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 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 "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. addition, certain other restrictions will be applied as described below.
1. ``SP_EL0`` 1. ``SP_EL0``
...@@ -601,7 +600,7 @@ address map from a Secure Partition. This is done by mapping these regions in ...@@ -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. the Secure EL1&0 Translation regime with appropriate memory attributes.
Attributes refer to memory type, permission, cacheability and shareability Attributes refer to memory type, permission, cacheability and shareability
attributes used in the Translation tables. The definitions of these attributes 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, 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 even before handing over to the Secure Partition for the first time. The initial
...@@ -813,9 +812,9 @@ Error Codes ...@@ -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 .. _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 .. _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 .. _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 ...@@ -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 OS: https://github.com/OP-TEE/build
.. _OP-TEE build.git: 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 Trusted Little Kernel (TLK) Dispatcher
====================================== ======================================
TLK dispatcher adds support for NVIDIA's Trusted Little Kernel (TLK) to work TLK dispatcher (TLK-D) adds support for NVIDIA's Trusted Little Kernel (TLK)
with the Trusted Firmware. TLK-D can be compiled by including it in the to work with Trusted Firmware-A (TF-A). TLK-D can be compiled by including it
platform's makefile. TLK is primarily meant to work with Tegra SoCs, so until in the platform's makefile. TLK is primarily meant to work with Tegra SoCs,
Trusted Firmware starts supporting Tegra, the dispatcher code can only be so while TF-A only supports TLK on Tegra, the dispatcher code can only be
compiled for other platforms. compiled for other platforms.
In order to compile TLK-D, we need a BL32 image to be present. Since, TLKD In order to compile TLK-D, we need a BL32 image to be present. Since, TLKD
...@@ -20,7 +20,7 @@ Trusted Little Kernel (TLK) ...@@ -20,7 +20,7 @@ Trusted Little Kernel (TLK)
TLK is a Trusted OS running as Secure EL1. It is a Free Open Source Software TLK is a Trusted OS running as Secure EL1. It is a Free Open Source Software
(FOSS) release of the NVIDIA® Trusted Little Kernel (TLK) technology, which (FOSS) release of the NVIDIA® Trusted Little Kernel (TLK) technology, which
extends technology made available with the development of the Little Kernel (LK). 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 x86, and AVR32 systems from https://github.com/travisg/lk
NVIDIA implemented its Trusted Little Kernel (TLK) technology, designed as a NVIDIA implemented its Trusted Little Kernel (TLK) technology, designed as a
...@@ -72,5 +72,5 @@ Example: ...@@ -72,5 +72,5 @@ Example:
:: ::
bl32_ep_info->args.arg0 = TZDRAM size available for BL32 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 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. ...@@ -28,5 +28,5 @@ should then be set to the size of that block.
Supported platforms 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. 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 ...@@ -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 normal world bootloader. It does this by establishing a Chain of Trust using
Public-Key-Cryptography Standards (PKCS). Public-Key-Cryptography Standards (PKCS).
This document describes the design of ARM Trusted Firmware TBB, which is an This document describes the design of Trusted Firmware-A (TF-A) TBB, which is
implementation of the Trusted Board Boot Requirements (TBBR) specification, an implementation of the Trusted Board Boot Requirements (TBBR) specification,
ARM DEN0006C-1. It should be used in conjunction with the `Firmware Update`_ Arm DEN0006C-1. It should be used in conjunction with the `Firmware Update`_
design document, which implements a specific aspect of the TBBR. design document, which implements a specific aspect of the TBBR.
Chain of Trust Chain of Trust
-------------- --------------
A Chain of Trust (CoT) starts with a set of implicitly trusted components. On 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 - A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the
trusted root-key storage registers. trusted root-key storage registers.
...@@ -39,7 +39,7 @@ Certificate Authority (CA) because the CoT is not established by verifying the ...@@ -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 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 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 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 The certificates are categorised as "Key" and "Content" certificates. Key
certificates are used to verify public keys which have been used to sign content certificates are used to verify public keys which have been used to sign content
...@@ -148,7 +148,7 @@ if any of the steps fail. ...@@ -148,7 +148,7 @@ if any of the steps fail.
registers. If they match, the BL2 hash is read from the certificate. registers. If they match, the BL2 hash is read from the certificate.
Note: the matching operation is platform specific and is currently Note: 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 - BL1 loads the BL2 image. Its hash is calculated and compared with the hash
read from the certificate. Control is transferred to the BL2 image if all read from the certificate. Control is transferred to the BL2 image if all
...@@ -196,7 +196,7 @@ enabled through use of specific build flags as described in the `User Guide`_. ...@@ -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 On the host machine, a tool generates the certificates, which are included in
the FIP along with the boot loader images. These certificates are loaded in the FIP along with the boot loader images. These certificates are loaded in
Trusted SRAM using the IO storage framework. They are then verified by an 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 The mechanism used for generating the FIP and the Authentication module are
described in the following sections. described in the following sections.
...@@ -204,9 +204,9 @@ described in the following sections. ...@@ -204,9 +204,9 @@ described in the following sections.
Authentication Framework Authentication Framework
------------------------ ------------------------
The authentication framework included in the Trusted Firmware provides support The authentication framework included in TF-A provides support to implement
to implement the desired trusted boot sequence. ARM platforms use this framework the desired trusted boot sequence. Arm platforms use this framework to
to implement the boot requirements specified in the TBBR-client document. implement the boot requirements specified in the TBBR-client document.
More information about the authentication framework can be found in the More information about the authentication framework can be found in the
`Auth Framework`_ document. `Auth Framework`_ document.
...@@ -215,8 +215,8 @@ Certificate Generation Tool ...@@ -215,8 +215,8 @@ Certificate Generation Tool
--------------------------- ---------------------------
The ``cert_create`` tool is built and runs on the host machine as part of the 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 TF-A build process when ``GENERATE_COT=1``. It takes the boot loader images
images and keys as inputs (keys must be in PEM format) and generates the 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 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 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. 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`_. ...@@ -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 .. _Firmware Update: firmware-update.rst
.. _X.509 v3: http://www.ietf.org/rfc/rfc5280.txt .. _X.509 v3: http://www.ietf.org/rfc/rfc5280.txt
......
docs/user-guide.rst
View file @ fb45044b
ARM Trusted Firmware User Guide Trusted Firmware-A User Guide
=============================== =============================
.. section-numbering:: .. section-numbering::
...@@ -7,9 +7,9 @@ ARM Trusted Firmware User Guide ...@@ -7,9 +7,9 @@ ARM Trusted Firmware User Guide
.. contents:: .. contents::
This document describes how to build ARM Trusted Firmware (TF) and run it with a This document describes how to build Trusted Firmware-A (TF-A) and run it with a
tested set of other software components using defined configurations on the Juno tested set of other software components using defined configurations on the Juno
ARM development platform and ARM Fixed Virtual Platform (FVP) models. It is Arm development platform and Arm Fixed Virtual Platform (FVP) models. It is
possible to use other software components, configurations and platforms but that possible to use other software components, configurations and platforms but that
is outside the scope of this document. is outside the scope of this document.
...@@ -48,14 +48,13 @@ Cygwin, and Msys (MinGW) shells, using version 5.3.1 of the GNU toolchain. ...@@ -48,14 +48,13 @@ Cygwin, and Msys (MinGW) shells, using version 5.3.1 of the GNU toolchain.
Tools Tools
----- -----
Install the required packages to build Trusted Firmware with the following Install the required packages to build TF-A with the following command:
command:
:: ::
sudo apt-get install build-essential gcc make git libssl-dev sudo apt-get install build-essential gcc make git libssl-dev
ARM TF has been tested with `Linaro Release 17.10`_. TF-A has been tested with `Linaro Release 17.10`_.
Download and install the AArch32 or AArch64 little-endian GCC cross compiler. Download and install the AArch32 or AArch64 little-endian GCC cross compiler.
The `Linaro Release Notes`_ documents which version of the compiler to use for a The `Linaro Release Notes`_ documents which version of the compiler to use for a
...@@ -63,7 +62,7 @@ given Linaro Release. Also, these `Linaro instructions`_ provide further ...@@ -63,7 +62,7 @@ given Linaro Release. Also, these `Linaro instructions`_ provide further
guidance and a script, which can be used to download Linaro deliverables guidance and a script, which can be used to download Linaro deliverables
automatically. automatically.
Optionally, Trusted Firmware can be built using clang or ARM Compiler 6. Optionally, TF-A can be built using clang or Arm Compiler 6.
See instructions below on how to switch the default compiler. See instructions below on how to switch the default compiler.
In addition, the following optional packages and tools may be needed: In addition, the following optional packages and tools may be needed:
...@@ -71,26 +70,26 @@ In addition, the following optional packages and tools may be needed: ...@@ -71,26 +70,26 @@ In addition, the following optional packages and tools may be needed:
- ``device-tree-compiler`` package if you need to rebuild the Flattened Device - ``device-tree-compiler`` package if you need to rebuild the Flattened Device
Tree (FDT) source files (``.dts`` files) provided with this software. Tree (FDT) source files (``.dts`` files) provided with this software.
- For debugging, ARM `Development Studio 5 (DS-5)`_. - For debugging, Arm `Development Studio 5 (DS-5)`_.
- To create and modify the diagram files included in the documentation, `Dia`_. - To create and modify the diagram files included in the documentation, `Dia`_.
This tool can be found in most Linux distributions. Inkscape is needed to This tool can be found in most Linux distributions. Inkscape is needed to
generate the actual *.png files. generate the actual *.png files.
Getting the Trusted Firmware source code Getting the TF-A source code
---------------------------------------- ----------------------------
Download the Trusted Firmware source code from Github: Download the TF-A source code from Github:
:: ::
git clone https://github.com/ARM-software/arm-trusted-firmware.git git clone https://github.com/ARM-software/arm-trusted-firmware.git
Building the Trusted Firmware Building TF-A
----------------------------- -------------
- Before building Trusted Firmware, the environment variable ``CROSS_COMPILE`` - Before building TF-A, the environment variable ``CROSS_COMPILE`` must point
must point to the Linaro cross compiler. to the Linaro cross compiler.
For AArch64: For AArch64:
...@@ -104,15 +103,15 @@ Building the Trusted Firmware ...@@ -104,15 +103,15 @@ Building the Trusted Firmware
export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf- export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf-
It is possible to build Trusted Firmware using clang or ARM Compiler 6. It is possible to build TF-A using clang or Arm Compiler 6. To do so
To do so ``CC`` needs to point to the clang or armclang binary. Only the ``CC`` needs to point to the clang or armclang binary. Only the compiler
compiler is switched; the assembler and linker need to be provided by is switched; the assembler and linker need to be provided by the GNU
the GNU toolchain, thus ``CROSS_COMPILE`` should be set as described above. toolchain, thus ``CROSS_COMPILE`` should be set as described above.
ARM Compiler 6 will be selected when the base name of the path assigned Arm Compiler 6 will be selected when the base name of the path assigned
to ``CC`` matches the string 'armclang'. to ``CC`` matches the string 'armclang'.
For AArch64 using ARM Compiler 6: For AArch64 using Arm Compiler 6:
:: ::
...@@ -130,7 +129,7 @@ Building the Trusted Firmware ...@@ -130,7 +129,7 @@ Building the Trusted Firmware
export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu- export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu-
make CC=<path-to-clang>/bin/clang PLAT=<platform> all make CC=<path-to-clang>/bin/clang PLAT=<platform> all
- Change to the root directory of the Trusted Firmware source tree and build. - Change to the root directory of the TF-A source tree and build.
For AArch64: For AArch64:
...@@ -154,11 +153,11 @@ Building the Trusted Firmware ...@@ -154,11 +153,11 @@ Building the Trusted Firmware
- (AArch32 only) ``AARCH32_SP`` is the AArch32 EL3 Runtime Software and it - (AArch32 only) ``AARCH32_SP`` is the AArch32 EL3 Runtime Software and it
corresponds to the BL32 image. A minimal ``AARCH32_SP``, sp\_min, is corresponds to the BL32 image. A minimal ``AARCH32_SP``, sp\_min, is
provided by ARM Trusted Firmware to demonstrate how PSCI Library can provided by TF-A to demonstrate how PSCI Library can be integrated with
be integrated with an AArch32 EL3 Runtime Software. Some AArch32 EL3 an AArch32 EL3 Runtime Software. Some AArch32 EL3 Runtime Software may
Runtime Software may include other runtime services, for example include other runtime services, for example Trusted OS services. A guide
Trusted OS services. A guide to integrate PSCI library with AArch32 to integrate PSCI library with AArch32 EL3 Runtime Software can be found
EL3 Runtime Software can be found `here`_. `here`_.
- (AArch64 only) The TSP (Test Secure Payload), corresponding to the BL32 - (AArch64 only) The TSP (Test Secure Payload), corresponding to the BL32
image, is not compiled in by default. Refer to the image, is not compiled in by default. Refer to the
...@@ -198,11 +197,11 @@ Building the Trusted Firmware ...@@ -198,11 +197,11 @@ Building the Trusted Firmware
Summary of build options Summary of build options
~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
ARM Trusted Firmware build system supports the following build options. Unless The TF-A build system supports the following build options. Unless mentioned
mentioned otherwise, these options are expected to be specified at the build otherwise, these options are expected to be specified at the build command
command line and are not to be modified in any component makefiles. Note that line and are not to be modified in any component makefiles. Note that the
the build system doesn't track dependency for build options. Therefore, if any build system doesn't track dependency for build options. Therefore, if any of
of the build options are changed from a previous build, a clean build must be the build options are changed from a previous build, a clean build must be
performed. performed.
Common build options Common build options
...@@ -213,52 +212,51 @@ Common build options ...@@ -213,52 +212,51 @@ Common build options
directory containing the SP source, relative to the ``bl32/``; the directory directory containing the SP source, relative to the ``bl32/``; the directory
is expected to contain a makefile called ``<aarch32_sp-value>.mk``. is expected to contain a makefile called ``<aarch32_sp-value>.mk``.
- ``ARCH`` : Choose the target build architecture for ARM Trusted Firmware. - ``ARCH`` : Choose the target build architecture for TF-A. It can take either
It can take either ``aarch64`` or ``aarch32`` as values. By default, it is ``aarch64`` or ``aarch32`` as values. By default, it is defined to
defined to ``aarch64``. ``aarch64``.
- ``ARM_ARCH_MAJOR``: The major version of ARM Architecture to target when - ``ARM_ARCH_MAJOR``: The major version of Arm Architecture to target when
compiling ARM Trusted Firmware. Its value must be numeric, and defaults to compiling TF-A. Its value must be numeric, and defaults to 8 . See also,
8 . See also, *ARMv8 Architecture Extensions* and *Armv8 Architecture Extensions* and *Armv7 Architecture Extensions* in
*ARMv7 Architecture Extensions* in `Firmware Design`_. `Firmware Design`_.
- ``ARM_ARCH_MINOR``: The minor version of ARM Architecture to target when - ``ARM_ARCH_MINOR``: The minor version of Arm Architecture to target when
compiling ARM Trusted Firmware. Its value must be a numeric, and defaults compiling TF-A. Its value must be a numeric, and defaults to 0. See also,
to 0. See also, *ARMv8 Architecture Extensions* in `Firmware Design`_. *Armv8 Architecture Extensions* in `Firmware Design`_.
- ``ARM_GIC_ARCH``: Choice of ARM GIC architecture version used by the ARM - ``ARM_GIC_ARCH``: Choice of Arm GIC architecture version used by the Arm
Legacy GIC driver for implementing the platform GIC API. This API is used Legacy GIC driver for implementing the platform GIC API. This API is used
by the interrupt management framework. Default is 2 (that is, version 2.0). by the interrupt management framework. Default is 2 (that is, version 2.0).
This build option is deprecated. This build option is deprecated.
- ``ARM_PLAT_MT``: This flag determines whether the ARM platform layer has to - ``ARM_PLAT_MT``: This flag determines whether the Arm platform layer has to
cater for the multi-threading ``MT`` bit when accessing MPIDR. When this flag cater for the multi-threading ``MT`` bit when accessing MPIDR. When this flag
is set, the functions which deal with MPIDR assume that the ``MT`` bit in is set, the functions which deal with MPIDR assume that the ``MT`` bit in
MPIDR is set and access the bit-fields in MPIDR accordingly. Default value of MPIDR is set and access the bit-fields in MPIDR accordingly. Default value of
this flag is 0. Note that this option is not used on FVP platforms. this flag is 0. Note that this option is not used on FVP platforms.
- ``BL2``: This is an optional build option which specifies the path to BL2 - ``BL2``: This is an optional build option which specifies the path to BL2
image for the ``fip`` target. In this case, the BL2 in the ARM Trusted image for the ``fip`` target. In this case, the BL2 in the TF-A will not be
Firmware will not be built. built.
- ``BL2U``: This is an optional build option which specifies the path to - ``BL2U``: This is an optional build option which specifies the path to
BL2U image. In this case, the BL2U in the ARM Trusted Firmware will not BL2U image. In this case, the BL2U in TF-A will not be built.
be built.
- ``BL2_AT_EL3``: This is an optional build option that enables the use of - ``BL2_AT_EL3``: This is an optional build option that enables the use of
BL2 at EL3 execution level. BL2 at EL3 execution level.
- ``BL31``: This is an optional build option which specifies the path to - ``BL31``: This is an optional build option which specifies the path to
BL31 image for the ``fip`` target. In this case, the BL31 in the ARM BL31 image for the ``fip`` target. In this case, the BL31 in TF-A will not
Trusted Firmware will not be built. be built.
- ``BL31_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the - ``BL31_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the
file that contains the BL31 private key in PEM format. If ``SAVE_KEYS=1``, file that contains the BL31 private key in PEM format. If ``SAVE_KEYS=1``,
this file name will be used to save the key. this file name will be used to save the key.
- ``BL32``: This is an optional build option which specifies the path to - ``BL32``: This is an optional build option which specifies the path to
BL32 image for the ``fip`` target. In this case, the BL32 in the ARM BL32 image for the ``fip`` target. In this case, the BL32 in TF-A will not
Trusted Firmware will not be built. be built.
- ``BL32_EXTRA1``: This is an optional build option which specifies the path to - ``BL32_EXTRA1``: This is an optional build option which specifies the path to
Trusted OS Extra1 image for the ``fip`` target. Trusted OS Extra1 image for the ``fip`` target.
...@@ -271,7 +269,7 @@ Common build options ...@@ -271,7 +269,7 @@ Common build options
this file name will be used to save the key. this file name will be used to save the key.
- ``BL33``: Path to BL33 image in the host file system. This is mandatory for - ``BL33``: Path to BL33 image in the host file system. This is mandatory for
``fip`` target in case the BL2 from ARM Trusted Firmware is used. ``fip`` target in case TF-A BL2 is used.
- ``BL33_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the - ``BL33_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the
file that contains the BL33 private key in PEM format. If ``SAVE_KEYS=1``, file that contains the BL33 private key in PEM format. If ``SAVE_KEYS=1``,
...@@ -282,8 +280,8 @@ Common build options ...@@ -282,8 +280,8 @@ Common build options
where applicable). Defaults to a string that contains the time and date of where applicable). Defaults to a string that contains the time and date of
the compilation. the compilation.
- ``BUILD_STRING``: Input string for VERSION\_STRING, which allows the TF build - ``BUILD_STRING``: Input string for VERSION\_STRING, which allows the TF-A
to be uniquely identified. Defaults to the current git commit id. build to be uniquely identified. Defaults to the current git commit id.
- ``CFLAGS``: Extra user options appended on the compiler's command line in - ``CFLAGS``: Extra user options appended on the compiler's command line in
addition to the options set by the build system. addition to the options set by the build system.
...@@ -347,10 +345,10 @@ Common build options ...@@ -347,10 +345,10 @@ Common build options
software. software.
- ``ENABLE_RUNTIME_INSTRUMENTATION``: Boolean option to enable runtime - ``ENABLE_RUNTIME_INSTRUMENTATION``: Boolean option to enable runtime
instrumentation which injects timestamp collection points into instrumentation which injects timestamp collection points into TF-A to
Trusted Firmware to allow runtime performance to be measured. allow runtime performance to be measured. Currently, only PSCI is
Currently, only PSCI is instrumented. Enabling this option enables instrumented. Enabling this option enables the ``ENABLE_PMF`` build option
the ``ENABLE_PMF`` build option as well. Default is 0. as well. Default is 0.
- ``ENABLE_SPE_FOR_LOWER_ELS`` : Boolean option to enable Statistical Profiling - ``ENABLE_SPE_FOR_LOWER_ELS`` : Boolean option to enable Statistical Profiling
extensions. This is an optional architectural feature for AArch64. extensions. This is an optional architectural feature for AArch64.
...@@ -427,15 +425,15 @@ Common build options ...@@ -427,15 +425,15 @@ Common build options
- ``HANDLE_EA_EL3_FIRST``: When defined External Aborts and SError Interrupts - ``HANDLE_EA_EL3_FIRST``: When defined External Aborts and SError Interrupts
will be always trapped in EL3 i.e. in BL31 at runtime. will be always trapped in EL3 i.e. in BL31 at runtime.
- ``HW_ASSISTED_COHERENCY``: On most ARM systems to-date, platform-specific - ``HW_ASSISTED_COHERENCY``: On most Arm systems to-date, platform-specific
software operations are required for CPUs to enter and exit coherency. software operations are required for CPUs to enter and exit coherency.
However, there exists newer systems where CPUs' entry to and exit from However, there exists newer systems where CPUs' entry to and exit from
coherency is managed in hardware. Such systems require software to only coherency is managed in hardware. Such systems require software to only
initiate the operations, and the rest is managed in hardware, minimizing initiate the operations, and the rest is managed in hardware, minimizing
active software management. In such systems, this boolean option enables ARM active software management. In such systems, this boolean option enables
Trusted Firmware to carry out build and run-time optimizations during boot TF-A to carry out build and run-time optimizations during boot and power
and power management operations. This option defaults to 0 and if it is management operations. This option defaults to 0 and if it is enabled,
enabled, then it implies ``WARMBOOT_ENABLE_DCACHE_EARLY`` is also enabled. then it implies ``WARMBOOT_ENABLE_DCACHE_EARLY`` is also enabled.
- ``JUNO_AARCH32_EL3_RUNTIME``: This build flag enables you to execute EL3 - ``JUNO_AARCH32_EL3_RUNTIME``: This build flag enables you to execute EL3
runtime software in AArch32 mode, which is required to run AArch32 on Juno. runtime software in AArch32 mode, which is required to run AArch32 on Juno.
...@@ -497,10 +495,10 @@ Common build options ...@@ -497,10 +495,10 @@ Common build options
any register that is not part of the SBSA generic UART specification. any register that is not part of the SBSA generic UART specification.
Default value is 0 (a full PL011 compliant UART is present). Default value is 0 (a full PL011 compliant UART is present).
- ``PLAT``: Choose a platform to build ARM Trusted Firmware for. The chosen - ``PLAT``: Choose a platform to build TF-A for. The chosen platform name
platform name must be subdirectory of any depth under ``plat/``, and must must be subdirectory of any depth under ``plat/``, and must contain a
contain a platform makefile named ``platform.mk``. For example to build ARM platform makefile named ``platform.mk``. For example, to build TF-A for the
Trusted Firmware for ARM Juno board select PLAT=juno. Arm Juno board, select PLAT=juno.
- ``PRELOADED_BL33_BASE``: This option enables booting a preloaded BL33 image - ``PRELOADED_BL33_BASE``: This option enables booting a preloaded BL33 image
instead of the normal boot flow. When defined, it must specify the entry instead of the normal boot flow. When defined, it must specify the entry
...@@ -524,7 +522,7 @@ Common build options ...@@ -524,7 +522,7 @@ Common build options
means by default the original power-state format is used by the PSCI means by default the original power-state format is used by the PSCI
implementation. This flag should be specified by the platform makefile implementation. This flag should be specified by the platform makefile
and it governs the return value of PSCI\_FEATURES API for CPU\_SUSPEND and it governs the return value of PSCI\_FEATURES API for CPU\_SUSPEND
smc function id. When this option is enabled on ARM platforms, the smc function id. When this option is enabled on Arm platforms, the
option ``ARM_RECOM_STATE_ID_ENC`` needs to be set to 1 as well. option ``ARM_RECOM_STATE_ID_ENC`` needs to be set to 1 as well.
- ``RESET_TO_BL31``: Enable BL31 entrypoint as the CPU reset vector instead - ``RESET_TO_BL31``: Enable BL31 entrypoint as the CPU reset vector instead
...@@ -532,11 +530,10 @@ Common build options ...@@ -532,11 +530,10 @@ Common build options
entrypoint) or 1 (CPU reset to BL31 entrypoint). entrypoint) or 1 (CPU reset to BL31 entrypoint).
The default value is 0. The default value is 0.
- ``RESET_TO_SP_MIN``: SP\_MIN is the minimal AArch32 Secure Payload provided in - ``RESET_TO_SP_MIN``: SP\_MIN is the minimal AArch32 Secure Payload provided
ARM Trusted Firmware. This flag configures SP\_MIN entrypoint as the CPU in TF-A. This flag configures SP\_MIN entrypoint as the CPU reset vector
reset vector instead of the BL1 entrypoint. It can take the value 0 (CPU instead of the BL1 entrypoint. It can take the value 0 (CPU reset to BL1
reset to BL1 entrypoint) or 1 (CPU reset to SP\_MIN entrypoint). The default entrypoint) or 1 (CPU reset to SP\_MIN entrypoint). The default value is 0.
value is 0.
- ``ROT_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the - ``ROT_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the
file that contains the ROT private key in PEM format. If ``SAVE_KEYS=1``, this file that contains the ROT private key in PEM format. If ``SAVE_KEYS=1``, this
...@@ -570,11 +567,11 @@ Common build options ...@@ -570,11 +567,11 @@ Common build options
pages" section in `Firmware Design`_. This flag is disabled by default and pages" section in `Firmware Design`_. This flag is disabled by default and
affects all BL images. affects all BL images.
- ``SPD``: Choose a Secure Payload Dispatcher component to be built into the - ``SPD``: Choose a Secure Payload Dispatcher component to be built into TF-A.
Trusted Firmware. This build option is only valid if ``ARCH=aarch64``. The This build option is only valid if ``ARCH=aarch64``. The value should be
value should be the path to the directory containing the SPD source, the path to the directory containing the SPD source, relative to
relative to ``services/spd/``; the directory is expected to ``services/spd/``; the directory is expected to contain a makefile called
contain a makefile called ``<spd-value>.mk``. ``<spd-value>.mk``.
- ``SPIN_ON_BL1_EXIT``: This option introduces an infinite loop in BL1. It can - ``SPIN_ON_BL1_EXIT``: This option introduces an infinite loop in BL1. It can
take either 0 (no loop) or 1 (add a loop). 0 is the default. This loop stops take either 0 (no loop) or 1 (add a loop). 0 is the default. This loop stops
...@@ -622,16 +619,16 @@ Common build options ...@@ -622,16 +619,16 @@ Common build options
- ``USE_COHERENT_MEM``: This flag determines whether to include the coherent - ``USE_COHERENT_MEM``: This flag determines whether to include the coherent
memory region in the BL memory map or not (see "Use of Coherent memory in memory region in the BL memory map or not (see "Use of Coherent memory in
Trusted Firmware" section in `Firmware Design`_). It can take the value 1 TF-A" section in `Firmware Design`_). It can take the value 1
(Coherent memory region is included) or 0 (Coherent memory region is (Coherent memory region is included) or 0 (Coherent memory region is
excluded). Default is 1. excluded). Default is 1.
- ``V``: Verbose build. If assigned anything other than 0, the build commands - ``V``: Verbose build. If assigned anything other than 0, the build commands
are printed. Default is 0. are printed. Default is 0.
- ``VERSION_STRING``: String used in the log output for each TF image. Defaults - ``VERSION_STRING``: String used in the log output for each TF-A image.
to a string formed by concatenating the version number, build type and build Defaults to a string formed by concatenating the version number, build type
string. and build string.
- ``WARMBOOT_ENABLE_DCACHE_EARLY`` : Boolean option to enable D-cache early on - ``WARMBOOT_ENABLE_DCACHE_EARLY`` : Boolean option to enable D-cache early on
the CPU after warm boot. This is applicable for platforms which do not the CPU after warm boot. This is applicable for platforms which do not
...@@ -639,7 +636,7 @@ Common build options ...@@ -639,7 +636,7 @@ Common build options
cluster platforms). If this option is enabled, then warm boot path cluster platforms). If this option is enabled, then warm boot path
enables D-caches immediately after enabling MMU. This option defaults to 0. enables D-caches immediately after enabling MMU. This option defaults to 0.
ARM development platform specific build options Arm development platform specific build options
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- ``ARM_BL31_IN_DRAM``: Boolean option to select loading of BL31 in TZC secured - ``ARM_BL31_IN_DRAM``: Boolean option to select loading of BL31 in TZC secured
...@@ -652,7 +649,7 @@ ARM development platform specific build options ...@@ -652,7 +649,7 @@ ARM development platform specific build options
of the memory reserved for each image. This affects the maximum size of each of the memory reserved for each image. This affects the maximum size of each
BL image as well as the number of allocated memory regions and translation BL image as well as the number of allocated memory regions and translation
tables. By default this flag is 0, which means it uses the default tables. By default this flag is 0, which means it uses the default
unoptimised values for these macros. ARM development platforms that wish to unoptimised values for these macros. Arm development platforms that wish to
optimise memory usage need to set this flag to 1 and must override the optimise memory usage need to set this flag to 1 and must override the
related macros. related macros.
...@@ -663,7 +660,7 @@ ARM development platform specific build options ...@@ -663,7 +660,7 @@ ARM development platform specific build options
Default is true (access to the frame is allowed). Default is true (access to the frame is allowed).
- ``ARM_DISABLE_TRUSTED_WDOG``: boolean option to disable the Trusted Watchdog. - ``ARM_DISABLE_TRUSTED_WDOG``: boolean option to disable the Trusted Watchdog.
By default, ARM platforms use a watchdog to trigger a system reset in case By default, Arm platforms use a watchdog to trigger a system reset in case
an error is encountered during the boot process (for example, when an image an error is encountered during the boot process (for example, when an image
could not be loaded or authenticated). The watchdog is enabled in the early could not be loaded or authenticated). The watchdog is enabled in the early
platform setup hook at BL1 and disabled in the BL1 prepare exit hook. The platform setup hook at BL1 and disabled in the BL1 prepare exit hook. The
...@@ -680,7 +677,7 @@ ARM development platform specific build options ...@@ -680,7 +677,7 @@ ARM development platform specific build options
- ``ARM_ROTPK_LOCATION``: used when ``TRUSTED_BOARD_BOOT=1``. It specifies the - ``ARM_ROTPK_LOCATION``: used when ``TRUSTED_BOARD_BOOT=1``. It specifies the
location of the ROTPK hash returned by the function ``plat_get_rotpk_info()`` location of the ROTPK hash returned by the function ``plat_get_rotpk_info()``
for ARM platforms. Depending on the selected option, the proper private key for Arm platforms. Depending on the selected option, the proper private key
must be specified using the ``ROT_KEY`` option when building the Trusted must be specified using the ``ROT_KEY`` option when building the Trusted
Firmware. This private key will be used by the certificate generation tool Firmware. This private key will be used by the certificate generation tool
to sign the BL2 and Trusted Key certificates. Available options for to sign the BL2 and Trusted Key certificates. Available options for
...@@ -707,27 +704,26 @@ ARM development platform specific build options ...@@ -707,27 +704,26 @@ ARM development platform specific build options
- ``dram`` : Secure region in DRAM (default option when TBB is enabled, - ``dram`` : Secure region in DRAM (default option when TBB is enabled,
configured by the TrustZone controller) configured by the TrustZone controller)
- ``ARM_XLAT_TABLES_LIB_V1``: boolean option to compile the Trusted Firmware - ``ARM_XLAT_TABLES_LIB_V1``: boolean option to compile TF-A with version 1
with version 1 of the translation tables library instead of version 2. It is of the translation tables library instead of version 2. It is set to 0 by
set to 0 by default, which selects version 2. default, which selects version 2.
- ``ARM_CRYPTOCELL_INTEG`` : bool option to enable Trusted Firmware to invoke - ``ARM_CRYPTOCELL_INTEG`` : bool option to enable TF-A to invoke Arm®
ARM® TrustZone® CryptoCell functionality for Trusted Board Boot on capable TrustZone® CryptoCell functionality for Trusted Board Boot on capable Arm
ARM platforms. If this option is specified, then the path to the CryptoCell platforms. If this option is specified, then the path to the CryptoCell
SBROM library must be specified via ``CCSBROM_LIB_PATH`` flag. SBROM library must be specified via ``CCSBROM_LIB_PATH`` flag.
For a better understanding of these options, the ARM development platform memory For a better understanding of these options, the Arm development platform memory
map is explained in the `Firmware Design`_. map is explained in the `Firmware Design`_.
ARM CSS platform specific build options Arm CSS platform specific build options
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- ``CSS_DETECT_PRE_1_7_0_SCP``: Boolean flag to detect SCP version - ``CSS_DETECT_PRE_1_7_0_SCP``: Boolean flag to detect SCP version
incompatibility. Version 1.7.0 of the SCP firmware made a non-backwards incompatibility. Version 1.7.0 of the SCP firmware made a non-backwards
compatible change to the MTL protocol, used for AP/SCP communication. compatible change to the MTL protocol, used for AP/SCP communication.
Trusted Firmware no longer supports earlier SCP versions. If this option is TF-A no longer supports earlier SCP versions. If this option is set to 1
set to 1 then Trusted Firmware will detect if an earlier version is in use. then TF-A will detect if an earlier version is in use. Default is 1.
Default is 1.
- ``CSS_LOAD_SCP_IMAGES``: Boolean flag, which when set, adds SCP\_BL2 and - ``CSS_LOAD_SCP_IMAGES``: Boolean flag, which when set, adds SCP\_BL2 and
SCP\_BL2U to the FIP and FWU\_FIP respectively, and enables them to be loaded SCP\_BL2U to the FIP and FWU\_FIP respectively, and enables them to be loaded
...@@ -738,13 +734,12 @@ ARM CSS platform specific build options ...@@ -738,13 +734,12 @@ ARM CSS platform specific build options
management operations and for SCP RAM Firmware transfer. If this option management operations and for SCP RAM Firmware transfer. If this option
is set to 1, then SCMI/SDS drivers will be used. Default is 0. is set to 1, then SCMI/SDS drivers will be used. Default is 0.
ARM FVP platform specific build options Arm FVP platform specific build options
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- ``FVP_CLUSTER_COUNT`` : Configures the cluster count to be used to - ``FVP_CLUSTER_COUNT`` : Configures the cluster count to be used to
build the topology tree within Trusted Firmware. By default the build the topology tree within TF-A. By default TF-A is configured for dual
Trusted Firmware is configured for dual cluster topology and this option cluster topology and this option can be used to override the default value.
can be used to override the default value.
- ``FVP_INTERCONNECT_DRIVER``: Selects the interconnect driver to be built. The - ``FVP_INTERCONNECT_DRIVER``: Selects the interconnect driver to be built. The
default interconnect driver depends on the value of ``FVP_CLUSTER_COUNT`` as default interconnect driver depends on the value of ``FVP_CLUSTER_COUNT`` as
...@@ -768,9 +763,8 @@ ARM FVP platform specific build options ...@@ -768,9 +763,8 @@ ARM FVP platform specific build options
- ``FVP_GICV2`` : The GICv2 only driver is selected - ``FVP_GICV2`` : The GICv2 only driver is selected
- ``FVP_GICV3`` : The GICv3 only driver is selected (default option) - ``FVP_GICV3`` : The GICv3 only driver is selected (default option)
- ``FVP_GICV3_LEGACY``: The Legacy GICv3 driver is selected (deprecated) - ``FVP_GICV3_LEGACY``: The Legacy GICv3 driver is selected (deprecated)
Note: If Trusted Firmware is compiled with this option on FVPs with Note: If TF-A is compiled with this option on FVPs with GICv3 hardware,
GICv3 hardware, then it configures the hardware to run in GICv2 then it configures the hardware to run in GICv2 emulation mode
emulation mode
- ``FVP_USE_SP804_TIMER`` : Use the SP804 timer instead of the Generic Timer - ``FVP_USE_SP804_TIMER`` : Use the SP804 timer instead of the Generic Timer
for functions that wait for an arbitrary time length (udelay and mdelay). for functions that wait for an arbitrary time length (udelay and mdelay).
...@@ -808,7 +802,7 @@ When debugging logic problems it might also be useful to disable all compiler ...@@ -808,7 +802,7 @@ When debugging logic problems it might also be useful to disable all compiler
optimizations by using ``-O0``. optimizations by using ``-O0``.
NOTE: Using ``-O0`` could cause output images to be larger and base addresses 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 might need to be recalculated (see the **Memory layout on Arm development
platforms** section in the `Firmware Design`_). platforms** section in the `Firmware Design`_).
Extra debug options can be passed to the build system by setting ``CFLAGS`` or Extra debug options can be passed to the build system by setting ``CFLAGS`` or
...@@ -823,8 +817,8 @@ Note that using ``-Wl,`` style compilation driver options in ``CFLAGS`` will be ...@@ -823,8 +817,8 @@ Note that using ``-Wl,`` style compilation driver options in ``CFLAGS`` will be
ignored as the linker is called directly. ignored as the linker is called directly.
It is also possible to introduce an infinite loop to help in debugging the It is also possible to introduce an infinite loop to help in debugging the
post-BL2 phase of the Trusted Firmware. This can be done by rebuilding BL1 with post-BL2 phase of TF-A. This can be done by rebuilding BL1 with the
the ``SPIN_ON_BL1_EXIT=1`` build flag. Refer to the `Summary of build options`_ ``SPIN_ON_BL1_EXIT=1`` build flag. Refer to the `Summary of build options`_
section. In this case, the developer may take control of the target using a section. In this case, the developer may take control of the target using a
debugger when indicated by the console output. When using DS-5, the following debugger when indicated by the console output. When using DS-5, the following
commands can be used: commands can be used:
...@@ -852,8 +846,8 @@ called the TSPD. Therefore, if you intend to use the TSP, the BL31 image ...@@ -852,8 +846,8 @@ called the TSPD. Therefore, if you intend to use the TSP, the BL31 image
must be recompiled as well. For more information on SPs and SPDs, see the must be recompiled as well. For more information on SPs and SPDs, see the
`Secure-EL1 Payloads and Dispatchers`_ section in the `Firmware Design`_. `Secure-EL1 Payloads and Dispatchers`_ section in the `Firmware Design`_.
First clean the Trusted Firmware build directory to get rid of any previous First clean the TF-A build directory to get rid of any previous BL31 binary.
BL31 binary. Then to build the TSP image use: Then to build the TSP image use:
:: ::
...@@ -895,17 +889,17 @@ is set to ``origin/master``. ...@@ -895,17 +889,17 @@ is set to ``origin/master``.
Building and using the FIP tool Building and using the FIP tool
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Firmware Image Package (FIP) is a packaging format used by the Trusted Firmware Firmware Image Package (FIP) is a packaging format used by TF-A to package
project to package firmware images in a single binary. The number and type of firmware images in a single binary. The number and type of images that should
images that should be packed in a FIP is platform specific and may include TF be packed in a FIP is platform specific and may include TF-A images and other
images and other firmware images required by the platform. For example, most firmware images required by the platform. For example, most platforms require
platforms require a BL33 image which corresponds to the normal world bootloader a BL33 image which corresponds to the normal world bootloader (e.g. UEFI or
(e.g. UEFI or U-Boot). U-Boot).
The TF build system provides the make target ``fip`` to create a FIP file for the The TF-A build system provides the make target ``fip`` to create a FIP file
specified platform using the FIP creation tool included in the TF project. for the specified platform using the FIP creation tool included in the TF-A
Examples below show how to build a FIP file for FVP, packaging TF images and a project. Examples below show how to build a FIP file for FVP, packaging TF-A
BL33 image. and BL33 images.
For AArch64: For AArch64:
...@@ -1026,9 +1020,10 @@ images with support for these features: ...@@ -1026,9 +1020,10 @@ images with support for these features:
#. Fulfill the dependencies of the ``mbedtls`` cryptographic and image parser #. Fulfill the dependencies of the ``mbedtls`` cryptographic and image parser
modules by checking out a recent version of the `mbed TLS Repository`_. It modules by checking out a recent version of the `mbed TLS Repository`_. It
is important to use a version that is compatible with TF and fixes any is important to use a version that is compatible with TF-A and fixes any
known security vulnerabilities. See `mbed TLS Security Center`_ for more known security vulnerabilities. See `mbed TLS Security Center`_ for more
information. The latest version of TF is tested with tag ``mbedtls-2.6.0``. information. The latest version of TF-A is tested with tag
``mbedtls-2.6.0``.
The ``drivers/auth/mbedtls/mbedtls_*.mk`` files contain the list of mbed TLS The ``drivers/auth/mbedtls/mbedtls_*.mk`` files contain the list of mbed TLS
source files the modules depend upon. source files the modules depend upon.
...@@ -1036,17 +1031,17 @@ images with support for these features: ...@@ -1036,17 +1031,17 @@ images with support for these features:
options required to build the mbed TLS sources. options required to build the mbed TLS sources.
Note that the mbed TLS library is licensed under the Apache version 2.0 Note that the mbed TLS library is licensed under the Apache version 2.0
license. Using mbed TLS source code will affect the licensing of license. Using mbed TLS source code will affect the licensing of TF-A
Trusted Firmware binaries that are built using this library. binaries that are built using this library.
#. To build the FIP image, ensure the following command line variables are set #. To build the FIP image, ensure the following command line variables are set
while invoking ``make`` to build Trusted Firmware: while invoking ``make`` to build TF-A:
- ``MBEDTLS_DIR=<path of the directory containing mbed TLS sources>`` - ``MBEDTLS_DIR=<path of the directory containing mbed TLS sources>``
- ``TRUSTED_BOARD_BOOT=1`` - ``TRUSTED_BOARD_BOOT=1``
- ``GENERATE_COT=1`` - ``GENERATE_COT=1``
In the case of ARM platforms, the location of the ROTPK hash must also be In the case of Arm platforms, the location of the ROTPK hash must also be
specified at build time. Two locations are currently supported (see specified at build time. Two locations are currently supported (see
``ARM_ROTPK_LOCATION`` build option): ``ARM_ROTPK_LOCATION`` build option):
...@@ -1060,11 +1055,11 @@ images with support for these features: ...@@ -1060,11 +1055,11 @@ images with support for these features:
available. available.
- ``ARM_ROTPK_LOCATION=devel_rsa``: use the ROTPK hash that is hardcoded - ``ARM_ROTPK_LOCATION=devel_rsa``: use the ROTPK hash that is hardcoded
in the ARM platform port. The private/public RSA key pair may be in the Arm platform port. The private/public RSA key pair may be
found in ``plat/arm/board/common/rotpk``. found in ``plat/arm/board/common/rotpk``.
- ``ARM_ROTPK_LOCATION=devel_ecdsa``: use the ROTPK hash that is hardcoded - ``ARM_ROTPK_LOCATION=devel_ecdsa``: use the ROTPK hash that is hardcoded
in the ARM platform port. The private/public ECDSA key pair may be in the Arm platform port. The private/public ECDSA key pair may be
found in ``plat/arm/board/common/rotpk``. found in ``plat/arm/board/common/rotpk``.
Example of command line using RSA development keys: Example of command line using RSA development keys:
...@@ -1086,7 +1081,7 @@ images with support for these features: ...@@ -1086,7 +1081,7 @@ images with support for these features:
#. The optional FWU\_FIP contains any additional images to be loaded from #. The optional FWU\_FIP contains any additional images to be loaded from
Non-Volatile storage during the `Firmware Update`_ process. To build the Non-Volatile storage during the `Firmware Update`_ process. To build the
FWU\_FIP, any FWU images required by the platform must be specified on the FWU\_FIP, any FWU images required by the platform must be specified on the
command line. On ARM development platforms like Juno, these are: command line. On Arm development platforms like Juno, these are:
- NS\_BL2U. The AP non-secure Firmware Updater image. - NS\_BL2U. The AP non-secure Firmware Updater image.
- SCP\_BL2U. The SCP Firmware Update Configuration image. - SCP\_BL2U. The SCP Firmware Update Configuration image.
...@@ -1121,9 +1116,10 @@ images with support for these features: ...@@ -1121,9 +1116,10 @@ images with support for these features:
Building the Certificate Generation Tool Building the Certificate Generation Tool
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``cert_create`` tool is built as part of the TF build process when the ``fip`` The ``cert_create`` tool is built as part of the TF-A build process when the
make target is specified and TBB is enabled (as described in the previous ``fip`` make target is specified and TBB is enabled (as described in the
section), but it can also be built separately with the following command: previous section), but it can also be built separately with the following
command:
:: ::
...@@ -1188,7 +1184,7 @@ corrupted binaries. ...@@ -1188,7 +1184,7 @@ corrupted binaries.
Note for AArch32, the instructions below assume that nt-fw.bin is a custom Note for AArch32, the instructions below assume that nt-fw.bin is a custom
Normal world boot loader that supports AArch32. Normal world boot loader that supports AArch32.
#. Build TF images and create a new FIP for FVP #. Build TF-A images and create a new FIP for FVP
:: ::
...@@ -1198,7 +1194,7 @@ corrupted binaries. ...@@ -1198,7 +1194,7 @@ corrupted binaries.
# AArch32 # AArch32
make PLAT=fvp ARCH=aarch32 AARCH32_SP=sp_min BL33=nt-fw.bin all fip make PLAT=fvp ARCH=aarch32 AARCH32_SP=sp_min BL33=nt-fw.bin all fip
#. Build TF images and create a new FIP for Juno #. Build TF-A images and create a new FIP for Juno
For AArch64: For AArch64:
...@@ -1322,16 +1318,16 @@ scratch, this is a complex task on some platforms, depending on the level of ...@@ -1322,16 +1318,16 @@ scratch, this is a complex task on some platforms, depending on the level of
configuration required to put the system in the expected state. configuration required to put the system in the expected state.
Rather than booting a baremetal application, a possible compromise is to boot Rather than booting a baremetal application, a possible compromise is to boot
``EL3 payloads`` through the Trusted Firmware instead. This is implemented as an ``EL3 payloads`` through TF-A instead. This is implemented as an alternative
alternative boot flow, where a modified BL2 boots an EL3 payload, instead of boot flow, where a modified BL2 boots an EL3 payload, instead of loading the
loading the other BL images and passing control to BL31. It reduces the other BL images and passing control to BL31. It reduces the complexity of
complexity of developing EL3 baremetal code by: developing EL3 baremetal code by:
- putting the system into a known architectural state; - putting the system into a known architectural state;
- taking care of platform secure world initialization; - taking care of platform secure world initialization;
- loading the SCP\_BL2 image if required by the platform. - loading the SCP\_BL2 image if required by the platform.
When booting an EL3 payload on ARM standard platforms, the configuration of the When booting an EL3 payload on Arm standard platforms, the configuration of the
TrustZone controller is simplified such that only region 0 is enabled and is TrustZone controller is simplified such that only region 0 is enabled and is
configured to permit secure access only. This gives full access to the whole configured to permit secure access only. This gives full access to the whole
DRAM to the EL3 payload. DRAM to the EL3 payload.
...@@ -1350,11 +1346,11 @@ Booting an EL3 payload ...@@ -1350,11 +1346,11 @@ Booting an EL3 payload
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
The EL3 payload image is a standalone image and is not part of the FIP. It is The EL3 payload image is a standalone image and is not part of the FIP. It is
not loaded by the Trusted Firmware. Therefore, there are 2 possible scenarios: not loaded by TF-A. Therefore, there are 2 possible scenarios:
- The EL3 payload may reside in non-volatile memory (NVM) and execute in - The EL3 payload may reside in non-volatile memory (NVM) and execute in
place. In this case, booting it is just a matter of specifying the right place. In this case, booting it is just a matter of specifying the right
address in NVM through ``EL3_PAYLOAD_BASE`` when building the TF. address in NVM through ``EL3_PAYLOAD_BASE`` when building TF-A.
- The EL3 payload needs to be loaded in volatile memory (e.g. DRAM) at - The EL3 payload needs to be loaded in volatile memory (e.g. DRAM) at
run-time. run-time.
...@@ -1423,7 +1419,7 @@ used: ...@@ -1423,7 +1419,7 @@ used:
--data="/path/to/el3-payload"@address [Foundation FVP] --data="/path/to/el3-payload"@address [Foundation FVP]
The address provided to the FVP must match the ``EL3_PAYLOAD_BASE`` address The address provided to the FVP must match the ``EL3_PAYLOAD_BASE`` address
used when building the Trusted Firmware. used when building TF-A.
Booting an EL3 payload on Juno Booting an EL3 payload on Juno
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...@@ -1441,15 +1437,14 @@ Preloaded BL33 alternative boot flow ...@@ -1441,15 +1437,14 @@ Preloaded BL33 alternative boot flow
------------------------------------ ------------------------------------
Some platforms have the ability to preload BL33 into memory instead of relying Some platforms have the ability to preload BL33 into memory instead of relying
on Trusted Firmware to load it. This may simplify packaging of the normal world on TF-A to load it. This may simplify packaging of the normal world code and
code and improve performance in a development environment. When secure world improve performance in a development environment. When secure world cold boot
cold boot is complete, Trusted Firmware simply jumps to a BL33 base address is complete, TF-A simply jumps to a BL33 base address provided at build time.
provided at build time.
For this option to be used, the ``PRELOADED_BL33_BASE`` build option has to be For this option to be used, the ``PRELOADED_BL33_BASE`` build option has to be
used when compiling the Trusted Firmware. For example, the following command used when compiling TF-A. For example, the following command will create a FIP
will create a FIP without a BL33 and prepare to jump to a BL33 image loaded at without a BL33 and prepare to jump to a BL33 image loaded at address
address 0x80000000: 0x80000000:
:: ::
...@@ -1459,8 +1454,8 @@ Boot of a preloaded bootwrapped kernel image on Base FVP ...@@ -1459,8 +1454,8 @@ Boot of a preloaded bootwrapped kernel image on Base FVP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following example uses the AArch64 boot wrapper. This simplifies normal The following example uses the AArch64 boot wrapper. This simplifies normal
world booting while also making use of TF features. It can be obtained from its world booting while also making use of TF-A features. It can be obtained from
repository with: its repository with:
:: ::
...@@ -1494,13 +1489,14 @@ to load the ELF file over JTAG on Juno. ...@@ -1494,13 +1489,14 @@ to load the ELF file over JTAG on Juno.
Running the software on FVP Running the software on FVP
--------------------------- ---------------------------
The latest version of the AArch64 build of ARM Trusted Firmware has been tested The latest version of the AArch64 build of TF-A has been tested on the following
on the following ARM FVPs (64-bit host machine only). Arm FVPs without shifted affinities, and that do not support threaded CPU cores
(64-bit host machine only).
NOTE: Unless otherwise stated, the model version is Version 11.2 Build 11.2.33. NOTE: Unless otherwise stated, the model version is Version 11.2 Build 11.2.33.
- ``Foundation_Platform`` - ``Foundation_Platform``
- ``FVP_Base_AEMv8A-AEMv8A`` (Version 9.0, Build 0.8.9005) - ``FVP_Base_AEMv8A-AEMv8A`` (and also Version 9.0, Build 0.8.9005)
- ``FVP_Base_Cortex-A35x4`` - ``FVP_Base_Cortex-A35x4``
- ``FVP_Base_Cortex-A53x4`` - ``FVP_Base_Cortex-A53x4``
- ``FVP_Base_Cortex-A57x4-A53x4`` - ``FVP_Base_Cortex-A57x4-A53x4``
...@@ -1510,12 +1506,25 @@ NOTE: Unless otherwise stated, the model version is Version 11.2 Build 11.2.33. ...@@ -1510,12 +1506,25 @@ NOTE: Unless otherwise stated, the model version is Version 11.2 Build 11.2.33.
- ``FVP_Base_Cortex-A73x4-A53x4`` - ``FVP_Base_Cortex-A73x4-A53x4``
- ``FVP_Base_Cortex-A73x4`` - ``FVP_Base_Cortex-A73x4``
The latest version of the AArch32 build of ARM Trusted Firmware has been tested Additionally, the AArch64 build was tested on the following Arm FVPs with
on the following ARM FVPs (64-bit host machine only). shifted affinities, supporting threaded CPU cores (64-bit host machine only).
- ``FVP_Base_Cortex-A55x4-A75x4`` (Version 0.0, build 0.0.4395)
- ``FVP_Base_Cortex-A55x4`` (Version 0.0, build 0.0.4395)
- ``FVP_Base_Cortex-A75x4`` (Version 0.0, build 0.0.4395)
- ``FVP_Base_RevC-2xAEMv8A``
- ``FVP_Base_AEMv8A-AEMv8A`` (Version 9.0, Build 0.8.9005) The latest version of the AArch32 build of TF-A has been tested on the following
Arm FVPs without shifted affinities, and that do not support threaded CPU cores
(64-bit host machine only).
- ``FVP_Base_AEMv8A-AEMv8A``
- ``FVP_Base_Cortex-A32x4`` - ``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 build numbers quoted above are those reported by launching the FVP NOTE: The build numbers quoted above are those reported by launching the FVP
with the ``--version`` parameter. with the ``--version`` parameter.
...@@ -1529,7 +1538,7 @@ NOTE: The software will not work on Version 1.0 of the Foundation FVP. ...@@ -1529,7 +1538,7 @@ 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. The commands below would report an ``unhandled argument`` error in this case.
NOTE: FVPs can be launched with ``--cadi-server`` option such that a NOTE: 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 CADI-compliant debugger (for example, Arm DS-5) can connect to and control its
execution. execution.
NOTE: Since FVP model Version 11.0 Build 11.0.34 and Version 8.5 Build 0.8.5202 NOTE: Since FVP model Version 11.0 Build 11.0.34 and Version 8.5 Build 0.8.5202
...@@ -1538,46 +1547,59 @@ models. The models can be launched with ``-Q 100`` option if they are required ...@@ -1538,46 +1547,59 @@ models. The models can be launched with ``-Q 100`` option if they are required
to match the run time characteristics of the older versions. to match the run time characteristics of the older versions.
The Foundation FVP is a cut down version of the AArch64 Base FVP. It can be The Foundation FVP is a cut down version of the AArch64 Base FVP. It can be
downloaded for free from `ARM's website`_. downloaded for free from `Arm's website`_.
The Cortex-A models listed above are also available to download from The Cortex-A models listed above are also available to download from
`ARM's website`_. `Arm's website`_.
Please refer to the FVP documentation for a detailed description of the model Please refer to the FVP documentation for a detailed description of the model
parameter options. A brief description of the important ones that affect the ARM parameter options. A brief description of the important ones that affect TF-A
Trusted Firmware and normal world software behavior is provided below. and normal world software behavior is provided below.
Obtaining the Flattened Device Trees Obtaining the Flattened Device Trees
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Depending on the FVP configuration and Linux configuration used, different Depending on the FVP configuration and Linux configuration used, different
FDT files are required. FDTs for the Foundation and Base FVPs can be found in FDT files are required. FDTs for the Foundation and Base FVPs can be found in
the Trusted Firmware source directory under ``fdts/``. The Foundation FVP has a the TF-A source directory under ``fdts/``. The Foundation FVP has a subset of
subset of the Base FVP components. For example, the Foundation FVP lacks CLCD the Base FVP components. For example, the Foundation FVP lacks CLCD and MMC
and MMC support, and has only one CPU cluster. support, and has only one CPU cluster.
Note: It is not recommended to use the FDTs built along the kernel because not Note: It is not recommended to use the FDTs built along the kernel because not
all FDTs are available from there. all FDTs are available from there.
- ``fvp-base-gicv2-psci.dtb`` - ``fvp-base-gicv2-psci.dtb``
For use with both AEMv8 and Cortex-A57-A53 Base FVPs with For use with models such as the Cortex-A57-A53 Base FVPs without shifted
Base memory map configuration. affinities and with Base memory map configuration.
- ``fvp-base-gicv2-psci-aarch32.dtb`` - ``fvp-base-gicv2-psci-aarch32.dtb``
For use with AEMv8 and Cortex-A32 Base FVPs running Linux in AArch32 state For use with models such as the Cortex-A32 Base FVPs without shifted
with Base memory map configuration. affinities and running Linux in AArch32 state with Base memory map
configuration.
- ``fvp-base-gicv3-psci.dtb`` - ``fvp-base-gicv3-psci.dtb``
(Default) For use with both AEMv8 and Cortex-A57-A53 Base FVPs with Base For use with models such as the Cortex-A57-A53 Base FVPs without shifted
memory map configuration and Linux GICv3 support. affinities and with Base memory map configuration and Linux GICv3 support.
- ``fvp-base-gicv3-psci-1t.dtb``
For use with models such as the AEMv8-RevC Base FVP with shifted affinities,
single threaded CPUs, Base memory map configuration and Linux GICv3 support.
- ``fvp-base-gicv3-psci-dynamiq.dtb``
For use with models as the Cortex-A55-A75 Base FVPs with shifted affinities,
single cluster, single threaded CPUs, Base memory map configuration and Linux
GICv3 support.
- ``fvp-base-gicv3-psci-aarch32.dtb`` - ``fvp-base-gicv3-psci-aarch32.dtb``
For use with AEMv8 and Cortex-A32 Base FVPs running Linux in AArch32 state For use with models such as the Cortex-A32 Base FVPs without shifted
with Base memory map configuration and Linux GICv3 support. affinities and running Linux in AArch32 state with Base memory map
configuration and Linux GICv3 support.
- ``fvp-foundation-gicv2-psci.dtb`` - ``fvp-foundation-gicv2-psci.dtb``
...@@ -1592,7 +1614,7 @@ Running on the Foundation FVP with reset to BL1 entrypoint ...@@ -1592,7 +1614,7 @@ Running on the Foundation FVP with reset to BL1 entrypoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following ``Foundation_Platform`` parameters should be used to boot Linux with The following ``Foundation_Platform`` parameters should be used to boot Linux with
4 CPUs using the AArch64 build of ARM Trusted Firmware. 4 CPUs using the AArch64 build of TF-A.
:: ::
...@@ -1616,23 +1638,23 @@ Notes: ...@@ -1616,23 +1638,23 @@ Notes:
- The default use-case for the Foundation FVP is to use the ``--gicv3`` option - The default use-case for the Foundation FVP is to use the ``--gicv3`` option
and enable the GICv3 device in the model. Note that without this option, and enable the GICv3 device in the model. Note that without this option,
the Foundation FVP defaults to legacy (Versatile Express) memory map which the Foundation FVP defaults to legacy (Versatile Express) memory map which
is not supported by ARM Trusted Firmware. is not supported by TF-A.
- In order for the Arm Trusted Firmware to run correctly on the Foundation - In order for TF-A to run correctly on the Foundation FVP, the architecture
Model the architecture versions must match. The Foundation FVP defaults to versions must match. The Foundation FVP defaults to the highest v8.x
the highest v8.x version it supports but the default build for Arm Trusted version it supports but the default build for TF-A is for v8.0. To avoid
Firmware is for v8.0. To avoid issues either start the Foundation Model to issues either start the Foundation FVP to use v8.0 architecture using the
use v8.0 architecture using the ``--arm-v8.0`` option or build Arm Trusted ``--arm-v8.0`` option, or build TF-A with an appropriate value for
Firmware with an appropriate value for ``ARM_ARCH_MINOR``. ``ARM_ARCH_MINOR``.
Running on the AEMv8 Base FVP with reset to BL1 entrypoint Running on the AEMv8 Base FVP with reset to BL1 entrypoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
with 8 CPUs using the AArch64 build of ARM Trusted Firmware. with 8 CPUs using the AArch64 build of TF-A.
:: ::
<path-to>/FVP_Base_AEMv8A-AEMv8A \ <path-to>/FVP_Base_RevC-2xAEMv8A \
-C pctl.startup=0.0.0.0 \ -C pctl.startup=0.0.0.0 \
-C bp.secure_memory=1 \ -C bp.secure_memory=1 \
-C bp.tzc_400.diagnostics=1 \ -C bp.tzc_400.diagnostics=1 \
...@@ -1649,7 +1671,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint ...@@ -1649,7 +1671,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
with 8 CPUs using the AArch32 build of ARM Trusted Firmware. with 8 CPUs using the AArch32 build of TF-A.
:: ::
...@@ -1678,7 +1700,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL1 entrypoint ...@@ -1678,7 +1700,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL1 entrypoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
boot Linux with 8 CPUs using the AArch64 build of ARM Trusted Firmware. boot Linux with 8 CPUs using the AArch64 build of TF-A.
:: ::
...@@ -1697,7 +1719,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to BL1 entrypoint ...@@ -1697,7 +1719,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to BL1 entrypoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware. boot Linux with 4 CPUs using the AArch32 build of TF-A.
:: ::
...@@ -1715,12 +1737,12 @@ boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware. ...@@ -1715,12 +1737,12 @@ boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware.
Running on the AEMv8 Base FVP with reset to BL31 entrypoint Running on the AEMv8 Base FVP with reset to BL31 entrypoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux
with 8 CPUs using the AArch64 build of ARM Trusted Firmware. with 8 CPUs using the AArch64 build of TF-A.
:: ::
<path-to>/FVP_Base_AEMv8A-AEMv8A \ <path-to>/FVP_Base_RevC-2xAEMv8A \
-C pctl.startup=0.0.0.0 \ -C pctl.startup=0.0.0.0 \
-C bp.secure_memory=1 \ -C bp.secure_memory=1 \
-C bp.tzc_400.diagnostics=1 \ -C bp.tzc_400.diagnostics=1 \
...@@ -1763,7 +1785,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to SP\_MIN entrypoint ...@@ -1763,7 +1785,7 @@ Running on the AEMv8 Base FVP (AArch32) with reset to SP\_MIN entrypoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
with 8 CPUs using the AArch32 build of ARM Trusted Firmware. with 8 CPUs using the AArch32 build of TF-A.
:: ::
...@@ -1803,7 +1825,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint ...@@ -1803,7 +1825,7 @@ Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to
boot Linux with 8 CPUs using the AArch64 build of ARM Trusted Firmware. boot Linux with 8 CPUs using the AArch64 build of TF-A.
:: ::
...@@ -1831,7 +1853,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to SP\_MIN entrypoint ...@@ -1831,7 +1853,7 @@ Running on the Cortex-A32 Base FVP (AArch32) with reset to SP\_MIN entrypoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware. boot Linux with 4 CPUs using the AArch32 build of TF-A.
:: ::
...@@ -1853,8 +1875,7 @@ boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware. ...@@ -1853,8 +1875,7 @@ boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware.
Running the software on Juno Running the software on Juno
---------------------------- ----------------------------
This version of the ARM Trusted Firmware has been tested on variants r0, r1 and This version of TF-A has been tested on variants r0, r1 and r2 of Juno.
r2 of Juno.
To execute the software stack on Juno, the version of the Juno board recovery To execute the software stack on Juno, the version of the Juno board recovery
image indicated in the `Linaro Release Notes`_ must be installed. If you have an image indicated in the `Linaro Release Notes`_ must be installed. If you have an
...@@ -1862,18 +1883,18 @@ earlier version installed or are unsure which version is installed, please ...@@ -1862,18 +1883,18 @@ earlier version installed or are unsure which version is installed, please
re-install the recovery image by following the re-install the recovery image by following the
`Instructions for using Linaro's deliverables on Juno`_. `Instructions for using Linaro's deliverables on Juno`_.
Preparing Trusted Firmware images Preparing TF-A images
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
After building Trusted Firmware, the files ``bl1.bin`` and ``fip.bin`` need copying After building TF-A, the files ``bl1.bin`` and ``fip.bin`` need copying to the
to the ``SOFTWARE/`` directory of the Juno SD card. ``SOFTWARE/`` directory of the Juno SD card.
Other Juno software information Other Juno software information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please visit the `ARM Platforms Portal`_ to get support and obtain any other Juno Please visit the `Arm Platforms Portal`_ to get support and obtain any other Juno
software information. Please also refer to the `Juno Getting Started Guide`_ to software information. Please also refer to the `Juno Getting Started Guide`_ to
get more detailed information about the Juno ARM development platform and how to get more detailed information about the Juno Arm development platform and how to
configure it. configure it.
Testing SYSTEM SUSPEND on Juno Testing SYSTEM SUSPEND on Juno
...@@ -1893,7 +1914,7 @@ wakeup interrupt from RTC. ...@@ -1893,7 +1914,7 @@ wakeup interrupt from RTC.
-------------- --------------
*Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved.* *Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.*
.. _Linaro: `Linaro Release Notes`_ .. _Linaro: `Linaro Release Notes`_
.. _Linaro Release: `Linaro Release Notes`_ .. _Linaro Release: `Linaro Release Notes`_
...@@ -1901,7 +1922,7 @@ wakeup interrupt from RTC. ...@@ -1901,7 +1922,7 @@ wakeup interrupt from RTC.
.. _Linaro Release 17.10: https://community.arm.com/dev-platforms/w/docs/226/old-linaro-release-notes#1710 .. _Linaro Release 17.10: https://community.arm.com/dev-platforms/w/docs/226/old-linaro-release-notes#1710
.. _Linaro instructions: https://community.arm.com/dev-platforms/w/docs/304/linaro-software-deliverables .. _Linaro instructions: https://community.arm.com/dev-platforms/w/docs/304/linaro-software-deliverables
.. _Instructions for using Linaro's deliverables on Juno: https://community.arm.com/dev-platforms/w/docs/303/juno .. _Instructions for using Linaro's deliverables on Juno: https://community.arm.com/dev-platforms/w/docs/303/juno
.. _ARM Platforms Portal: https://community.arm.com/dev-platforms/ .. _Arm Platforms Portal: https://community.arm.com/dev-platforms/
.. _Development Studio 5 (DS-5): http://www.arm.com/products/tools/software-tools/ds-5/index.php .. _Development Studio 5 (DS-5): http://www.arm.com/products/tools/software-tools/ds-5/index.php
.. _Dia: https://wiki.gnome.org/Apps/Dia/Download .. _Dia: https://wiki.gnome.org/Apps/Dia/Download
.. _here: psci-lib-integration-guide.rst .. _here: psci-lib-integration-guide.rst
...@@ -1911,7 +1932,7 @@ wakeup interrupt from RTC. ...@@ -1911,7 +1932,7 @@ wakeup interrupt from RTC.
.. _Firmware Design: firmware-design.rst .. _Firmware Design: firmware-design.rst
.. _mbed TLS Repository: https://github.com/ARMmbed/mbedtls.git .. _mbed TLS Repository: https://github.com/ARMmbed/mbedtls.git
.. _mbed TLS Security Center: https://tls.mbed.org/security .. _mbed TLS Security Center: https://tls.mbed.org/security
.. _ARM's website: `FVP models`_ .. _Arm's website: `FVP models`_
.. _FVP models: https://developer.arm.com/products/system-design/fixed-virtual-platforms .. _FVP models: https://developer.arm.com/products/system-design/fixed-virtual-platforms
.. _Juno Getting Started Guide: http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/DUI0928E_juno_arm_development_platform_gsg.pdf .. _Juno Getting Started Guide: http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/DUI0928E_juno_arm_development_platform_gsg.pdf
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
docs/xlat-tables-lib-v2-design.rst
View file @ fb45044b
...@@ -9,7 +9,7 @@ Translation Tables Library Design ...@@ -9,7 +9,7 @@ Translation Tables Library Design
This document describes the design of the translation tables library (version 2) This document describes the design of the translation tables library (version 2)
used by 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 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 registers related to the Memory Management Unit (MMU) and performing the
required Translation Lookaside Buffer (TLB) maintenance operations. required Translation Lookaside Buffer (TLB) maintenance operations.
...@@ -329,7 +329,7 @@ The memory mapping algorithm ...@@ -329,7 +329,7 @@ The memory mapping algorithm
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The mapping function is implemented as a recursive algorithm. It is however The mapping function is implemented as a recursive algorithm. It is however
bound by the level of depth of the translation tables (the ARMv8-A architecture bound by the level of depth of the translation tables (the Armv8-A architecture
allows up to 4 lookup levels). allows up to 4 lookup levels).
By default [#granularity-ref]_, the algorithm will attempt to minimize the By default [#granularity-ref]_, the algorithm will attempt to minimize the
...@@ -376,7 +376,7 @@ changes are visible to subsequent execution, including speculative execution, ...@@ -376,7 +376,7 @@ changes are visible to subsequent execution, including speculative execution,
that uses the changed translation table entries. that uses the changed translation table entries.
A counter-example is the initialization of translation tables. In this case, 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 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 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 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 ...@@ -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 invalid translation table entry [#tlb-no-invalid-entry]_, this means that this
mapping cannot be cached in the TLBs. mapping cannot be cached in the TLBs.
.. [#tlb-reset-ref] See section D4.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 Architectural module
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
...@@ -405,7 +405,7 @@ translation context to work on. ...@@ -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\_v2: ../lib/xlat_tables_v2
.. _lib/xlat\_tables: ../lib/xlat_tables .. _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, Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met: are permitted provided that the following conditions are met:
...@@ -10,7 +10,7 @@ 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 list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution. 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 endorse or promote products derived from this software without specific prior
written permission. 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 ultimately merged by the maintainers listed below. Technical ownership of some
parts of the codebase is delegated to the sub-maintainers listed below. An parts of the codebase is delegated to the sub-maintainers listed below. An
acknowledgement from these sub-maintainers may be required before the acknowledgement from these sub-maintainers may be required before the
...@@ -123,8 +123,8 @@ Files: ...@@ -123,8 +123,8 @@ Files:
- docs/plat/xilinx-zynqmp.rst - docs/plat/xilinx-zynqmp.rst
- plat/xilinx/\* - plat/xilinx/\*
ARMv7 architecture sub-maintainer Armv7-A architecture sub-maintainer
--------------------------------- -----------------------------------
Etienne Carriere (etienne.carriere@linaro.org, `etienne-lms`_) 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 Trusted Firmware-A (TF-A) provides a reference implementation of secure world
software for `ARMv8-A`_, including a `Secure Monitor`_ executing at software for `Armv8-A`_, including a `Secure Monitor`_ executing at Exception
Exception Level 3 (EL3). It implements various ARM interface standards, such as: Level 3 (EL3). It implements various Arm interface standards, such as:
- The `Power State Coordination Interface (PSCI)`_ - 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`_ - `SMC Calling Convention`_
- `System Control and Management Interface`_ - `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. model and hardware platforms.
ARM will continue development in collaboration with interested parties to Arm will continue development in collaboration with interested parties to
provide a full reference implementation of Secure Monitor code and ARM standards provide a full reference implementation of Secure Monitor code and Arm standards
to the benefit of all developers working with ARMv8-A TrustZone technology. to the benefit of all developers working with Armv8-A TrustZone technology.
License License
------- -------
...@@ -45,7 +45,7 @@ world boot and runtime firmware, in either the AArch32 or AArch64 execution ...@@ -45,7 +45,7 @@ world boot and runtime firmware, in either the AArch32 or AArch64 execution
state. state.
Users are encouraged to do their own security validation, including penetration 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 Functionality
~~~~~~~~~~~~~ ~~~~~~~~~~~~~
...@@ -54,15 +54,15 @@ Functionality ...@@ -54,15 +54,15 @@ Functionality
registers and interrupts for the platform. registers and interrupts for the platform.
- Library support for CPU specific reset and power down sequences. This - 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), Generic Interrupt Controller (GIC), Cache Coherent Interconnect (CCI),
Cache Coherent Network (CCN), Network Interconnect (NIC) and TrustZone Cache Coherent Network (CCN), Network Interconnect (NIC) and TrustZone
Controller (TZC). Controller (TZC).
- A generic `SCMI`_ driver to interface with conforming power controllers, for - 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 - SMC (Secure Monitor Call) handling, conforming to the `SMC Calling
Convention`_ using an EL3 runtime services framework. Convention`_ using an EL3 runtime services framework.
...@@ -93,14 +93,14 @@ Functionality ...@@ -93,14 +93,14 @@ Functionality
recovery mode), and packaging of the various firmware images into a recovery mode), and packaging of the various firmware images into a
Firmware Image Package (FIP). 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. advantage of its hardware Root of Trust and crypto acceleration services.
- Support for alternative boot flows, for example to support platforms where - Support for alternative boot flows, for example to support platforms where
the EL3 Runtime Software is loaded using other firmware or a separate the EL3 Runtime Software is loaded using other firmware or a separate
secure system processor. 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 For a full description of functionality and implementation details, please
see the `Firmware Design`_ and supporting documentation. The `Change Log`_ see the `Firmware Design`_ and supporting documentation. The `Change Log`_
...@@ -110,9 +110,9 @@ Platforms ...@@ -110,9 +110,9 @@ Platforms
~~~~~~~~~ ~~~~~~~~~
Various AArch32 and AArch64 builds of this release has been tested on variants 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): `FVP`_\ s (64-bit host machine only):
NOTE: Unless otherwise stated, the FVP Version is 11.0, Build 11.0.34. 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. ...@@ -129,14 +129,14 @@ NOTE: Unless otherwise stated, the FVP Version is 11.0, Build 11.0.34.
- ``FVP_Base_Cortex-A73x4`` - ``FVP_Base_Cortex-A73x4``
- ``FVP_CSS_SGM-775`` (Version 11.0, Build 11.0.36) - ``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`_\ s (64-bit host machine only):
- ``FVP_Base_AEMv8A-AEMv8A`` (Version 8.5, Build 0.8.8502) - ``FVP_Base_AEMv8A-AEMv8A`` (Version 8.5, Build 0.8.8502)
- ``FVP_Base_Cortex-A32x4`` - ``FVP_Base_Cortex-A32x4``
The Foundation FVP can be downloaded free of charge. The Base FVPs can be The Foundation FVP can be downloaded free of charge. The Base FVPs can be
licensed from ARM. See the `ARM FVP website`_. licensed from Arm. See the `Arm FVP website`_.
All the above platforms have been tested with `Linaro Release 17.04`_. All the above platforms have been tested with `Linaro Release 17.04`_.
...@@ -167,15 +167,15 @@ Log`_ and the `GitHub issue tracker`_. ...@@ -167,15 +167,15 @@ Log`_ and the `GitHub issue tracker`_.
Getting Started 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 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 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 See the `Contributing Guidelines`_ for information on how to contribute to this
project and the `Acknowledgments`_ file for a list of contributors to the project and the `Acknowledgments`_ file for a list of contributors to the
...@@ -184,26 +184,26 @@ project. ...@@ -184,26 +184,26 @@ project.
Feedback and support Feedback and support
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
ARM welcomes any feedback on Trusted Firmware. If you think you have found a Arm welcomes any feedback on TF-A. If you think you have found a security
security vulnerability, please report this using the process defined in the vulnerability, please report this using the process defined in the TF-A
Trusted Firmware `Security Centre`_. For all other feedback, please use the `Security Centre`_. For all other feedback, please use the
`GitHub issue tracker`_. `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 .. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php
.. _Power State Coordination Interface (PSCI): PSCI_ .. _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 .. _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 .. _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_ .. _System Control and Management Interface: SCMI_
.. _SCMI: http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf .. _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 .. _Juno Arm Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php
.. _ARM FVP website: FVP_ .. _Arm FVP website: FVP_
.. _FVP: https://developer.arm.com/products/system-design/fixed-virtual-platforms .. _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 .. _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 .. _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