|
|
|
/*
|
|
|
|
* Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <common/bl_common.ld.h>
|
|
|
|
#include <lib/xlat_tables/xlat_tables_defs.h>
|
|
|
|
|
|
|
|
OUTPUT_FORMAT(PLATFORM_LINKER_FORMAT)
|
|
|
|
OUTPUT_ARCH(PLATFORM_LINKER_ARCH)
|
|
|
|
ENTRY(bl1_entrypoint)
|
|
|
|
|
|
|
|
MEMORY {
|
|
|
|
ROM (rx): ORIGIN = BL1_RO_BASE, LENGTH = BL1_RO_LIMIT - BL1_RO_BASE
|
|
|
|
RAM (rwx): ORIGIN = BL1_RW_BASE, LENGTH = BL1_RW_LIMIT - BL1_RW_BASE
|
|
|
|
}
|
|
|
|
|
|
|
|
SECTIONS
|
|
|
|
{
|
|
|
|
. = BL1_RO_BASE;
|
|
|
|
ASSERT(. == ALIGN(PAGE_SIZE),
|
|
|
|
"BL1_RO_BASE address is not aligned on a page boundary.")
|
|
|
|
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
8 years ago
|
|
|
#if SEPARATE_CODE_AND_RODATA
|
|
|
|
.text . : {
|
|
|
|
__TEXT_START__ = .;
|
|
|
|
*bl1_entrypoint.o(.text*)
|
|
|
|
*(SORT_BY_ALIGNMENT(.text*))
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
8 years ago
|
|
|
*(.vectors)
|
|
|
|
. = ALIGN(PAGE_SIZE);
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
8 years ago
|
|
|
__TEXT_END__ = .;
|
|
|
|
} >ROM
|
|
|
|
|
|
|
|
/* .ARM.extab and .ARM.exidx are only added because Clang need them */
|
|
|
|
.ARM.extab . : {
|
|
|
|
*(.ARM.extab* .gnu.linkonce.armextab.*)
|
|
|
|
} >ROM
|
|
|
|
|
|
|
|
.ARM.exidx . : {
|
|
|
|
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
|
|
|
|
} >ROM
|
|
|
|
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
8 years ago
|
|
|
.rodata . : {
|
|
|
|
__RODATA_START__ = .;
|
|
|
|
*(SORT_BY_ALIGNMENT(.rodata*))
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
8 years ago
|
|
|
|
linker_script: replace common read-only data with RODATA_COMMON
The common section data are repeated in many linker scripts (often
twice in each script to support SEPARATE_CODE_AND_RODATA). When you
add a new read-only data section, you end up with touching lots of
places.
After this commit, you will only need to touch bl_common.ld.h when
you add a new section to RODATA_COMMON.
Replace a series of RO section with RODATA_COMMON, which contains
6 sections, some of which did not exist before.
This is not a big deal because unneeded data should not be compiled
in the first place. I believe this should be controlled by BL*_SOURCES
in Makefiles, not by linker scripts.
When I was working on this commit, the BL1 image size increased
due to the fconf_populator. Commit c452ba159c14 ("fconf: exclude
fconf_dyn_cfg_getter.c from BL1_SOURCES") fixed this issue.
I investigated BL1, BL2, BL2U, BL31 for plat=fvp, and BL2-AT-EL3,
BL31, BL31 for plat=uniphier. I did not see any more unexpected
code addition.
Change-Id: I5d14d60dbe3c821765bce3ae538968ef266f1460
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
5 years ago
|
|
|
RODATA_COMMON
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
8 years ago
|
|
|
|
|
|
|
/*
|
|
|
|
* No need to pad out the .rodata section to a page boundary. Next is
|
|
|
|
* the .data section, which can mapped in ROM with the same memory
|
|
|
|
* attributes as the .rodata section.
|
|
|
|
*
|
|
|
|
* Pad out to 16 bytes though as .data section needs to be 16 byte
|
|
|
|
* aligned and lld does not align the LMA to the aligment specified
|
|
|
|
* on the .data section.
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
8 years ago
|
|
|
*/
|
|
|
|
__RODATA_END__ = .;
|
|
|
|
. = ALIGN(16);
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
8 years ago
|
|
|
} >ROM
|
|
|
|
#else
|
|
|
|
ro . : {
|
|
|
|
__RO_START__ = .;
|
|
|
|
*bl1_entrypoint.o(.text*)
|
|
|
|
*(SORT_BY_ALIGNMENT(.text*))
|
|
|
|
*(SORT_BY_ALIGNMENT(.rodata*))
|
|
|
|
|
linker_script: replace common read-only data with RODATA_COMMON
The common section data are repeated in many linker scripts (often
twice in each script to support SEPARATE_CODE_AND_RODATA). When you
add a new read-only data section, you end up with touching lots of
places.
After this commit, you will only need to touch bl_common.ld.h when
you add a new section to RODATA_COMMON.
Replace a series of RO section with RODATA_COMMON, which contains
6 sections, some of which did not exist before.
This is not a big deal because unneeded data should not be compiled
in the first place. I believe this should be controlled by BL*_SOURCES
in Makefiles, not by linker scripts.
When I was working on this commit, the BL1 image size increased
due to the fconf_populator. Commit c452ba159c14 ("fconf: exclude
fconf_dyn_cfg_getter.c from BL1_SOURCES") fixed this issue.
I investigated BL1, BL2, BL2U, BL31 for plat=fvp, and BL2-AT-EL3,
BL31, BL31 for plat=uniphier. I did not see any more unexpected
code addition.
Change-Id: I5d14d60dbe3c821765bce3ae538968ef266f1460
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
5 years ago
|
|
|
RODATA_COMMON
|
|
|
|
|
|
|
|
*(.vectors)
|
|
|
|
__RO_END__ = .;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Pad out to 16 bytes as .data section needs to be 16 byte aligned and
|
|
|
|
* lld does not align the LMA to the aligment specified on the .data
|
|
|
|
* section.
|
|
|
|
*/
|
|
|
|
. = ALIGN(16);
|
|
|
|
} >ROM
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
8 years ago
|
|
|
#endif
|
|
|
|
|
|
|
|
ASSERT(__CPU_OPS_END__ > __CPU_OPS_START__,
|
|
|
|
"cpu_ops not defined for this platform.")
|
|
|
|
|
|
|
|
. = BL1_RW_BASE;
|
|
|
|
ASSERT(BL1_RW_BASE == ALIGN(PAGE_SIZE),
|
|
|
|
"BL1_RW_BASE address is not aligned on a page boundary.")
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The .data section gets copied from ROM to RAM at runtime.
|
|
|
|
* Its LMA should be 16-byte aligned to allow efficient copying of 16-bytes
|
|
|
|
* aligned regions in it.
|
|
|
|
* Its VMA must be page-aligned as it marks the first read/write page.
|
|
|
|
*
|
|
|
|
* It must be placed at a lower address than the stacks if the stack
|
|
|
|
* protector is enabled. Alternatively, the .data.stack_protector_canary
|
|
|
|
* section can be placed independently of the main .data section.
|
|
|
|
*/
|
|
|
|
.data . : ALIGN(16) {
|
|
|
|
__DATA_RAM_START__ = .;
|
|
|
|
*(SORT_BY_ALIGNMENT(.data*))
|
|
|
|
__DATA_RAM_END__ = .;
|
|
|
|
} >RAM AT>ROM
|
|
|
|
|
bl1: remove '.' from stacks section in linker script
Only BL1 specifies '.' in the address field of the stacks section.
Commit 4f59d8359f97 ("Make BL1 RO and RW base addresses configurable")
added '.' on purpose but the commit message does not help to understand
why.
This commit gets rid of it in order to factor out the stacks section
into include/common/bl_common.ld.h
I compared the build result for PLAT=qemu.
'aarch64-linux-gnu-nm -n build/qemu/release/bl1/bl1.elf' will change
as follows:
@@ -336,8 +336,8 @@
000000000e04e0e0 d max_log_level
000000000e04e0e4 D console_state
000000000e04e0e5 D __DATA_RAM_END__
-000000000e04e0e5 B __STACKS_START__
000000000e04e100 b platform_normal_stacks
+000000000e04e100 B __STACKS_START__
000000000e04f100 b bl1_cpu_context
000000000e04f100 B __BSS_START__
000000000e04f100 B __STACKS_END__
After this change, __STACKS_START__ will match to platform_normal_stacks,
and I think it makes more sense.
'aarch64-linux-gnu-objdump -h build/qemu/release/bl1/bl1.elf' will change
as follows:
@@ -9,11 +9,11 @@
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 000000e5 000000000e04e000 0000000000004a60 0001e000 2**4
CONTENTS, ALLOC, LOAD, DATA
- 3 stacks 0000101b 000000000e04e0e5 000000000e04e0e5 0001e0e5 2**6
+ 3 stacks 00001000 000000000e04e100 0000000000004b45 0001e100 2**6
ALLOC
- 4 .bss 000007e0 000000000e04f100 000000000e04f100 0001e0e5 2**5
+ 4 .bss 000007e0 000000000e04f100 0000000000004b50 0001f100 2**5
ALLOC
- 5 xlat_table 00006000 000000000e050000 000000000e050000 0001e0e5 2**12
+ 5 xlat_table 00006000 000000000e050000 0000000000004b45 00020000 2**12
ALLOC
6 coherent_ram 00000000 000000000e056000 000000000e056000 0001f000 2**12
CONTENTS
Sandrine pointed me to a useful document [1] to understand why LMAs of
stacks, .bss, and xlat_table section have changed.
Before this patch, they fell into this scenario:
"If the section has a specific VMA address, then this is used as the
LMA address as well."
With this commit, the following applies:
"Otherwise if a memory region can be found that is compatible with the
current section, and this region contains at least one section, then
the LMA is set so the difference between the VMA and LMA is the same
as the difference between the VMA and LMA of the last section in the
located region."
Anyway, those three sections are not loaded, so the LMA changes will not
be a problem. The size of bl1.bin is still the same.
QEMU still boots successfully with this change.
A good thing is, this fixes the error for the latest LLD. If I use the
mainline LLVM, I see the following error. The alignment check will probably
be included in the LLVM 11 release, so it is better to fix it now.
$ PLAT=qemu CC=clang CROSS_COMPILE=aarch64-linux-gnu-
[ snip ]
ld.lld: error: address (0xe04e0e5) of section stacks is not a multiple of alignment (64)
make: *** [Makefile:1050: build/qemu/release/bl1/bl1.elf] Error 1
[1]: https://sourceware.org/binutils/docs/ld/Output-Section-LMA.html#Output-Section-LMA
Change-Id: I3d2f3cc2858be8b3ce2eab3812a76d1e0b5f3a32
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
5 years ago
|
|
|
stacks (NOLOAD) : {
|
|
|
|
__STACKS_START__ = .;
|
|
|
|
*(tzfw_normal_stacks)
|
|
|
|
__STACKS_END__ = .;
|
|
|
|
} >RAM
|
|
|
|
|
linker_script: move bss section to bl_common.ld.h
Move the bss section to the common header. This adds BAKERY_LOCK_NORMAL
and PMF_TIMESTAMP, which previously existed only in BL31. This is not
a big deal because unused data should not be compiled in the first
place. I believe this should be controlled by BL*_SOURCES in Makefiles,
not by linker scripts.
I investigated BL1, BL2, BL2U, BL31 for plat=fvp, and BL2-AT-EL3,
BL31, BL31 for plat=uniphier. I did not see any more unexpected
code addition.
The bss section has bigger alignment. I added BSS_ALIGN for this.
Currently, SORT_BY_ALIGNMENT() is missing in sp_min.ld.S, and with this
change, the BSS symbols in SP_MIN will be sorted by the alignment.
This is not a big deal (or, even better in terms of the image size).
Change-Id: I680ee61f84067a559bac0757f9d03e73119beb33
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
5 years ago
|
|
|
BSS_SECTION >RAM
|
|
|
|
XLAT_TABLE_SECTION >RAM
|
|
|
|
|
|
|
|
#if USE_COHERENT_MEM
|
|
|
|
/*
|
|
|
|
* The base address of the coherent memory section must be page-aligned (4K)
|
|
|
|
* to guarantee that the coherent data are stored on their own pages and
|
|
|
|
* are not mixed with normal data. This is required to set up the correct
|
|
|
|
* memory attributes for the coherent data page tables.
|
|
|
|
*/
|
|
|
|
coherent_ram (NOLOAD) : ALIGN(PAGE_SIZE) {
|
|
|
|
__COHERENT_RAM_START__ = .;
|
|
|
|
*(tzfw_coherent_mem)
|
|
|
|
__COHERENT_RAM_END_UNALIGNED__ = .;
|
|
|
|
/*
|
|
|
|
* Memory page(s) mapped to this section will be marked
|
|
|
|
* as device memory. No other unexpected data must creep in.
|
|
|
|
* Ensure the rest of the current memory page is unused.
|
|
|
|
*/
|
|
|
|
. = ALIGN(PAGE_SIZE);
|
|
|
|
__COHERENT_RAM_END__ = .;
|
|
|
|
} >RAM
|
|
|
|
#endif
|
|
|
|
|
|
|
|
__BL1_RAM_START__ = ADDR(.data);
|
|
|
|
__BL1_RAM_END__ = .;
|
|
|
|
|
|
|
|
__DATA_ROM_START__ = LOADADDR(.data);
|
|
|
|
__DATA_SIZE__ = SIZEOF(.data);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The .data section is the last PROGBITS section so its end marks the end
|
|
|
|
* of BL1's actual content in Trusted ROM.
|
|
|
|
*/
|
|
|
|
__BL1_ROM_END__ = __DATA_ROM_START__ + __DATA_SIZE__;
|
|
|
|
ASSERT(__BL1_ROM_END__ <= BL1_RO_LIMIT,
|
|
|
|
"BL1's ROM content has exceeded its limit.")
|
|
|
|
|
|
|
|
__BSS_SIZE__ = SIZEOF(.bss);
|
|
|
|
|
|
|
|
#if USE_COHERENT_MEM
|
|
|
|
__COHERENT_RAM_UNALIGNED_SIZE__ =
|
|
|
|
__COHERENT_RAM_END_UNALIGNED__ - __COHERENT_RAM_START__;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
ASSERT(. <= BL1_RW_LIMIT, "BL1's RW section has exceeded its limit.")
|
|
|
|
}
|