Skip to content

GitLab

"frontend/src/vscode:/vscode.git/clone" did not exist on "6dcb27632e6176c3b5155afa81634a09109a3b3f"
Commit 414cfa18 authored by danh-arm's avatar danh-arm
Browse files

Merge pull request #163 from sandrine-bailleux/sb/tf-issue-117-v2 

fvp: Reuse BL1 and BL2 memory through image overlaying (v2)
parents 6a223156 46d49f63
Hide whitespace changes
Inline Side-by-side
bl31/bl31.ld.S
View file @ 414cfa18
......@@ -75,6 +75,10 @@ SECTIONS
__DATA_END__ = .;
} >RAM
#ifdef BL31_PROGBITS_LIMIT
ASSERT(. <= BL31_PROGBITS_LIMIT, "BL3-1 progbits has exceeded its limit.")
#endif
stacks (NOLOAD) : {
__STACKS_START__ = .;
*(tzfw_normal_stacks)
......
bl32/tsp/tsp.ld.S
View file @ 414cfa18
......@@ -68,6 +68,10 @@ SECTIONS
__DATA_END__ = .;
} >RAM
#ifdef BL32_PROGBITS_LIMIT
ASSERT(. <= BL32_PROGBITS_LIMIT, "BL3-2 progbits has exceeded its limit.")
#endif
stacks (NOLOAD) : {
__STACKS_START__ = .;
*(tzfw_normal_stacks)
......
docs/firmware-design.md
View file @ 414cfa18
......@@ -934,46 +934,62 @@ The sample crash output is shown below.
7. Memory layout on FVP platforms
----------------------------------
Each bootloader image can be divided in 2 parts:
* the static contents of the image. These are data actually stored in the
binary on the disk. In the ELF terminology, they are called `PROGBITS`
sections;
* the run-time contents of the image. These are data that don't occupy any
space in the binary on the disk. The ELF binary just contains some
metadata indicating where these data will be stored at run-time and the
corresponding sections need to be allocated and initialized at run-time.
In the ELF terminology, they are called `NOBITS` sections.
All PROGBITS sections are grouped together at the beginning of the image,
followed by all NOBITS sections. This is true for all Trusted Firmware images
and it is governed by the linker scripts. This ensures that the raw binary
images are as small as possible. If a NOBITS section would sneak in between
PROGBITS sections then the resulting binary file would contain a bunch of zero
bytes at the location of this NOBITS section, making the image unnecessarily
bigger. Smaller images allow faster loading from the FIP to the main memory.
On FVP platforms, we use the Trusted ROM and Trusted SRAM to store the trusted
firmware binaries. BL1 is originally sitting in the Trusted ROM at address
`0x0`. Its read-write data are relocated at the base of the Trusted SRAM at
runtime. BL1 loads BL2 image near the top of the trusted SRAM. BL2 loads BL3-1
image between BL1 and BL2. Optionally, BL2 then loads the TSP as the BL3-2
image. By default it is loaded in Trusted SRAM, in this case it sits between
BL3-1 and BL2. This memory layout is illustrated by the following diagram.
Trusted SRAM
+----------+ 0x04040000
| |
|----------|
| BL2 |
|----------|
| |
|----------|
| BL32 | (optional)
|----------|
| |
|----------|
| BL31 |
|----------|
| |
|----------|
| BL1 (rw) |
+----------+ 0x04000000
Trusted ROM
+----------+ 0x04000000
| BL1 (ro) |
+----------+ 0x00000000
firmware binaries.
* BL1 is originally sitting in the Trusted ROM at address `0x0`. Its
read-write data are relocated at the top of the Trusted SRAM at runtime.
* BL3-1 is loaded at the top of the Trusted SRAM, such that its NOBITS
sections will overwrite BL1 R/W data.
* BL2 is loaded below BL3-1.
* The TSP is loaded as the BL3-2 image at the base of the Trusted SRAM. Its
NOBITS sections are allowed to overlay BL2.
This memory layout is designed to give the BL3-2 image as much memory as
possible. It is illustrated by the following diagram.
Trusted SRAM
0x04040000 +----------+ loaded by BL2 ------------------
| BL1 (rw) | <<<<<<<<<<<<< | BL3-1 NOBITS |
|----------| <<<<<<<<<<<<< |----------------|
| | <<<<<<<<<<<<< | BL3-1 PROGBITS |
|----------| ------------------
| BL2 | <<<<<<<<<<<<< | BL3-2 NOBITS |
|----------| <<<<<<<<<<<<< |----------------|
| | <<<<<<<<<<<<< | BL3-2 PROGBITS |
0x04000000 +----------+ ------------------
Trusted ROM
0x04000000 +----------+
| BL1 (ro) |
0x00000000 +----------+
The TSP image may be loaded in Trusted DRAM instead. This doesn't change the
memory layout of the other boot loader images in Trusted SRAM.
Although the goal at long term is to give complete flexibility over the memory
layout, all platforms should conform to this layout at the moment. This is
because of some limitations in the implementation of the image loader in the
Trusted Firmware. Refer to the "Limitations of the image loader" section below.
Each bootloader stage image layout is described by its own linker script. The
linker scripts export some symbols into the program symbol table. Their values
correspond to particular addresses. The trusted firmware code can refer to these
......@@ -1095,82 +1111,9 @@ happens, the linker will issue a message similar to the following:
aarch64-none-elf-ld: BLx has exceeded its limit.
On FVP platforms, the base addresses have been chosen such that all images can
reside concurrently in Trusted RAM without overlapping each other. Note that
this is not a requirement, as not all images live in memory at the same time.
For example, when the BL3-1 image takes over execution, BL1 and BL2 images are
not needed anymore.
### Limitations of the image loader
The current implementation of the image loader can result in wasted space
because of the simplified data structure used to represent the extents of free
memory. For example, to load BL2 at address `0x0402D000`, the resulting memory
layout should be as follows:
------------ 0x04040000
| | <- Free space (1)
|----------|
| BL2 |
|----------| BL2_BASE (0x0402D000)
| | <- Free space (2)
|----------|
| BL1 |
------------ 0x04000000
In the current implementation, we need to specify whether BL2 is loaded at the
top or bottom of the free memory. BL2 is top-loaded so in the example above,
the free space (1) above BL2 is hidden, resulting in the following view of
memory:
------------ 0x04040000
| |
| |
| BL2 |
|----------| BL2_BASE (0x0402D000)
| | <- Free space (2)
|----------|
| BL1 |
------------ 0x04000000
BL3-1 is bottom-loaded above BL1. For example, if BL3-1 is bottom-loaded at
`0x0400E000`, the memory layout should look like this:
------------ 0x04040000
| |
| |
| BL2 |
|----------| BL2_BASE (0x0402D000)
| | <- Free space (2)
| |
|----------|
| |
| BL31 |
|----------| BL31_BASE (0x0400E000)
| | <- Free space (3)
|----------|
| BL1 |
------------ 0x04000000
But the free space (3) between BL1 and BL3-1 is wasted, resulting in the
following view:
------------ 0x04040000
| |
| |
| BL2 |
|----------| BL2_BASE (0x0402D000)
| | <- Free space (2)
| |
|----------|
| |
| |
| BL31 | BL31_BASE (0x0400E000)
| |
|----------|
| BL1 |
------------ 0x04000000
Additionally, if the platform memory layout implies some image overlaying like
on FVP, BL3-1 and TSP need to know the limit address that their PROGBITS
sections must not overstep. The platform code must provide those.
8. Firmware Image Package (FIP)
--------------------------------
......
docs/porting-guide.md
View file @ 414cfa18
......@@ -253,6 +253,17 @@ be defined as well:
the secure memory identified by `TSP_SEC_MEM_BASE` and `TSP_SEC_MEM_SIZE`
constants.
The following constants are optional. They should be defined when the platform
memory layout implies some image overlaying like on FVP.
* **#define : BL31_PROGBITS_LIMIT**
Defines the maximum address in secure RAM that the BL3-1's progbits sections
can occupy.
* **#define : BL32_PROGBITS_LIMIT**
Defines the maximum address that the TSP's progbits sections can occupy.
### File : plat_macros.S [mandatory]
......
plat/fvp/include/platform_def.h
View file @ 414cfa18
......@@ -101,24 +101,33 @@
******************************************************************************/
#define BL1_RO_BASE TZROM_BASE
#define BL1_RO_LIMIT (TZROM_BASE + TZROM_SIZE)
#define BL1_RW_BASE TZRAM_BASE
#define BL1_RW_LIMIT BL31_BASE
/*
* Put BL1 RW at the top of the Trusted SRAM. BL1_RW_BASE is calculated using
* the current BL1 RW debug size plus a little space for growth.
*/
#define BL1_RW_BASE (TZRAM_BASE + TZRAM_SIZE - 0x6000)
#define BL1_RW_LIMIT (TZRAM_BASE + TZRAM_SIZE)
/*******************************************************************************
* BL2 specific defines.
******************************************************************************/
#define BL2_BASE (TZRAM_BASE + TZRAM_SIZE - 0xc000)
#define BL2_LIMIT (TZRAM_BASE + TZRAM_SIZE)
/*
* Put BL2 just below BL3-1. BL2_BASE is calculated using the current BL2 debug
* size plus a little space for growth.
*/
#define BL2_BASE (BL31_BASE - 0xC000)
#define BL2_LIMIT BL31_BASE
/*******************************************************************************
* BL31 specific defines.
******************************************************************************/
#define BL31_BASE (TZRAM_BASE + 0x6000)
#if TSP_RAM_LOCATION_ID == TSP_IN_TZRAM
#define BL31_LIMIT BL32_BASE
#elif TSP_RAM_LOCATION_ID == TSP_IN_TZDRAM
#define BL31_LIMIT BL2_BASE
#endif
/*
* Put BL3-1 at the top of the Trusted SRAM. BL31_BASE is calculated using the
* current BL3-1 debug size plus a little space for growth.
*/
#define BL31_BASE (TZRAM_BASE + TZRAM_SIZE - 0x1D000)
#define BL31_PROGBITS_LIMIT BL1_RW_BASE
#define BL31_LIMIT (TZRAM_BASE + TZRAM_SIZE)
/*******************************************************************************
* BL32 specific defines.
......@@ -132,8 +141,9 @@
#if TSP_RAM_LOCATION_ID == TSP_IN_TZRAM
# define TSP_SEC_MEM_BASE TZRAM_BASE
# define TSP_SEC_MEM_SIZE TZRAM_SIZE
# define BL32_BASE (TZRAM_BASE + TZRAM_SIZE - 0x1c000)
# define BL32_LIMIT BL2_BASE
# define BL32_BASE TZRAM_BASE
# define BL32_PROGBITS_LIMIT BL2_BASE
# define BL32_LIMIT BL31_BASE
#elif TSP_RAM_LOCATION_ID == TSP_IN_TZDRAM
# define TSP_SEC_MEM_BASE TZDRAM_BASE
# define TSP_SEC_MEM_SIZE TZDRAM_SIZE
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment