Commit 4def07d5 authored by Dan Handley's avatar Dan Handley Committed by David Cunado
Browse files

Update Arm TF references to TF-A



Update Arm Trusted Firmware references in the upstream documents to
Trusted Firmware-A (TF-A). This is for consistency with and
disambiguation from Trusted Firmware-M (TF-M).

Also update other Arm trademarks, e.g. ARM->Arm, ARMv8->Armv8-A.

Change-Id: I8bb0e18af29c6744eeea2dc6c08f2c10b20ede22
Signed-off-by: default avatarDan Handley <dan.handley@arm.com>
Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
parent c3e34a9e
Contributing to ARM Trusted Firmware
====================================
Contributing to Trusted Firmware-A
==================================
Getting Started
---------------
- Make sure you have a `GitHub account`_.
- Create an `issue`_ for your work if one does not already exist. This gives
everyone visibility of whether others are working on something similar. ARM
licensees may contact ARM directly via their partner managers instead if
everyone visibility of whether others are working on something similar. Arm
licensees may contact Arm directly via their partner managers instead if
they prefer.
- Note that the `issue`_ tracker for this project is in a separate
......@@ -27,8 +27,8 @@ Making Changes
- Make commits of logical units. See these general `Git guidelines`_ for
contributing to a project.
- Follow the `Linux coding style`_; this style is enforced for the ARM Trusted
Firmware project (style errors only, not warnings).
- Follow the `Linux coding style`_; this style is enforced for the TF-A
project (style errors only, not warnings).
- Use the checkpatch.pl script provided with the Linux source tree. A
Makefile target is provided for convenience (see section 2 in the
......@@ -57,7 +57,7 @@ Making Changes
::
Portions copyright (c) [XXXX-]YYYY, ARM Limited and Contributors. All rights reserved.
Portions copyright (c) [XXXX-]YYYY, Arm Limited and Contributors. All rights reserved.
where XXXX is the year of first contribution (if different to YYYY) and
YYYY is the year of most recent contribution.
......@@ -108,7 +108,7 @@ Submitting Changes
--------------
*Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2013-2018, Arm Limited and Contributors. All rights reserved.*
.. _GitHub account: https://github.com/signup/free
.. _issue: https://github.com/ARM-software/tf-issues/issues
......
ARM SiP Service
Arm SiP Service
===============
This document enumerates and describes the ARM SiP (Silicon Provider) services.
This document enumerates and describes the Arm SiP (Silicon Provider) services.
SiP services are non-standard, platform-specific services offered by the silicon
implementer or platform provider. They are accessed via. ``SMC`` ("SMC calls")
......@@ -13,20 +13,20 @@ services:
``0xc200ffff`` for 64-bit calls, and ``0x82000000`` - ``0x8200ffff`` for 32-bit
calls.
The ARM SiP implementation offers the following services:
The Arm SiP implementation offers the following services:
- Performance Measurement Framework (PMF)
- Execution State Switching service
Source definitions for ARM SiP service are located in the ``arm_sip_svc.h`` header
Source definitions for Arm SiP service are located in the ``arm_sip_svc.h`` header
file.
Performance Measurement Framework (PMF)
---------------------------------------
The `Performance Measurement Framework`_
allows callers to retrieve timestamps captured at various paths in ARM Trusted
Firmware execution. It's described in detail in `Firmware Design document`_.
allows callers to retrieve timestamps captured at various paths in TF-A
execution. It's described in detail in `Firmware Design document`_.
Execution State Switching service
---------------------------------
......@@ -35,8 +35,8 @@ Execution State Switching service provides a mechanism for a non-secure lower
Exception Level (either EL2, or NS EL1 if EL2 isn't implemented) to request to
switch its execution state (a.k.a. Register Width), either from AArch64 to
AArch32, or from AArch32 to AArch64, for the calling CPU. This service is only
available when ARM Trusted Firmware is built for AArch64 (i.e. when build option
``ARCH`` is set to ``aarch64``).
available when Trusted Firmware-A (TF-A) is built for AArch64 (i.e. when build
option ``ARCH`` is set to ``aarch64``).
``ARM_SIP_SVC_EXE_STATE_SWITCH``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
......@@ -79,8 +79,8 @@ The service may return the following error codes:
- ``STATE_SW_E_PARAM``: If any of the parameters were deemed invalid for
a specific request.
- ``STATE_SW_E_DENIED``: If the call is not successful, or when ARM Trusted
Firmware is built for AArch32.
- ``STATE_SW_E_DENIED``: If the call is not successful, or when TF-A is
built for AArch32.
If the call is successful, the caller wouldn't observe the SMC returning.
Instead, execution starts at the supplied entry point, with the CPU registers 0
......@@ -89,7 +89,7 @@ respectively.
--------------
*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
.. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
.. _Performance Measurement Framework: ./firmware-design.rst#user-content-performance-measurement-framework
......
......@@ -7,8 +7,9 @@ Abstracting a Chain of Trust
.. contents::
The aim of this document is to describe the authentication framework implemented
in the Trusted Firmware. This framework fulfills the following requirements:
The aim of this document is to describe the authentication framework
implemented in Trusted Firmware-A (TF-A). This framework fulfills the
following requirements:
#. It should be possible for a platform port to specify the Chain of Trust in
terms of certificate hierarchy and the mechanisms used to verify a
......@@ -152,8 +153,8 @@ performed to verify it:
In Diagram 1, each component is responsible for one or more of these operations.
The responsibilities are briefly described below.
TF Generic code and IO framework (GEN/IO)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TF-A Generic code and IO framework (GEN/IO)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These components are responsible for initiating the authentication process for a
particular image in BL1 or BL2. For each BL image that requires authentication,
......@@ -162,8 +163,8 @@ image until either an authenticated image or the ROT is reached. Then the
Generic code calls the IO framewotk to load the image and calls the
Authentication module to authenticate it, following the CoT from ROT to Image.
TF Platform Port (PP)
^^^^^^^^^^^^^^^^^^^^^
TF-A Platform Port (PP)
^^^^^^^^^^^^^^^^^^^^^^^
The platform is responsible for:
......@@ -374,8 +375,8 @@ single parsing method. There has to be one IPL for every method used by the
platform.
#. Raw format: This format is effectively a nop as an image using this method
is treated as being in raw binary format e.g. boot loader images used by ARM
TF. This method should only be used by data images.
is treated as being in raw binary format e.g. boot loader images used by
TF-A. This method should only be used by data images.
#. X509V3 method: This method uses industry standards like X.509 to represent
PKI certificates (authentication images). It is expected that open source
......@@ -631,8 +632,8 @@ array of image descriptors and it is registered in the framework using the macro
process to fail).
The number of images participating in the boot process depends on the CoT. There
is, however, a minimum set of images that are mandatory in the Trusted Firmware
and thus all CoTs must present:
is, however, a minimum set of images that are mandatory in TF-A and thus all
CoTs must present:
- ``BL2``
- ``SCP_BL2`` (platform specific)
......@@ -648,7 +649,7 @@ Following the `Platform Porting Guide`_, a platform must provide unique
identifiers for all the images and certificates that will be loaded during the
boot process. If a platform is using the TBBR as a reference for trusted boot,
these identifiers can be obtained from ``include/common/tbbr/tbbr_img_def.h``.
ARM platforms include this file in ``include/plat/arm/common/arm_def.h``. Other
Arm platforms include this file in ``include/plat/arm/common/arm_def.h``. Other
platforms may also include this file or provide their own identifiers.
**Important**: the authentication module uses these identifiers to index the
......@@ -880,7 +881,7 @@ extract the authentication parameters. The number and type of parser libraries
depend on the images used in the CoT. Raw images do not need a library, so
only an x509v3 library is required for the TBBR CoT.
ARM platforms will use an x509v3 library based on mbed TLS. This library may be
Arm platforms will use an x509v3 library based on mbed TLS. This library may be
found in ``drivers/auth/mbedtls/mbedtls_x509_parser.c``. It exports three
functions:
......@@ -898,14 +899,14 @@ an image of type ``IMG_CERT``, it will call the corresponding function exported
in this file.
The build system must be updated to include the corresponding library and
mbed TLS sources. ARM platforms use the ``arm_common.mk`` file to pull the
mbed TLS sources. Arm platforms use the ``arm_common.mk`` file to pull the
sources.
The cryptographic library
~~~~~~~~~~~~~~~~~~~~~~~~~
The cryptographic module relies on a library to perform the required operations,
i.e. verify a hash or a digital signature. ARM platforms will use a library
i.e. verify a hash or a digital signature. Arm platforms will use a library
based on mbed TLS, which can be found in
``drivers/auth/mbedtls/mbedtls_crypto.c``. This library is registered in the
authentication framework using the macro ``REGISTER_CRYPTO_LIB()`` and exports
......@@ -934,7 +935,7 @@ of SHA-256 with smaller memory footprint (~1.5 KB less) but slower (~30%).
--------------
*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
.. _Trusted Board Boot: ./trusted-board-boot.rst
.. _Platform Porting Guide: ./porting-guide.rst
This diff is collapsed.
ARM CPU Specific Build Macros
Arm CPU Specific Build Macros
=============================
......@@ -14,8 +14,8 @@ for a specific CPU on a platform.
Security Vulnerability Workarounds
----------------------------------
ARM Trusted Firmware exports a series of build flags which control which
security vulnerability workarounds should be applied at runtime.
TF-A exports a series of build flags which control which security
vulnerability workarounds should be applied at runtime.
- ``WORKAROUND_CVE_2017_5715``: Enables the security workaround for
`CVE-2017-5715`_. Defaults to 1.
......@@ -23,10 +23,9 @@ security vulnerability workarounds should be applied at runtime.
CPU Errata Workarounds
----------------------
ARM Trusted Firmware exports a series of build flags which control the
errata workarounds that are applied to each CPU by the reset handler. The
errata details can be found in the CPU specific errata documents published
by ARM:
TF-A exports a series of build flags which control the errata workarounds that
are applied to each CPU by the reset handler. The errata details can be found
in the CPU specific errata documents published by Arm:
- `Cortex-A53 MPCore Software Developers Errata Notice`_
- `Cortex-A57 MPCore Software Developers Errata Notice`_
......@@ -135,8 +134,8 @@ architecture that can be enabled by the platform as desired.
- ``A53_DISABLE_NON_TEMPORAL_HINT``: This flag disables the cache non-temporal
hint. The LDNP/STNP instructions as implemented on Cortex-A53 do not behave
in a way most programmers expect, and will most probably result in a
significant speed degradation to any code that employs them. The ARMv8-A
architecture (see ARM DDI 0487A.h, section D3.4.3) allows cores to ignore
significant speed degradation to any code that employs them. The Armv8-A
architecture (see Arm DDI 0487A.h, section D3.4.3) allows cores to ignore
the non-temporal hint and treat LDNP/STNP as LDP/STP instead. Enabling this
flag enforces this behaviour. This needs to be enabled only for revisions
<= r0p3 of the CPU and is enabled by default.
......@@ -149,7 +148,7 @@ architecture that can be enabled by the platform as desired.
--------------
*Copyright (c) 2014-2016, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.*
.. _CVE-2017-5715: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5715
.. _Cortex-A53 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm048406/Cortex_A53_MPCore_Software_Developers_Errata_Notice.pdf
......
This diff is collapsed.
ARM Trusted Firmware - Firmware Update Design Guide
===================================================
Trusted Firmware-A - Firmware Update design guide
=================================================
.. section-numbering::
......@@ -21,9 +21,9 @@ is corrupt or missing; it therefore may be used as a recovery mode. It may also
be complemented by other, higher level firmware update software.
FWU implements a specific part of the Trusted Board Boot Requirements (TBBR)
specification, ARM DEN0006C-1. It should be used in conjunction with the
specification, Arm DEN0006C-1. It should be used in conjunction with the
`Trusted Board Boot`_ design document, which describes the image authentication
parts of the Trusted Firmware (TF) TBBR implementation.
parts of the Trusted Firmware-A (TF-A) TBBR implementation.
Scope
~~~~~
......@@ -63,11 +63,11 @@ The primary requirements of the FWU feature are:
it needs, and to enable platform specific FWU functionality. See the
`Porting Guide`_ for details of this interface.
TF uses abbreviated image terminology for FWU images like for other TF images.
An overview of this terminology can be found `here`_.
TF-A uses abbreviated image terminology for FWU images like for other TF-A
images. An overview of this terminology can be found `here`_.
The following diagram shows the FWU boot flow for ARM development platforms.
ARM CSS platforms like Juno have a System Control Processor (SCP), and these
The following diagram shows the FWU boot flow for Arm development platforms.
Arm CSS platforms like Juno have a System Control Processor (SCP), and these
use all defined FWU images. Other platforms may use a subset of these.
|Flow Diagram|
......@@ -193,8 +193,8 @@ BL1\_SMC\_RUN\_IMAGE
if (ep_info not EL3) synchronous exception
This SMC passes execution control to an EL3 image described by the provided
``entry_point_info_t`` structure. In the normal TF boot flow, BL2 invokes this SMC
for BL1 to pass execution control to BL31.
``entry_point_info_t`` structure. In the normal TF-A boot flow, BL2 invokes
this SMC for BL1 to pass execution control to BL31.
FWU\_SMC\_IMAGE\_COPY
~~~~~~~~~~~~~~~~~~~~~
......@@ -400,7 +400,7 @@ This is only allowed if the image is not being executed.
--------------
*Copyright (c) 2015-2017, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.*
.. _Trusted Board Boot: ./trusted-board-boot.rst
.. _Porting Guide: ./porting-guide.rst
......
ARM Trusted Firmware Interrupt Management Design guide
======================================================
Trusted Firmware-A interrupt management design guide
====================================================
.. section-numbering::
......@@ -88,8 +88,8 @@ The framework considers certain routing models for each type of interrupt to be
incorrect as they conflict with the requirements mentioned in Section 1. The
following sub-sections describe all the possible routing models and specify
which ones are valid or invalid. EL3 interrupts are currently supported only
for GIC version 3.0 (ARM GICv3) and only the Secure-EL1 and Non-secure interrupt
types are supported for GIC version 2.0 (ARM GICv2) (See 1.2). The terminology
for GIC version 3.0 (Arm GICv3) and only the Secure-EL1 and Non-secure interrupt
types are supported for GIC version 2.0 (Arm GICv2) (See 1.2). The terminology
used in the following sub-sections is explained below.
#. **CSS**. Current Security State. ``0`` when secure and ``1`` when non-secure
......@@ -111,7 +111,7 @@ Secure-EL1 interrupts
#. **CSS=1, TEL3=0**. Interrupt is routed to the FEL when execution is in
non-secure state. This is an invalid routing model as a secure interrupt
is not visible to the secure software which violates the motivation behind
the ARM Security Extensions.
the Arm Security Extensions.
#. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
non-secure state. This is a valid routing model as secure software in EL3
......@@ -162,7 +162,7 @@ EL3 interrupts
#. **CSS=1, TEL3=0**. Interrupt is routed to the FEL when execution is in
non-secure state. This is an invalid routing model as a secure interrupt
is not visible to the secure software which violates the motivation behind
the ARM Security Extensions.
the Arm Security Extensions.
#. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
non-secure state. This is a valid routing model as secure software in EL3
......@@ -179,7 +179,7 @@ uses this information to determine whether the IRQ or the FIQ bit should be
programmed in ``SCR_EL3`` while applying the routing model for a type of
interrupt. The platform provides this information through the
``plat_interrupt_type_to_line()`` API (described in the
`Porting Guide`_). For example, on the FVP port when the platform uses an ARM GICv2
`Porting Guide`_). For example, on the FVP port when the platform uses an Arm GICv2
interrupt controller, Secure-EL1 interrupts are signaled through the FIQ signal
while Non-secure interrupts are signaled through the IRQ signal. This applies
when execution is in either security state.
......@@ -194,7 +194,7 @@ that security state. This means that all the other interrupt types using the
same interrupt signal will be forced to the same routing model. This should be
borne in mind when choosing the routing model for an interrupt type.
For example, in ARM GICv3, when the execution context is Secure-EL1/
For example, in Arm GICv3, when the execution context is Secure-EL1/
Secure-EL0, both the EL3 and the non secure interrupt types map to the FIQ
signal. So if either one of the interrupt type sets the routing model so
that **TEL3=1** when **CSS=0**, the FIQ bit in ``SCR_EL3`` will be programmed to
......@@ -208,8 +208,8 @@ The framework makes the following assumptions to simplify its implementation.
#. Although the framework has support for 2 types of secure interrupts (EL3
and Secure-EL1 interrupt), only interrupt controller architectures
like ARM GICv3 has architectural support for EL3 interrupts in the form of
Group 0 interrupts. In ARM GICv2, all secure interrupts are assumed to be
like Arm GICv3 has architectural support for EL3 interrupts in the form of
Group 0 interrupts. In Arm GICv2, all secure interrupts are assumed to be
handled in Secure-EL1. They can be delivered to Secure-EL1 via EL3 but they
cannot be handled in EL3.
......@@ -260,7 +260,7 @@ the non-secure interrupts and target them to the primary CPU. It should also
export the interface described in the `Porting Guide`_ to enable
handling of interrupts.
In the remainder of this document, for the sake of simplicity a ARM GICv2 system
In the remainder of this document, for the sake of simplicity a Arm GICv2 system
is considered and it is assumed that the FIQ signal is used to generate Secure-EL1
interrupts and the IRQ signal is used to generate non-secure interrupts in either
security state. EL3 interrupts are not considered.
......@@ -272,8 +272,7 @@ Roles and responsibilities for interrupt management are sub-divided between the
following components of software running in EL3 and Secure-EL1. Each component is
briefly described below.
#. EL3 Runtime Firmware. This component is common to all ports of the ARM
Trusted Firmware.
#. EL3 Runtime Firmware. This component is common to all ports of TF-A.
#. Secure Payload Dispatcher (SPD) service. This service interfaces with the
Secure Payload (SP) software which runs in Secure-EL1/Secure-EL0 and is
......@@ -282,20 +281,20 @@ briefly described below.
exported by the Context management library to implement this functionality.
Switching execution between the two security states is a requirement for
interrupt management as well. This results in a significant dependency on
the SPD service. ARM Trusted firmware implements an example Test Secure
Payload Dispatcher (TSPD) service.
the SPD service. TF-A implements an example Test Secure Payload Dispatcher
(TSPD) service.
An SPD service plugs into the EL3 runtime firmware and could be common to
some ports of the ARM Trusted Firmware.
some ports of TF-A.
#. Secure Payload (SP). On a production system, the Secure Payload corresponds
to a Secure OS which runs in Secure-EL1/Secure-EL0. It interfaces with the
SPD service to manage communication with non-secure software. ARM Trusted
Firmware implements an example secure payload called Test Secure Payload
(TSP) which runs only in Secure-EL1.
SPD service to manage communication with non-secure software. TF-A
implements an example secure payload called Test Secure Payload (TSP)
which runs only in Secure-EL1.
A Secure payload implementation could be common to some ports of the ARM
Trusted Firmware just like the SPD service.
A Secure payload implementation could be common to some ports of TF-A,
just like the SPD service.
Interrupt registration
----------------------
......@@ -515,7 +514,7 @@ the interrupt routing model is not known to the SPD service at compile time,
then the SP should pass this information to the SPD service at runtime during
its initialisation phase.
As mentioned earlier, a ARM GICv2 system is considered and it is assumed that
As mentioned earlier, an Arm GICv2 system is considered and it is assumed that
the FIQ signal is used to generate Secure-EL1 interrupts and the IRQ signal
is used to generate non-secure interrupts in either security state.
......@@ -595,7 +594,7 @@ exceptions taken at the same (Secure-EL1) exception level. This table is
referenced through the ``tsp_exceptions`` variable and programmed into the
VBAR\_EL1. It caters for the asynchronous handling model.
The TSP also programs the Secure Physical Timer in the ARM Generic Timer block
The TSP also programs the Secure Physical Timer in the Arm Generic Timer block
to raise a periodic interrupt (every half a second) for the purpose of testing
interrupt management across all the software components listed in 2.1
......@@ -999,7 +998,7 @@ TSP by returning ``SMC_UNK`` error.
--------------
*Copyright (c) 2014-2018, ARM Limited and Contributors. All rights reserved.*
*Copyright (c) 2014-2018, Arm Limited and Contributors. All rights reserved.*
.. _Porting Guide: ./porting-guide.rst
.. _SMC calling convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
......
......@@ -11,7 +11,7 @@ How to build
Code Locations
--------------
- ARM Trusted Firmware:
- Trusted Firmware-A:
`link <https://github.com/ARM-software/arm-trusted-firmware>`__
- OP-TEE
......@@ -76,13 +76,13 @@ Build Procedure
export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools
export EDK2_DIR=${BUILD_PATH}/edk2
EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey/${BUILD_OPTION}_${AARCH64_TOOLCHAIN}
# Build fastboot for ARM Trust Firmware. It's used for recovery mode.
# Build fastboot for Trusted Firmware-A. It's used for recovery mode.
cd ${BUILD_PATH}/atf-fastboot
CROSS_COMPILE=aarch64-linux-gnu- make PLAT=hikey DEBUG=1
# Convert DEBUG/RELEASE to debug/release
FASTBOOT_BUILD_OPTION=$(echo ${BUILD_OPTION} | tr '[A-Z]' '[a-z]')
cd ${EDK2_DIR}
# Build UEFI & ARM Trust Firmware
# Build UEFI & Trusted Firmware-A
${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware -s ../optee_os hikey
- Generate l-loader.bin and partition table for aosp. The eMMC capacity is either 8GB or 4GB. Just change "aosp-8g" to "linux-8g" for debian.
......
......@@ -11,7 +11,7 @@ How to build
Code Locations
--------------
- ARM Trusted Firmware:
- Trusted Firmware-A:
`link <https://github.com/ARM-software/arm-trusted-firmware>`__
- OP-TEE:
......@@ -73,7 +73,7 @@ Build Procedure
export EDK2_DIR=${BUILD_PATH}/edk2
EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey960/${BUILD_OPTION}_${AARCH64_TOOLCHAIN}
cd ${EDK2_DIR}
# Build UEFI & ARM Trust Firmware
# Build UEFI & Trusted Firmware-A
${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware -s ../optee_os hikey960
- Generate l-loader.bin and partition table.
......
......@@ -4,10 +4,10 @@ Tegra SoCs - Overview
- .. rubric:: T210
:name: t210
T210 has Quad ARM® Cortex®-A57 cores in a switched configuration with a
companion set of quad ARM Cortex-A53 cores. The Cortex-A57 and A53 cores
support ARMv8, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code
including legacy ARMv7 applications. The Cortex-A57 processors each have
T210 has Quad Arm® Cortex®-A57 cores in a switched configuration with a
companion set of quad Arm Cortex-A53 cores. The Cortex-A57 and A53 cores
support Armv8-A, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code
including legacy Armv7-A applications. The Cortex-A57 processors each have
48 KB Instruction and 32 KB Data Level 1 caches; and have a 2 MB shared
Level 2 unified cache. The Cortex-A53 processors each have 32 KB Instruction
and 32 KB Data Level 1 caches; and have a 512 KB shared Level 2 unified cache.
......@@ -16,7 +16,7 @@ and 32 KB Data Level 1 caches; and have a 512 KB shared Level 2 unified cache.
:name: t132
Denver is NVIDIA's own custom-designed, 64-bit, dual-core CPU which is
fully ARMv8 architecture compatible. Each of the two Denver cores
fully Armv8-A architecture compatible. Each of the two Denver cores
implements a 7-way superscalar microarchitecture (up to 7 concurrent
micro-ops can be executed per clock), and includes a 128KB 4-way L1
instruction cache, a 64KB 4-way L1 data cache, and a 2MB 16-way L2
......@@ -94,5 +94,5 @@ Tegra configs
=============
- 'tegra\_enable\_l2\_ecc\_parity\_prot': This flag enables the L2 ECC and Parity
Protection bit, for ARM Cortex-A57 CPUs, during CPU boot. This flag will
Protection bit, for Arm Cortex-A57 CPUs, during CPU boot. This flag will
be enabled by Tegrs SoCs during 'Cluster power up' or 'System Suspend' exit.
......@@ -5,7 +5,7 @@ Poplar is the first development board compliant with the 96Boards Enterprise
Edition TV Platform specification.
The board features the Hi3798C V200 with an integrated quad-core 64-bit
ARM Cortex A53 processor and high performance Mali T720 GPU, making it capable
Arm Cortex A53 processor and high performance Mali T720 GPU, making it capable
of running any commercial set-top solution based on Linux or Android.
It supports a premium user experience with up to H.265 HEVC decoding of 4K
......@@ -14,7 +14,7 @@ video at 60 frames per second.
::
SOC Hisilicon Hi3798CV200
CPU Quad-core ARM Cortex-A53 64 bit
CPU Quad-core Arm Cortex-A53 64 bit
DRAM DDR3/3L/4 SDRAM interface, maximum 32-bit data width 2 GB
USB Two USB 2.0 ports One USB 3.0 ports
CONSOLE USB-micro port for console support
......@@ -28,11 +28,11 @@ video at 60 frames per second.
At the start of the boot sequence, the bootROM executes the so called l-loader
binary whose main role is to change the processor state to 64bit mode. This
must happen prior invoking the arm trusted firmware:
must happen prior to invoking Trusted Firmware-A:
::
l-loader --> arm_trusted_firmware --> u-boot
l-loader --> Trusted Firmware-A --> u-boot
How to build
============
......@@ -40,7 +40,7 @@ How to build
Code Locations
--------------
- ARM Trusted Firmware:
- Trusted Firmware-A:
`link <https://github.com/ARM-software/arm-trusted-firmware>`__
- l-loader:
......
ARM Trusted Firmware for QEMU virt ARMv8-A
==========================================
Trusted Firmware-A for QEMU virt Armv8-A
========================================
ARM Trusted Firmware implements the EL3 firmware layer for QEMU virt
ARMv8-A. BL1 is used as the BootROM, supplied with the -bios argument.
Trusted Firmware-A (TF-A) implements the EL3 firmware layer for QEMU virt
Armv8-A. BL1 is used as the BootROM, supplied with the -bios argument.
When QEMU starts all CPUs are released simultaneously, BL1 selects a
primary CPU to handle the boot and the secondaries are placed in a polling
loop to be released by normal world via PSCI.
......@@ -10,7 +10,7 @@ loop to be released by normal world via PSCI.
BL2 edits the Flattened Device Tree, FDT, generated by QEMU at run-time to
add a node describing PSCI and also enable methods for the CPUs.
An ARM64 defonfig v4.5 Linux kernel is known to boot, FTD doesn't need to be
An ARM64 defconfig v4.5 Linux kernel is known to boot, FDT doesn't need to be
provided as it's generated by QEMU.
Current limitations:
......
Arm Trusted Firmware for Raspberry Pi 3
=======================================
Trusted Firmware-A for Raspberry Pi 3
=====================================
.. section-numbering::
:suffix: .
......@@ -7,16 +7,16 @@ Arm Trusted Firmware for Raspberry Pi 3
.. contents::
The `Raspberry Pi 3`_ is an inexpensive single-board computer that contains four
Cortex-A53 cores, which makes it possible to have a port of the Arm Trusted
Firmware.
Arm Cortex-A53 cores, which makes it possible to have a port of Trusted
Firmware-A (TF-A).
The following instructions explain how to use this port of the Trusted Firmware
with the default distribution of `Raspbian`_ because that's the distribution
officially supported by the Raspberry Pi Foundation. At the moment of writing
this, the officially supported kernel is a AArch32 kernel. This doesn't mean
that this port of the Trusted Firmware can't boot a AArch64 kernel. The `Linux
tree fork`_ maintained by the Foundation can be compiled for AArch64 by
following the steps in `AArch64 kernel build instructions`_.
The following instructions explain how to use this port of the TF-A with the
default distribution of `Raspbian`_ because that's the distribution officially
supported by the Raspberry Pi Foundation. At the moment of writing this, the
officially supported kernel is a AArch32 kernel. This doesn't mean that this
port of TF-A can't boot a AArch64 kernel. The `Linux tree fork`_ maintained by
the Foundation can be compiled for AArch64 by following the steps in
`AArch64 kernel build instructions`_.
**IMPORTANT NOTE**: This port isn't secure. All of the memory used is DRAM,
which is available from both the Non-secure and Secure worlds. This port
......@@ -46,15 +46,15 @@ The rules are simple:
the cores are powered on at the same time and start at address **0x0**.
This means that we can use the default AArch32 kernel provided in the official
`Raspbian`_ distribution by renaming it to ``kernel8.img``, while the Trusted
Firmware and anything else we need is in ``armstub8.bin``. This way we can
forget about the default bootstrap code. When using a AArch64 kernel, it is only
needed to make sure that the name on the SD card is ``kernel8.img``.
`Raspbian`_ distribution by renaming it to ``kernel8.img``, while TF-A and
anything else we need is in ``armstub8.bin``. This way we can forget about the
default bootstrap code. When using a AArch64 kernel, it is only needed to make
sure that the name on the SD card is ``kernel8.img``.
Ideally, we want to load the kernel and have all cores available, which means
that we need to make the secondary cores work in the way the kernel expects, as
explained in `Secondary cores`_. In practice, a small bootstrap is needed
between the Trusted Firmware and the kernel.
between TF-A and the kernel.
To get the most out of a AArch32 kernel, we want to boot it in Hypervisor mode
in AArch32. This means that BL33 can't be in EL2 in AArch64 mode. The
......@@ -66,7 +66,7 @@ Placement of images
The file ``armstub8.bin`` contains BL1 and the FIP. It is needed to add padding
between them so that the addresses they are loaded to match the ones specified
when compiling the Trusted Firmware.
when compiling TF-A.