Lines Matching defs:BL2
53 - Boot Loader stage 2 (BL2) *Trusted Boot Firmware*
61 - Boot Loader stage 2 (BL2) *Trusted Boot Firmware*
83 Firmware in place of the provided BL1 and BL2
99 and BL2.
110 stage. BL2 passes the list of the next images to execute to the *EL3 Runtime
115 - BL1 passes the address of a meminfo_t structure to BL2 via ``arg1``. This
116 structure contains the memory layout available to BL2.
122 - FW_CONFIG is loaded by BL1, then its address is passed in ``arg0`` to BL2.
123 - TB_FW_CONFIG address is retrieved by BL2 from FW_CONFIG device tree.
125 BL2. Note, ``arg1`` is already used for meminfo_t.
126 - If SOC_FW_CONFIG is loaded by BL2, then its address is passed in ``arg1``
128 - Similarly, if HW_CONFIG is loaded by BL1 or BL2, then its address is
131 BL2, then its address is passed in ``arg0`` and if HW_CONFIG is loaded
240 - ``BL1_SMC_RUN_IMAGE``: This SMC is raised by BL2 to make BL1 pass control
264 (BL2).
266 load it to the platform defined address and make it available to BL2 via
285 BL2 image load and execution
297 #. BL1 loads a BL2 raw binary image from platform storage, at a
300 use the image information. If the BL2 image file is not present or if
306 "Failed to load BL2 firmware."
310 populate the necessary arguments for BL2, which may also include the memory
314 #. BL1 passes control to the BL2 image at Secure EL1 (for AArch64) or at
317 BL2
320 BL1 loads and passes control to BL2 at Secure-EL1 (for AArch64) or at Secure
321 SVC mode (for AArch32) . BL2 is linked against and loaded at a platform-specific
323 The functionality implemented by BL2 is as follows.
328 For AArch64, BL2 performs the minimal architectural initialization required
335 and BL2 execute at PL1.
340 On Arm platforms, BL2 performs the following platform initializations:
354 Image loading in BL2
357 BL2 generic code loads the images based on the list of loadable images
358 provided by the platform. BL2 passes the list of executable images
371 reset and system control. BL2 loads the optional SCP_BL2 image from platform
377 for BL2 execution to continue.
382 BL2 loads the EL3 Runtime Software image from platform storage into a platform-
389 BL2 loads the optional BL32 image from platform storage into a platform-
390 specific region of secure memory. The image executes in the secure world. BL2
391 relies on BL31 to pass control to the BL32 image, if present. Hence, BL2
394 for entry into BL32 is not determined by BL2, it is initialized by the
401 BL2 loads the BL33 image (e.g. UEFI or other test or boot software) from
404 BL2 relies on EL3 Runtime Software to pass control to BL33 once secure state
405 initialization is complete. Hence, BL2 populates a platform-specific area of
414 BL2 execution continues as follows:
416 #. BL2 passes control back to BL1 by raising an SMC, providing BL1 with the
426 Running BL2 at EL3 execution level
431 as its only purpose is to ensure TF-A BL2 is entered at S-EL1. To avoid
432 this waste, a special mode enables BL2 to execute at EL3, which allows
433 a non-TF-A Boot ROM to load and jump directly to BL2. This mode is selected
437 #. BL2 includes the reset code and the mailbox mechanism to differentiate
441 #. BL2 does not receive the meminfo information from BL1 anymore. This
443 BL2 image.
445 #. Since BL2 executes at EL3, BL2 jumps directly to the next image,
453 of BL2 whose memory cannot be reclaimed by any other image. The
465 In the last 2 cases, no part of BL2 needs to remain resident at
467 differentiate between warm and cold boot, to avoid loading BL2 again
480 BL2 memory.
486 The image for this stage is loaded by BL2 and BL1 passes control to BL31 at
569 information provided by BL2 to jump to the Non-trusted firmware image (BL33)
572 Using alternative Trusted Boot Firmware in place of BL1 & BL2 (AArch64 only)
620 BL1 and BL2 images to transfer additional platform specific information from
634 TF-A's BL2 implementation passes a ``bl31_params`` structure in
651 BL2, a platform that uses an extended entry_point_info structure to convey
731 platforms which use TF-A's BL1 and BL2 images to transfer additional platform
744 ``bl_params`` structure in ``R0`` from BL2 to be interpreted by AArch32 EL3 Runtime
1071 the BL32 image. It needs access to the information passed by BL2 to BL31 to do
1751 For example, in the case of BL1 loading BL2, ``bl1_plat_sec_mem_layout()`` will
1752 return the region defined by the platform where BL1 intends to load BL2. The
1771 - Another 4 KB page is reserved for passing memory layout between BL1 and BL2
1778 - BL2 is loaded below BL1 RW
1782 overwrite BL1 R/W data and BL2. This implies that BL1 global variables
1818 ``bl2_mem_params_descs`` contains parameters passed from BL2 to next the
1850 0x04040000 +----------+ loaded by BL2 +----------------+
1853 | BL2 | <<<<<<<<<<<<< | |
1895 0x04040000 +--------------+ loaded by BL2 +----------------+
1898 | BL2 | <<<<<<<<<<<<< | |
1940 0x04040000 +----------+ loaded by BL2 +----------------+
1943 | BL2 | <<<<<<<<<<<<< | |
1986 0x04040000 +----------+ loaded by BL2 +----------------+
1989 | BL2 | <<<<<<<<<<<<< | |
2028 0x04040000 +----------+ loaded by BL2 +----------------+
2031 | BL2 | <<<<<<<<<<<<< | |
2755 BL2, BL31, and the TSP if it is used.
2829 Directory Used by BL1? Used by BL2? Used by BL31?