michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: release-notes: document aarch32 cortex_a_r linker command file changes

Browse source 
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 <mail@birnbaum.immo>
This commit is contained in:
Immo Birnbaum 2023-08-08 09:46:26 +02:00 • committed by Fabio Baltieri
commit eb731abeb8
1 changed files with 24 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

25
doc/releases/release-notes-3.5.rst
View file

@ -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