mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2025-04-08 05:43:53 +00:00
43f35ef516
The User Guide document has grown organically over time and now covers a wide range of topics, making it difficult to skim read and extract information from. Currently, it covers these topics and maybe a couple more: - Requirements (hardware, tools, libs) - Checking out the repo - Basic build instructions - A comprehensive list of build flags - FIP packaging - Building specifically for Juno - Firmware update images - EL3 payloads - Preloaded BL33 boot flow - Running on FVPs - Running on Juno I have separated these out into a few groups that become new documents. Broadly speaking, build instructions for the tools, for TF-A generally, and for specific scenarios are separated. Content relating to specific platforms (Juno and the FVPs are Arm-specific platforms, essentially) has been moved into the documentation that is specific to those platforms, under docs/plat/arm. Change-Id: Ica87c52d8cd4f577332be0b0738998ea3ba3bbec Signed-off-by: Paul Beesley <paul.beesley@arm.com>
84 lines
3.3 KiB
ReStructuredText
84 lines
3.3 KiB
ReStructuredText
Alternative Boot Flows
|
|
======================
|
|
|
|
EL3 payloads alternative boot flow
|
|
----------------------------------
|
|
|
|
On a pre-production system, the ability to execute arbitrary, bare-metal code at
|
|
the highest exception level is required. It allows full, direct access to the
|
|
hardware, for example to run silicon soak tests.
|
|
|
|
Although it is possible to implement some baremetal secure firmware from
|
|
scratch, this is a complex task on some platforms, depending on the level of
|
|
configuration required to put the system in the expected state.
|
|
|
|
Rather than booting a baremetal application, a possible compromise is to boot
|
|
``EL3 payloads`` through TF-A instead. This is implemented as an alternative
|
|
boot flow, where a modified BL2 boots an EL3 payload, instead of loading the
|
|
other BL images and passing control to BL31. It reduces the complexity of
|
|
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.
|
|
|
|
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
|
|
configured to permit secure access only. This gives full access to the whole
|
|
DRAM to the EL3 payload.
|
|
|
|
The system is left in the same state as when entering BL31 in the default boot
|
|
flow. In particular:
|
|
|
|
- Running in EL3;
|
|
- Current state is AArch64;
|
|
- Little-endian data access;
|
|
- All exceptions disabled;
|
|
- MMU disabled;
|
|
- Caches disabled.
|
|
|
|
.. _alt_boot_flows_el3_payload:
|
|
|
|
Booting an EL3 payload
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The EL3 payload image is a standalone image and is not part of the FIP. It is
|
|
not loaded by TF-A. Therefore, there are 2 possible scenarios:
|
|
|
|
- The EL3 payload may reside in non-volatile memory (NVM) and execute in
|
|
place. In this case, booting it is just a matter of specifying the right
|
|
address in NVM through ``EL3_PAYLOAD_BASE`` when building TF-A.
|
|
|
|
- The EL3 payload needs to be loaded in volatile memory (e.g. DRAM) at
|
|
run-time.
|
|
|
|
To help in the latter scenario, the ``SPIN_ON_BL1_EXIT=1`` build option can be
|
|
used. The infinite loop that it introduces in BL1 stops execution at the right
|
|
moment for a debugger to take control of the target and load the payload (for
|
|
example, over JTAG).
|
|
|
|
It is expected that this loading method will work in most cases, as a debugger
|
|
connection is usually available in a pre-production system. The user is free to
|
|
use any other platform-specific mechanism to load the EL3 payload, though.
|
|
|
|
|
|
Preloaded BL33 alternative boot flow
|
|
------------------------------------
|
|
|
|
Some platforms have the ability to preload BL33 into memory instead of relying
|
|
on TF-A to load it. This may simplify packaging of the normal world code and
|
|
improve performance in a development environment. When secure world cold boot
|
|
is complete, TF-A simply jumps to a BL33 base address provided at build time.
|
|
|
|
For this option to be used, the ``PRELOADED_BL33_BASE`` build option has to be
|
|
used when compiling TF-A. For example, the following command will create a FIP
|
|
without a BL33 and prepare to jump to a BL33 image loaded at address
|
|
0x80000000:
|
|
|
|
.. code:: shell
|
|
|
|
make PRELOADED_BL33_BASE=0x80000000 PLAT=fvp all fip
|
|
|
|
--------------
|
|
|
|
*Copyright (c) 2019, Arm Limited. All rights reserved.*
|