mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2025-04-16 09:34:18 +00:00
Doc: Remove useless escape characters
Just like has been done in the porting guide a couple of patches earlier, kill all escaped underscore characters in all documents. Change-Id: I7fb5b806412849761d9221a6ce3cbd95ec43d611 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
This commit is contained in:
Sandrine Bailleux
parent
337e2f1f2b
commit
f3cacadae3
12 changed files with 180 additions and 180 deletions
|
|
@ -209,7 +209,7 @@ It is responsible for:
|
|||
#. Tracking which images have been verified. In case an image is a part of
|
||||
multiple CoTs then it should be verified only once e.g. the Trusted World
|
||||
Key Certificate in the TBBR-Client spec. contains information to verify
|
||||
SCP\_BL2, BL31, BL32 each of which have a separate CoT. (This
|
||||
SCP_BL2, BL31, BL32 each of which have a separate CoT. (This
|
||||
responsibility has not been described in this document but should be
|
||||
trivial to implement).
|
||||
|
||||
|
|
@ -627,7 +627,7 @@ The TBBR CoT
|
|||
|
||||
The CoT can be found in ``drivers/auth/tbbr/tbbr_cot.c``. This CoT consists of an
|
||||
array of image descriptors and it is registered in the framework using the macro
|
||||
``REGISTER_COT(cot_desc)``, where 'cot\_desc' must be the name of the array
|
||||
``REGISTER_COT(cot_desc)``, where 'cot_desc' must be the name of the array
|
||||
(passing a pointer or any other type of indirection will cause the registration
|
||||
process to fail).
|
||||
|
||||
|
|
|
|||
|
|
@ -973,7 +973,7 @@ New features
|
|||
|
||||
- Updated PSCI support:
|
||||
|
||||
- Added support for PSCI NODE\_HW\_STATE API for Arm platforms.
|
||||
- Added support for PSCI NODE_HW_STATE API for Arm platforms.
|
||||
|
||||
- New optional platform hook, ``pwr_domain_pwr_down_wfi()``, in
|
||||
``plat_psci_ops`` to enable platforms to perform platform-specific actions
|
||||
|
|
@ -1000,14 +1000,14 @@ New features
|
|||
This can be useful to map a non-cacheable memory region, such as a DMA
|
||||
buffer.
|
||||
|
||||
- Introduced the MT\_EXECUTE/MT\_EXECUTE\_NEVER memory mapping attributes to
|
||||
- Introduced the MT_EXECUTE/MT_EXECUTE_NEVER memory mapping attributes to
|
||||
specify the access permissions for instruction execution of a memory
|
||||
region.
|
||||
|
||||
- Enabled support to isolate code and read-only data on separate memory pages,
|
||||
allowing independent access control to be applied to each.
|
||||
|
||||
- Enabled SCR\_EL3.SIF (Secure Instruction Fetch) bit in BL1 and BL31 common
|
||||
- Enabled SCR_EL3.SIF (Secure Instruction Fetch) bit in BL1 and BL31 common
|
||||
architectural setup code, preventing fetching instructions from non-secure
|
||||
memory when in secure state.
|
||||
|
||||
|
|
@ -1025,7 +1025,7 @@ New features
|
|||
the working directory.
|
||||
|
||||
- Aligned command line options for specifying images to use same naming
|
||||
convention as specified by TBBR and already used in cert\_create tool.
|
||||
convention as specified by TBBR and already used in cert_create tool.
|
||||
|
||||
- Refactored the TZC-400 driver to also support memory controllers that
|
||||
integrate TZC functionality, for example Arm CoreLink DMC-500. Also added
|
||||
|
|
@ -1036,7 +1036,7 @@ New features
|
|||
|
||||
- Enhanced support for Arm platforms:
|
||||
|
||||
- Updated image loading support to make SCP images (SCP\_BL2 and SCP\_BL2U)
|
||||
- Updated image loading support to make SCP images (SCP_BL2 and SCP_BL2U)
|
||||
optional.
|
||||
|
||||
- Enhanced topology description support to allow multi-cluster topology
|
||||
|
|
@ -1104,7 +1104,7 @@ New features
|
|||
**Note** the default build of TF-A will not be able to boot
|
||||
Linux kernel with GICv2 FDT blob.
|
||||
|
||||
- Enabled wake-up from CPU\_SUSPEND to stand-by by temporarily re-routing
|
||||
- Enabled wake-up from CPU_SUSPEND to stand-by by temporarily re-routing
|
||||
interrupts and then restoring after resume.
|
||||
|
||||
Issues resolved since last release
|
||||
|
|
@ -1219,7 +1219,7 @@ New features
|
|||
|
||||
- Better alignment with version 1.0 of the PSCI specification.
|
||||
|
||||
- Added support for the SYSTEM\_SUSPEND PSCI API on Arm platforms. When invoked
|
||||
- Added support for the SYSTEM_SUSPEND PSCI API on Arm platforms. When invoked
|
||||
on the last running core on a supported platform, this puts the system
|
||||
into a low power mode with memory retention.
|
||||
|
||||
|
|
@ -1615,7 +1615,7 @@ Known issues
|
|||
<SimName>System Generator:FVP_Base_A57x4_A53x4</SimName>
|
||||
|
||||
to
|
||||
System Generator:FVP\_Base\_Cortex-A57x4\_A53x4
|
||||
System Generator:FVP_Base_Cortex-A57x4_A53x4
|
||||
|
||||
A similar change can be made to the other Cortex-A57-A53 Base FVP variants.
|
||||
|
||||
|
|
@ -1643,7 +1643,7 @@ New features
|
|||
|
||||
- Moved architectural timer setup to platform-specific code.
|
||||
|
||||
- Added standby state support to PSCI cpu\_suspend implementation.
|
||||
- Added standby state support to PSCI cpu_suspend implementation.
|
||||
|
||||
- SRAM usage improvements:
|
||||
|
||||
|
|
@ -1669,7 +1669,7 @@ New features
|
|||
default configuration is provided for the Base FVPs. This means the model
|
||||
parameter ``-C bp.secure_memory=1`` is now supported.
|
||||
|
||||
- Started saving the PSCI cpu\_suspend 'power\_state' parameter prior to
|
||||
- Started saving the PSCI cpu_suspend 'power_state' parameter prior to
|
||||
suspending a CPU. This allows platforms that implement multiple power-down
|
||||
states at the same affinity level to identify a specific state.
|
||||
|
||||
|
|
@ -1767,13 +1767,13 @@ New features
|
|||
instructions for how to contribute and updated copyright text in all files
|
||||
to acknowledge contributors.
|
||||
|
||||
- The PSCI CPU\_SUSPEND API has been stabilised to the extent where it can be
|
||||
- The PSCI CPU_SUSPEND API has been stabilised to the extent where it can be
|
||||
used for entry into power down states with the following restrictions:
|
||||
|
||||
- Entry into standby states is not supported.
|
||||
- The API is only supported on the AEMv8 and Cortex-A57-A53 Base FVPs.
|
||||
|
||||
- The PSCI AFFINITY\_INFO api has undergone limited testing on the Base FVPs to
|
||||
- The PSCI AFFINITY_INFO api has undergone limited testing on the Base FVPs to
|
||||
allow experimental use.
|
||||
|
||||
- Required C library and runtime header files are now included locally in
|
||||
|
|
@ -1803,7 +1803,7 @@ New features
|
|||
particular code modules to DRAM itself.
|
||||
|
||||
- Reworked BL2 to BL3-1 handover interface. A new composite structure
|
||||
(bl31\_args) holds the superset of information that needs to be passed from
|
||||
(bl31_args) holds the superset of information that needs to be passed from
|
||||
BL2 to BL3-1, including information on how handover execution control to
|
||||
BL3-2 (if present) and BL3-3 (non-trusted firmware).
|
||||
|
||||
|
|
@ -1817,7 +1817,7 @@ New features
|
|||
- Added a framework for implementing EL3 runtime services. Reworked the PSCI
|
||||
implementation to be one such runtime service.
|
||||
|
||||
- Reworked the exception handling logic, making use of both SP\_EL0 and SP\_EL3
|
||||
- Reworked the exception handling logic, making use of both SP_EL0 and SP_EL3
|
||||
stack pointers for determining the type of exception, managing general
|
||||
purpose and system register context on exception entry/exit, and handling
|
||||
SMCs. SMCs are directed to the correct EL3 runtime service.
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ For Cortex-A53, the following errata build flags are defined :
|
|||
- ``ERRATA_A53_855873``: This applies errata 855873 workaround to Cortex-A53
|
||||
CPUs. Though the erratum is present in every revision of the CPU,
|
||||
this workaround is only applied to CPUs from r0p3 onwards, which feature
|
||||
a chicken bit in CPUACTLR\_EL1 to enable a hardware workaround.
|
||||
a chicken bit in CPUACTLR_EL1 to enable a hardware workaround.
|
||||
Earlier revisions of the CPU have other errata which require the same
|
||||
workaround in software, so they should be covered anyway.
|
||||
|
||||
|
|
@ -194,4 +194,4 @@ architecture that can be enabled by the platform as desired.
|
|||
.. _Cortex-A72 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm012079/index.html
|
||||
.. _Firmware Design guide: firmware-design.rst
|
||||
.. _Cortex-A57 Software Optimization Guide: http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/Cortex_A57_Software_Optimization_Guide_external.pdf
|
||||
.. _Arm DSU Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm138168/index.html
|
||||
.. _Arm DSU Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm138168/index.html
|
||||
|
|
|
|||
|
|
@ -404,16 +404,16 @@ needed in the ``bl2_plat_handle_post_image_load()`` function. These
|
|||
configuration files can be passed to next Boot Loader stages as arguments
|
||||
by updating the corresponding entrypoint information in this function.
|
||||
|
||||
SCP\_BL2 (System Control Processor Firmware) image load
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
SCP_BL2 (System Control Processor Firmware) image load
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Some systems have a separate System Control Processor (SCP) for power, clock,
|
||||
reset and system control. BL2 loads the optional SCP\_BL2 image from platform
|
||||
reset and system control. BL2 loads the optional SCP_BL2 image from platform
|
||||
storage into a platform-specific region of secure memory. The subsequent
|
||||
handling of SCP\_BL2 is platform specific. For example, on the Juno Arm
|
||||
handling of SCP_BL2 is platform specific. For example, on the Juno Arm
|
||||
development platform port the image is transferred into SCP's internal memory
|
||||
using the Boot Over MHU (BOM) protocol after being loaded in the trusted SRAM
|
||||
memory. The SCP executes SCP\_BL2 and signals to the Application Processor (AP)
|
||||
memory. The SCP executes SCP_BL2 and signals to the Application Processor (AP)
|
||||
for BL2 execution to continue.
|
||||
|
||||
EL3 Runtime Software image load
|
||||
|
|
@ -688,7 +688,7 @@ Data structures used in the BL31 cold boot interface
|
|||
These structures are designed to support compatibility and independent
|
||||
evolution of the structures and the firmware images. For example, a version of
|
||||
BL31 that can interpret the BL3x image information from different versions of
|
||||
BL2, a platform that uses an extended entry\_point\_info structure to convey
|
||||
BL2, a platform that uses an extended entry_point_info structure to convey
|
||||
additional register information to BL31, or a ELF image loader that can convey
|
||||
more details about the firmware images.
|
||||
|
||||
|
|
@ -803,10 +803,10 @@ Required CPU state for warm boot initialization
|
|||
|
||||
When requesting a CPU power-on, or suspending a running CPU, AArch32 EL3
|
||||
Runtime Software must ensure execution of a warm boot initialization entrypoint.
|
||||
If TF-A BL1 is used and the PROGRAMMABLE\_RESET\_ADDRESS build flag is false,
|
||||
If TF-A BL1 is used and the PROGRAMMABLE_RESET_ADDRESS build flag is false,
|
||||
then AArch32 EL3 Runtime Software must ensure that BL1 branches to the warm
|
||||
boot entrypoint by arranging for the BL1 platform function,
|
||||
plat\_get\_my\_entrypoint(), to return a non-zero value.
|
||||
plat_get_my_entrypoint(), to return a non-zero value.
|
||||
|
||||
In this case, the warm boot entrypoint must be in AArch32 EL3, little-endian
|
||||
data access and all interrupt sources masked:
|
||||
|
|
@ -996,7 +996,7 @@ mandatory APIs in PSCI v1.1, PSCI v1.0 and in PSCI v0.2 draft specification
|
|||
`Power State Coordination Interface PDD`_ are implemented. The table lists
|
||||
the PSCI v1.1 APIs and their support in generic code.
|
||||
|
||||
An API implementation might have a dependency on platform code e.g. CPU\_SUSPEND
|
||||
An API implementation might have a dependency on platform code e.g. CPU_SUSPEND
|
||||
requires the platform to export a part of the implementation. Hence the level
|
||||
of support of the mandatory APIs depends upon the support exported by the
|
||||
platform port as well. The Juno and FVP (all variants) platforms export all the
|
||||
|
|
@ -1657,13 +1657,13 @@ The following list describes the memory layout on the Arm development platforms:
|
|||
|
||||
- BL2 is loaded below BL1 RW
|
||||
|
||||
- EL3 Runtime Software, BL31 for AArch64 and BL32 for AArch32 (e.g. SP\_MIN),
|
||||
- EL3 Runtime Software, BL31 for AArch64 and BL32 for AArch32 (e.g. SP_MIN),
|
||||
is loaded at the top of the Trusted SRAM, such that its NOBITS sections will
|
||||
overwrite BL1 R/W data and BL2. This implies that BL1 global variables
|
||||
remain valid only until execution reaches the EL3 Runtime Software entry
|
||||
point during a cold boot.
|
||||
|
||||
- On Juno, SCP\_BL2 is loaded temporarily into the EL3 Runtime Software memory
|
||||
- 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
|
||||
Software.
|
||||
|
||||
|
|
@ -2089,11 +2089,11 @@ the update made by CPU0 as well.
|
|||
|
||||
To use bakery locks when ``USE_COHERENT_MEM`` is disabled, the lock data structure
|
||||
has been redesigned. The changes utilise the characteristic of Lamport's Bakery
|
||||
algorithm mentioned earlier. The bakery\_lock structure only allocates the memory
|
||||
algorithm mentioned earlier. The bakery_lock structure only allocates the memory
|
||||
for a single CPU. The macro ``DEFINE_BAKERY_LOCK`` allocates all the bakery locks
|
||||
needed for a CPU into a section ``bakery_lock``. The linker allocates the memory
|
||||
for other cores by using the total size allocated for the bakery\_lock section
|
||||
and multiplying it with (PLATFORM\_CORE\_COUNT - 1). This enables software to
|
||||
for other cores by using the total size allocated for the bakery_lock section
|
||||
and multiplying it with (PLATFORM_CORE_COUNT - 1). This enables software to
|
||||
perform software cache maintenance on the lock data structure without running
|
||||
into coherency issues associated with mismatched attributes.
|
||||
|
||||
|
|
@ -2155,7 +2155,7 @@ with n bakery locks are:
|
|||
------------------
|
||||
|
||||
Consider a system of 2 CPUs with 'N' bakery locks as shown above. For an
|
||||
operation on Lock\_N, the corresponding ``bakery_info_t`` in both CPU0 and CPU1
|
||||
operation on Lock_N, the corresponding ``bakery_info_t`` in both CPU0 and CPU1
|
||||
``bakery_lock`` section need to be fetched and appropriate cache operations need
|
||||
to be performed for each access.
|
||||
|
||||
|
|
@ -2619,8 +2619,8 @@ categories. Based upon the above, the code layout looks like this:
|
|||
lib Yes Yes Yes
|
||||
services No No Yes
|
||||
|
||||
The build system provides a non configurable build option IMAGE\_BLx for each
|
||||
boot loader stage (where x = BL stage). e.g. for BL1 , IMAGE\_BL1 will be
|
||||
The build system provides a non configurable build option IMAGE_BLx for each
|
||||
boot loader stage (where x = BL stage). e.g. for BL1 , IMAGE_BL1 will be
|
||||
defined by the build system. This enables TF-A to compile certain code only
|
||||
for specific boot loader stages
|
||||
|
||||
|
|
|
|||
|
|
@ -135,8 +135,8 @@ The following is a brief description of the supported states:
|
|||
BL1 SMC Interface
|
||||
-----------------
|
||||
|
||||
BL1\_SMC\_CALL\_COUNT
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
BL1_SMC_CALL_COUNT
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -148,8 +148,8 @@ BL1\_SMC\_CALL\_COUNT
|
|||
|
||||
This SMC returns the number of SMCs supported by BL1.
|
||||
|
||||
BL1\_SMC\_UID
|
||||
~~~~~~~~~~~~~
|
||||
BL1_SMC_UID
|
||||
~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -162,8 +162,8 @@ BL1\_SMC\_UID
|
|||
This SMC returns the 128-bit `Universally Unique Identifier`_ for the
|
||||
BL1 SMC service.
|
||||
|
||||
BL1\_SMC\_VERSION
|
||||
~~~~~~~~~~~~~~~~~
|
||||
BL1_SMC_VERSION
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -176,8 +176,8 @@ BL1\_SMC\_VERSION
|
|||
|
||||
This SMC returns the current version of the BL1 SMC service.
|
||||
|
||||
BL1\_SMC\_RUN\_IMAGE
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
BL1_SMC_RUN_IMAGE
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -196,8 +196,8 @@ This SMC passes execution control to an EL3 image described by the provided
|
|||
``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
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
FWU_SMC_IMAGE_COPY
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -245,8 +245,8 @@ contiguous memory.
|
|||
|
||||
Once the SMC is handled, BL1 returns from exception to the normal world caller.
|
||||
|
||||
FWU\_SMC\_IMAGE\_AUTH
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
FWU_SMC_IMAGE_AUTH
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -285,8 +285,8 @@ BL1 returns from exception to the caller. If authentication succeeds then BL1
|
|||
sets the image state to AUTHENTICATED. If authentication fails then BL1 returns
|
||||
the -EAUTH error and sets the image state back to RESET.
|
||||
|
||||
FWU\_SMC\_IMAGE\_EXECUTE
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
FWU_SMC_IMAGE_EXECUTE
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -313,8 +313,8 @@ secure world image.
|
|||
BL1 saves the normal world caller's context, sets the secure image state to
|
||||
EXECUTED, and returns from exception to the secure image.
|
||||
|
||||
FWU\_SMC\_IMAGE\_RESUME
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
FWU_SMC_IMAGE_RESUME
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -340,8 +340,8 @@ the resuming world. If the call is successful then the caller provided
|
|||
``image_param`` is returned to the resumed world, otherwise an error code is
|
||||
returned to the caller.
|
||||
|
||||
FWU\_SMC\_SEC\_IMAGE\_DONE
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
FWU_SMC_SEC_IMAGE_DONE
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -361,8 +361,8 @@ BL1 sets the previously executing secure image state to the RESET state,
|
|||
restores the normal world context and returns from exception into the normal
|
||||
world.
|
||||
|
||||
FWU\_SMC\_UPDATE\_DONE
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
FWU_SMC_UPDATE_DONE
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -377,8 +377,8 @@ This SMC completes the firmware update process. BL1 calls the platform specific
|
|||
function ``bl1_plat_fwu_done``, passing the optional argument ``client_cookie`` as
|
||||
a ``void *``. The SMC does not return.
|
||||
|
||||
FWU\_SMC\_IMAGE\_RESET
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
FWU_SMC_IMAGE_RESET
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -451,7 +451,7 @@ requirements mentioned earlier.
|
|||
The handover agreement between the TSP and the TSPD requires that the TSPD
|
||||
masks all interrupts (``PSTATE.DAIF`` bits) when it calls
|
||||
``tsp_sel1_intr_entry()``. The TSP has to preserve the callee saved general
|
||||
purpose, SP\_EL1/Secure-EL0, LR, VFP and system registers. It can use
|
||||
purpose, SP_EL1/Secure-EL0, LR, VFP and system registers. It can use
|
||||
``x0-x18`` to enable its C runtime.
|
||||
|
||||
#. The TSPD implements a handler function for Secure-EL1 interrupts. This
|
||||
|
|
@ -595,7 +595,7 @@ The TSP also replaces the default exception vector table referenced through the
|
|||
``early_exceptions`` variable, with a vector table capable of handling FIQ and IRQ
|
||||
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.
|
||||
VBAR_EL1. It caters for the asynchronous handling model.
|
||||
|
||||
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
|
||||
|
|
@ -904,7 +904,7 @@ In the synchronous model, it should begin handling a Secure-EL1 interrupt after
|
|||
receiving control from the SPD service at an entrypoint agreed upon during build
|
||||
time or during the registration phase. Before handling the interrupt, the SP
|
||||
should save any Secure-EL1 system register context which is needed for resuming
|
||||
normal execution in the SP later e.g. ``SPSR_EL1,``\ ELR\_EL1\`. After handling the
|
||||
normal execution in the SP later e.g. ``SPSR_EL1,``\ ELR_EL1\`. After handling the
|
||||
interrupt, the SP could return control back to the exception level and security
|
||||
state where the interrupt was originally taken from. The SP should use an SMC32
|
||||
or SMC64 to ask the SPD service to do this.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
TF-A Platform Compatibility Policy
|
||||
======================================================
|
||||
==================================
|
||||
|
||||
|
||||
.. section-numbering::
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ to this library are declared in ``psci.h`` and are as listed below:
|
|||
void psci_register_spd_pm_hook(const spd_pm_ops_t *pm);
|
||||
void psci_prepare_next_non_secure_ctx(entry_point_info_t *next_image_info);
|
||||
|
||||
The CPU context data 'cpu\_context\_t' is programmed to the registers differently
|
||||
The CPU context data 'cpu_context_t' is programmed to the registers differently
|
||||
when PSCI is integrated with an AArch32 EL3 Runtime Software compared to
|
||||
when the PSCI is integrated with an AArch64 EL3 Runtime Software (BL31). For
|
||||
example, in the case of AArch64, there is no need to retrieve ``cpu_context_t``
|
||||
|
|
@ -159,7 +159,7 @@ values if required.
|
|||
|
||||
PSCI library needs the flexibility to access both secure and non-secure
|
||||
copies of banked registers. Hence it needs to be invoked in Monitor mode
|
||||
for AArch32 and in EL3 for AArch64. The NS bit in SCR (in AArch32) or SCR\_EL3
|
||||
for AArch32 and in EL3 for AArch64. The NS bit in SCR (in AArch32) or SCR_EL3
|
||||
(in AArch64) must be set to 0. Additional requirements for the PSCI library
|
||||
interfaces are:
|
||||
|
||||
|
|
@ -175,8 +175,8 @@ interfaces are:
|
|||
Further requirements for each interface can be found in the interface
|
||||
description.
|
||||
|
||||
Interface : psci\_setup()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Interface : psci_setup()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -212,8 +212,8 @@ must have completed. Major actions performed by this interface are:
|
|||
`CPU Context management API`_) for all the CPUs in the
|
||||
platform
|
||||
|
||||
Interface : psci\_prepare\_next\_non\_secure\_ctx()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Interface : psci_prepare_next_non_secure_ctx()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -225,11 +225,11 @@ must be called by the EL3 Runtime Software to initialize the non-secure world
|
|||
context. The non-secure world entrypoint information ``next_image_info`` (first
|
||||
argument) will be used to determine the non-secure context. After this function
|
||||
returns, the EL3 Runtime Software must retrieve the ``cpu_context_t`` (using
|
||||
cm\_get\_context()) for the current CPU and program the registers prior to exit
|
||||
cm_get_context()) for the current CPU and program the registers prior to exit
|
||||
to the non-secure world.
|
||||
|
||||
Interface : psci\_register\_spd\_pm\_hook()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Interface : psci_register_spd_pm_hook()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -244,8 +244,8 @@ appropriately during power management. Calling this function is optional and
|
|||
need to be called by the primary CPU during the cold boot sequence after
|
||||
``psci_setup()`` has completed.
|
||||
|
||||
Interface : psci\_smc\_handler()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Interface : psci_smc_handler()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -270,8 +270,8 @@ PSCI API corresponding to ``smc_fid``. This function may not return back to the
|
|||
caller if PSCI API causes power down of the CPU. In this case, when the CPU
|
||||
wakes up, it will start execution from the warm reset address.
|
||||
|
||||
Interface : psci\_warmboot\_entrypoint()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Interface : psci_warmboot_entrypoint()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -302,7 +302,7 @@ EL3 Runtime Software dependencies
|
|||
---------------------------------
|
||||
|
||||
The PSCI Library includes supporting frameworks like context management,
|
||||
cpu operations (cpu\_ops) and per-cpu data framework. Other helper library
|
||||
cpu operations (cpu_ops) and per-cpu data framework. Other helper library
|
||||
functions like bakery locks and spin locks are also included in the library.
|
||||
The dependencies which must be fulfilled by the EL3 Runtime Software
|
||||
for integration with PSCI library are described below.
|
||||
|
|
@ -323,7 +323,7 @@ these functions but the EL3 Runtime Software may use its own implementation.
|
|||
|
||||
These must be implemented as described in ISO C Standard.
|
||||
|
||||
**Function : flush\_dcache\_range()**
|
||||
**Function : flush_dcache_range()**
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -333,7 +333,7 @@ These must be implemented as described in ISO C Standard.
|
|||
This function cleans and invalidates (flushes) the data cache for memory
|
||||
at address ``addr`` (first argument) address and of size ``size`` (second argument).
|
||||
|
||||
**Function : inv\_dcache\_range()**
|
||||
**Function : inv_dcache_range()**
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -343,7 +343,7 @@ at address ``addr`` (first argument) address and of size ``size`` (second argume
|
|||
This function invalidates (flushes) the data cache for memory at address
|
||||
``addr`` (first argument) address and of size ``size`` (second argument).
|
||||
|
||||
**Function : do\_panic()**
|
||||
**Function : do_panic()**
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -363,7 +363,7 @@ demonstrates how these APIs can be implemented but the EL3 Runtime Software can
|
|||
choose a more optimal implementation (like dedicating the secure TPIDRPRW
|
||||
system register (in AArch32) for storing these pointers).
|
||||
|
||||
**Function : cm\_set\_context\_by\_index()**
|
||||
**Function : cm_set_context_by_index()**
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -384,7 +384,7 @@ The actual method of storing the ``context`` pointers is implementation specific
|
|||
For example, SP-MIN stores the pointers in the array ``sp_min_cpu_ctx_ptr``
|
||||
declared in ``sp_min_main.c``.
|
||||
|
||||
**Function : cm\_get\_context()**
|
||||
**Function : cm_get_context()**
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -398,7 +398,7 @@ context pointers are stored prior to invoking this API. The ``security_state``
|
|||
will always be non-secure when called by PSCI library and this argument
|
||||
is retained for compatibility with BL31.
|
||||
|
||||
**Function : cm\_get\_context\_by\_index()**
|
||||
**Function : cm_get_context_by_index()**
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -423,25 +423,25 @@ Runtime Software for integration with the PSCI library.
|
|||
|
||||
The mandatory platform APIs are:
|
||||
|
||||
- plat\_my\_core\_pos
|
||||
- plat\_core\_pos\_by\_mpidr
|
||||
- plat\_get\_syscnt\_freq2
|
||||
- plat\_get\_power\_domain\_tree\_desc
|
||||
- plat\_setup\_psci\_ops
|
||||
- plat\_reset\_handler
|
||||
- plat\_panic\_handler
|
||||
- plat\_get\_my\_stack
|
||||
- plat_my_core_pos
|
||||
- plat_core_pos_by_mpidr
|
||||
- plat_get_syscnt_freq2
|
||||
- plat_get_power_domain_tree_desc
|
||||
- plat_setup_psci_ops
|
||||
- plat_reset_handler
|
||||
- plat_panic_handler
|
||||
- plat_get_my_stack
|
||||
|
||||
The mandatory platform macros are:
|
||||
|
||||
- PLATFORM\_CORE\_COUNT
|
||||
- PLAT\_MAX\_PWR\_LVL
|
||||
- PLAT\_NUM\_PWR\_DOMAINS
|
||||
- CACHE\_WRITEBACK\_GRANULE
|
||||
- PLAT\_MAX\_OFF\_STATE
|
||||
- PLAT\_MAX\_RET\_STATE
|
||||
- PLAT\_MAX\_PWR\_LVL\_STATES (optional)
|
||||
- PLAT\_PCPU\_DATA\_SIZE (optional)
|
||||
- PLATFORM_CORE_COUNT
|
||||
- PLAT_MAX_PWR_LVL
|
||||
- PLAT_NUM_PWR_DOMAINS
|
||||
- CACHE_WRITEBACK_GRANULE
|
||||
- PLAT_MAX_OFF_STATE
|
||||
- PLAT_MAX_RET_STATE
|
||||
- PLAT_MAX_PWR_LVL_STATES (optional)
|
||||
- PLAT_PCPU_DATA_SIZE (optional)
|
||||
|
||||
The details of these APIs/macros can be found in `Porting Guide`_.
|
||||
|
||||
|
|
@ -486,50 +486,50 @@ enabled/re-targeted back to the current CPU.
|
|||
|
||||
A brief description of each callback is given below:
|
||||
|
||||
- svc\_on, svc\_off, svc\_on\_finish
|
||||
- svc_on, svc_off, svc_on_finish
|
||||
|
||||
The ``svc_on``, ``svc_off`` callbacks are called during PSCI\_CPU\_ON,
|
||||
PSCI\_CPU\_OFF APIs respectively. The ``svc_on_finish`` is called when the
|
||||
target CPU of PSCI\_CPU\_ON API powers up and executes the
|
||||
The ``svc_on``, ``svc_off`` callbacks are called during PSCI_CPU_ON,
|
||||
PSCI_CPU_OFF APIs respectively. The ``svc_on_finish`` is called when the
|
||||
target CPU of PSCI_CPU_ON API powers up and executes the
|
||||
``psci_warmboot_entrypoint()`` PSCI library interface.
|
||||
|
||||
- svc\_suspend, svc\_suspend\_finish
|
||||
- svc_suspend, svc_suspend_finish
|
||||
|
||||
The ``svc_suspend`` callback is called during power down bu either
|
||||
PSCI\_SUSPEND or PSCI\_SYSTEM\_SUSPEND APIs. The ``svc_suspend_finish`` is
|
||||
PSCI_SUSPEND or PSCI_SYSTEM_SUSPEND APIs. The ``svc_suspend_finish`` is
|
||||
called when the CPU wakes up from suspend and executes the
|
||||
``psci_warmboot_entrypoint()`` PSCI library interface. The ``max_off_pwrlvl``
|
||||
(first parameter) denotes the highest power domain level being powered down
|
||||
to or woken up from suspend.
|
||||
|
||||
- svc\_system\_off, svc\_system\_reset
|
||||
- svc_system_off, svc_system_reset
|
||||
|
||||
These callbacks are called during PSCI\_SYSTEM\_OFF and PSCI\_SYSTEM\_RESET
|
||||
These callbacks are called during PSCI_SYSTEM_OFF and PSCI_SYSTEM_RESET
|
||||
PSCI APIs respectively.
|
||||
|
||||
- svc\_migrate\_info
|
||||
- svc_migrate_info
|
||||
|
||||
This callback is called in response to PSCI\_MIGRATE\_INFO\_TYPE or
|
||||
PSCI\_MIGRATE\_INFO\_UP\_CPU APIs. The return value of this callback must
|
||||
correspond to the return value of PSCI\_MIGRATE\_INFO\_TYPE API as described
|
||||
This callback is called in response to PSCI_MIGRATE_INFO_TYPE or
|
||||
PSCI_MIGRATE_INFO_UP_CPU APIs. The return value of this callback must
|
||||
correspond to the return value of PSCI_MIGRATE_INFO_TYPE API as described
|
||||
in `PSCI spec`_. If the secure payload is a Uniprocessor (UP)
|
||||
implementation, then it must update the mpidr of the CPU it is resident in
|
||||
via ``resident_cpu`` (first argument). The updates to ``resident_cpu`` is
|
||||
ignored if the secure payload is a multiprocessor (MP) implementation.
|
||||
|
||||
- svc\_migrate
|
||||
- svc_migrate
|
||||
|
||||
This callback is only relevant if the secure payload in EL3 Runtime
|
||||
Software is a Uniprocessor (UP) implementation and supports migration from
|
||||
the current CPU ``from_cpu`` (first argument) to another CPU ``to_cpu``
|
||||
(second argument). This callback is called in response to PSCI\_MIGRATE
|
||||
(second argument). This callback is called in response to PSCI_MIGRATE
|
||||
API. This callback is never called if the secure payload is a
|
||||
Multiprocessor (MP) implementation.
|
||||
|
||||
CPU operations
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
The CPU operations (cpu\_ops) framework implement power down sequence specific
|
||||
The CPU operations (cpu_ops) framework implement power down sequence specific
|
||||
to the CPU and the details of which can be found in the
|
||||
``CPU specific operations framework`` section of `Firmware Design`_. The TF-A
|
||||
tree implements the ``cpu_ops`` for various supported CPUs and the EL3 Runtime
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ 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.
|
||||
|
||||
Runtime service sources will need to include the `runtime\_svc.h`_ header file.
|
||||
Runtime service sources will need to include the `runtime_svc.h`_ header file.
|
||||
|
||||
Registering a runtime service
|
||||
-----------------------------
|
||||
|
|
@ -140,7 +140,7 @@ to ensure that the following conditions are met:
|
|||
#. The ``_type`` is one of ``SMC_TYPE_FAST`` or ``SMC_TYPE_YIELD``
|
||||
#. ``_setup`` and ``_smch`` routines have been specified
|
||||
|
||||
`std\_svc\_setup.c`_ provides an example of registering a runtime service:
|
||||
`std_svc_setup.c`_ provides an example of registering a runtime service:
|
||||
|
||||
.. code:: c
|
||||
|
||||
|
|
@ -310,6 +310,6 @@ provide this information....
|
|||
.. _Firmware Design: ./firmware-design.rst
|
||||
.. _services: ../services
|
||||
.. _lib/psci: ../lib/psci
|
||||
.. _runtime\_svc.h: ../include/common/runtime_svc.h
|
||||
.. _runtime_svc.h: ../include/common/runtime_svc.h
|
||||
.. _smccc.h: ../include/lib/smccc.h
|
||||
.. _std\_svc\_setup.c: ../services/std_svc/std_svc_setup.c
|
||||
.. _std_svc_setup.c: ../services/std_svc/std_svc_setup.c
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ The keys used to establish the CoT are:
|
|||
- **Trusted world key**
|
||||
|
||||
The private part is used to sign the key certificates corresponding to the
|
||||
secure world images (SCP\_BL2, BL31 and BL32). The public part is stored in
|
||||
secure world images (SCP_BL2, BL31 and BL32). The public part is stored in
|
||||
one of the extension fields in the trusted world certificate.
|
||||
|
||||
- **Non-trusted world key**
|
||||
|
|
@ -70,7 +70,7 @@ The keys used to establish the CoT are:
|
|||
|
||||
- **BL3-X keys**
|
||||
|
||||
For each of SCP\_BL2, BL31, BL32 and BL33, the private part is used to
|
||||
For each of SCP_BL2, BL31, BL32 and BL33, the private part is used to
|
||||
sign the content certificate for the BL3-X image. The public part is stored
|
||||
in one of the extension fields in the corresponding key certificate.
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ The following images are included in the CoT:
|
|||
|
||||
- BL1
|
||||
- BL2
|
||||
- SCP\_BL2 (optional)
|
||||
- SCP_BL2 (optional)
|
||||
- BL31
|
||||
- BL33
|
||||
- BL32 (optional)
|
||||
|
|
@ -96,14 +96,14 @@ The following certificates are used to authenticate the images.
|
|||
public part of the trusted world key and the public part of the non-trusted
|
||||
world key.
|
||||
|
||||
- **SCP\_BL2 key certificate**
|
||||
- **SCP_BL2 key certificate**
|
||||
|
||||
It is self-signed with the trusted world key. It contains the public part of
|
||||
the SCP\_BL2 key.
|
||||
the SCP_BL2 key.
|
||||
|
||||
- **SCP\_BL2 content certificate**
|
||||
- **SCP_BL2 content certificate**
|
||||
|
||||
It is self-signed with the SCP\_BL2 key. It contains a hash of the SCP\_BL2
|
||||
It is self-signed with the SCP_BL2 key. It contains a hash of the SCP_BL2
|
||||
image.
|
||||
|
||||
- **BL31 key certificate**
|
||||
|
|
@ -133,8 +133,8 @@ The following certificates are used to authenticate the images.
|
|||
|
||||
It is self-signed with the BL33 key. It contains a hash of the BL33 image.
|
||||
|
||||
The SCP\_BL2 and BL32 certificates are optional, but they must be present if the
|
||||
corresponding SCP\_BL2 or BL32 images are present.
|
||||
The SCP_BL2 and BL32 certificates are optional, but they must be present if the
|
||||
corresponding SCP_BL2 or BL32 images are present.
|
||||
|
||||
Trusted Board Boot Sequence
|
||||
---------------------------
|
||||
|
|
@ -160,8 +160,8 @@ if any of the steps fail.
|
|||
registers. If the comparison succeeds, BL2 reads and saves the trusted and
|
||||
non-trusted world public keys from the verified certificate.
|
||||
|
||||
The next two steps are executed for each of the SCP\_BL2, BL31 & BL32 images.
|
||||
The steps for the optional SCP\_BL2 and BL32 images are skipped if these images
|
||||
The next two steps are executed for each of the SCP_BL2, BL31 & BL32 images.
|
||||
The steps for the optional SCP_BL2 and BL32 images are skipped if these images
|
||||
are not present.
|
||||
|
||||
- BL2 loads and verifies the BL3x key certificate. The certificate signature
|
||||
|
|
|
|||
|
|
@ -197,7 +197,7 @@ Building TF-A
|
|||
- (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
|
||||
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
|
||||
an AArch32 EL3 Runtime Software. Some AArch32 EL3 Runtime Software may
|
||||
include other runtime services, for example Trusted OS services. A guide
|
||||
|
|
@ -324,7 +324,7 @@ Common build options
|
|||
where applicable). Defaults to a string that contains the time and date of
|
||||
the compilation.
|
||||
|
||||
- ``BUILD_STRING``: Input string for VERSION\_STRING, which allows the TF-A
|
||||
- ``BUILD_STRING``: Input string for VERSION_STRING, which allows the TF-A
|
||||
build to be uniquely identified. Defaults to the current git commit id.
|
||||
|
||||
- ``CFLAGS``: Extra user options appended on the compiler's command line in
|
||||
|
|
@ -479,12 +479,12 @@ Common build options
|
|||
- ``GENERATE_COT``: Boolean flag used to build and execute the ``cert_create``
|
||||
tool to create certificates as per the Chain of Trust described in
|
||||
`Trusted Board Boot`_. The build system then calls ``fiptool`` to
|
||||
include the certificates in the FIP and FWU\_FIP. Default value is '0'.
|
||||
include the certificates in the FIP and FWU_FIP. Default value is '0'.
|
||||
|
||||
Specify both ``TRUSTED_BOARD_BOOT=1`` and ``GENERATE_COT=1`` to include support
|
||||
for the Trusted Board Boot feature in the BL1 and BL2 images, to generate
|
||||
the corresponding certificates, and to include those certificates in the
|
||||
FIP and FWU\_FIP.
|
||||
FIP and FWU_FIP.
|
||||
|
||||
Note that if ``TRUSTED_BOARD_BOOT=0`` and ``GENERATE_COT=1``, the BL1 and BL2
|
||||
images will not include support for Trusted Board Boot. The FIP will still
|
||||
|
|
@ -492,7 +492,7 @@ Common build options
|
|||
Chain of Trust on the host machine through other mechanisms.
|
||||
|
||||
Note that if ``TRUSTED_BOARD_BOOT=1`` and ``GENERATE_COT=0``, the BL1 and BL2
|
||||
images will include support for Trusted Board Boot, but the FIP and FWU\_FIP
|
||||
images will include support for Trusted Board Boot, but the FIP and FWU_FIP
|
||||
will not include the corresponding certificates, causing a boot failure.
|
||||
|
||||
- ``GICV2_G0_FOR_EL3``: Unlike GICv3, the GICv2 architecture doesn't have
|
||||
|
|
@ -566,7 +566,7 @@ Common build options
|
|||
specifies the file that contains the Non-Trusted World private key in PEM
|
||||
format. If ``SAVE_KEYS=1``, this file name will be used to save the key.
|
||||
|
||||
- ``NS_BL2U``: Path to NS\_BL2U image in the host file system. This image is
|
||||
- ``NS_BL2U``: Path to NS_BL2U image in the host file system. This image is
|
||||
optional. It is only needed if the platform makefile specifies that it
|
||||
is required in order to build the ``fwu_fip`` target.
|
||||
|
||||
|
|
@ -611,7 +611,7 @@ Common build options
|
|||
to use the extended format. The default value of this flag is 0, which
|
||||
means by default the original power-state format is used by the PSCI
|
||||
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
|
||||
option ``ARM_RECOM_STATE_ID_ENC`` needs to be set to 1 as well.
|
||||
|
||||
|
|
@ -629,10 +629,10 @@ Common build options
|
|||
entrypoint) or 1 (CPU reset to BL31 entrypoint).
|
||||
The default value is 0.
|
||||
|
||||
- ``RESET_TO_SP_MIN``: SP\_MIN is the minimal AArch32 Secure Payload provided
|
||||
in TF-A. This flag configures SP\_MIN entrypoint as the CPU reset vector
|
||||
- ``RESET_TO_SP_MIN``: SP_MIN is the minimal AArch32 Secure Payload provided
|
||||
in TF-A. This flag configures SP_MIN entrypoint as the CPU reset vector
|
||||
instead of the BL1 entrypoint. It can take the value 0 (CPU reset to BL1
|
||||
entrypoint) or 1 (CPU reset to SP\_MIN entrypoint). The default value is 0.
|
||||
entrypoint) or 1 (CPU reset to SP_MIN entrypoint). The default value is 0.
|
||||
|
||||
- ``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
|
||||
|
|
@ -642,15 +642,15 @@ Common build options
|
|||
certificate generation tool to save the keys used to establish the Chain of
|
||||
Trust. Allowed options are '0' or '1'. Default is '0' (do not save).
|
||||
|
||||
- ``SCP_BL2``: Path to SCP\_BL2 image in the host file system. This image is optional.
|
||||
If a SCP\_BL2 image is present then this option must be passed for the ``fip``
|
||||
- ``SCP_BL2``: Path to SCP_BL2 image in the host file system. This image is optional.
|
||||
If a SCP_BL2 image is present then this option must be passed for the ``fip``
|
||||
target.
|
||||
|
||||
- ``SCP_BL2_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the
|
||||
file that contains the SCP\_BL2 private key in PEM format. If ``SAVE_KEYS=1``,
|
||||
file that contains the SCP_BL2 private key in PEM format. If ``SAVE_KEYS=1``,
|
||||
this file name will be used to save the key.
|
||||
|
||||
- ``SCP_BL2U``: Path to SCP\_BL2U image in the host file system. This image is
|
||||
- ``SCP_BL2U``: Path to SCP_BL2U image in the host file system. This image is
|
||||
optional. It is only needed if the platform makefile specifies that it
|
||||
is required in order to build the ``fwu_fip`` target.
|
||||
|
||||
|
|
@ -689,7 +689,7 @@ Common build options
|
|||
Boot feature. When set to '1', BL1 and BL2 images include support to load
|
||||
and verify the certificates and images in a FIP, and BL1 includes support
|
||||
for the Firmware Update. The default value is '0'. Generation and inclusion
|
||||
of certificates in the FIP and FWU\_FIP depends upon the value of the
|
||||
of certificates in the FIP and FWU_FIP depends upon the value of the
|
||||
``GENERATE_COT`` option.
|
||||
|
||||
Note: This option depends on ``CREATE_KEYS`` to be enabled. If the keys
|
||||
|
|
@ -832,8 +832,8 @@ Arm CSS platform specific build options
|
|||
TF-A no longer supports earlier SCP versions. If this option is set to 1
|
||||
then TF-A will detect if an earlier version is in use. Default is 1.
|
||||
|
||||
- ``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
|
||||
- ``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
|
||||
during boot. Default is 1.
|
||||
|
||||
- ``CSS_USE_SCMI_SDS_DRIVER``: Boolean flag which selects SCMI/SDS drivers
|
||||
|
|
@ -1087,7 +1087,7 @@ Trusted Board Boot primarily consists of the following two features:
|
|||
- Image Authentication, described in `Trusted Board Boot`_, and
|
||||
- Firmware Update, described in `Firmware Update`_
|
||||
|
||||
The following steps should be followed to build FIP and (optionally) FWU\_FIP
|
||||
The following steps should be followed to build FIP and (optionally) FWU_FIP
|
||||
images with support for these features:
|
||||
|
||||
#. Fulfill the dependencies of the ``mbedtls`` cryptographic and image parser
|
||||
|
|
@ -1150,13 +1150,13 @@ images with support for these features:
|
|||
described in the TBBR-client document. These certificates can also be found
|
||||
in the output build directory.
|
||||
|
||||
#. 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
|
||||
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:
|
||||
|
||||
- NS\_BL2U. The AP non-secure Firmware Updater image.
|
||||
- SCP\_BL2U. The SCP Firmware Update Configuration image.
|
||||
- NS_BL2U. The AP non-secure Firmware Updater image.
|
||||
- SCP_BL2U. The SCP Firmware Update Configuration image.
|
||||
|
||||
Example of Juno command line for generating both ``fwu`` and ``fwu_fip``
|
||||
targets using RSA development:
|
||||
|
|
@ -1173,15 +1173,15 @@ images with support for these features:
|
|||
NS_BL2U=<path-to>/<ns_bl2u_image> \
|
||||
all fip fwu_fip
|
||||
|
||||
Note: The BL2U image will be built by default and added to the FWU\_FIP.
|
||||
Note: The BL2U image will be built by default and added to the FWU_FIP.
|
||||
The user may override this by adding ``BL2U=<path-to>/<bl2u_image>``
|
||||
to the command line above.
|
||||
|
||||
Note: Building and installing the non-secure and SCP FWU images (NS\_BL1U,
|
||||
NS\_BL2U and SCP\_BL2U) is outside the scope of this document.
|
||||
Note: Building and installing the non-secure and SCP FWU images (NS_BL1U,
|
||||
NS_BL2U and SCP_BL2U) is outside the scope of this document.
|
||||
|
||||
The result of this build will be bl1.bin, fip.bin and fwu\_fip.bin binaries.
|
||||
Both the FIP and FWU\_FIP will include the certificates corresponding to the
|
||||
The result of this build will be bl1.bin, fip.bin and fwu_fip.bin binaries.
|
||||
Both the FIP and FWU_FIP will include the certificates corresponding to the
|
||||
Chain of Trust described in the TBBR-client document. These certificates
|
||||
can also be found in the output build directory.
|
||||
|
||||
|
|
@ -1198,7 +1198,7 @@ command:
|
|||
make PLAT=<platform> [DEBUG=1] [V=1] certtool
|
||||
|
||||
For platforms that require their own IDs in certificate files, the generic
|
||||
'cert\_create' tool can be built with the following command:
|
||||
'cert_create' tool can be built with the following command:
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -1240,9 +1240,9 @@ section for more info on selecting the right FDT to use.
|
|||
|
||||
make realclean
|
||||
|
||||
#. Obtain SCP\_BL2 (Juno) and BL33 (all platforms)
|
||||
#. Obtain SCP_BL2 (Juno) and BL33 (all platforms)
|
||||
|
||||
Use the fiptool to extract the SCP\_BL2 and BL33 images from the FIP
|
||||
Use the fiptool to extract the SCP_BL2 and BL33 images from the FIP
|
||||
package included in the Linaro release:
|
||||
|
||||
::
|
||||
|
|
@ -1255,7 +1255,7 @@ section for more info on selecting the right FDT to use.
|
|||
<path/to/linaro/release>/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
|
||||
current working directory. The SCP_BL2 image corresponds to
|
||||
``scp-fw.bin`` and BL33 corresponds to ``nt-fw.bin``.
|
||||
|
||||
Note: The fiptool will complain if the images to be unpacked already
|
||||
|
|
@ -1406,7 +1406,7 @@ developing EL3 baremetal code by:
|
|||
|
||||
- putting the system into a known architectural state;
|
||||
- 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
|
||||
TrustZone controller is simplified such that only region 0 is enabled and is
|
||||
|
|
@ -1923,8 +1923,8 @@ Notes:
|
|||
``--data="<path-to><bl32-binary>"@<base-address-of-bl32>`` to the new value of
|
||||
``BL32_BASE``.
|
||||
|
||||
Running on the AEMv8 Base FVP (AArch32) with reset to SP\_MIN entrypoint
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
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
|
||||
with 8 CPUs using the AArch32 build of TF-A.
|
||||
|
|
@ -1991,8 +1991,8 @@ boot Linux with 8 CPUs using the AArch64 build of TF-A.
|
|||
--data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \
|
||||
--data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000
|
||||
|
||||
Running on the Cortex-A32 Base FVP (AArch32) with reset to SP\_MIN entrypoint
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
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
|
||||
boot Linux with 4 CPUs using the AArch32 build of TF-A.
|
||||
|
|
|
|||
|
|
@ -37,8 +37,8 @@ About version 1 and version 2
|
|||
-----------------------------
|
||||
|
||||
This document focuses on version 2 of the library, whose sources are available
|
||||
in the `lib/xlat\_tables\_v2`_ directory. Version 1 of the library can still be
|
||||
found in `lib/xlat\_tables`_ directory but it is less flexible and doesn't
|
||||
in the `lib/xlat_tables_v2`_ directory. Version 1 of the library can still be
|
||||
found in `lib/xlat_tables`_ directory but it is less flexible and doesn't
|
||||
support dynamic mapping. Although potential bug fixes will be applied to both
|
||||
versions, future features enhancements will focus on version 2 and might not be
|
||||
back-ported to version 1. Therefore, it is recommended to use version 2,
|
||||
|
|
@ -69,7 +69,7 @@ map. It is one of the key interfaces to the library. It is identified by:
|
|||
- its attributes;
|
||||
- its mapping granularity (optional).
|
||||
|
||||
See the ``struct mmap_region`` type in `xlat\_tables\_v2.h`_.
|
||||
See the ``struct mmap_region`` type in `xlat_tables_v2.h`_.
|
||||
|
||||
The user usually provides a list of such mmap regions to map and lets the
|
||||
library transpose that in a set of translation tables. As a result, the library
|
||||
|
|
@ -80,7 +80,7 @@ normal memory) as well as the memory access permissions (read-only or
|
|||
read-write, executable or not, secure or non-secure, and so on). In the case of
|
||||
the EL1&0 translation regime, the attributes also specify whether the region is
|
||||
a User region (EL0) or Privileged region (EL1). See the ``MT_xxx`` definitions
|
||||
in `xlat\_tables\_v2.h`_. Note that for the EL1&0 translation regime the Execute
|
||||
in `xlat_tables_v2.h`_. Note that for the EL1&0 translation regime the Execute
|
||||
Never attribute is set simultaneously for both EL1 and EL0.
|
||||
|
||||
The granularity controls the translation table level to go down to when mapping
|
||||
|
|
@ -208,7 +208,7 @@ Library APIs
|
|||
------------
|
||||
|
||||
The external APIs exposed by this library are declared and documented in the
|
||||
`xlat\_tables\_v2.h`_ header file. This should be the reference point for
|
||||
`xlat_tables_v2.h`_ header file. This should be the reference point for
|
||||
getting information about the usage of the different APIs this library
|
||||
provides. This section just provides some extra details and clarifications.
|
||||
|
||||
|
|
@ -291,7 +291,7 @@ The library is divided into 4 modules:
|
|||
provides functions such as ``mmap_add_region_ctx`` that let the caller specify
|
||||
the translation tables context affected by them.
|
||||
|
||||
See `xlat\_tables\_core.c`_.
|
||||
See `xlat_tables_core.c`_.
|
||||
|
||||
- **Active context module**
|
||||
|
||||
|
|
@ -300,14 +300,14 @@ The library is divided into 4 modules:
|
|||
This module provides functions such as ``mmap_add_region``, that directly
|
||||
affect the BL image using them.
|
||||
|
||||
See `xlat\_tables\_context.c`_.
|
||||
See `xlat_tables_context.c`_.
|
||||
|
||||
- **Utilities module**
|
||||
|
||||
Provides additional functionality like debug print of the current state of the
|
||||
translation tables and helpers to query memory attributes and to modify them.
|
||||
|
||||
See `xlat\_tables\_utils.c`_.
|
||||
See `xlat_tables_utils.c`_.
|
||||
|
||||
- **Architectural module**
|
||||
|
||||
|
|
@ -316,7 +316,7 @@ The library is divided into 4 modules:
|
|||
MMU, or calculate the Physical Address Space size. They do not need a
|
||||
translation context to work on.
|
||||
|
||||
See `aarch32/xlat\_tables\_arch.c`_ and `aarch64/xlat\_tables\_arch.c`_.
|
||||
See `aarch32/xlat_tables_arch.c`_ and `aarch64/xlat_tables_arch.c`_.
|
||||
|
||||
From mmap regions to translation tables
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -416,13 +416,13 @@ mapping cannot be cached in the TLBs.
|
|||
|
||||
*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
|
||||
.. _xlat\_tables\_v2.h: ../include/lib/xlat_tables/xlat_tables_v2.h
|
||||
.. _xlat\_tables\_context.c: ../lib/xlat_tables_v2/xlat_tables_context.c
|
||||
.. _xlat\_tables\_core.c: ../lib/xlat_tables_v2/xlat_tables_core.c
|
||||
.. _xlat\_tables\_utils.c: ../lib/xlat_tables_v2/xlat_tables_utils.c
|
||||
.. _aarch32/xlat\_tables\_arch.c: ../lib/xlat_tables_v2/aarch32/xlat_tables_arch.c
|
||||
.. _aarch64/xlat\_tables\_arch.c: ../lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
|
||||
.. _lib/xlat_tables_v2: ../lib/xlat_tables_v2
|
||||
.. _lib/xlat_tables: ../lib/xlat_tables
|
||||
.. _xlat_tables_v2.h: ../include/lib/xlat_tables/xlat_tables_v2.h
|
||||
.. _xlat_tables_context.c: ../lib/xlat_tables_v2/xlat_tables_context.c
|
||||
.. _xlat_tables_core.c: ../lib/xlat_tables_v2/xlat_tables_core.c
|
||||
.. _xlat_tables_utils.c: ../lib/xlat_tables_v2/xlat_tables_utils.c
|
||||
.. _aarch32/xlat_tables_arch.c: ../lib/xlat_tables_v2/aarch32/xlat_tables_arch.c
|
||||
.. _aarch64/xlat_tables_arch.c: ../lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
|
||||
.. _Porting Guide: porting-guide.rst
|
||||
.. |Alignment Example| image:: ./diagrams/xlat_align.png?raw=true
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue