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