github
/
arm-trusted-firmware
mirror of https://github.com/ARM-software/arm-trusted-firmware.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

doc: Update information about the memory layout 

Rework the "Memory layout on FVP platforms" section in the Firmware
Design document. Add information about where the TSP image fits
in the memory layout when present.

Add documentation for the base addresses of each bootloader image
in the porting guide.

Change-Id: I4afb2605e008a1cb28c44a697804f2cb6bb4c9aa
pull/101/head
Sandrine Bailleux 11 years ago
parent
a37255a205
commit
638363eb5f
2 changed files with 74 additions and 78 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 124
      docs/firmware-design.md
  2. 28
      docs/porting-guide.md

124
docs/firmware-design.md
View File

@ -660,10 +660,12 @@ before returning through EL3 and running the non-trusted firmware (BL3-3):
---------------------------------- ----------------------------------
On FVP platforms, we use the Trusted ROM and Trusted SRAM to store the trusted 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. Its read-write firmware binaries. BL1 is originally sitting in the Trusted ROM at address
data are relocated at the base of the Trusted SRAM at runtime. BL1 loads BL2 `0x0`. Its read-write data are relocated at the base of the Trusted SRAM at
image near the top of the the trusted SRAM. BL2 loads BL3-1 image between BL1 runtime. BL1 loads BL2 image near the top of the trusted SRAM. BL2 loads BL3-1
and BL2. This memory layout is illustrated by the following diagram. 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 Trusted SRAM
+----------+ 0x04040000 +----------+ 0x04040000
@ -673,6 +675,10 @@ and BL2. This memory layout is illustrated by the following diagram.
|----------| |----------|
| | | |
|----------| |----------|
| BL32 | (optional)
|----------|
| |
|----------|
| BL31 | | BL31 |
|----------| |----------|
| | | |
@ -685,6 +691,14 @@ and BL2. This memory layout is illustrated by the following diagram.
| BL1 (ro) | | BL1 (ro) |
+----------+ 0x00000000 +----------+ 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 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 linker scripts export some symbols into the program symbol table. Their values
correspond to particular addresses. The trusted firmware code can refer to these correspond to particular addresses. The trusted firmware code can refer to these
@ -768,97 +782,51 @@ for this purpose:
* `__BL1_RAM_START__` This is the start address of BL1 RW data. * `__BL1_RAM_START__` This is the start address of BL1 RW data.
* `__BL1_RAM_END__` This is the end address of BL1 RW data. * `__BL1_RAM_END__` This is the end address of BL1 RW data.
### BL2's and BL3-1's linker symbols ### BL2's, BL3-1's and TSP's linker symbols
Both BL2 and BL3-1 need to know the extents of their read-only section to set BL2, BL3-1 and TSP need to know the extents of their read-only section to set
the right memory attributes for this memory region in their MMU setup code. The the right memory attributes for this memory region in their MMU setup code. The
following linker symbols are defined for this purpose: following linker symbols are defined for this purpose:
* `__RO_START__` * `__RO_START__`
* `__RO_END__` * `__RO_END__`
### How to choose the right base address for each bootloader stage image ### How to choose the right base addresses for each bootloader stage image
The current implementation of the image loader has some limitations. It is
designed to load images dynamically, at a load address chosen to minimize memory
fragmentation. The chosen image location can be either at the top or the bottom
of free memory. However, until this feature is fully functional, the code also
contains support for loading images at a link-time fixed address.
BL1 is always loaded at address `0x0`. BL2 and BL3-1 are loaded at specified
locations in Trusted SRAM. The lack of dynamic image loader support means these
load addresses must currently be adjusted as the code grows. The individual
images must be linked against their ultimate runtime locations.
BL2 is loaded near the top of the Trusted SRAM. BL3-1 is loaded between BL1 There is currently no support for dynamic image loading in the Trusted Firmware.
and BL2. All three images are resident concurrently in Trusted RAM during boot This means that all bootloader images need to be linked against their ultimate
so overlaps are not permitted. runtime locations and the base addresses of each image must be chosen carefully
such that images don't overlap each other in an undesired way. As the code
grows, the base addresses might need adjustments to cope with the new memory
layout.
The image end addresses can be determined from the link map files of the The memory layout is completely specific to the platform and so there is no
different images. These are the `build/<platform>/<build-type>/bl<x>/bl<x>.map` general recipe for choosing the right base addresses for each bootloader image.
files, with `<x>` the stage bootloader. However, there are tools to aid in understanding the memory layout. These are
the link map files: `build/<platform>/<build-type>/bl<x>/bl<x>.map`, with `<x>`
being the stage bootloader. They provide a detailed view of the memory usage of
each image. Among other useful information, they provide the end address of
each image.
* `bl1.map` link map file provides `__BL1_RAM_END__` address. * `bl1.map` link map file provides `__BL1_RAM_END__` address.
* `bl2.map` link map file provides `__BL2_END__` address. * `bl2.map` link map file provides `__BL2_END__` address.
* `bl31.map` link map file provides `__BL31_END__` address. * `bl31.map` link map file provides `__BL31_END__` address.
* `bl32.map` link map file provides `__BL32_END__` address.
To prevent images from overlapping each other, the following constraints must be For each bootloader image, the platform code must provide its start address
enforced: as well as a limit address that it must not overstep. The latter is used in the
linker scripts to check that the image doesn't grow past that address. If that
1. `__BL1_RAM_END__ <= BL31_BASE` happens, the linker will issue a message similar to the following:
2. `__BL31_END__ <= BL2_BASE`
3. `__BL2_END__ <= (<Top of Trusted SRAM>)`
This is illustrated by the following memory layout diagram:
+----------+ 0x04040000
| |
|----------| __BL2_END__
| BL2 |
|----------| BL2_BASE
| |
|----------| __BL31_END__
| BL31 |
|----------| BL31_BASE
| |
|----------| __BL1_RAM_END__
| BL1 (rw) |
+----------+ 0x04000000
Overlaps are detected during image linking as follows.
Constraint 1 is enforced by BL1's linker script. If it is violated then the
linker will report an error while building BL1 to indicate that it doesn't
fit:
aarch64-none-elf-ld: BL31 image overlaps BL1 image.
This error means that the BL3-1 base address needs to be incremented. Ensure
that the new memory layout still obeys all constraints.
Constraint 2 is enforced by BL3-1's linker script. If it is violated then the
linker will report an error while building BL3-1 to indicate that it doesn't
fit:
aarch64-none-elf-ld: BL31 image overlaps BL2 image.
This error can either mean that the BL3-1 base address needs to be decremented
or that BL2 base address needs to be incremented. Ensure that the new memory
layout still obeys all constraints.
Constraint 3 is enforced by BL2's linker script. If it is violated then the
linker will report an error while building BL2 to indicate that it doesn't
fit. For example:
aarch64-none-elf-ld: address 0x40400c8 of bl2.elf section `.bss' is not aarch64-none-elf-ld: BLx has exceeded its limit.
within region `RAM'
This error means that the BL2 base address needs to be decremented. Ensure that On FVP platforms, the base addresses have been chosen such that all images can
the new memory layout still obeys all constraints. 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.
Since constraint checks are scattered across linker scripts, it is required to ### Limitations of the image loader
`make clean` prior to building to ensure that all possible overlapping scenarios
are checked.
The current implementation of the image loader can result in wasted space 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 because of the simplified data structure used to represent the extents of free

