This document describes the design of the Firmware Update (FWU) feature, which
enables authenticated firmware to update firmware images from external
interfaces such as USB, UART, SD-eMMC, NAND, NOR or Ethernet to SoC Non-Volatile
-memories such as NAND Flash, LPPDR2-NVM or any memory determined by the
+memories such as NAND Flash, LPDDR2-NVM or any memory determined by the
platform. This feature functions even when the current firmware in the system
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.
project = 'Trusted Firmware-A'
-version = '2.1'
-release = version # We don't need these to be distinct
-
# -- General configuration ---------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be
point during a cold boot.
- On Juno, SCP_BL2 is loaded temporarily into the EL3 Runtime Software memory
- region and transfered to the SCP before being overwritten by EL3 Runtime
+ region and transferred to the SCP before being overwritten by EL3 Runtime
Software.
- BL32 (for AArch64) can be loaded in one of the following locations:
Cortex-A15 target.
Platform can also set ``ARM_WITH_NEON=yes`` to enable neon support.
-Note that using neon at runtime has constraints on non secure wolrd context.
+Note that using neon at runtime has constraints on non secure world context.
TF-A does not yet provide VFP context management.
Directive ``ARM_CORTEX_A<x>`` and ``ARM_WITH_NEON`` are used to set
General Notes
-------------
-- Some of the names and abbreviated names have changed to accomodate new
+- Some of the names and abbreviated names have changed to accommodate new
requirements. The changed names are as backward compatible as possible to
minimize confusion. Where applicable, the previous names are indicated. Some
code, documentation and build artefacts may still refer to the previous names;
~~~~~~~~~~~~~~~~~~~~~~~
Typically, this is the first code to execute on the AP and cannot be modified.
-Its primary purpose is to perform the minimum intialization necessary to load
+Its primary purpose is to perform the minimum initialization necessary to load
and authenticate an updateable AP firmware image into an executable RAM
location, then hand-off control to that image.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Typically, this is the first code to execute on the SCP and cannot be modified.
-Its primary purpose is to perform the minimum intialization necessary to load
+Its primary purpose is to perform the minimum initialization necessary to load
and authenticate an updateable SCP firmware image into an executable RAM
location, then hand-off control to that image. This may be performed in
conjunction with other processor firmware (for example, ``AP_BL1`` and
Typically, this is the first normal world code to execute on the AP during a
firmware update operation, and cannot be modified. Its primary purpose is to
-load subequent firmware update images from an external interface and communicate
+load subsequent firmware update images from an external interface and communicate
with ``AP_BL1`` to authenticate those images.
During firmware update, there are (potentially) multiple transitions between the
- **PLAT_PARTITION_BLOCK_SIZE**
The size of partition block. It could be either 512 bytes or 4096 bytes.
The default value is 512.
- `For example, define the build flag in platform.mk`_:
+ For example, define the build flag in ``platform.mk``:
PLAT_PARTITION_BLOCK_SIZE := 4096
$(eval $(call add_define,PLAT_PARTITION_BLOCK_SIZE))
Return : void
A platform may need to do additional initialization after reset. This function
-allows the platform to do the platform specific intializations. Platform
+allows the platform to do the platform specific initializations. Platform
specific errata workarounds could also be implemented here. The API should
preserve the values of callee saved registers x19 to x29.
added to the local implementation.
Some C headers have been obtained from `FreeBSD`_ and `SCC`_, while others have
-been written specifically for TF-A. Fome implementation files have been obtained
+been written specifically for TF-A. Some implementation files have been obtained
from `FreeBSD`_, others have been written specifically for TF-A as well. The
files can be found in ``include/lib/libc`` and ``lib/libc``.
`Summary of build options`_ for more information on available build
options.
- - (AArch32 only) Currently only ``PLAT=fvp`` is supported.
-
- (AArch32 only) ``AARCH32_SP`` is the AArch32 EL3 Runtime Software and it
corresponds to the BL32 image. A minimal ``AARCH32_SP``, sp_min, is
provided by TF-A to demonstrate how PSCI Library can be integrated with
make [DEBUG=1] [V=1] fiptool
# Unpack firmware images from Linaro FIP
- ./tools/fiptool/fiptool unpack <path-to-linaro-release>/fip.bin
+ ./tools/fiptool/fiptool unpack <path-to-linaro-release>/[SOFTWARE]/fip.bin
The unpack operation will result in a set of binary images extracted to the
current working directory. The SCP_BL2 image corresponds to
.. code:: shell
- export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf-
+ export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-eabi-
- Build BL32 in AArch32.
(64-bit host machine only).
.. note::
- The FVP models used are Version 11.5 Build 33, unless otherwise stated.
+ The FVP models used are Version 11.6 Build 45, unless otherwise stated.
- ``FVP_Base_AEMv8A-AEMv8A``
- ``FVP_Base_AEMv8A-AEMv8A-AEMv8A-AEMv8A-CCN502``
The Foundation FVP can be downloaded free of charge. The Base FVPs can be
licensed from Arm. See the `Arm FVP website`_.
-All the above platforms have been tested with `Linaro Release 18.04`_.
+All the above platforms have been tested with `Linaro Release 19.06`_.
This release also contains the following platform support:
.. _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 18.04: https://community.arm.com/dev-platforms/b/documents/posts/linaro-release-notes-deprecated#LinaroRelease18.04
+.. _Linaro Release 19.06: http://releases.linaro.org/members/arm/platforms/19.06
.. _OP-TEE Secure OS: https://github.com/OP-TEE/optee_os
.. _NVIDIA Trusted Little Kernel: http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/ote_partner/tlk.git;a=summary
.. _Trusty Secure OS: https://source.android.com/security/trusty
:F: plat/amlogic/gxl/
Amlogic Meson S905X2 (G12A) platform port
----------------------------------------
+-----------------------------------------
:M: Carlo Caione <ccaione@baylibre.com>
-:G: `carlo.caione`_
+:G: `carlocaione`_
:F: docs/plat/meson-g12a.rst
:F: drivers/amlogic/g12a
:F: plat/amlogic/g12a/
:M: Tien Hock Loh <tien.hock.loh@intel.com>
:G: `thloh85-intel`_
:M: Hadi Asyrafi <muhammad.hadi.asyrafi.abdul.halim@intel.com>
-:G: `mabdulha`_
+:G: mabdulha
:F: plat/intel/soc
:F: drivers/intel/soc/
.. _Anson-Huang: https://github.com/Anson-Huang
.. _bryanodonoghue: https://github.com/bryanodonoghue
.. _b49020: https://github.com/b49020
+.. _carlocaione: https://github.com/carlocaione
.. _danh-arm: https://github.com/danh-arm
.. _etienne-lms: https://github.com/etienne-lms
.. _glneo: https://github.com/glneo
.. _sivadur: https://github.com/sivadur
.. _smaeul: https://github.com/smaeul
.. _soby-mathew: https://github.com/soby-mathew
+.. _thloh85-intel: https://github.com/thloh85-intel
.. _thomas-arm: https://github.com/thomas-arm
.. _TonyXie06: https://github.com/TonyXie06
.. _vwadekar: https://github.com/vwadekar
| 5 | 21 | 17 | 6 |
+-------+---------------------+--------------------+--------------------------+
-The ``CLUSH_OVERHEAD`` times for lead CPU 4 and all CPUs in the non-lead cluster
+The ``CFLUSH_OVERHEAD`` times for lead CPU 4 and all CPUs in the non-lead cluster
are large because all other CPUs in the cluster are powered down during the
test. The ``CPU_SUSPEND`` call powers down to the cluster level, requiring a
flush of both L1 and L2 caches.
.. seealso::
For XFI/SFI comphy type there is procedure "rx_training" which eases
- process of suiting some of the parameters. Please see :ref:`uboot_cmd`
+ process of suiting some of the parameters. Please see *uboot_cmd*
section: rx_training.
The PHY porting layer simplifies updating static values per board type,
Amlogic Meson S905X2 (G12A)
-==========================
+===========================
The Amlogic Meson S905X2 is a SoC with a quad core Arm Cortex-A53 running at
~1.8GHz. It also contains a Cortex-M3 used as SCP.
- ``**WARNING: Use of volatile is usually wrong``: see
`Why the “volatile” type class should not be used`_ . Although this document
- contains some very useful information, there are several legimate uses of the
- volatile keyword within the TF codebase.
+ contains some very useful information, there are several legitimate uses of
+ the volatile keyword within the TF codebase.
Headers and inclusion
---------------------
For Cortex-A73 and Cortex-A75 CPUs, the PRs in this advisory invalidate the
branch predictor when entering EL3 by temporarily dropping into AArch32
Secure-EL1 and executing the ``BPIALL`` instruction. This workaround is
-signifiantly more complex than the "MMU disable/enable" workaround. The latter
+significantly more complex than the "MMU disable/enable" workaround. The latter
is not effective at invalidating the branch predictor on Cortex-A73/Cortex-A75.
Note that if other privileged software, for example a Rich OS kernel, implements
#if (ARM_ARCH_MAJOR == 7) && !defined(ARMV7_SUPPORTS_VIRTUALIZATION)
push {r0,r3}
softudiv r0,r1,r2,r3
- mov r1, r0
+ mov r2, r0
pop {r0,r3}
#else
udiv r2, r1, r2
projects / project / bcm63xx / atf.git / commitdiff