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

126 lines
3.1 KiB
ArmAsm
Raw Permalink Normal View History

ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
/*
feat(rme): run BL2 in root world when FEAT_RME is enabled This patch enables BL2 to run in root world (EL3) which is needed as per the security model of RME-enabled systems. Using the existing BL2_AT_EL3 TF-A build option is not convenient because that option assumes TF-A BL1 doesn't exist, which is not the case for RME-enabled systems. For the purposes of RME, we use a normal BL1 image but we also want to run BL2 in EL3 as normally as possible, therefore rather than use the special bl2_entrypoint function in bl2_el3_entrypoint.S, we use a new bl2_entrypoint function (in bl2_rme_entrypoint.S) which doesn't need reset or mailbox initialization code seen in the el3_entrypoint_common macro. The patch also cleans up bl2_el3_entrypoint.S, moving the bl2_run_next_image function to its own file to avoid duplicating code. Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com> Change-Id: I99821b4cd550cadcb701f4c0c4dc36da81c7ef55
2021-07-09 17:37:10 +01:00
* Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +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
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +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
#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>
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
OUTPUT_FORMAT(PLATFORM_LINKER_FORMAT)
OUTPUT_ARCH(PLATFORM_LINKER_ARCH)
Specify image entry in linker script At present, the entry point for each BL image is specified via the Makefiles and provided on the command line to the linker. When using a link script the entry point should rather be specified via the ENTRY() directive in the link script. This patch updates linker scripts of all BL images to specify the entry point using the ENTRY() directive. It also removes the --entry flag passed to the linker through Makefile. Fixes issue ARM-software/tf-issues#66 Change-Id: I1369493ebbacea31885b51185441f6b628cf8da0
2014-03-11 11:06:45 +00:00
ENTRY(bl2_entrypoint)
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
MEMORY {
Fix LENGTH attribute value in linker scripts This patch fixes the incorrect value of the LENGTH attribute in the linker scripts. This attribute must define the memory size, not the limit address. Fixes ARM-software/tf-issues#252 Change-Id: I328c38b9ec502debe12046a8912d7dfc54610c46
2014-09-16 10:40:35 +01:00
RAM (rwx): ORIGIN = BL2_BASE, LENGTH = BL2_LIMIT - BL2_BASE
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
}
SECTIONS
{
. = BL2_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),
Various improvements/cleanups on the linker scripts - Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
2013-11-27 09:38:52 +00:00
"BL2_BASE address is not aligned on a page boundary.")
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
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__ = .;
feat(rme): run BL2 in root world when FEAT_RME is enabled This patch enables BL2 to run in root world (EL3) which is needed as per the security model of RME-enabled systems. Using the existing BL2_AT_EL3 TF-A build option is not convenient because that option assumes TF-A BL1 doesn't exist, which is not the case for RME-enabled systems. For the purposes of RME, we use a normal BL1 image but we also want to run BL2 in EL3 as normally as possible, therefore rather than use the special bl2_entrypoint function in bl2_el3_entrypoint.S, we use a new bl2_entrypoint function (in bl2_rme_entrypoint.S) which doesn't need reset or mailbox initialization code seen in the el3_entrypoint_common macro. The patch also cleans up bl2_el3_entrypoint.S, moving the bl2_run_next_image function to its own file to avoid duplicating code. Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com> Change-Id: I99821b4cd550cadcb701f4c0c4dc36da81c7ef55
2021-07-09 17:37:10 +01:00
#if ENABLE_RME
*bl2_rme_entrypoint.o(.text*)
#else /* ENABLE_RME */
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
*bl2_entrypoint.o(.text*)
feat(rme): run BL2 in root world when FEAT_RME is enabled This patch enables BL2 to run in root world (EL3) which is needed as per the security model of RME-enabled systems. Using the existing BL2_AT_EL3 TF-A build option is not convenient because that option assumes TF-A BL1 doesn't exist, which is not the case for RME-enabled systems. For the purposes of RME, we use a normal BL1 image but we also want to run BL2 in EL3 as normally as possible, therefore rather than use the special bl2_entrypoint function in bl2_el3_entrypoint.S, we use a new bl2_entrypoint function (in bl2_rme_entrypoint.S) which doesn't need reset or mailbox initialization code seen in the el3_entrypoint_common macro. The patch also cleans up bl2_el3_entrypoint.S, moving the bl2_run_next_image function to its own file to avoid duplicating code. Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com> Change-Id: I99821b4cd550cadcb701f4c0c4dc36da81c7ef55
2021-07-09 17:37:10 +01:00
#endif /* ENABLE_RME */
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*))
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
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
Various improvements/cleanups on the linker scripts - Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
2013-11-27 09:38:52 +00:00
ro . : {
__RO_START__ = .;
Use --gc-sections during link All common functions are being built into all binary images, whether or not they are actually used. This change enables the use of -ffunction-sections, -fdata-sections and --gc-sections in the compiler and linker to remove unused code and data from the images. Change-Id: Ia9f78c01054ac4fa15d145af38b88a0d6fb7d409
2014-03-18 07:13:52 +00:00
*bl2_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*))
TBB: add authentication framework This patch adds the authentication framework that will be used as the base to implement Trusted Board Boot in the Trusted Firmware. The framework comprises the following modules: - Image Parser Module (IPM) This module is responsible for interpreting images, check their integrity and extract authentication information from them during Trusted Board Boot. The module currently supports three types of images i.e. raw binaries, X509v3 certificates and any type specific to a platform. An image parser library must be registered for each image type (the only exception is the raw image parser, which is included in the main module by default). Each parser library (if used) must export a structure in a specific linker section which contains function pointers to: 1. Initialize the library 2. Check the integrity of the image type supported by the library 3. Extract authentication information from the image - Cryptographic Module (CM) This module is responsible for verifying digital signatures and hashes. It relies on an external cryptographic library to perform the cryptographic operations. To register a cryptographic library, the library must use the REGISTER_CRYPTO_LIB macro, passing function pointers to: 1. Initialize the library 2. Verify a digital signature 3. Verify a hash Failing to register a cryptographic library will generate a build time error. - Authentication Module (AM) This module provides methods to authenticate an image, like hash comparison or digital signatures. It uses the image parser module to extract authentication parameters, the crypto module to perform cryptographic operations and the Chain of Trust to authenticate the images. The Chain of Trust (CoT) is a data structure that defines the dependencies between images and the authentication methods that must be followed to authenticate an image. The Chain of Trust, when added, must provide a header file named cot_def.h with the following definitions: - COT_MAX_VERIFIED_PARAMS Integer value indicating the maximum number of authentication parameters an image can present. This value will be used by the authentication module to allocate the memory required to load the parameters in the image descriptor. Change-Id: Ied11bd5cd410e1df8767a1df23bb720ce7e58178
2015-04-02 09:48:16 +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
TBB: add authentication framework This patch adds the authentication framework that will be used as the base to implement Trusted Board Boot in the Trusted Firmware. The framework comprises the following modules: - Image Parser Module (IPM) This module is responsible for interpreting images, check their integrity and extract authentication information from them during Trusted Board Boot. The module currently supports three types of images i.e. raw binaries, X509v3 certificates and any type specific to a platform. An image parser library must be registered for each image type (the only exception is the raw image parser, which is included in the main module by default). Each parser library (if used) must export a structure in a specific linker section which contains function pointers to: 1. Initialize the library 2. Check the integrity of the image type supported by the library 3. Extract authentication information from the image - Cryptographic Module (CM) This module is responsible for verifying digital signatures and hashes. It relies on an external cryptographic library to perform the cryptographic operations. To register a cryptographic library, the library must use the REGISTER_CRYPTO_LIB macro, passing function pointers to: 1. Initialize the library 2. Verify a digital signature 3. Verify a hash Failing to register a cryptographic library will generate a build time error. - Authentication Module (AM) This module provides methods to authenticate an image, like hash comparison or digital signatures. It uses the image parser module to extract authentication parameters, the crypto module to perform cryptographic operations and the Chain of Trust to authenticate the images. The Chain of Trust (CoT) is a data structure that defines the dependencies between images and the authentication methods that must be followed to authenticate an image. The Chain of Trust, when added, must provide a header file named cot_def.h with the following definitions: - COT_MAX_VERIFIED_PARAMS Integer value indicating the maximum number of authentication parameters an image can present. This value will be used by the authentication module to allocate the memory required to load the parameters in the image descriptor. Change-Id: Ied11bd5cd410e1df8767a1df23bb720ce7e58178
2015-04-02 09:48:16 +01:00
Setup VBAR_EL3 incrementally This patch ensures that VBAR_EL3 points to the simple stack-less 'early_exceptions' when the C runtime stack is not correctly setup to use the more complex 'runtime_exceptions'. It is initialised to 'runtime_exceptions' once this is done. This patch also moves all exception vectors into a '.vectors' section and modifies linker scripts to place all such sections together. This will minimize space wastage from alignment restrictions. Change-Id: I8c3e596ea3412c8bd582af9e8d622bb1cb2e049d
2014-01-18 16:50:09 +00:00
*(.vectors)
Various improvements/cleanups on the linker scripts - Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
2013-11-27 09:38:52 +00:00
__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);
Various improvements/cleanups on the linker scripts - Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
2013-11-27 09:38:52 +00:00
__RO_END__ = .;
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
} >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
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
Make generic code work in presence of system caches On the ARMv8 architecture, cache maintenance operations by set/way on the last level of integrated cache do not affect the system cache. This means that such a flush or clean operation could result in the data being pushed out to the system cache rather than main memory. Another CPU could access this data before it enables its data cache or MMU. Such accesses could be serviced from the main memory instead of the system cache. If the data in the sysem cache has not yet been flushed or evicted to main memory then there could be a loss of coherency. The only mechanism to guarantee that the main memory will be updated is to use cache maintenance operations to the PoC by MVA(See section D3.4.11 (System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G). This patch removes the reliance of Trusted Firmware on the flush by set/way operation to ensure visibility of data in the main memory. Cache maintenance operations by MVA are now used instead. The following are the broad category of changes: 1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is initialised. This ensures that any stale cache lines at any level of cache are removed. 2. Updates to global data in runtime firmware (BL31) by the primary CPU are made visible to secondary CPUs using a cache clean operation by MVA. 3. Cache maintenance by set/way operations are only used prior to power down. NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES. Fixes ARM-software/tf-issues#205 Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
2015-09-11 16:03:13 +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
Factor out translation table setup in ARM FVP port This patch factors out the ARM FVP specific code to create MMU translation tables so that it is possible for a boot loader stage to create a different set of tables instead of using the default ones. The default translation tables are created with the assumption that the calling boot loader stage executes out of secure SRAM. This might not be true for the BL3_2 stage in the future. A boot loader stage can define the `fill_xlation_tables()` function as per its requirements. It returns a reference to the level 1 translation table which is used by the common platform code to setup the TTBR_EL3. This patch is a temporary solution before a larger rework of translation table creation logic is introduced. Change-Id: I09a075d5da16822ee32a411a9dbe284718fb4ff6
2014-02-09 13:30:38 +00:00
Remove coherent memory from the BL memory maps This patch extends the build option `USE_COHERENT_MEMORY` to conditionally remove coherent memory from the memory maps of all boot loader stages. The patch also adds necessary documentation for coherent memory removal in firmware-design, porting and user guides. Fixes ARM-Software/tf-issues#106 Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
2015-01-08 18:02:44 +00:00
#if USE_COHERENT_MEM
Various improvements/cleanups on the linker scripts - Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
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.
*/
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) {
Various improvements/cleanups on the linker scripts - Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
2013-11-27 09:38:52 +00: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);
Various improvements/cleanups on the linker scripts - Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
2013-11-27 09:38:52 +00:00
__COHERENT_RAM_END__ = .;
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
} >RAM
Remove coherent memory from the BL memory maps This patch extends the build option `USE_COHERENT_MEMORY` to conditionally remove coherent memory from the memory maps of all boot loader stages. The patch also adds necessary documentation for coherent memory removal in firmware-design, porting and user guides. Fixes ARM-Software/tf-issues#106 Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
2015-01-08 18:02:44 +00:00
#endif
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
Make generic code work in presence of system caches On the ARMv8 architecture, cache maintenance operations by set/way on the last level of integrated cache do not affect the system cache. This means that such a flush or clean operation could result in the data being pushed out to the system cache rather than main memory. Another CPU could access this data before it enables its data cache or MMU. Such accesses could be serviced from the main memory instead of the system cache. If the data in the sysem cache has not yet been flushed or evicted to main memory then there could be a loss of coherency. The only mechanism to guarantee that the main memory will be updated is to use cache maintenance operations to the PoC by MVA(See section D3.4.11 (System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G). This patch removes the reliance of Trusted Firmware on the flush by set/way operation to ensure visibility of data in the main memory. Cache maintenance operations by MVA are now used instead. The following are the broad category of changes: 1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is initialised. This ensures that any stale cache lines at any level of cache are removed. 2. Updates to global data in runtime firmware (BL31) by the primary CPU are made visible to secondary CPUs using a cache clean operation by MVA. 3. Cache maintenance by set/way operations are only used prior to power down. NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES. Fixes ARM-software/tf-issues#205 Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a
2015-09-11 16:03:13 +01:00
/*
* Define a linker symbol to mark end of the RW memory area for this
* image.
*/
__RW_END__ = .;
Various improvements/cleanups on the linker scripts - Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
2013-11-27 09:38:52 +00:00
__BL2_END__ = .;
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
Various improvements/cleanups on the linker scripts - Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
2013-11-27 09:38:52 +00:00
__BSS_SIZE__ = SIZEOF(.bss);
Remove coherent memory from the BL memory maps This patch extends the build option `USE_COHERENT_MEMORY` to conditionally remove coherent memory from the memory maps of all boot loader stages. The patch also adds necessary documentation for coherent memory removal in firmware-design, porting and user guides. Fixes ARM-Software/tf-issues#106 Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
2015-01-08 18:02:44 +00:00
#if USE_COHERENT_MEM
Various improvements/cleanups on the linker scripts - Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
2013-11-27 09:38:52 +00:00
__COHERENT_RAM_UNALIGNED_SIZE__ =
__COHERENT_RAM_END_UNALIGNED__ - __COHERENT_RAM_START__;
Remove coherent memory from the BL memory maps This patch extends the build option `USE_COHERENT_MEMORY` to conditionally remove coherent memory from the memory maps of all boot loader stages. The patch also adds necessary documentation for coherent memory removal in firmware-design, porting and user guides. Fixes ARM-Software/tf-issues#106 Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
2015-01-08 18:02:44 +00:00
#endif
Make the memory layout more flexible Currently the platform code gets to define the base address of each boot loader image. However, the linker scripts couteract this flexibility by enforcing a fixed overall layout of the different images. For example, they require that the BL3-1 image sits below the BL2 image. Choosing BL3-1 and BL2 base addresses in such a way that it violates this constraint makes the build fail at link-time. This patch requires the platform code to now define a limit address for each image. The linker scripts check that the image fits within these bounds so they don't rely anymore on the position of a given image in regard to the others. Fixes ARM-software/tf-issues#163 Change-Id: I8c108646825da19a6a8dfb091b613e1dd4ae133c
2014-05-22 15:28:26 +01:00
ASSERT(. <= BL2_LIMIT, "BL2 image has exceeded its limit.")
ARMv8 Trusted Firmware release v0.2
2013-10-25 09:08:21 +01:00
}