andrius
/
arm-trusted-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
arm-trusted-firmware/bl2u/bl2u.ld.S

119 lines
2.9 KiB
ArmAsm
Raw Normal View History

FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
/*
Factor xlat_table sections in linker scripts out into a header file TF-A has so many linker scripts, at least one linker script for each BL image, and some platforms have their own ones. They duplicate quite similar code (and comments). When we add some changes to linker scripts, we end up with touching so many files. This is not nice in the maintainability perspective. When you look at Linux kernel, the common code is macrofied in include/asm-generic/vmlinux.lds.h, which is included from each arch linker script, arch/*/kernel/vmlinux.lds.S TF-A can follow this approach. Let's factor out the common code into include/common/bl_common.ld.h As a start point, this commit factors out the xlat_table section. Change-Id: Ifa369e9b48e8e12702535d721cc2a16d12397895 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-03-09 08:39:48 +00:00
* Copyright (c) 2015-2020, ARM Limited and Contributors. All rights reserved.
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
*
Use SPDX license identifiers To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file. NOTE: Files that have been imported by FreeBSD have not been modified. [0]: https://spdx.org/ Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-05-03 09:38:09 +01:00
* SPDX-License-Identifier: BSD-3-Clause
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
*/
#include <platform_def.h>
Sanitise includes across codebase Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3a282 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca33988b9 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-12-14 00:18:21 +00:00
Factor xlat_table sections in linker scripts out into a header file TF-A has so many linker scripts, at least one linker script for each BL image, and some platforms have their own ones. They duplicate quite similar code (and comments). When we add some changes to linker scripts, we end up with touching so many files. This is not nice in the maintainability perspective. When you look at Linux kernel, the common code is macrofied in include/asm-generic/vmlinux.lds.h, which is included from each arch linker script, arch/*/kernel/vmlinux.lds.S TF-A can follow this approach. Let's factor out the common code into include/common/bl_common.ld.h As a start point, this commit factors out the xlat_table section. Change-Id: Ifa369e9b48e8e12702535d721cc2a16d12397895 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-03-09 08:39:48 +00:00
#include <common/bl_common.ld.h>
Sanitise includes across codebase Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3a282 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca33988b9 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-12-14 00:18:21 +00:00
#include <lib/xlat_tables/xlat_tables_defs.h>
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
OUTPUT_FORMAT(PLATFORM_LINKER_FORMAT)
OUTPUT_ARCH(PLATFORM_LINKER_ARCH)
ENTRY(bl2u_entrypoint)
MEMORY {
RAM (rwx): ORIGIN = BL2U_BASE, LENGTH = BL2U_LIMIT - BL2U_BASE
}
SECTIONS
{
. = BL2U_BASE;
Replace magic numbers in linkerscripts by PAGE_SIZE When defining different sections in linker scripts it is needed to align them to multiples of the page size. In most linker scripts this is done by aligning to the hardcoded value 4096 instead of PAGE_SIZE. This may be confusing when taking a look at all the codebase, as 4096 is used in some parts that aren't meant to be a multiple of the page size. Change-Id: I36c6f461c7782437a58d13d37ec8b822a1663ec1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2017-11-15 11:45:35 +00:00
ASSERT(. == ALIGN(PAGE_SIZE),
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
"BL2U_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__ = .;
*bl2u_entrypoint.o(.text*)
Reduce space lost to object alignment Currently, sections within .text/.rodata/.data/.bss are emitted in the order they are seen by the linker. This leads to wasted space, when a section with a larger alignment follows one with a smaller alignment. We can avoid this wasted space by sorting the sections. To take full advantage of this, we must disable generation of common symbols, so "common" data can be sorted along with the rest of .bss. An example of the improvement, from `make DEBUG=1 PLAT=sun50i_a64 bl31`: .text => no change .rodata => 16 bytes saved .data => 11 bytes saved .bss => 576 bytes saved As a side effect, the addition of `-fno-common` in TF_CFLAGS makes it easier to spot bugs in header files. Signed-off-by: Samuel Holland <samuel@sholland.org> Change-Id: I073630a9b0b84e7302a7a500d4bb4b547be01d51
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)
Use ALIGN instead of NEXT in linker scripts Clang linker doesn't support NEXT. As we are not using the MEMORY command to define discontinuous memory for the output file in any of the linker scripts, ALIGN and NEXT are equivalent. Change-Id: I867ffb9c9a76d4e81c9ca7998280b2edf10efea0 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
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__ = .;
} >RAM
Add .extab and .exidx sections These sections are required by clang when the code is compiled for aarch32. These sections are related to the unwind of the stack in exceptions, but in the way that clang defines and uses them, the garbage collector cannot get rid of them. Change-Id: I085efc0cf77eae961d522472f72c4b5bad2237ab Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
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.*)
} >RAM
.ARM.exidx . : {
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
} >RAM
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__ = .;
Reduce space lost to object alignment Currently, sections within .text/.rodata/.data/.bss are emitted in the order they are seen by the linker. This leads to wasted space, when a section with a larger alignment follows one with a smaller alignment. We can avoid this wasted space by sorting the sections. To take full advantage of this, we must disable generation of common symbols, so "common" data can be sorted along with the rest of .bss. An example of the improvement, from `make DEBUG=1 PLAT=sun50i_a64 bl31`: .text => no change .rodata => 16 bytes saved .data => 11 bytes saved .bss => 576 bytes saved As a side effect, the addition of `-fno-common` in TF_CFLAGS makes it easier to spot bugs in header files. Signed-off-by: Samuel Holland <samuel@sholland.org> Change-Id: I073630a9b0b84e7302a7a500d4bb4b547be01d51
2019-10-20 22:11:25 +01:00
*(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>
2020-03-26 01:57:12 +00:00
RODATA_COMMON
Use ALIGN instead of NEXT in linker scripts Clang linker doesn't support NEXT. As we are not using the MEMORY command to define discontinuous memory for the output file in any of the linker scripts, ALIGN and NEXT are equivalent. Change-Id: I867ffb9c9a76d4e81c9ca7998280b2edf10efea0 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
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
__RODATA_END__ = .;
} >RAM
#else
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
ro . : {
__RO_START__ = .;
*bl2u_entrypoint.o(.text*)
Reduce space lost to object alignment Currently, sections within .text/.rodata/.data/.bss are emitted in the order they are seen by the linker. This leads to wasted space, when a section with a larger alignment follows one with a smaller alignment. We can avoid this wasted space by sorting the sections. To take full advantage of this, we must disable generation of common symbols, so "common" data can be sorted along with the rest of .bss. An example of the improvement, from `make DEBUG=1 PLAT=sun50i_a64 bl31`: .text => no change .rodata => 16 bytes saved .data => 11 bytes saved .bss => 576 bytes saved As a side effect, the addition of `-fno-common` in TF_CFLAGS makes it easier to spot bugs in header files. Signed-off-by: Samuel Holland <samuel@sholland.org> Change-Id: I073630a9b0b84e7302a7a500d4bb4b547be01d51
2019-10-20 22:11:25 +01:00
*(SORT_BY_ALIGNMENT(.text*))
*(SORT_BY_ALIGNMENT(.rodata*))
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +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
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
*(.vectors)
__RO_END_UNALIGNED__ = .;
/*
* Memory page(s) mapped to this section will be marked as
* read-only, executable. No RW data from the next section must
* creep in. Ensure the rest of the current memory page is unused.
*/
Use ALIGN instead of NEXT in linker scripts Clang linker doesn't support NEXT. As we are not using the MEMORY command to define discontinuous memory for the output file in any of the linker scripts, ALIGN and NEXT are equivalent. Change-Id: I867ffb9c9a76d4e81c9ca7998280b2edf10efea0 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-04-11 11:53:31 +01:00
. = ALIGN(PAGE_SIZE);
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
__RO_END__ = .;
} >RAM
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
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
/*
* Define a linker symbol to mark start of the RW memory area for this
* image.
*/
__RW_START__ = . ;
linker_script: move .data section to bl_common.ld.h Move the data section to the common header. I slightly tweaked some scripts as follows: [1] bl1.ld.S has ALIGN(16). I added DATA_ALIGN macro, which is 1 by default, but overridden by bl1.ld.S. Currently, ALIGN(16) of the .data section is redundant because commit 412865907699 ("Fix boot failures on some builds linked with ld.lld.") padded out the previous section to work around the issue of LLD version <= 10.0. This will be fixed in the future release of LLVM, so I am keeping the proper way to align LMA. [2] bl1.ld.S and bl2_el3.ld.S define __DATA_RAM_{START,END}__ instead of __DATA_{START,END}__. I put them out of the .data section. [3] SORT_BY_ALIGNMENT() is missing tsp.ld.S, sp_min.ld.S, and mediatek/mt6795/bl31.ld.S. This commit adds SORT_BY_ALIGNMENT() for all images, so the symbol order in those three will change, but I do not think it is a big deal. Change-Id: I215bb23c319f045cd88e6f4e8ee2518c67f03692 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-04-22 02:50:12 +01:00
DATA_SECTION >RAM
linker_script: move stacks section to bl_common.ld.h The stacks section is the same for all BL linker scripts. Move it to the common header file. Change-Id: Ibd253488667ab4f69702d56ff9e9929376704f6c Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-04-07 05:04:24 +01:00
STACK_SECTION >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
Factor xlat_table sections in linker scripts out into a header file TF-A has so many linker scripts, at least one linker script for each BL image, and some platforms have their own ones. They duplicate quite similar code (and comments). When we add some changes to linker scripts, we end up with touching so many files. This is not nice in the maintainability perspective. When you look at Linux kernel, the common code is macrofied in include/asm-generic/vmlinux.lds.h, which is included from each arch linker script, arch/*/kernel/vmlinux.lds.S TF-A can follow this approach. Let's factor out the common code into include/common/bl_common.ld.h As a start point, this commit factors out the xlat_table section. Change-Id: Ifa369e9b48e8e12702535d721cc2a16d12397895 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2020-03-09 08:39:48 +00:00
XLAT_TABLE_SECTION >RAM
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
#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.
*/
Replace magic numbers in linkerscripts by PAGE_SIZE When defining different sections in linker scripts it is needed to align them to multiples of the page size. In most linker scripts this is done by aligning to the hardcoded value 4096 instead of PAGE_SIZE. This may be confusing when taking a look at all the codebase, as 4096 is used in some parts that aren't meant to be a multiple of the page size. Change-Id: I36c6f461c7782437a58d13d37ec8b822a1663ec1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2017-11-15 11:45:35 +00:00
coherent_ram (NOLOAD) : ALIGN(PAGE_SIZE) {
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
__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.
*/
Use ALIGN instead of NEXT in linker scripts Clang linker doesn't support NEXT. As we are not using the MEMORY command to define discontinuous memory for the output file in any of the linker scripts, ALIGN and NEXT are equivalent. Change-Id: I867ffb9c9a76d4e81c9ca7998280b2edf10efea0 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-04-11 11:53:31 +01:00
. = ALIGN(PAGE_SIZE);
FWU: Add Generic BL2U FWU image support in BL2 The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
2015-10-14 15:27:24 +01:00
__COHERENT_RAM_END__ = .;
} >RAM
#endif
/*
* Define a linker symbol to mark end of the RW memory area for this
* image.
*/
__RW_END__ = .;
__BL2U_END__ = .;
__BSS_SIZE__ = SIZEOF(.bss);
ASSERT(. <= BL2U_LIMIT, "BL2U image has exceeded its limit.")
}