| 0a0a7a9a | 26-Mar-2020 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
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
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>
show more ...
|
| 68c76088 | 06-Feb-2020 |
Alexei Fedorov <Alexei.Fedorov@arm.com> |
Make PAC demangling more generic
At the moment, address demangling is only used by the backtrace functionality. However, at some point, other parts of the TF-A codebase may want to use it. The 'dema
Make PAC demangling more generic
At the moment, address demangling is only used by the backtrace functionality. However, at some point, other parts of the TF-A codebase may want to use it. The 'demangle_address' function is replaced with a single XPACI instruction which is also added in 'do_crash_reporting()'.
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com> Change-Id: I4424dcd54d5bf0a5f9b2a0a84c4e565eec7329ec
show more ...
|
| 511046ea | 17-Jan-2020 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
BL31: discard .dynsym .dynstr .hash sections to make ENABLE_PIE work
When I tried ENABLE_PIE for my PLAT=uniphier platform, BL31 crashed at its entry. When it is built with ENABLE_PIE=1, some sectio
BL31: discard .dynsym .dynstr .hash sections to make ENABLE_PIE work
When I tried ENABLE_PIE for my PLAT=uniphier platform, BL31 crashed at its entry. When it is built with ENABLE_PIE=1, some sections are inserted before the executable code.
$ make PLAT=uniphier CROSS_COMPILE=aarch64-linux-gnu- ENABLE_PIE=1 bl31 $ aarch64-linux-gnu-objdump -h build/uniphier/release/bl31/bl31.elf | head -n 13
build/uniphier/release/bl31/bl31.elf: file format elf64-littleaarch64
Sections: Idx Name Size VMA LMA File off Algn 0 .dynsym 000002a0 0000000081000000 0000000081000000 00010000 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .dynstr 000002a0 00000000810002a0 00000000810002a0 000102a0 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 00000124 0000000081000540 0000000081000540 00010540 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 ro 0000699c 0000000081000664 0000000081000664 00010664 2**11 CONTENTS, ALLOC, LOAD, CODE
The previous stage loader generally jumps over to the base address of BL31, where no valid instruction exists.
I checked the linker script of Linux (arch/arm64/kernel/vmlinux.lds.S) and U-Boot (arch/arm/cpu/armv8/u-boot.lds), both of which support relocation. They simply discard those sections.
Do similar in TF-A too.
Change-Id: I6c33e9143856765d4ffa24f3924b0ab51a17cde9 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| f8578e64 | 18-Oct-2018 |
Samuel Holland <samuel@sholland.org> |
bl31: Split into two separate memory regions
Some platforms are extremely memory constrained and must split BL31 between multiple non-contiguous areas in SRAM. Allow the NOBITS sections (.bss, stack
bl31: Split into two separate memory regions
Some platforms are extremely memory constrained and must split BL31 between multiple non-contiguous areas in SRAM. Allow the NOBITS sections (.bss, stacks, page tables, and coherent memory) to be placed in a separate region of RAM from the loaded firmware image.
Because the NOBITS region may be at a lower address than the rest of BL31, __RW_{START,END}__ and __BL31_{START,END}__ cannot include this region, or el3_entrypoint_common would attempt to invalidate the dcache for the entire address space. New symbols __NOBITS_{START,END}__ are added when SEPARATE_NOBITS_REGION is enabled, and the dcached for the NOBITS region is invalidated separately.
Signed-off-by: Samuel Holland <samuel@sholland.org> Change-Id: Idedfec5e4dbee77e94f2fdd356e6ae6f4dc79d37
show more ...
|
| 3f3c341a | 16-Sep-2019 |
Paul Beesley <paul.beesley@arm.com> |
Remove dependency between SPM_MM and ENABLE_SPM build flags
There are two different implementations of Secure Partition management in TF-A. One is based on the "Management Mode" (MM) design, the oth
Remove dependency between SPM_MM and ENABLE_SPM build flags
There are two different implementations of Secure Partition management in TF-A. One is based on the "Management Mode" (MM) design, the other is based on the Secure Partition Client Interface (SPCI) specification. Currently there is a dependency between their build flags that shouldn't exist, making further development harder than it should be. This patch removes that dependency, making the two flags function independently.
Before: ENABLE_SPM=1 is required for using either implementation. By default, the SPCI-based implementation is enabled and this is overridden if SPM_MM=1.
After: ENABLE_SPM=1 enables the SPCI-based implementation. SPM_MM=1 enables the MM-based implementation. The two build flags are mutually exclusive.
Note that the name of the ENABLE_SPM flag remains a bit ambiguous - this will be improved in a subsequent patch. For this patch the intention was to leave the name as-is so that it is easier to track the changes that were made.
Change-Id: I8e64ee545d811c7000f27e8dc8ebb977d670608a Signed-off-by: Paul Beesley <paul.beesley@arm.com>
show more ...
|