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 4128659076
("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>
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>
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>
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 c452ba159c ("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>
These are mostly used to collect data from special structure,
and repeated in many linker scripts.
To differentiate the alignment size between aarch32/aarch64, I added
a new macro STRUCT_ALIGN.
While I moved the PMF_SVC_DESCS, I dropped #if ENABLE_PMF conditional.
As you can see in include/lib/pmf/pmf_helpers.h, PMF_REGISTER_SERVICE*
are no-op when ENABLE_PMF=0. So, pmf_svc_descs and pmf_timestamp_array
data are not populated.
Change-Id: I3f4ab7fa18f76339f1789103407ba76bda7e56d0
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
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>
This patch introduces explicit linker variables to mark the start and
end of the per-cpu bakery lock section to help bakery_lock_normal.c
calculate the size of the section. This patch removes the previously
used '__PERCPU_BAKERY_LOCK_SIZE__' linker variable to make the code
uniform across GNU linker and ARM linker.
Change-Id: Ie0c51702cbc0fe8a2076005344a1fcebb48e7cca
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
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: e0ea0928d5 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a2 ("drivers: add tzc380 support").
This problem was introduced in commit 4ecca33988 ("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>
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>
When the MMU is enabled and the translation tables are mapped, data
read/writes to the translation tables are made using the attributes
specified in the translation tables themselves. However, the MMU
performs table walks with the attributes specified in TCR_ELx. They are
completely independent, so special care has to be taken to make sure
that they are the same.
This has to be done manually because it is not practical to have a test
in the code. Such a test would need to know the virtual memory region
that contains the translation tables and check that for all of the
tables the attributes match the ones in TCR_ELx. As the tables may not
even be mapped at all, this isn't a test that can be made generic.
The flags used by enable_mmu_xxx() have been moved to the same header
where the functions are.
Also, some comments in the linker scripts related to the translation
tables have been fixed.
Change-Id: I1754768bffdae75f53561b1c4a5baf043b45a304
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
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>
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>
Introduce new build option ENABLE_STACK_PROTECTOR. It enables
compilation of all BL images with one of the GCC -fstack-protector-*
options.
A new platform function plat_get_stack_protector_canary() is introduced.
It returns a value that is used to initialize the canary for stack
corruption detection. Returning a random value will prevent an attacker
from predicting the value and greatly increase the effectiveness of the
protection.
A message is printed at the ERROR level when a stack corruption is
detected.
To be effective, the global data must be stored at an address
lower than the base of the stacks. Failure to do so would allow an
attacker to overwrite the canary as part of an attack which would void
the protection.
FVP implementation of plat_get_stack_protector_canary is weak as
there is no real source of entropy on the FVP. It therefore relies on a
timer's value, which could be predictable.
Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
Introduce zeromem_dczva function on AArch64 that can handle unaligned
addresses and make use of DC ZVA instruction to zero a whole block at a
time. This zeroing takes place directly in the cache to speed it up
without doing external memory access.
Remove the zeromem16 function on AArch64 and replace it with an alias to
zeromem. This zeromem16 function is now deprecated.
Remove the 16-bytes alignment constraint on __BSS_START__ in
firmware-design.md as it is now not mandatory anymore (it used to comply
with zeromem16 requirements).
Change the 16-bytes alignment constraints in SP min's linker script to a
8-bytes alignment constraint as the AArch32 zeromem implementation is now
more efficient on 8-bytes aligned addresses.
Introduce zero_normalmem and zeromem helpers in platform agnostic header
that are implemented this way:
* AArch32:
* zero_normalmem: zero using usual data access
* zeromem: alias for zero_normalmem
* AArch64:
* zero_normalmem: zero normal memory using DC ZVA instruction
(needs MMU enabled)
* zeromem: zero using usual data access
Usage guidelines: in most cases, zero_normalmem should be preferred.
There are 2 scenarios where zeromem (or memset) must be used instead:
* Code that must run with MMU disabled (which means all memory is
considered device memory for data accesses).
* Code that fills device memory with null bytes.
Optionally, the following rule can be applied if performance is
important:
* Code zeroing small areas (few bytes) that are not secrets should use
memset to take advantage of compiler optimizations.
Note: Code zeroing security-related critical information should use
zero_normalmem/zeromem instead of memset to avoid removal by
compilers' optimizations in some cases or misbehaving versions of GCC.
FixesARM-software/tf-issues#408
Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
Masahiro Yamada
Varun Wadekar
Antonio Nino Diaz
Roberto Vargas
dp-arm
Douglas Raillard
Leon Chen