From eb731abeb8caeaddabf692990068444866f9c949 Mon Sep 17 00:00:00 2001 From: Immo Birnbaum Date: Tue, 8 Aug 2023 09:46:26 +0200 Subject: [PATCH] doc: release-notes: document aarch32 cortex_a_r linker command file changes Document the changes implemented in #60368: * Placement of the .bss and .noinit sections at the end of the binary so that large zero-/uninitialized data structures such as heaps, arrays etc. don't have to be padded in the resulting binary. * Location of the z_mapped_start marker: prevents the assignment of the single 4k-page wide .vectors section right at the RAM base address as dynamic memory by the MMU at run-time. Instead of pointing to the start of the subsequent .text section, the z_mapped_start marker now covers all the data contained within the binary that ends up in RAM. Signed-off-by: Immo Birnbaum --- doc/releases/release-notes-3.5.rst | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/doc/releases/release-notes-3.5.rst b/doc/releases/release-notes-3.5.rst index 8ad4f5f7d14e9b..880664da195d14 100644 --- a/doc/releases/release-notes-3.5.rst +++ b/doc/releases/release-notes-3.5.rst @@ -58,10 +58,33 @@ Kernel Architectures ************* -* ARM +* ARC * ARM + * Fixed the Cortex-A/-R linker command file: + + * The sections for zero-initialized (.bss) and uninitialized (.noinit) data + are now the last sections within the binary. This allows the linker to just + account for the required memory, but not having to actually include large + empty spaces within the binary. With the .bss and .noinit sections placed + somewhere in the middle of the resulting binary, as was the case with + previous releases, the linker had to pad the space for zero-/uninitialized + data due to subsequent sections containing initialized data. The inclusion + of large zero-initialized arrays or statically defined heaps reflected + directly in the size of the resulting binary, resulting in unnecessarily + large binaries, even when stripped. + * Fixed the location of the z_mapped_start address marker to point to the + base of RAM instead of to the start of the .text section. Therefore, the + single 4k page .vectors section, which is located right at the base of RAM + before the .text section and which was previously not included in the + mapped memory range, is now considered mapped and unavailable for dynamic + memory mapping via the MMU at run-time. This prevents the 4k page containing + the exception vectors data being mapped as regular memory at run-time, with + any subsequently mapped pages being located beyond the permanently mapped + memory regions (beyond z_mapped_end), resulting in non-contiguous memory + allocation for any first memory request greater than 4k. + * ARM64 * RISC-V