docs/design/reset-design.rst

   1 CPU Reset
   2 =========
   3
   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,
   7 resulting in a simplified and more optimised boot flow.
   8
   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.
  12
  13 General reset code flow
  14 -----------------------
  15
  16 The TF-A reset code is implemented in BL1 by default. The following high-level
  17 diagram illustrates this:
  18
  19 |Default reset code flow|
  20
  21 This diagram shows the default, unoptimised reset flow. Depending on the system
  22 configuration, some of these steps might be unnecessary. The following sections
  23 guide the platform integrator by indicating which build options exclude which
  24 steps, 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
  32 Programmable CPU reset address
  33 ------------------------------
  34
  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
  37 they reset. Further logic is then required to identify whether it is a cold or
  38 warm boot to direct CPUs to the right execution path.
  39
  40 If 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
  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:
  44
  45 |Reset code flow with programmable reset address|
  46
  47 To enable this boot flow, compile TF-A with ``PROGRAMMABLE_RESET_ADDRESS=1``.
  48 This option only affects the TF-A reset image, which is BL1 by default or BL31 if
  49 ``RESET_TO_BL31=1``.
  50
  51 On both the FVP and Juno platforms, the reset vector address is not programmable
  52 so both ports use ``PROGRAMMABLE_RESET_ADDRESS=0``.
  53
  54 Cold boot on a single CPU
  55 -------------------------
  56
  57 By default, TF-A assumes that several CPUs may be released out of reset.
  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.
  62
  63 If the platform guarantees that only a single CPU will ever be brought up then
  64 no arbitration is required. The notion of primary/secondary CPU itself no longer
  65 applies. This results in the following boot flow:
  66
  67 |Reset code flow with single CPU released out of reset|
  68
  69 To enable this boot flow, compile TF-A with ``COLD_BOOT_SINGLE_CPU=1``. This
  70 option only affects the TF-A reset image, which is BL1 by default or BL31 if
  71 ``RESET_TO_BL31=1``.
  72
  73 On both the FVP and Juno platforms, although only one core is powered up by
  74 default, there are platform-specific ways to release any number of cores out of
  75 reset. Therefore, both platform ports use ``COLD_BOOT_SINGLE_CPU=0``.
  76
  77 Programmable CPU reset address, Cold boot on a single CPU
  78 ---------------------------------------------------------
  79
  80 It is obviously possible to combine both optimisations on platforms that have
  81 a programmable CPU reset address and which release a single CPU out of reset.
  82 This results in the following boot flow:
  83
  84
  85 |Reset code flow with programmable reset address and single CPU released out of reset|
  86
  87 To enable this boot flow, compile TF-A with both ``COLD_BOOT_SINGLE_CPU=1``
  88 and ``PROGRAMMABLE_RESET_ADDRESS=1``. These options only affect the TF-A reset
  89 image, which is BL1 by default or BL31 if ``RESET_TO_BL31=1``.
  90
  91 Using BL31 entrypoint as the reset address
  92 ------------------------------------------
  93
  94 On some platforms the runtime firmware (BL3x images) for the application
  95 processors are loaded by some firmware running on a secure system processor
  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.
  99
 100 TF-A provides a build-time option ``RESET_TO_BL31`` that includes some additional
 101 logic in the BL31 entry point to support this use case.
 102
 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
 107 required and providing entry point information for them to BL31. Loading these
 108 images might be done by the Trusted Boot Firmware or by platform code in BL31.
 109
 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
 113 only.
 114
 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:`User Guide` for details of running the FVP models in this
 119 way.
 120
 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.
 124
 125 The ``RESET_TO_BL31`` configuration requires some additions and changes in the
 126 BL31 functionality:
 127
 128 Determination of boot path
 129 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 130
 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
 134 same way.
 135
 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
 139 CPU executes a modified BL31 initialization, as described below.
 140
 141 Platform initialization
 142 ~~~~~~~~~~~~~~~~~~~~~~~
 143
 144 In this configuration, when the CPU resets to BL31 there are no parameters that
 145 can be passed in registers by previous boot stages. Instead, the platform code
 146 in BL31 needs to know, or be able to determine, the location of the BL32 (if
 147 required) and BL33 images and provide this information in response to the
 148 ``bl31_plat_get_next_image_ep_info()`` function.
 149
 150 Additionally, platform software is responsible for carrying out any security
 151 initialisation, for example programming a TrustZone address space controller.
 152 This might be done by the Trusted Boot Firmware or by platform code in BL31.
 153
 154 --------------
 155
 156 *Copyright (c) 2015-2019, Arm Limited and Contributors. All rights reserved.*
 157
 158 .. |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