2013-10-25 09:08:21 +01:00
|
|
|
/*
|
2020-03-09 08:39:48 +00:00
|
|
|
* Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
|
2013-10-25 09:08:21 +01:00
|
|
|
*
|
2017-05-03 09:38:09 +01:00
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
2013-10-25 09:08:21 +01:00
|
|
|
*/
|
|
|
|
|
2020-03-09 08:39:48 +00:00
|
|
|
#include <common/bl_common.ld.h>
|
2018-12-14 00:18:21 +00:00
|
|
|
#include <lib/xlat_tables/xlat_tables_defs.h>
|
2013-10-25 09:08:21 +01:00
|
|
|
|
|
|
|
OUTPUT_FORMAT(PLATFORM_LINKER_FORMAT)
|
|
|
|
OUTPUT_ARCH(PLATFORM_LINKER_ARCH)
|
2014-03-11 11:06:45 +00:00
|
|
|
ENTRY(bl1_entrypoint)
|
2013-10-25 09:08:21 +01:00
|
|
|
|
|
|
|
MEMORY {
|
2014-09-16 10:40:35 +01:00
|
|
|
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
|
2013-10-25 09:08:21 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
SECTIONS
|
|
|
|
{
|
2014-05-22 15:21:35 +01:00
|
|
|
. = BL1_RO_BASE;
|
2017-11-15 11:45:35 +00:00
|
|
|
ASSERT(. == ALIGN(PAGE_SIZE),
|
2014-05-22 15:21:35 +01:00
|
|
|
"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
2016-07-08 14:37:40 +01:00
|
|
|
#if SEPARATE_CODE_AND_RODATA
|
|
|
|
.text . : {
|
|
|
|
__TEXT_START__ = .;
|
|
|
|
*bl1_entrypoint.o(.text*)
|
2019-10-20 22:11:25 +01:00
|
|
|
*(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
2016-07-08 14:37:40 +01:00
|
|
|
*(.vectors)
|
2018-04-11 11:53:31 +01:00
|
|
|
. = 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
2016-07-08 14:37:40 +01:00
|
|
|
__TEXT_END__ = .;
|
|
|
|
} >ROM
|
|
|
|
|
2018-05-10 11:01:16 +01:00
|
|
|
/* .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
2016-07-08 14:37:40 +01:00
|
|
|
.rodata . : {
|
|
|
|
__RODATA_START__ = .;
|
2019-10-20 22:11:25 +01:00
|
|
|
*(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
2016-07-08 14:37:40 +01:00
|
|
|
|
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>
2020-03-26 01:57:12 +00:00
|
|
|
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
2016-07-08 14:37:40 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
2020-02-07 22:12:35 +00:00
|
|
|
*
|
|
|
|
* 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
2016-07-08 14:37:40 +01:00
|
|
|
*/
|
|
|
|
__RODATA_END__ = .;
|
2020-02-07 22:12:35 +00:00
|
|
|
. = 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
2016-07-08 14:37:40 +01:00
|
|
|
} >ROM
|
|
|
|
#else
|
2014-05-22 15:21:35 +01:00
|
|
|
ro . : {
|
2013-11-27 09:38:52 +00:00
|
|
|
__RO_START__ = .;
|
2014-03-18 07:13:52 +00:00
|
|
|
*bl1_entrypoint.o(.text*)
|
2019-10-20 22:11:25 +01:00
|
|
|
*(SORT_BY_ALIGNMENT(.text*))
|
|
|
|
*(SORT_BY_ALIGNMENT(.rodata*))
|
2014-08-14 11:33:56 +01:00
|
|
|
|
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>
2020-03-26 01:57:12 +00:00
|
|
|
RODATA_COMMON
|
2014-08-14 11:33:56 +01:00
|
|
|
|
2014-01-18 16:50:09 +00:00
|
|
|
*(.vectors)
|
2013-11-27 09:38:52 +00:00
|
|
|
__RO_END__ = .;
|
2020-02-07 22:12:35 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 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);
|
2013-10-25 09:08:21 +01:00
|
|
|
} >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
2016-07-08 14:37:40 +01:00
|
|
|
#endif
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2014-08-14 11:33:56 +01:00
|
|
|
ASSERT(__CPU_OPS_END__ > __CPU_OPS_START__,
|
|
|
|
"cpu_ops not defined for this platform.")
|
|
|
|
|
2017-02-24 18:14:15 +00:00
|
|
|
. = BL1_RW_BASE;
|
2017-11-15 11:45:35 +00:00
|
|
|
ASSERT(BL1_RW_BASE == ALIGN(PAGE_SIZE),
|
2017-02-24 18:14:15 +00:00
|
|
|
"BL1_RW_BASE address is not aligned on a page boundary.")
|
|
|
|
|
2013-11-27 09:38:52 +00:00
|
|
|
/*
|
|
|
|
* The .data section gets copied from ROM to RAM at runtime.
|
2017-02-24 18:14:15 +00:00
|
|
|
* Its LMA should be 16-byte aligned to allow efficient copying of 16-bytes
|
|
|
|
* aligned regions in it.
|
2014-05-22 15:21:35 +01:00
|
|
|
* Its VMA must be page-aligned as it marks the first read/write page.
|
2017-02-24 18:14:15 +00:00
|
|
|
*
|
|
|
|
* 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.
|
2013-11-27 09:38:52 +00:00
|
|
|
*/
|
2014-05-22 15:21:35 +01:00
|
|
|
.data . : ALIGN(16) {
|
2013-10-25 09:08:21 +01:00
|
|
|
__DATA_RAM_START__ = .;
|
2019-10-20 22:11:25 +01:00
|
|
|
*(SORT_BY_ALIGNMENT(.data*))
|
2013-11-27 09:38:52 +00:00
|
|
|
__DATA_RAM_END__ = .;
|
|
|
|
} >RAM AT>ROM
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2014-05-22 15:21:35 +01:00
|
|
|
stacks . (NOLOAD) : {
|
2013-11-27 09:38:52 +00:00
|
|
|
__STACKS_START__ = .;
|
2013-10-25 09:08:21 +01:00
|
|
|
*(tzfw_normal_stacks)
|
2013-11-27 09:38:52 +00:00
|
|
|
__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>
2020-03-26 04:16:33 +00:00
|
|
|
BSS_SECTION >RAM
|
2020-03-09 08:39:48 +00:00
|
|
|
XLAT_TABLE_SECTION >RAM
|
2014-02-17 17:26:51 +00:00
|
|
|
|
2015-01-08 18:02:44 +00:00
|
|
|
#if USE_COHERENT_MEM
|
2013-11-27 09:38:52 +00:00
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
2017-11-15 11:45:35 +00:00
|
|
|
coherent_ram (NOLOAD) : ALIGN(PAGE_SIZE) {
|
2013-11-27 09:38:52 +00:00
|
|
|
__COHERENT_RAM_START__ = .;
|
2013-10-25 09:08:21 +01:00
|
|
|
*(tzfw_coherent_mem)
|
2013-11-27 09:38:52 +00:00
|
|
|
__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.
|
|
|
|
*/
|
2018-04-11 11:53:31 +01:00
|
|
|
. = ALIGN(PAGE_SIZE);
|
2013-11-27 09:38:52 +00:00
|
|
|
__COHERENT_RAM_END__ = .;
|
2013-10-25 09:08:21 +01:00
|
|
|
} >RAM
|
2015-01-08 18:02:44 +00:00
|
|
|
#endif
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2013-11-27 09:38:52 +00:00
|
|
|
__BL1_RAM_START__ = ADDR(.data);
|
|
|
|
__BL1_RAM_END__ = .;
|
|
|
|
|
|
|
|
__DATA_ROM_START__ = LOADADDR(.data);
|
|
|
|
__DATA_SIZE__ = SIZEOF(.data);
|
2016-06-15 13:53:50 +01:00
|
|
|
|
2014-05-22 15:28:26 +01:00
|
|
|
/*
|
|
|
|
* The .data section is the last PROGBITS section so its end marks the end
|
2016-06-15 13:53:50 +01:00
|
|
|
* of BL1's actual content in Trusted ROM.
|
2014-05-22 15:28:26 +01:00
|
|
|
*/
|
2016-06-15 13:53:50 +01:00
|
|
|
__BL1_ROM_END__ = __DATA_ROM_START__ + __DATA_SIZE__;
|
|
|
|
ASSERT(__BL1_ROM_END__ <= BL1_RO_LIMIT,
|
|
|
|
"BL1's ROM content has exceeded its limit.")
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2013-11-27 09:38:52 +00:00
|
|
|
__BSS_SIZE__ = SIZEOF(.bss);
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2015-01-08 18:02:44 +00:00
|
|
|
#if USE_COHERENT_MEM
|
2013-11-27 09:38:52 +00:00
|
|
|
__COHERENT_RAM_UNALIGNED_SIZE__ =
|
|
|
|
__COHERENT_RAM_END_UNALIGNED__ - __COHERENT_RAM_START__;
|
2015-01-08 18:02:44 +00:00
|
|
|
#endif
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2014-05-22 15:28:26 +01:00
|
|
|
ASSERT(. <= BL1_RW_LIMIT, "BL1's RW section has exceeded its limit.")
|
2013-10-25 09:08:21 +01:00
|
|
|
}
|