Lines Matching defs:boot
10 world in DRAM. This is the cold boot path.
14 (for example, secondary CPU boot, hotplug and idle). Normal world software can
35 Cold boot
38 The cold boot path starts when the platform is physically turned on. If
41 CPU is chosen through platform-specific means. The cold boot path is mainly
44 the primary CPU has performed enough initialization to boot them.
49 The cold boot path in this implementation of TF-A depends on the execution
80 - initialization and execution of the first three stages during cold boot
85 Dynamic Configuration during cold boot
156 Determination of boot path
160 boot and a cold boot. This is done using platform-specific mechanisms (see the
162 of a warm boot, a CPU is expected to continue execution from a separate
163 entrypoint. In the case of a cold boot, the secondary CPUs are placed in a safe
165 the :ref:`Porting Guide`) while the primary CPU executes the remaining cold boot
276 required or to proceed with the normal boot process. If the platform code
277 returns ``BL2_IMAGE_ID`` then the normal boot sequence is executed as described
288 In the normal boot flow, BL1 execution continues as follows:
401 BL2 loads the BL33 image (e.g. UEFI or other test or boot software) from
429 Some platforms have a non-TF-A Boot ROM that expects the next boot stage
438 cold boot and warm boot. It runs at EL3 doing the arch
452 and warm boot. In this case, we will need to keep a resident part
459 psci_warmboot_entrypoint during cold boot.
463 cold boot, bypassing the boot ROM for warm boot.
467 differentiate between warm and cold boot, to avoid loading BL2 again
468 during warm boot.
541 warm boot path. It is not currently possible to use 'exclusive' based spinlocks,
567 world cold boot, ensuring that no secure state information finds its way into
584 Required CPU state when calling ``bl31_entrypoint()`` during cold boot
630 Cold boot Initialization parameters. This data may need to be cleaned out of
631 the CPU caches if it is provided by an earlier boot stage and then accessed by
645 Data structures used in the BL31 cold boot interface
673 Required CPU state for BL31 Warm boot initialization
677 the platform power management code with a Warm boot initialization
679 On entry to the Warm boot initialization function the calling CPU must be in
704 Required CPU state when entering during cold boot
739 via the Cold boot Initialization parameters. This data may need to be cleaned
740 out of the CPU caches if it is provided by an earlier boot stage and then
754 Data structures used in cold boot interface
757 The AArch32 EL3 Runtime Software cold boot interface uses ``bl_params`` instead
759 described in AArch64 BL31 cold boot interface section.
761 Required CPU state for warm boot initialization
765 Runtime Software must ensure execution of a warm boot initialization entrypoint.
768 boot entrypoint by arranging for the BL1 platform function,
771 In this case, the warm boot entrypoint must be in AArch32 EL3, little-endian
779 The warm boot entrypoint may be implemented by using TF-A
873 framework running on the primary CPU during cold boot as part of the BL31
875 Normal world boot firmware that might in turn use these services.
895 function is only invoked on the primary CPU during cold boot. If the service
1035 boot flow in TF-A. The firmware will attempt to locate, load and execute a
1125 continue the boot process in the normal world.
1307 boot paths. This is done by calling the ``reset_handler()`` function in both
1746 TF-A does not provide any mechanism to verify at boot time that the memory
1784 point during a cold boot.
1819 BL image during boot.
2214 ``level`` and ``lock_index`` are only written once during cold boot. Hence removing
2536 needed again after boot time. In order to reduce the runtime memory
2540 The build option ``RECLAIM_INIT_CODE`` can be set to mark this boot time code
2545 overlapping the secondary CPU stacks so that after the cold boot is done, this
2552 boot initialization and it is upto the platform to make the decision.
2809 TF-A code is logically divided between the three boot loader stages mentioned
2819 - **Stage specific.** Code specific to a boot stage.
2824 Each boot loader stage uses code from one or more of the above mentioned
2840 boot loader stage (where x = BL stage). e.g. for BL1 , IMAGE_BL1 will be
2842 for specific boot loader stages
2845 boot stage have the extension ``.ld.S``. These are processed by GCC to create the
2849 kernel at boot time. These can be found in the ``fdts`` directory.
2869 .. _Trusted Board Boot Requirements CLIENT (TBBR-CLIENT) Armv8-A (ARM DEN0006D): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a