Lines Matching defs:image
133 - In case SPMC_AT_EL3 is enabled, populate the BL32 image base, size and max
263 - Configure any required platform storage to load the next bootloader image
279 required and execution passes to the first image in the
281 of the next image by calling ``bl1_plat_get_image_desc()``. The image descriptor
283 execution state of the next image.
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
309 for platforms to take further action after image load. This function must
314 #. BL1 passes control to the BL2 image at Secure EL1 (for AArch64) or at
347 - Reserve some memory for passing information to the next bootloader image
350 bootloader image.
359 provided by the platform to the next handover BL image.
367 SCP_BL2 (System Control Processor Firmware) image load
371 reset and system control. BL2 loads the optional SCP_BL2 image from platform
374 development platform port the image is transferred into SCP's internal memory
379 EL3 Runtime Software image load
382 BL2 loads the EL3 Runtime Software image from platform storage into a platform-
384 image or image is missing it leads to an assertion failure.
386 AArch64 BL32 (Secure-EL1 Payload) image load
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
393 of the BL32 image. The value of the Saved Processor Status Register (``SPSR``)
398 BL33 (Non-trusted Firmware) image load
401 BL2 loads the BL33 image (e.g. UEFI or other test or boot software) from
407 normal world software image. The entrypoint is the load address of the BL33
408 image. The ``SPSR`` is determined as specified in Section 5.13 of the
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
470 This functionality can be tested with FVP loading the image directly
486 The image for this stage is loaded by BL2 and BL1 passes control to BL31 at
550 AArch64 BL32 (Secure-EL1 Payload) image initialization
553 If a BL32 image is present then there must be a matching Secure-EL1 Payload
569 information provided by BL2 to jump to the Non-trusted firmware image (BL33)
624 BL31 common and SPD initialization code depends on image and entrypoint
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
1036 BL32 image.
1044 Test BL32 image and service are replaced by the Trusted OS and its dispatcher
1071 the BL32 image. It needs access to the information passed by BL2 to BL31 to do
1079 the image which will be run in the specified security state. The SPD uses this
1080 API to get entry point information for the SECURE image, BL32.
1082 In the absence of a BL32 image, BL31 passes control to the normal world
1083 bootloader image (BL33). When the BL32 image is present, it is typical
1588 Each bootloader image can be divided in 2 parts:
1590 - the static contents of the image. These are data actually stored in the
1594 - the run-time contents of the image. These are data that don't occupy any
1600 All PROGBITS sections are grouped together at the beginning of the image,
1605 this NOBITS section, making the image unnecessarily bigger. Smaller images
1616 Each bootloader stage image layout is described by its own linker script. The
1619 figure out the image memory layout.
1694 BL1 being the ROM image, it has additional requirements. BL1 resides in ROM and
1711 How to choose the right base addresses for each bootloader stage image
1714 There is currently no support for dynamic image loading in TF-A. This means
1716 locations and the base addresses of each image must be chosen carefully such
1721 general recipe for choosing the right base addresses for each bootloader image.
1725 each image. Among other useful information, they provide the end address of
1726 each image.
1733 For each bootloader image, the platform code must provide its start address
1735 linker scripts to check that the image doesn't grow past that address. If that
1742 Additionally, if the platform memory layout implies some image overlaying like
1747 to load a new image is free to prevent overwriting a previously loaded image.
1753 ``load_image()`` function performs bounds check for the image size based on the
1754 base and maximum image size provided by the platforms. Platforms must take
1800 The location of the BL32 image will result in different memory maps. This is
1805 Loading the BL32 image in TZC secured DRAM doesn't change the memory
1819 BL image during boot.
2104 the requested image name into the corresponding UUID when accessing the
2116 only supports packing bootloader images. Additional image definitions can be
2372 The default memory layout for each BL image is as follows:
2410 platform code gets a finer-grained view of the image layout and can
2439 add zero or one page to the memory footprint of each BL image. Each platform
2542 within the BL image for later reclamation by the platform. The platform can
2873 .. |Image 1| image:: ../resources/diagrams/rt-svc-descs-layout.png