docs/design/reset-design.rst

4 This document describes the high-level design of the framework to handle CPU
5 resets in Trusted Firmware-A (TF-A). It also describes how the platform
6 integrator can tailor this code to the system configuration to some extent,
9 This document should be used in conjunction with the :ref:`Firmware Design`
10 document which provides greater implementation details around the reset code,
11 specifically for the cold boot path.
21 This diagram shows the default, unoptimised reset flow. Depending on the system
23 guide the platform integrator by indicating which build options exclude which
24 steps, depending on the capability of the platform.
27    If BL31 is used as the TF-A entry point instead of BL1, the diagram
29    this case. Please refer to section 6 "Using BL31 entrypoint as the reset
35 By default, TF-A assumes that the CPU reset address is not programmable.
36 Therefore, all CPUs start at the same address (typically address 0) whenever
38 warm boot to direct CPUs to the right execution path.
40 If the reset vector address (reflected in the reset vector base address register
42 at the right address, both on a cold and warm reset. Therefore, the boot type
43 detection can be skipped, resulting in the following boot flow:
48 This option only affects the TF-A reset image, which is BL1 by default or BL31 if
51 On both the FVP and Juno platforms, the reset vector address is not programmable
58 Therefore, the cold boot code has to arbitrate access to hardware resources
59 shared amongst CPUs. This is done by nominating one of the CPUs as the primary,
60 which is responsible for initialising shared hardware and coordinating the boot
61 flow with the other CPUs.
63 If the platform guarantees that only a single CPU will ever be brought up then
65 applies. This results in the following boot flow:
70 option only affects the TF-A reset image, which is BL1 by default or BL31 if
73 On both the FVP and Juno platforms, although only one core is powered up by
82 This results in the following boot flow:
88 and ``PROGRAMMABLE_RESET_ADDRESS=1``. These options only affect the TF-A reset
91 Using BL31 entrypoint as the reset address
94 On some platforms the runtime firmware (BL3x images) for the application
96 on the SoC, rather than by BL1 and BL2 running on the primary application
97 processor. For this type of SoC it is desirable for the application processor
98 to always reset to BL31 which eliminates the need for BL1 and BL2.
101 logic in the BL31 entry point to support this use case.
103 In this configuration, the platform's Trusted Boot Firmware must ensure that
104 BL31 is loaded to its runtime address, which must match the CPU's ``RVBAR_EL3``
105 reset vector base address, before the application processor is powered on.
106 Additionally, platform software is responsible for loading the other BL3x images
108 images might be done by the Trusted Boot Firmware or by platform code in BL31.
110 Although the Arm FVP platform does not support programming the reset base
111 address 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
115 It allows the Arm FVP port to support the ``RESET_TO_BL31`` configuration, in
116 which case the ``bl31.bin`` image must be loaded to its run address in Trusted
117 SRAM and all CPU reset vectors be changed from the default ``0x0`` to this run
118 address. See the :ref:`Arm Fixed Virtual Platforms (FVP)` for details of running
119 the FVP models in this way.
121 Although technically it would be possible to program the reset base address with
122 the right support in the SCP firmware, this is currently not implemented so the
123 Juno port doesn't support the ``RESET_TO_BL31`` configuration.
125 The ``RESET_TO_BL31`` configuration requires some additions and changes in the
131 In this configuration, BL31 uses the same reset framework and code as the one
132 described for BL1 above. Therefore, it is affected by the
133 ``PROGRAMMABLE_RESET_ADDRESS`` and ``COLD_BOOT_SINGLE_CPU`` build options in the
136 In the default, unoptimised BL31 reset flow, on a warm boot a CPU is directed
137 to the PSCI implementation via a platform defined mechanism. On a cold boot,
138 the platform must place any secondary CPUs into a safe state while the primary
144 In this configuration, since the CPU resets to BL31, no parameters are expected
146 Instead, the platform code in BL31 needs to know, or be able to determine, the
147 location of the BL32 (if required) and BL33 images and provide this information
148 in response to the ``bl31_plat_get_next_image_ep_info()`` function.
152 This might be done by the Trusted Boot Firmware or by platform code in BL31.
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