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