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