Lines Matching defs:BL31
54 - Boot Loader stage 3-1 (BL31) *EL3 Runtime Software*
81 - specification of the EL3 Runtime Software (BL31 for AArch64 and BL32 for
100 - SOC_FW_CONFIG - SoC Firmware configuration file. Used by BL31.
111 Software* (BL31 for AArch64 and BL32 for AArch32) via `arg0`. All the other
127 to BL31. Note, ``arg0`` is used to pass the list of executable images.
129 passed in ``arg2`` to BL31.
140 BL31/SP_MIN, and the SOC_FW_CONFIG and HW_CONFIG details are retrieved
391 relies on BL31 to pass control to the BL32 image, if present. Hence, BL2
395 Secure-EL1 Payload Dispatcher (see later) within BL31, which is responsible for
396 managing interaction with BL32. This information is passed to BL31.
411 AArch64 BL31 (EL3 Runtime Software) execution
417 BL31 entrypoint. The exception is handled by the SMC exception handler
424 #. BL1 passes control to BL31 at the specified entrypoint at EL3.
483 AArch64 BL31
486 The image for this stage is loaded by BL2 and BL1 passes control to BL31 at
487 EL3. BL31 executes solely in trusted SRAM. BL31 is linked against and
489 in this document). The functionality implemented by BL31 is as follows.
494 Currently, BL31 performs a similar architectural initialization to BL1 as
496 architectural initialization in BL31 allows override of any previous
499 BL31 initializes the per-CPU data framework, which provides a cache of
504 It then replaces the exception vectors populated by BL1 with its own. BL31
506 is the only mechanism to access the runtime services implemented by BL31 (PSCI
507 for example). BL31 checks each SMC for validity as specified by the
511 BL31 programs the ``CNTFRQ_EL0`` register with the clock frequency of the system
517 BL31 performs detailed platform initialization, which enables normal world
532 BL31 is responsible for initializing the runtime services. One of them is PSCI.
534 As part of the PSCI initializations, BL31 detects the system topology. It also
539 initializes the locks that protect them. BL31 accesses the state of a CPU or
542 therefore BL31 uses locks based on Lamport's Bakery algorithm instead.
556 once the runtime services are fully initialized. BL31 invokes such a
576 would like to use TF-A BL31 for the EL3 Runtime Software. To enable this
578 interface between the Trusted Boot Firmware and BL31.
580 Future changes to the BL31 interface will be done in a backwards compatible
600 platform code in BL31:
607 BL31 zero-init sections (e.g. ``.bss``) should not contain valid data on entry,
615 used by the common BL31 code.
617 The convention is that ``X0`` conveys information regarding the BL31, BL32 and
624 BL31 common and SPD initialization code depends on image and entrypoint
625 information about BL33 and BL32, which is provided via BL31 platform APIs.
628 the platform code in BL31, or provided in a platform defined memory location
632 BL31 platform code before the caches are enabled.
635 ``X0`` and the Arm development platforms interpret this in the BL31 platform
641 BL31 does not depend on the enabled state of the MMU, data caches or
645 Data structures used in the BL31 cold boot interface
650 BL31 that can interpret the BL3x image information from different versions of
652 additional register information to BL31, or a ELF image loader that can convey
656 BL31 to detect which information is present and respond appropriately. The
673 Required CPU state for BL31 Warm boot initialization
759 described in AArch64 BL31 cold boot interface section.
798 Software (BL31).
851 the framework to find all service descriptors included into BL31.
873 framework running on the primary CPU during cold boot as part of the BL31
880 The BL31 linker script collects all of the declared service descriptors into a
1032 the Trusted OS is coupled with a companion runtime service in the BL31
1071 the BL32 image. It needs access to the information passed by BL2 to BL31 to do
1082 In the absence of a BL32 image, BL31 passes control to the normal world
1101 Secure-EL1. BL31 will exit to BL32 using the asynchronous method by
1105 BL31 by issuing an SMC, using a Function ID allocated to the SPD. On
1121 On completion BL32 returns control to BL31 via a SMC, and on receipt the
1127 Exception handling in BL31
1186 Crash Reporting in BL31
1189 BL31 implements a scheme for reporting the processor state when an unhandled
1191 register contents and report it via a dedicated UART (PL011 console). BL31
1194 A dedicated per-CPU crash stack is maintained by BL31 and this is retrieved via
1308 the BL1 and BL31 images. It in turn calls the platform and CPU specific reset
1456 During the BL31 initialization sequence, the pointer to the matching ``cpu_ops``
1477 If the crash reporting is enabled in BL31, when a crash occurs, the crash
1577 runtime firmware (BL31 in AArch64, and BL32 in AArch32) will invoke a generic
1608 For BL31, a platform can specify an alternate location for NOBITS sections
1743 on FVP, BL31 and TSP need to know the limit address that their PROGBITS
1780 - EL3 Runtime Software, BL31 for AArch64 and BL32 for AArch32 (e.g. SP_MIN),
1798 BL31.
1852 |----------| <<<<<<<<<<<<< | BL31 NOBITS |
1855 | | <<<<<<<<<<<<< | BL31 PROGBITS |
1897 |--------------| <<<<<<<<<<<<< | BL31 NOBITS |
1900 | | <<<<<<<<<<<<< | BL31 PROGBITS |
1942 |----------| <<<<<<<<<<<<< | BL31 NOBITS |
1945 | | <<<<<<<<<<<<< | BL31 PROGBITS |
1983 0x08000000 +----------+ BL31 is loaded
1988 |----------| <<<<<<<<<<<<< | BL31 NOBITS |
1991 | SCP_BL2 | <<<<<<<<<<<<< | BL31 PROGBITS |
2025 0x08000000 +----------+ BL31 is loaded
2030 |----------| <<<<<<<<<<<<< | BL31 NOBITS |
2033 | SCP_BL2 | <<<<<<<<<<<<< | BL31 PROGBITS |
2532 Reclaiming the BL31 initialization code
2535 A significant amount of the code used for the initialization of BL31 is never
2543 specify the filter and the memory region for this init section in BL31 via the
2547 mapped with ``RO``, ``EXECUTE`` attributes. After BL31 initialization has
2755 BL2, BL31, and the TSP if it is used.
2829 Directory Used by BL1? Used by BL2? Used by BL31?