blob: a92ceeba7a963629722505d889120e9089fd89c4 [file] [log] [blame]
Paul Beesleyfc9ee362019-03-07 15:47:15 +00001CPU Reset
2=========
Douglas Raillardd7c21b72017-06-28 15:23:03 +01003
Douglas Raillardd7c21b72017-06-28 15:23:03 +01004This document describes the high-level design of the framework to handle CPU
Dan Handley610e7e12018-03-01 18:44:00 +00005resets 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.
Douglas Raillardd7c21b72017-06-28 15:23:03 +01008
Paul Beesleyf8640672019-04-12 14:19:42 +01009This 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.
Douglas Raillardd7c21b72017-06-28 15:23:03 +010012
13General reset code flow
14-----------------------
15
Dan Handley610e7e12018-03-01 18:44:00 +000016The TF-A reset code is implemented in BL1 by default. The following high-level
17diagram illustrates this:
Douglas Raillardd7c21b72017-06-28 15:23:03 +010018
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
Paul Beesleyba3ed402019-03-13 16:20:44 +000026.. 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.
Douglas Raillardd7c21b72017-06-28 15:23:03 +010031
32Programmable CPU reset address
33------------------------------
34
Dan Handley610e7e12018-03-01 18:44:00 +000035By default, TF-A assumes that the CPU reset address is not programmable.
Douglas Raillardd7c21b72017-06-28 15:23:03 +010036Therefore, 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
Dan Handley610e7e12018-03-01 18:44:00 +000047To 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
Douglas Raillardd7c21b72017-06-28 15:23:03 +010049``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
Dan Handley610e7e12018-03-01 18:44:00 +000057By default, TF-A assumes that several CPUs may be released out of reset.
Douglas Raillardd7c21b72017-06-28 15:23:03 +010058Therefore, 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
Dan Handley610e7e12018-03-01 18:44:00 +000069To 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
Douglas Raillardd7c21b72017-06-28 15:23:03 +010071``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
Dan Handley610e7e12018-03-01 18:44:00 +000087To 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
Douglas Raillardd7c21b72017-06-28 15:23:03 +010089image, 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
Dan Handley610e7e12018-03-01 18:44:00 +0000100TF-A provides a build-time option ``RESET_TO_BL31`` that includes some additional
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100101logic 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
Dan Handley610e7e12018-03-01 18:44:00 +0000110Although the Arm FVP platform does not support programming the reset base
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100111address dynamically at run-time, it is possible to set the initial value of the
Paul Beesleyf8640672019-04-12 14:19:42 +0100112``RVBAR_EL3`` register at start-up. This feature is provided on the Base FVP
113only.
114
Dan Handley610e7e12018-03-01 18:44:00 +0000115It allows the Arm FVP port to support the ``RESET_TO_BL31`` configuration, in
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100116which 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
Paul Beesleyf8640672019-04-12 14:19:42 +0100118address. See the :ref:`User Guide` for details of running the FVP models in this
119way.
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100120
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, when the CPU resets to BL31 there are no parameters that
145can be passed in registers by previous boot stages. Instead, the platform code
146in BL31 needs to know, or be able to determine, the location of the BL32 (if
147required) and BL33 images and provide this information in response to the
148``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--------------
155
Paul Beesleyf8640672019-04-12 14:19:42 +0100156*Copyright (c) 2015-2019, Arm Limited and Contributors. All rights reserved.*
Douglas Raillardd7c21b72017-06-28 15:23:03 +0100157
Paul Beesley814f8c02019-03-13 15:49:27 +0000158.. |Default reset code flow| image:: ../resources/diagrams/default_reset_code.png
159.. |Reset code flow with programmable reset address| image:: ../resources/diagrams/reset_code_no_boot_type_check.png
160.. |Reset code flow with single CPU released out of reset| image:: ../resources/diagrams/reset_code_no_cpu_check.png
161.. |Reset code flow with programmable reset address and single CPU released out of reset| image:: ../resources/diagrams/reset_code_no_checks.png