1Alternative Boot Flows
2======================
3
4EL3 payloads alternative boot flow
5----------------------------------
6
7On a pre-production system, the ability to execute arbitrary, bare-metal code at
8the highest exception level is required. It allows full, direct access to the
9hardware, for example to run silicon soak tests.
10
11Although it is possible to implement some baremetal secure firmware from
12scratch, this is a complex task on some platforms, depending on the level of
13configuration required to put the system in the expected state.
14
15Rather than booting a baremetal application, a possible compromise is to boot
16``EL3 payloads`` through TF-A instead. This is implemented as an alternative
17boot flow, where a modified BL2 boots an EL3 payload, instead of loading the
18other BL images and passing control to BL31. It reduces the complexity of
19developing EL3 baremetal code by:
20
21-  putting the system into a known architectural state;
22-  taking care of platform secure world initialization;
23-  loading the SCP_BL2 image if required by the platform.
24
25When booting an EL3 payload on Arm standard platforms, the configuration of the
26TrustZone controller is simplified such that only region 0 is enabled and is
27configured to permit secure access only. This gives full access to the whole
28DRAM to the EL3 payload.
29
30The system is left in the same state as when entering BL31 in the default boot
31flow. In particular:
32
33-  Running in EL3;
34-  Current state is AArch64;
35-  Little-endian data access;
36-  All exceptions disabled;
37-  MMU disabled;
38-  Caches disabled.
39
40.. _alt_boot_flows_el3_payload:
41
42Booting an EL3 payload
43~~~~~~~~~~~~~~~~~~~~~~
44
45The EL3 payload image is a standalone image and is not part of the FIP. It is
46not loaded by TF-A. Therefore, there are 2 possible scenarios:
47
48-  The EL3 payload may reside in non-volatile memory (NVM) and execute in
49   place. In this case, booting it is just a matter of specifying the right
50   address in NVM through ``EL3_PAYLOAD_BASE`` when building TF-A.
51
52-  The EL3 payload needs to be loaded in volatile memory (e.g. DRAM) at
53   run-time.
54
55To help in the latter scenario, the ``SPIN_ON_BL1_EXIT=1`` build option can be
56used. The infinite loop that it introduces in BL1 stops execution at the right
57moment for a debugger to take control of the target and load the payload (for
58example, over JTAG).
59
60It is expected that this loading method will work in most cases, as a debugger
61connection is usually available in a pre-production system. The user is free to
62use any other platform-specific mechanism to load the EL3 payload, though.
63
64
65Preloaded BL33 alternative boot flow
66------------------------------------
67
68Some platforms have the ability to preload BL33 into memory instead of relying
69on TF-A to load it. This may simplify packaging of the normal world code and
70improve performance in a development environment. When secure world cold boot
71is complete, TF-A simply jumps to a BL33 base address provided at build time.
72
73For this option to be used, the ``PRELOADED_BL33_BASE`` build option has to be
74used when compiling TF-A. For example, the following command will create a FIP
75without a BL33 and prepare to jump to a BL33 image loaded at address
760x80000000:
77
78.. code:: shell
79
80    make PRELOADED_BL33_BASE=0x80000000 PLAT=fvp all fip
81
82--------------
83
84*Copyright (c) 2019, Arm Limited. All rights reserved.*
85