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

Docs: Update various for v1.5 release

docs/psci-pd-tree.rst

-PSCI Library Integration guide for ARMv8-A AArch32 systems
+PSCI Library Integration guide for Armv8-A AArch32 systems
 ==========================================================
 
 
@@ -309,4 +309,4 @@ domain nodes do not need to be identified.
 
 --------------
 
-*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*

docs/reset-design.rst

-ARM Trusted Firmware Reset Design
-=================================
+Trusted Firmware-A reset design
+===============================
 
 
 .. section-numbering::
@@ -8,9 +8,9 @@ ARM Trusted Firmware Reset Design
 .. contents::
 
 This document describes the high-level design of the framework to handle CPU
-resets in ARM Trusted Firmware. It also describes how the platform integrator
-can tailor this code to the system configuration to some extent, resulting in a
-simplified and more optimised boot flow.
+resets in Trusted Firmware-A (TF-A). It also describes how the platform
+integrator can tailor this code to the system configuration to some extent,
+resulting in a simplified and more optimised boot flow.
 
 This document should be used in conjunction with the `Firmware Design`_, which
 provides greater implementation details around the reset code, specifically
@@ -19,8 +19,8 @@ for the cold boot path.
 General reset code flow
 -----------------------
 
-The ARM Trusted Firmware (TF) reset code is implemented in BL1 by default. The
-following high-level diagram illustrates this:
+The TF-A reset code is implemented in BL1 by default. The following high-level
+diagram illustrates this:
 
 |Default reset code flow|
 
@@ -29,15 +29,15 @@ configuration, some of these steps might be unnecessary. The following sections
 guide the platform integrator by indicating which build options exclude which
 steps, depending on the capability of the platform.
 
-Note: If BL31 is used as the Trusted Firmware entry point instead of BL1, the
-diagram above is still relevant, as all these operations will occur in BL31 in
+Note: If BL31 is used as the TF-A entry point instead of BL1, the diagram
+above is still relevant, as all these operations will occur in BL31 in
 this case. Please refer to section 6 "Using BL31 entrypoint as the reset
 address" for more information.
 
 Programmable CPU reset address
 ------------------------------
 
-By default, the TF assumes that the CPU reset address is not programmable.
+By default, TF-A assumes that the CPU reset address is not programmable.
 Therefore, all CPUs start at the same address (typically address 0) whenever
 they reset. Further logic is then required to identify whether it is a cold or
 warm boot to direct CPUs to the right execution path.
@@ -49,8 +49,8 @@ detection can be skipped, resulting in the following boot flow:
 
 |Reset code flow with programmable reset address|
 
-To enable this boot flow, compile the TF with ``PROGRAMMABLE_RESET_ADDRESS=1``.
-This option only affects the TF reset image, which is BL1 by default or BL31 if
+To enable this boot flow, compile TF-A with ``PROGRAMMABLE_RESET_ADDRESS=1``.
+This option only affects the TF-A reset image, which is BL1 by default or BL31 if
 ``RESET_TO_BL31=1``.
 
 On both the FVP and Juno platforms, the reset vector address is not programmable
@@ -59,7 +59,7 @@ so both ports use ``PROGRAMMABLE_RESET_ADDRESS=0``.
 Cold boot on a single CPU
 -------------------------
 
-By default, the TF assumes that several CPUs may be released out of reset.
+By default, TF-A assumes that several CPUs may be released out of reset.
 Therefore, the cold boot code has to arbitrate access to hardware resources
 shared amongst CPUs. This is done by nominating one of the CPUs as the primary,
 which is responsible for initialising shared hardware and coordinating the boot
@@ -71,8 +71,8 @@ applies. This results in the following boot flow:
 
 |Reset code flow with single CPU released out of reset|
 
-To enable this boot flow, compile the TF with ``COLD_BOOT_SINGLE_CPU=1``. This
-option only affects the TF reset image, which is BL1 by default or BL31 if
+To enable this boot flow, compile TF-A with ``COLD_BOOT_SINGLE_CPU=1``. This
+option only affects the TF-A reset image, which is BL1 by default or BL31 if
 ``RESET_TO_BL31=1``.
 
 On both the FVP and Juno platforms, although only one core is powered up by
@@ -89,8 +89,8 @@ This results in the following boot flow:
 
 |Reset code flow with programmable reset address and single CPU released out of reset|
 
-To enable this boot flow, compile the TF with both ``COLD_BOOT_SINGLE_CPU=1``
-and ``PROGRAMMABLE_RESET_ADDRESS=1``. These options only affect the TF reset
+To enable this boot flow, compile TF-A with both ``COLD_BOOT_SINGLE_CPU=1``
+and ``PROGRAMMABLE_RESET_ADDRESS=1``. These options only affect the TF-A reset
 image, which is BL1 by default or BL31 if ``RESET_TO_BL31=1``.
 
 Using BL31 entrypoint as the reset address
@@ -102,7 +102,7 @@ on the SoC, rather than by BL1 and BL2 running on the primary application
 processor. For this type of SoC it is desirable for the application processor
 to always reset to BL31 which eliminates the need for BL1 and BL2.
 
