-
Masahiro Yamada authored
Only BL1 specifies '.' in the address field of the stacks section. Commit 4f59d835 ("Make BL1 RO and RW base addresses configurable") added '.' on purpose but the commit message does not help to understand why. This commit gets rid of it in order to factor out the stacks section into include/common/bl_common.ld.h I compared the build result for PLAT=qemu. 'aarch64-linux-gnu-nm -n build/qemu/release/bl1/bl1.elf' will change as follows: @@ -336,8 +336,8 @@ 000000000e04e0e0 d max_log_level 000000000e04e0e4 D console_state 000000000e04e0e5 D __DATA_RAM_END__ -000000000e04e0e5 B __STACKS_START__ 000000000e04e100 b platform_normal_stacks +000000000e04e100 B __STACKS_START__ 000000000e04f100 b bl1_cpu_context 000000000e04f100 B __BSS_START__ 000000000e04f100 B __STACKS_END__ After this change, __STACKS_START__ will match to platform_normal_stacks, and I think it makes more sense. 'aarch64-linux-gnu-objdump -h build/qemu/release/bl1/bl1.elf' will change as follows: @@ -9,11 +9,11 @@ CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 000000e5 000000000e04e000 0000000000004a60 0001e000 2**4 CONTENTS, ALLOC, LOAD, DATA - 3 stacks 0000101b 000000000e04e0e5 000000000e04e0e5 0001e0e5 2**6 + 3 stacks 00001000 000000000e04e100 0000000000004b45 0001e100 2**6 ALLOC - 4 .bss 000007e0 000000000e04f100 000000000e04f100 0001e0e5 2**5 + 4 .bss 000007e0 000000000e04f100 0000000000004b50 0001f100 2**5 ALLOC - 5 xlat_table 00006000 000000000e050000 000000000e050000 0001e0e5 2**12 + 5 xlat_table 00006000 000000000e050000 0000000000004b45 00020000 2**12 ALLOC 6 coherent_ram 00000000 000000000e056000 000000000e056000 0001f000 2**12 CONTENTS Sandrine pointed me to a useful document [1] to understand why LMAs of stacks, .bss, and xlat_table section have changed. Before this patch, they fell into this scenario: "If the section has a specific VMA address, then this is used as the LMA address as well." With this commit, the following applies: "Otherwise if a memory region can be found that is compatible with the current section, and this region contains at least one section, then the LMA is set so the difference between the VMA and LMA is the same as the difference between the VMA and LMA of the last section in the located region." Anyway, those three sections are not loaded, so the LMA changes will not be a problem. The size of bl1.bin is still the same. QEMU still boots successfully with this change. A good thing is, this fixes the error for the latest LLD. If I use the mainline LLVM, I see the following error. The alignment check will probably be included in the LLVM 11 release, so it is better to fix it now. $ PLAT=qemu CC=clang CROSS_COMPILE=aarch64-linux-gnu- [ snip ] ld.lld: error: address (0xe04e0e5) of section stacks is not a multiple of alignment (64) make: *** [Makefile:1050: build/qemu/release/bl1/bl1.elf] Error 1 [1]: https://sourceware.org/binutils/docs/ld/Output-Section-LMA.html#Output-Section-LMA Change-Id: I3d2f3cc2858be8b3ce2eab3812a76d1e0b5f3a32 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
b9f7b57d