28
docs/porting-guide.md
View File

@ -180,16 +180,44 @@ constants defined. In the ARM FVP port, this file is found in
Defines the base address of the `CNTCTLBase` frame of the memory mapped Defines the base address of the `CNTCTLBase` frame of the memory mapped
counter and timer in the system level implementation of the generic timer. counter and timer in the system level implementation of the generic timer.
* **#define : BL1_RO_BASE**
Defines the base address in secure ROM where BL1 originally lives. Must be
aligned on a page-size boundary.
* **#define : BL1_RO_LIMIT**
Defines the maximum address in secure ROM that BL1's actual content (i.e.
excluding any data section allocated at runtime) can occupy.
* **#define : BL1_RW_BASE**
Defines the base address in secure RAM where BL1's read-write data will live
at runtime. Must be aligned on a page-size boundary.
* **#define : BL1_RW_LIMIT**
Defines the maximum address in secure RAM that BL1's read-write data can
occupy at runtime.
* **#define : BL2_BASE** * **#define : BL2_BASE**
Defines the base address in secure RAM where BL1 loads the BL2 binary image. Defines the base address in secure RAM where BL1 loads the BL2 binary image.
Must be aligned on a page-size boundary. Must be aligned on a page-size boundary.
* **#define : BL2_LIMIT**
Defines the maximum address in secure RAM that the BL2 image can occupy.
* **#define : BL31_BASE** * **#define : BL31_BASE**
Defines the base address in secure RAM where BL2 loads the BL3-1 binary Defines the base address in secure RAM where BL2 loads the BL3-1 binary
image. Must be aligned on a page-size boundary. image. Must be aligned on a page-size boundary.
* **#define : BL31_LIMIT**
Defines the maximum address in secure RAM that the BL3-1 image can occupy.
* **#define : NS_IMAGE_OFFSET** * **#define : NS_IMAGE_OFFSET**
Defines the base address in non-secure DRAM where BL2 loads the BL3-3 binary Defines the base address in non-secure DRAM where BL2 loads the BL3-3 binary

Write Preview
Loading…
Cancel
Save