-TF provides a build-time option ``RESET_TO_BL31`` that includes some additional
+TF-A provides a build-time option ``RESET_TO_BL31`` that includes some additional
 logic in the BL31 entry point to support this use case.
 
 In this configuration, the platform's Trusted Boot Firmware must ensure that
@@ -112,10 +112,10 @@ Additionally, platform software is responsible for loading the other BL3x images
 required and providing entry point information for them to BL31. Loading these
 images might be done by the Trusted Boot Firmware or by platform code in BL31.
 
-Although the ARM FVP platform does not support programming the reset base
+Although the Arm FVP platform does not support programming the reset base
 address dynamically at run-time, it is possible to set the initial value of the
 ``RVBAR_EL3`` register at start-up. This feature is provided on the Base FVP only.
-It allows the ARM FVP port to support the ``RESET_TO_BL31`` configuration, in
+It allows the Arm FVP port to support the ``RESET_TO_BL31`` configuration, in
 which case the ``bl31.bin`` image must be loaded to its run address in Trusted
 SRAM and all CPU reset vectors be changed from the default ``0x0`` to this run
 address. See the `User Guide`_ for details of running the FVP models in this way.
@@ -155,7 +155,7 @@ This might be done by the Trusted Boot Firmware or by platform code in BL31.
 
 --------------
 
-*Copyright (c) 2015, ARM Limited and Contributors. All rights reserved.*
+*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.*
 
 .. _Firmware Design: firmware-design.rst
 .. _User Guide: user-guide.rst

docs/rt-svc-writers-guide.rst

-EL3 Runtime Service Writers Guide for ARM Trusted Firmware
-==========================================================
+Trusted Firmware-A EL3 runtime service writer's guide
+=====================================================
 
 
 .. section-numbering::
@@ -13,7 +13,7 @@ Introduction
 ------------
 
 This document describes how to add a runtime service to the EL3 Runtime
-Firmware component of ARM Trusted Firmware (BL31).
+Firmware component of Trusted Firmware-A (TF-A), BL31.
 
 Software executing in the normal world and in the trusted world at exception
 levels lower than EL3 will request runtime services using the Secure Monitor
@@ -27,7 +27,7 @@ example a subset of the Function IDs are designated as "OEM Calls" (see `SMCCC`_
 for full details). The EL3 runtime services framework in BL31 enables the
 independent implementation of services for each group, which are then compiled
 into the BL31 image. This simplifies the integration of common software from
-ARM to support `PSCI`_, Secure Monitor for a Trusted OS and SoC specific
+Arm to support `PSCI`_, Secure Monitor for a Trusted OS and SoC specific
 software. The common runtime services framework ensures that SMC Functions are
 dispatched to their respective service implementation - the `Firmware Design`_
 provides details of how this is achieved.
@@ -53,7 +53,7 @@ legacy 32-bit software that predates the `SMCCC`_.
 ::
 
     Type       OEN     Service
-    Fast        0      ARM Architecture calls
+    Fast        0      Arm Architecture calls
     Fast        1      CPU Service calls
     Fast        2      SiP Service calls
     Fast        3      OEM Service calls
@@ -62,7 +62,7 @@ legacy 32-bit software that predates the `SMCCC`_.
     Fast      48-49    Trusted Application calls
     Fast      50-63    Trusted OS calls
 
-    Yielding   0- 1    Reserved for existing ARMv7 calls
+    Yielding   0- 1    Reserved for existing Armv7-A calls
     Yielding   2-63    Trusted OS Standard Calls
 
 *Table 1: Service types and their corresponding Owning Entity Numbers*
@@ -72,7 +72,7 @@ range as they need - it is not necessary to coordinate with other entities of
 the same type. For example, two SoC providers can use the same Function ID
 within the SiP Service calls OEN range to mean different things - as these
 calls should be specific to the SoC. The Standard Runtime Calls OEN is used for
-services defined by ARM standards, such as `PSCI`_.
+services defined by Arm standards, such as `PSCI`_.
 
 The SMC Function ID also indicates whether the call has followed the SMC32
 calling convention, where all parameters are 32-bit, or the SMC64 calling
@@ -87,7 +87,7 @@ handler will be responsible for all SMC Functions within a given service type.
 Getting started
 ---------------
 
-ARM Trusted Firmware has a `services`_ directory in the source tree under which
+TF-A has a `services`_ directory in the source tree under which
 each owning entity can place the implementation of its runtime service. The
 `PSCI`_ implementation is located here in the `lib/psci`_ directory.
 
@@ -250,8 +250,7 @@ The handler is responsible for:
    UID and Revision Details for each service documented in section 6 of the
    `SMCCC`_.
 
-   The ARM Trusted Firmware expects owning entities to follow this
-   recommendation.
+   TF-A expects owning entities to follow this recommendation.
 
 #. Returning the result to the caller. The `SMCCC`_ allows for up to 256 bits
    of return value in SMC64 using X0-X3 and 128 bits in SMC32 using W0-W3. The
@@ -286,8 +285,8 @@ service which perform independent functions.
 In this situation it may be valuable to introduce a second level framework to
 enable independent implementation of sub-services. Such a framework might look
 very similar to the current runtime services framework, but using a different
-part of the SMC Function ID to identify the sub-service. Trusted Firmware does
-not provide such a framework at present.
+part of the SMC Function ID to identify the sub-service. TF-A does not provide
+such a framework at present.
 
 Secure-EL1 Payload Dispatcher service (SPD)
 -------------------------------------------
