Lines Matching +full:- +full:- +full:boot +full:- +full:method

1 Alternative Boot Flows
4 EL3 payloads alternative boot flow
5 ----------------------------------
7 On a pre-production system, the ability to execute arbitrary, bare-metal code at
15 Rather than booting a baremetal application, a possible compromise is to boot
16 ``EL3 payloads`` through TF-A instead. This is implemented as an alternative
17 boot flow, where a modified BL2 boots an EL3 payload, instead of loading the
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.
30 The system is left in the same state as when entering BL31 in the default boot
33 -  Running in EL3;
34 -  Current state is AArch64;
35 -  Little-endian data access;
36 -  All exceptions disabled;
37 -  MMU disabled;
38 -  Caches disabled.
46 not loaded by TF-A. Therefore, there are 2 possible scenarios:
48 -  The EL3 payload may reside in non-volatile memory (NVM) and execute in
50    address in NVM through ``EL3_PAYLOAD_BASE`` when building TF-A.
52 -  The EL3 payload needs to be loaded in volatile memory (e.g. DRAM) at
53    run-time.
60 It is expected that this loading method will work in most cases, as a debugger
61 connection is usually available in a pre-production system. The user is free to
62 use any other platform-specific mechanism to load the EL3 payload, though.
65 Preloaded BL33 alternative boot flow
66 ------------------------------------
69 on TF-A to load it. This may simplify packaging of the normal world code and
70 improve performance in a development environment. When secure world cold boot
71 is complete, TF-A simply jumps to a BL33 base address provided at build time.
74 used when compiling TF-A. For example, the following command will create a FIP
82 --------------