docs: update for removal of deprecated interfaces.
Change-Id: I69e2720f534583a0f8d0e44f2e7b6f393f6fd093
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
diff --git a/docs/firmware-design.rst b/docs/firmware-design.rst
index 8aa7622..ea98dc8 100644
--- a/docs/firmware-design.rst
+++ b/docs/firmware-design.rst
@@ -1650,80 +1650,10 @@
on FVP, BL31 and TSP need to know the limit address that their PROGBITS
sections must not overstep. The platform code must provide those.
-When LOAD\_IMAGE\_V2 is disabled, TF-A provides a mechanism to verify at boot
-time that the memory to load a new image is free to prevent overwriting a
-previously loaded image. For this mechanism to work, the platform must specify
-the memory available in the system as regions, where each region consists of
-base address, total size and the free area within it (as defined in the
-``meminfo_t`` structure). TF-A retrieves these memory regions by calling the
-corresponding platform API:
-
-- ``meminfo_t *bl1_plat_sec_mem_layout(void)``
-- ``meminfo_t *bl2_plat_sec_mem_layout(void)``
-- ``void bl2_plat_get_scp_bl2_meminfo(meminfo_t *scp_bl2_meminfo)``
-- ``void bl2_plat_get_bl32_meminfo(meminfo_t *bl32_meminfo)``
-- ``void bl2_plat_get_bl33_meminfo(meminfo_t *bl33_meminfo)``
-
-For example, in the case of BL1 loading BL2, ``bl1_plat_sec_mem_layout()`` will
-return the region defined by the platform where BL1 intends to load BL2. The
-``load_image()`` function will check that the memory where BL2 will be loaded is
-within the specified region and marked as free.
-
-The actual number of regions and their base addresses and sizes is platform
-specific. The platform may return the same region or define a different one for
-each API. However, the overlap verification mechanism applies only to a single
-region. Hence, it is the platform responsibility to guarantee that different
-regions do not overlap, or that if they do, the overlapping images are not
-accessed at the same time. This could be used, for example, to load temporary
-images (e.g. certificates) or firmware images prior to being transfered to its
-corresponding processor (e.g. the SCP BL2 image).
-
-To reduce fragmentation and simplify the tracking of free memory, all the free
-memory within a region is always located in one single buffer defined by its
-base address and size. TF-A implements a top/bottom load approach:
-after a new image is loaded, it checks how much memory remains free above and
-below the image. The smallest area is marked as unavailable, while the larger
-area becomes the new free memory buffer. Platforms should take this behaviour
-into account when defining the base address for each of the images. For example,
-if an image is loaded near the middle of the region, small changes in image size
-could cause a flip between a top load and a bottom load, which may result in an
-unexpected memory layout.
-
-The following diagram is an example of an image loaded in the bottom part of
-the memory region. The region is initially free (nothing has been loaded yet):
-
-::
-
- Memory region
- +----------+
- | |
- | | <<<<<<<<<<<<< Free
- | |
- |----------| +------------+
- | image | <<<<<<<<<<<<< | image |
- |----------| +------------+
- | xxxxxxxx | <<<<<<<<<<<<< Marked as unavailable
- +----------+
-
-And the following diagram is an example of an image loaded in the top part:
-
-::
-
- Memory region
- +----------+
- | xxxxxxxx | <<<<<<<<<<<<< Marked as unavailable
- |----------| +------------+
- | image | <<<<<<<<<<<<< | image |
- |----------| +------------+
- | |
- | | <<<<<<<<<<<<< Free
- | |
- +----------+
-
-When LOAD\_IMAGE\_V2 is enabled, TF-A does not provide any mechanism to verify
-at boot time that the memory to load a new image is free to prevent overwriting
-a previously loaded image. The platform must specify the memory available in
-the system for all the relevant BL images to be loaded.
+TF-A does not provide any mechanism to verify at boot time that the memory
+to load a new image is free to prevent overwriting a previously loaded image.
+The platform must specify the memory available in the system for all the
+relevant BL images to be loaded.
For example, in the case of BL1 loading BL2, ``bl1_plat_sec_mem_layout()`` will
return the region defined by the platform where BL1 intends to load BL2. The
@@ -1774,43 +1704,6 @@
When BL32 (for AArch64) is loaded into Trusted SRAM, it is loaded below
BL31.
-When LOAD\_IMAGE\_V2 is disabled the memory regions for the overlap detection
-mechanism at boot time are defined as follows (shown per API):
-
-- ``meminfo_t *bl1_plat_sec_mem_layout(void)``
-
- This region corresponds to the whole Trusted SRAM except for the shared
- memory at the base. This region is initially free. At boot time, BL1 will
- mark the BL1(rw) section within this region as occupied. The BL1(rw) section
- is placed at the top of Trusted SRAM.
-
-- ``meminfo_t *bl2_plat_sec_mem_layout(void)``
-
- This region corresponds to the whole Trusted SRAM as defined by
- ``bl1_plat_sec_mem_layout()``, but with the BL1(rw) section marked as
- occupied. This memory region is used to check that BL2 and BL31 do not
- overlap with each other. BL2\_BASE and BL1\_RW\_BASE are carefully chosen so
- that the memory for BL31 is top loaded above BL2.
-
-- ``void bl2_plat_get_scp_bl2_meminfo(meminfo_t *scp_bl2_meminfo)``
-
- This region is an exact copy of the region defined by
- ``bl2_plat_sec_mem_layout()``. Being a disconnected copy means that all the
- changes made to this region by the TF-A will not be propagated. This
- approach is valid because the SCP BL2 image is loaded temporarily while it
- is being transferred to the SCP, so this memory is reused afterwards.
-
-- ``void bl2_plat_get_bl32_meminfo(meminfo_t *bl32_meminfo)``
-
- This region depends on the location of the BL32 image. Currently, Arm
- platforms support three different locations (detailed below): Trusted SRAM,
- Trusted DRAM and the TZC-Secured DRAM.
-
-- ``void bl2_plat_get_bl33_meminfo(meminfo_t *bl33_meminfo)``
-
- This region corresponds to the Non-Secure DDR-DRAM, excluding the
- TZC-Secured area.
-
The location of the BL32 image will result in different memory maps. This is
illustrated for both FVP and Juno in the following diagrams, using the TSP as
an example.