@@ -304,7 +303,7 @@ provide this information....
 
 --------------
 
-*Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.*
+*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.*
 
 .. _SMCCC: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
 .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf

docs/sdei.rst

@@ -8,13 +8,13 @@ Software Delegated Exception Interface
 .. contents::
     :depth: 2
 
-This document provides an overview of the SDEI dispatcher implementation in ARM
-Trusted Firmware.
+This document provides an overview of the SDEI dispatcher implementation in
+Trusted Firmware-A (TF-A).
 
 Introduction
 ------------
 
-`Software Delegated Exception Interface`_ (SDEI) is an ARM specification for
+`Software Delegated Exception Interface`_ (SDEI) is an Arm specification for
 Non-secure world to register handlers with firmware to receive notifications
 about system events. Firmware will first receive the system events by way of
 asynchronous exceptions and, in response, arranges for the registered handler to
@@ -52,8 +52,8 @@ SDEI events can be explicitly dispatched in response to other asynchronous
 exceptions. See `Explicit dispatch of events`_.
 
 The remainder of this document only discusses the design and implementation of
-SDEI dispatcher in ARM Trusted Firmware, and assumes that the reader is familiar
-with the SDEI specification, the interfaces, and their requirements.
+SDEI dispatcher in TF-A, and assumes that the reader is familiar with the SDEI
+specification, the interfaces, and their requirements.
 
 .. [#std-event] Except event 0, which is defined by the SDEI specification as a
                 standard event.
@@ -314,7 +314,7 @@ Note on writing SDEI event handlers
 -----------------------------------
 
 *This section pertains to SDEI event handlers in general, not just when using
-ARM Trusted Firmware SDEI dispatcher.*
+the TF-A SDEI dispatcher.*
 
 The SDEI specification requires that event handlers preserve the contents of all
 registers except ``x0`` to ``x17``. This has significance if event handler is
@@ -364,7 +364,7 @@ implemented in assembly, following a similar pattern as below:
 
 ----
 
-*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
 
 .. _SDEI specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
 .. _SDEI porting requirements: porting-guide.rst#sdei-porting-requirements

docs/secure-partition-manager-design.rst

@@ -18,8 +18,8 @@ used by Non-secure world applications to access these services. A Trusted OS
 fulfils the requirements of a security service as described above.
 
 Management services are typically implemented at the highest level of privilege
-in the system (i.e. EL3 in Arm Trusted Firmware). The service requirements are
-fulfilled by the execution environment provided by Arm Trusted Firmware.
+in the system, i.e. EL3 in Trusted Firmware-A (TF-A). The service requirements are
+fulfilled by the execution environment provided by TF-A.
 
 The following diagram illustrates the corresponding software stack:
 
@@ -41,10 +41,10 @@ Introduction
 A **Secure Partition** is a software execution environment instantiated in
 S-EL0 that can be used to implement simple management and security services.
 Since S-EL0 is an unprivileged Exception Level, a Secure Partition relies on
-privileged firmware (i.e. Arm Trusted Firmware) to be granted access to system
-and processor resources. Essentially, it is a software sandbox in the Secure
-world that runs under the control of privileged software, provides one or more
-services and accesses the following system resources:
+privileged firmware (i.e. TF-A) to be granted access to system and processor
+resources. Essentially, it is a software sandbox in the Secure world that runs
+under the control of privileged software, provides one or more services and
+accesses the following system resources:
 
 - Memory and device regions in the system address map.
 
@@ -52,25 +52,24 @@ services and accesses the following system resources:
 
 - A range of synchronous exceptions (e.g. SMC function identifiers).
 
-Note that currently the Arm Trusted Firmware only supports handling one Secure
-Partition.
+Note that currently TF-A only supports handling one Secure Partition.
 
-A Secure Partition enables Arm Trusted Firmware to implement only the essential
-secure services in EL3 and instantiate the rest in a partition in S-EL0.
+A Secure Partition enables TF-A to implement only the essential secure
+services in EL3 and instantiate the rest in a partition in S-EL0.
 Furthermore, multiple Secure Partitions can be used to isolate unrelated
 services from each other.
 
 The following diagram illustrates the place of a Secure Partition in a typical
-ARMv8-A software stack. A single or multiple Secure Partitions provide secure
+Armv8-A software stack. A single or multiple Secure Partitions provide secure
 services to software components in the Non-secure world and other Secure
 Partitions.
 
 |Image 2|
 
-The Arm Trusted Firmware build system is responsible for including the Secure
-Partition image in the FIP. During boot, BL2 includes support to authenticate
-and load the Secure Partition image. A BL31 component called **Secure Partition
-Manager (SPM)** is responsible for managing the partition. This is semantically
+The TF-A build system is responsible for including the Secure Partition image
+in the FIP. During boot, BL2 includes support to authenticate and load the
+Secure Partition image. A BL31 component called **Secure Partition Manager
+(SPM)** is responsible for managing the partition. This is semantically
 similar to a hypervisor managing a virtual machine.
 
 The SPM is responsible for the following actions during boot:
@@ -105,8 +104,8 @@ made in the current implementation of this software architecture. Subsequent
 revisions of the implementation will include a richer set of features that
 enable a more flexible architecture.
 
-Building Arm Trusted Firmware with Secure Partition support
------------------------------------------------------------
+Building TF-A with Secure Partition support
+-------------------------------------------
 
 SPM is supported on the Arm FVP exclusively at the moment. The current
 implementation supports inclusion of only a single Secure Partition in which a
@@ -125,7 +124,7 @@ the UEFI specification (see the PI v1.6 Volume 4: Management Mode Core
 Interface). This will be referred to as the *Standalone MM Secure Partition* in
 the rest of this document.
 
-To enable SPM support in the TF, the source code must be compiled with the build
+To enable SPM support in TF-A, the source code must be compiled with the build
 flag ``ENABLE_SPM=1``. On Arm platforms the build option ``ARM_BL31_IN_DRAM``
 can be used to select the location of BL31, both SRAM and DRAM are supported.
 Also, the location of the binary that contains the BL32 image
@@ -134,7 +133,7 @@ Also, the location of the binary that contains the BL32 image
 First, build the Standalone MM Secure Partition. To build it, refer to the
 `instructions in the EDK2 repository`_.
 
-Then build TF with SPM support and include the Standalone MM Secure Partition
+Then build TF-A with SPM support and include the Standalone MM Secure Partition
 image in the FIP:
 
 ::
@@ -145,10 +144,10 @@ image in the FIP:
 Describing Secure Partition resources
 -------------------------------------
 
-Arm Trusted Firmware exports a porting interface that enables a platform to
-specify the system resources required by the Secure Partition. Some instructions
-are given below. However, this interface is under development and it may change
-as new features are implemented.
+TF-A exports a porting interface that enables a platform to specify the system
+resources required by the Secure Partition. Some instructions are given below.
+However, this interface is under development and it may change as new features
+are implemented.
 
 - A Secure Partition is considered a BL32 image, so the same defines that apply
   to BL32 images apply to a Secure Partition: ``BL32_BASE`` and ``BL32_LIMIT``.
@@ -176,9 +175,9 @@ For an example of all the changes in context, you may refer to commit
 Accessing Secure Partition services
 -----------------------------------
 
-The `SMC Calling Convention`_ (*ARM DEN 0028B*) describes SMCs as a conduit for
+The `SMC Calling Convention`_ (*Arm DEN 0028B*) describes SMCs as a conduit for
 accessing services implemented in the Secure world. The ``MM_COMMUNICATE``
-interface defined in the `Management Mode Interface Specification`_ (*ARM DEN
+interface defined in the `Management Mode Interface Specification`_ (*Arm DEN
 0060A*) is used to invoke a Secure Partition service as a Fast Call.
 
 The mechanism used to identify a service within the partition depends on the
@@ -208,11 +207,11 @@ e.g. ACPI table or device tree. It is possible for the Non-secure world to
 exchange data with a partition only if it has been populated in this shared
 memory area. The shared memory area is implemented as per the guidelines
 specified in Section 3.2.3 of the `Management Mode Interface Specification`_
-(*ARM DEN 0060A*).
+(*Arm DEN 0060A*).
 
 The format of data structures used to encapsulate data in the shared memory is
 agreed between the Non-secure world and the Secure Partition. For example, in
-the `Management Mode Interface specification`_ (*ARM DEN 0060A*), Section 4
+the `Management Mode Interface specification`_ (*Arm DEN 0060A*), Section 4
 describes that the communication buffer shared between the Non-secure world and
 the Management Mode (MM) in the Secure world must be of the type
 ``EFI_MM_COMMUNICATE_HEADER``. This data structure is defined in *Volume 4:
@@ -246,7 +245,7 @@ interfaces are not accessible from the Non-secure world.
 Conduit
 ^^^^^^^
 
-The `SMC Calling Convention`_ (*ARM DEN 0028B*) specification describes the SMC
+The `SMC Calling Convention`_ (*Arm DEN 0028B*) specification describes the SMC
 and HVC conduits for accessing firmware services and their availability
 depending on the implemented Exception levels. In S-EL0, the Supervisor Call
 exception (SVC) is the only architectural mechanism available for unprivileged
@@ -254,16 +253,16 @@ software to make a request for an operation implemented in privileged software.
 Hence, the SVC conduit must be used by the Secure Partition to access interfaces
 implemented by the SPM.
 
-A SVC causes an exception to be taken to S-EL1. Arm Trusted Firmware assumes
-ownership of S-EL1 and installs a simple exception vector table in S-EL1 that
-relays a SVC request from a Secure Partition as a SMC request to the SPM in EL3.
-Upon servicing the SMC request, Arm Trusted Firmware returns control directly to
-S-EL0 through an ERET instruction.
+A SVC causes an exception to be taken to S-EL1. TF-A assumes ownership of S-EL1
+and installs a simple exception vector table in S-EL1 that relays a SVC request
+from a Secure Partition as a SMC request to the SPM in EL3. Upon servicing the
+SMC request, Arm Trusted Firmware returns control directly to S-EL0 through an
+ERET instruction.
 
 Calling conventions
 ^^^^^^^^^^^^^^^^^^^
 
-The `SMC Calling Convention`_ (*ARM DEN 0028B*) specification describes the
+The `SMC Calling Convention`_ (*Arm DEN 0028B*) specification describes the
 32-bit and 64-bit calling conventions for the SMC and HVC conduits. The SVC
 conduit introduces the concept of SVC32 and SVC64 calling conventions. The SVC32
 and SVC64 calling conventions are equivalent to the 32-bit (SMC32) and the
@@ -285,8 +284,8 @@ Communication initiated by Secure Partition
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 A request is initiated from the Secure Partition by executing a SVC instruction.
-An ERET instruction is used by Arm Trusted Firmware to return to S-EL0 with the
-result of the request.
+An ERET instruction is used by TF-A to return to S-EL0 with the result of the
+request.
 
 For instance, a request to perform privileged operations on behalf of a
 partition (e.g.  management of memory attributes in the translation tables for
@@ -296,7 +295,7 @@ Interfaces
 ^^^^^^^^^^
 
 The current implementation reserves function IDs for Fast Calls in the Standard
-Secure Service calls range (see `SMC Calling Convention`_ (*ARM DEN 0028B*)
+Secure Service calls range (see `SMC Calling Convention`_ (*Arm DEN 0028B*)
 specification) for each API exported by the SPM. This section defines the
 function prototypes for each function ID. The function IDs specify whether one
 or both of the SVC32 and SVC64 calling conventions can be used to invoke the
@@ -461,7 +460,7 @@ This transition into S-EL0 is special since it is not in response to a previous
 request through a SVC instruction. This is the first entry into S-EL0. The
 general purpose register usage at the time of entry will be as specified in the
 "Return State" column of Table 3-1 in Section 3.1 "Register use in AArch64 SMC
-calls" of the `SMC Calling Convention`_ (*ARM DEN 0028B*) specification. In
+calls" of the `SMC Calling Convention`_ (*Arm DEN 0028B*) specification. In
 addition, certain other restrictions will be applied as described below.
 
 1. ``SP_EL0``
@@ -601,7 +600,7 @@ address map from a Secure Partition. This is done by mapping these regions in
 the Secure EL1&0 Translation regime with appropriate memory attributes.
 Attributes refer to memory type, permission, cacheability and shareability
 attributes used in the Translation tables. The definitions of these attributes
-and their usage can be found in the `ARMv8 ARM`_ (*ARM DDI 0487*).
+and their usage can be found in the `Armv8-A ARM`_ (*Arm DDI 0487*).
 
 All memory required by the Secure Partition is allocated upfront in the SPM,
 even before handing over to the Secure Partition for the first time. The initial
@@ -813,9 +812,9 @@ Error Codes
 
 --------------
 
-*Copyright (c) 2017, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
 
-.. _ARMv8 ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
+.. _Armv8-A ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
 .. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64StandaloneMm/HowtoBuild.MD
 .. _Management Mode Interface Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf
 .. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf

docs/spd/optee-dispatcher.rst

@@ -8,7 +8,7 @@ To build and execute OP-TEE follow the instructions at
 
 --------------
 
-*Copyright (c) 2014-2017, ARM Limited and Contributors. All rights reserved.*
+*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.*
 
 .. _OP-TEE OS: https://github.com/OP-TEE/build
 .. _OP-TEE build.git: https://github.com/OP-TEE/build

docs/spd/tlk-dispatcher.rst

 Trusted Little Kernel (TLK) Dispatcher
 ======================================
 
-TLK dispatcher adds support for NVIDIA's Trusted Little Kernel (TLK) to work
-with the Trusted Firmware. TLK-D can be compiled by including it in the
-platform's makefile. TLK is primarily meant to work with Tegra SoCs, so until
-Trusted Firmware starts supporting Tegra, the dispatcher code can only be
+TLK dispatcher (TLK-D) adds support for NVIDIA's Trusted Little Kernel (TLK)
+to work with Trusted Firmware-A (TF-A). TLK-D can be compiled by including it
+in the platform's makefile. TLK is primarily meant to work with Tegra SoCs,
+so while TF-A only supports TLK on Tegra, the dispatcher code can only be
 compiled for other platforms.
 
 In order to compile TLK-D, we need a BL32 image to be present. Since, TLKD
@@ -20,7 +20,7 @@ Trusted Little Kernel (TLK)
 TLK is a Trusted OS running as Secure EL1. It is a Free Open Source Software
 (FOSS) release of the NVIDIA® Trusted Little Kernel (TLK) technology, which
 extends technology made available with the development of the Little Kernel (LK).
-You can download the LK modular embedded preemptive kernel for use on ARM,
+You can download the LK modular embedded preemptive kernel for use on Arm,
 x86, and AVR32 systems from https://github.com/travisg/lk
 
 NVIDIA implemented its Trusted Little Kernel (TLK) technology, designed as a
@@ -72,5 +72,5 @@ Example:
 ::
 
     bl32_ep_info->args.arg0 = TZDRAM size available for BL32
-    bl32_ep_info->args.arg1 = unused (used only on ARMv7)
+    bl32_ep_info->args.arg1 = unused (used only on Armv7-A)
     bl32_ep_info->args.arg2 = pointer to boot args

docs/spd/trusty-dispatcher.rst

@@ -28,5 +28,5 @@ should then be set to the size of that block.
 Supported platforms
 ===================
 
-Out of all the platforms supported by the ARM Trusted Firmware, Trusty is
+Out of all the platforms supported by Trusted Firmware-A, Trusty is only
 verified and supported by NVIDIA's Tegra SoCs.

docs/trusted-board-boot.rst

@@ -12,16 +12,16 @@ the platform by authenticating all firmware images up to and including the
 normal world bootloader. It does this by establishing a Chain of Trust using
 Public-Key-Cryptography Standards (PKCS).
 
-This document describes the design of ARM Trusted Firmware TBB, which is an
-implementation of the Trusted Board Boot Requirements (TBBR) specification,
-ARM DEN0006C-1. It should be used in conjunction with the `Firmware Update`_
+This document describes the design of Trusted Firmware-A (TF-A) TBB, which is
+an implementation of the Trusted Board Boot Requirements (TBBR) specification,
+Arm DEN0006C-1. It should be used in conjunction with the `Firmware Update`_
 design document, which implements a specific aspect of the TBBR.
 
 Chain of Trust
 --------------
 
 A Chain of Trust (CoT) starts with a set of implicitly trusted components. On
-the ARM development platforms, these components are:
+the Arm development platforms, these components are:
 
 -  A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the
    trusted root-key storage registers.
@@ -39,7 +39,7 @@ Certificate Authority (CA) because the CoT is not established by verifying the
 validity of a certificate's issuer but by the content of the certificate
 extensions. To sign the certificates, the PKCS#1 SHA-256 with RSA Encryption
 signature scheme is used with a RSA key length of 2048 bits. Future version of
-Trusted Firmware will support additional cryptographic algorithms.
+TF-A will support additional cryptographic algorithms.
 
 The certificates are categorised as "Key" and "Content" certificates. Key
 certificates are used to verify public keys which have been used to sign content
@@ -148,7 +148,7 @@ if any of the steps fail.
    registers. If they match, the BL2 hash is read from the certificate.
 
    Note: the matching operation is platform specific and is currently
-   unimplemented on the ARM development platforms.
+   unimplemented on the Arm development platforms.
 
 -  BL1 loads the BL2 image. Its hash is calculated and compared with the hash
    read from the certificate. Control is transferred to the BL2 image if all
@@ -196,7 +196,7 @@ enabled through use of specific build flags as described in the `User Guide`_.
 On the host machine, a tool generates the certificates, which are included in
 the FIP along with the boot loader images. These certificates are loaded in
 Trusted SRAM using the IO storage framework. They are then verified by an
-Authentication module included in the Trusted Firmware.
+Authentication module included in TF-A.
 
 The mechanism used for generating the FIP and the Authentication module are
 described in the following sections.
@@ -204,9 +204,9 @@ described in the following sections.
 Authentication Framework
 ------------------------
 
-The authentication framework included in the Trusted Firmware provides support
-to implement the desired trusted boot sequence. ARM platforms use this framework
-to implement the boot requirements specified in the TBBR-client document.
+The authentication framework included in TF-A provides support to implement
+the desired trusted boot sequence. Arm platforms use this framework to
+implement the boot requirements specified in the TBBR-client document.
 
 More information about the authentication framework can be found in the
 `Auth Framework`_ document.
@@ -215,8 +215,8 @@ Certificate Generation Tool
 ---------------------------
 
 The ``cert_create`` tool is built and runs on the host machine as part of the
-Trusted Firmware build process when ``GENERATE_COT=1``. It takes the boot loader
-images and keys as inputs (keys must be in PEM format) and generates the
+TF-A build process when ``GENERATE_COT=1``. It takes the boot loader images
+and keys as inputs (keys must be in PEM format) and generates the
 certificates (in DER format) required to establish the CoT. New keys can be
 generated by the tool in case they are not provided. The certificates are then
 passed as inputs to the ``fiptool`` utility for creating the FIP.
@@ -230,7 +230,7 @@ for building and using the tool can be found in the `User Guide`_.
 
 --------------
 
-*Copyright (c) 2015, ARM Limited and Contributors. All rights reserved.*
+*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.*
 
 .. _Firmware Update: firmware-update.rst
 .. _X.509 v3: http://www.ietf.org/rfc/rfc5280.txt

docs/xlat-tables-lib-v2-design.rst

@@ -9,7 +9,7 @@ Translation Tables Library Design
 
 
 This document describes the design of the translation tables library (version 2)
-used by the ARM Trusted Firmware. This library provides APIs to create page
+used by Trusted Firmware-A (TF-A). This library provides APIs to create page
 tables based on a description of the memory layout, as well as setting up system
 registers related to the Memory Management Unit (MMU) and performing the
 required Translation Lookaside Buffer (TLB) maintenance operations.
@@ -329,7 +329,7 @@ The memory mapping algorithm
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The mapping function is implemented as a recursive algorithm. It is however
-bound by the level of depth of the translation tables (the ARMv8-A architecture
+bound by the level of depth of the translation tables (the Armv8-A architecture
 allows up to 4 lookup levels).
 
 By default [#granularity-ref]_, the algorithm will attempt to minimize the
@@ -376,7 +376,7 @@ changes are visible to subsequent execution, including speculative execution,
 that uses the changed translation table entries.
 
 A counter-example is the initialization of translation tables. In this case,
-explicit TLB maintenance is not required. The ARMv8-A architecture guarantees
+explicit TLB maintenance is not required. The Armv8-A architecture guarantees
 that all TLBs are disabled from reset and their contents have no effect on
 address translation at reset [#tlb-reset-ref]_. Therefore, the TLBs invalidation
 is deferred to the ``enable_mmu*()`` family of functions, just before the MMU is
@@ -391,9 +391,9 @@ descriptor. Given that the TLBs are not architecturally permitted to hold any
 invalid translation table entry [#tlb-no-invalid-entry]_, this means that this
 mapping cannot be cached in the TLBs.
 
-.. [#tlb-reset-ref] See section D4.8 `Translation Lookaside Buffers (TLBs)`, subsection `TLB behavior at reset` in ARMv8-A, rev B.a.
+.. [#tlb-reset-ref] See section D4.8 `Translation Lookaside Buffers (TLBs)`, subsection `TLB behavior at reset` in Armv8-A, rev B.a.
 
-.. [#tlb-no-invalid-entry] See section D4.9.1 `General TLB maintenance requirements` in ARMv8-A, rev B.a.
+.. [#tlb-no-invalid-entry] See section D4.9.1 `General TLB maintenance requirements` in Armv8-A, rev B.a.
 
 Architectural module
 ~~~~~~~~~~~~~~~~~~~~
@@ -405,7 +405,7 @@ translation context to work on.
 
 --------------
 
-*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
 
 .. _lib/xlat\_tables\_v2: ../lib/xlat_tables_v2
 .. _lib/xlat\_tables: ../lib/xlat_tables

license.rst

-Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.
+Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.
 
 Redistribution and use in source and binary forms, with or without modification,
 are permitted provided that the following conditions are met:
@@ -10,7 +10,7 @@ are permitted provided that the following conditions are met:
    list of conditions and the following disclaimer in the documentation and/or
    other materials provided with the distribution.
 
--  Neither the name of ARM nor the names of its contributors may be used to
+-  Neither the name of Arm nor the names of its contributors may be used to
    endorse or promote products derived from this software without specific prior
    written permission.
 

maintainers.rst

-ARM Trusted Firmware Maintainers
-================================
+Trusted Firmware-A maintainers
+==============================
 
-ARM Trusted Firmware is an ARM maintained project. All contributions are
+Trusted Firmware-A (TF-A) is an Arm maintained project. All contributions are
 ultimately merged by the maintainers listed below. Technical ownership of some
 parts of the codebase is delegated to the sub-maintainers listed below. An
 acknowledgement from these sub-maintainers may be required before the
@@ -123,8 +123,8 @@ Files:
 -  docs/plat/xilinx-zynqmp.rst
 -  plat/xilinx/\*
 
-ARMv7 architecture sub-maintainer
----------------------------------
+Armv7-A architecture sub-maintainer
+-----------------------------------
 
 Etienne Carriere (etienne.carriere@linaro.org, `etienne-lms`_)
 

readme.rst

-ARM Trusted Firmware - version 1.4
-==================================
+Trusted Firmware-A - version 1.4
+================================
 
-ARM Trusted Firmware provides a reference implementation of secure world
-software for `ARMv8-A`_, including a `Secure Monitor`_ executing at
-Exception Level 3 (EL3). It implements various ARM interface standards, such as:
+Trusted Firmware-A (TF-A) provides a reference implementation of secure world
+software for `Armv8-A`_, including a `Secure Monitor`_ executing at Exception
+Level 3 (EL3). It implements various Arm interface standards, such as:
 
 -  The `Power State Coordination Interface (PSCI)`_
--  Trusted Board Boot Requirements (TBBR, ARM DEN0006C-1)
+-  Trusted Board Boot Requirements (TBBR, Arm DEN0006C-1)
 -  `SMC Calling Convention`_
 -  `System Control and Management Interface`_
 
-As far as possible the code is designed for reuse or porting to other ARMv8-A
+As far as possible the code is designed for reuse or porting to other Armv8-A
 model and hardware platforms.
 
-ARM will continue development in collaboration with interested parties to
-provide a full reference implementation of Secure Monitor code and ARM standards
-to the benefit of all developers working with ARMv8-A TrustZone technology.
+Arm will continue development in collaboration with interested parties to
+provide a full reference implementation of Secure Monitor code and Arm standards
+to the benefit of all developers working with Armv8-A TrustZone technology.
 
 License
 -------
@@ -45,7 +45,7 @@ world boot and runtime firmware, in either the AArch32 or AArch64 execution
 state.
 
 Users are encouraged to do their own security validation, including penetration
-testing, on any secure world code derived from ARM Trusted Firmware.
+testing, on any secure world code derived from TF-A.
 
 Functionality
 ~~~~~~~~~~~~~
@@ -54,15 +54,15 @@ Functionality
    registers and interrupts for the platform.
 
 -  Library support for CPU specific reset and power down sequences. This
-   includes support for errata workarounds and the latest ARM DynamIQ CPUs.
+   includes support for errata workarounds and the latest Arm DynamIQ CPUs.
 
--  Drivers to enable standard initialization of ARM System IP, for example
+-  Drivers to enable standard initialization of Arm System IP, for example
    Generic Interrupt Controller (GIC), Cache Coherent Interconnect (CCI),
    Cache Coherent Network (CCN), Network Interconnect (NIC) and TrustZone
    Controller (TZC).
 
 -  A generic `SCMI`_ driver to interface with conforming power controllers, for
-   example the ARM System Control Processor (SCP).
+   example the Arm System Control Processor (SCP).
 
 -  SMC (Secure Monitor Call) handling, conforming to the `SMC Calling
    Convention`_ using an EL3 runtime services framework.
@@ -93,14 +93,14 @@ Functionality
    recovery mode), and packaging of the various firmware images into a
    Firmware Image Package (FIP).
 
--  Pre-integration of TBB with the ARM TrustZone CryptoCell product, to take
+-  Pre-integration of TBB with the Arm TrustZone CryptoCell product, to take
    advantage of its hardware Root of Trust and crypto acceleration services.
 
 -  Support for alternative boot flows, for example to support platforms where
    the EL3 Runtime Software is loaded using other firmware or a separate
    secure system processor.
 
--  Support for the GCC, LLVM and ARM Compiler 6 toolchains.
+-  Support for the GCC, LLVM and Arm Compiler 6 toolchains.
 
 For a full description of functionality and implementation details, please
 see the `Firmware Design`_ and supporting documentation. The `Change Log`_
@@ -110,9 +110,9 @@ Platforms
 ~~~~~~~~~
 
 Various AArch32 and AArch64 builds of this release has been tested on variants
-r0, r1 and r2 of the `Juno ARM Development Platform`_.
+r0, r1 and r2 of the `Juno Arm Development Platform`_.
 
-Various AArch64 builds of this release have been tested on the following ARM
+Various AArch64 builds of this release have been tested on the following Arm
 `FVP`_\ s (64-bit host machine only):
 
 NOTE: Unless otherwise stated, the FVP Version is 11.0, Build 11.0.34.
@@ -129,14 +129,14 @@ NOTE: Unless otherwise stated, the FVP Version is 11.0, Build 11.0.34.
 -  ``FVP_Base_Cortex-A73x4``
 -  ``FVP_CSS_SGM-775`` (Version 11.0, Build 11.0.36)
 
-Various AArch32 builds of this release has been tested on the following ARM
+Various AArch32 builds of this release has been tested on the following Arm
 `FVP`_\ s (64-bit host machine only):
 
 -  ``FVP_Base_AEMv8A-AEMv8A`` (Version 8.5, Build 0.8.8502)
 -  ``FVP_Base_Cortex-A32x4``
 
 The Foundation FVP can be downloaded free of charge. The Base FVPs can be
-licensed from ARM. See the `ARM FVP website`_.
+licensed from Arm. See the `Arm FVP website`_.
 
 All the above platforms have been tested with `Linaro Release 17.04`_.
 
@@ -167,15 +167,15 @@ Log`_ and the `GitHub issue tracker`_.
 Getting Started
 ---------------
 
-Get the Trusted Firmware source code from `GitHub`_.
+Get the TF-A source code from `GitHub`_.
 
 See the `User Guide`_ for instructions on how to install, build and use
-the Trusted Firmware with the ARM `FVP`_\ s.
+the TF-A with the Arm `FVP`_\ s.
 
-See the `Firmware Design`_ for information on how the Trusted Firmware works.
+See the `Firmware Design`_ for information on how the TF-A works.
 
 See the `Porting Guide`_ as well for information about how to use this
-software on another ARMv8-A platform.
+software on another Armv8-A platform.
 
 See the `Contributing Guidelines`_ for information on how to contribute to this
 project and the `Acknowledgments`_ file for a list of contributors to the
@@ -184,26 +184,26 @@ project.
 Feedback and support
 ~~~~~~~~~~~~~~~~~~~~
 
-ARM welcomes any feedback on Trusted Firmware. If you think you have found a
-security vulnerability, please report this using the process defined in the
-Trusted Firmware `Security Centre`_. For all other feedback, please use the
+Arm welcomes any feedback on TF-A. If you think you have found a security
+vulnerability, please report this using the process defined in the TF-A
+`Security Centre`_. For all other feedback, please use the
 `GitHub issue tracker`_.
 
-ARM licensees may contact ARM directly via their partner managers.
+Arm licensees may contact Arm directly via their partner managers.
 
 --------------
 
-*Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.*
+*Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.*
 
-.. _ARMv8-A: http://www.arm.com/products/processors/armv8-architecture.php
+.. _Armv8-A: http://www.arm.com/products/processors/armv8-architecture.php
 .. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php
 .. _Power State Coordination Interface (PSCI): PSCI_
 .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
 .. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
 .. _System Control and Management Interface: SCMI_
 .. _SCMI: http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf
-.. _Juno ARM Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php
-.. _ARM FVP website: FVP_
+.. _Juno Arm Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php
+.. _Arm FVP website: FVP_
 .. _FVP: https://developer.arm.com/products/system-design/fixed-virtual-platforms
 .. _Linaro Release 17.04: https://community.arm.com/dev-platforms/b/documents/posts/linaro-release-notes-deprecated#LinaroRelease17.04
 .. _OP-TEE Secure OS: https://github.com/OP-TEE/optee_os