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