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