1CPU Reset 2========= 3 4 5 6 7.. contents:: 8 9This document describes the high-level design of the framework to handle CPU 10resets in Trusted Firmware-A (TF-A). It also describes how the platform 11integrator can tailor this code to the system configuration to some extent, 12resulting in a simplified and more optimised boot flow. 13 14This document should be used in conjunction with the `Firmware Design`_, which 15provides greater implementation details around the reset code, specifically 16for the cold boot path. 17 18General reset code flow 19----------------------- 20 21The TF-A reset code is implemented in BL1 by default. The following high-level 22diagram illustrates this: 23 24|Default reset code flow| 25 26This diagram shows the default, unoptimised reset flow. Depending on the system 27configuration, some of these steps might be unnecessary. The following sections 28guide the platform integrator by indicating which build options exclude which 29steps, depending on the capability of the platform. 30 31Note: If BL31 is used as the TF-A entry point instead of BL1, the diagram 32above is still relevant, as all these operations will occur in BL31 in 33this case. Please refer to section 6 "Using BL31 entrypoint as the reset 34address" for more information. 35 36Programmable CPU reset address 37------------------------------ 38 39By default, TF-A assumes that the CPU reset address is not programmable. 40Therefore, all CPUs start at the same address (typically address 0) whenever 41they reset. Further logic is then required to identify whether it is a cold or 42warm boot to direct CPUs to the right execution path. 43 44If the reset vector address (reflected in the reset vector base address register 45``RVBAR_EL3``) is programmable then it is possible to make each CPU start directly 46at the right address, both on a cold and warm reset. Therefore, the boot type 47detection can be skipped, resulting in the following boot flow: 48 49|Reset code flow with programmable reset address| 50 51To enable this boot flow, compile TF-A with ``PROGRAMMABLE_RESET_ADDRESS=1``. 52This option only affects the TF-A reset image, which is BL1 by default or BL31 if 53``RESET_TO_BL31=1``. 54 55On both the FVP and Juno platforms, the reset vector address is not programmable 56so both ports use ``PROGRAMMABLE_RESET_ADDRESS=0``. 57 58Cold boot on a single CPU 59------------------------- 60 61By default, TF-A assumes that several CPUs may be released out of reset. 62Therefore, the cold boot code has to arbitrate access to hardware resources 63shared amongst CPUs. This is done by nominating one of the CPUs as the primary, 64which is responsible for initialising shared hardware and coordinating the boot 65flow with the other CPUs. 66 67If the platform guarantees that only a single CPU will ever be brought up then 68no arbitration is required. The notion of primary/secondary CPU itself no longer 69applies. This results in the following boot flow: 70 71|Reset code flow with single CPU released out of reset| 72 73To enable this boot flow, compile TF-A with ``COLD_BOOT_SINGLE_CPU=1``. This 74option only affects the TF-A reset image, which is BL1 by default or BL31 if 75``RESET_TO_BL31=1``. 76 77On both the FVP and Juno platforms, although only one core is powered up by 78default, there are platform-specific ways to release any number of cores out of 79reset. Therefore, both platform ports use ``COLD_BOOT_SINGLE_CPU=0``. 80 81Programmable CPU reset address, Cold boot on a single CPU 82--------------------------------------------------------- 83 84It is obviously possible to combine both optimisations on platforms that have 85a programmable CPU reset address and which release a single CPU out of reset. 86This results in the following boot flow: 87 88 89|Reset code flow with programmable reset address and single CPU released out of reset| 90 91To enable this boot flow, compile TF-A with both ``COLD_BOOT_SINGLE_CPU=1`` 92and ``PROGRAMMABLE_RESET_ADDRESS=1``. These options only affect the TF-A reset 93image, which is BL1 by default or BL31 if ``RESET_TO_BL31=1``. 94 95Using BL31 entrypoint as the reset address 96------------------------------------------ 97 98On some platforms the runtime firmware (BL3x images) for the application 99processors are loaded by some firmware running on a secure system processor 100on the SoC, rather than by BL1 and BL2 running on the primary application 101processor. For this type of SoC it is desirable for the application processor 102to always reset to BL31 which eliminates the need for BL1 and BL2. 103 104TF-A provides a build-time option ``RESET_TO_BL31`` that includes some additional 105logic in the BL31 entry point to support this use case. 106 107In this configuration, the platform's Trusted Boot Firmware must ensure that 108BL31 is loaded to its runtime address, which must match the CPU's ``RVBAR_EL3`` 109reset vector base address, before the application processor is powered on. 110Additionally, platform software is responsible for loading the other BL3x images 111required and providing entry point information for them to BL31. Loading these 112images might be done by the Trusted Boot Firmware or by platform code in BL31. 113 114Although the Arm FVP platform does not support programming the reset base 115address dynamically at run-time, it is possible to set the initial value of the 116``RVBAR_EL3`` register at start-up. This feature is provided on the Base FVP only. 117It allows the Arm FVP port to support the ``RESET_TO_BL31`` configuration, in 118which case the ``bl31.bin`` image must be loaded to its run address in Trusted 119SRAM and all CPU reset vectors be changed from the default ``0x0`` to this run 120address. See the `User Guide`_ for details of running the FVP models in this way. 121 122Although technically it would be possible to program the reset base address with 123the right support in the SCP firmware, this is currently not implemented so the 124Juno port doesn't support the ``RESET_TO_BL31`` configuration. 125 126The ``RESET_TO_BL31`` configuration requires some additions and changes in the 127BL31 functionality: 128 129Determination of boot path 130~~~~~~~~~~~~~~~~~~~~~~~~~~ 131 132In this configuration, BL31 uses the same reset framework and code as the one 133described for BL1 above. Therefore, it is affected by the 134``PROGRAMMABLE_RESET_ADDRESS`` and ``COLD_BOOT_SINGLE_CPU`` build options in the 135same way. 136 137In the default, unoptimised BL31 reset flow, on a warm boot a CPU is directed 138to the PSCI implementation via a platform defined mechanism. On a cold boot, 139the platform must place any secondary CPUs into a safe state while the primary 140CPU executes a modified BL31 initialization, as described below. 141 142Platform initialization 143~~~~~~~~~~~~~~~~~~~~~~~ 144 145In this configuration, when the CPU resets to BL31 there are no parameters that 146can be passed in registers by previous boot stages. Instead, the platform code 147in BL31 needs to know, or be able to determine, the location of the BL32 (if 148required) and BL33 images and provide this information in response to the 149``bl31_plat_get_next_image_ep_info()`` function. 150 151Additionally, platform software is responsible for carrying out any security 152initialisation, for example programming a TrustZone address space controller. 153This might be done by the Trusted Boot Firmware or by platform code in BL31. 154 155-------------- 156 157*Copyright (c) 2015-2018, Arm Limited and Contributors. All rights reserved.* 158 159.. _Firmware Design: firmware-design.rst 160.. _User Guide: ../getting_started/user-guide.rst 161 162.. |Default reset code flow| image:: ../diagrams/default_reset_code.png?raw=true 163.. |Reset code flow with programmable reset address| image:: ../diagrams/reset_code_no_boot_type_check.png?raw=true 164.. |Reset code flow with single CPU released out of reset| image:: ../diagrams/reset_code_no_cpu_check.png?raw=true 165.. |Reset code flow with programmable reset address and single CPU released out of reset| image:: ../diagrams/reset_code_no_checks.png?raw=true 166
