ARM Compiler 6.13 testing revealed linker errors pointing out
conflicting use of `__user_setup_stackheap` and
`__user_initial_stackheap` in some targets. Remove the unwanted
`__user_initial_stackheap` from the targets - the setup is
centralised in the common platform code.
Looking into this, a number of other issues were highlighted
* Almost all targets had `__initial_sp` hardcoded in assembler,
rather than getting it from the scatter file. This was behind
issue #11313. Fix this generally.
* A few targets' `__initial_sp` values did not match the scatter
file layout, in some cases meaning they were overlapping heap
space. They now all use the area reserved in the scatter file.
If any problems are seen, then there is an error in the
scatter file.
* A number of targets were reserving unneeded space for heap and
stack in their startup assembler, on top of the space reserved in
the scatter file, so wasting a few K. A couple were using that
space for the stack, rather than the space in the scatter file.
To clarify expected behaviour:
* Each scatter file contains empty regions `ARM_LIB_HEAP` and
`ARM_LIB_STACK` to reserve space. `ARM_LIB_STACK` is sized
by the macro `MBED_BOOT_STACK_SIZE`, which is set by the tools.
`ARM_LIB_HEAP` is generally the space left over after static
RAM and stack.
* The address of the end of `ARM_LIB_STACK` is written into the
vector table and on reset the CPU sets MSP to that address.
* The common platform code in Mbed OS provides `__user_setup_stackheap`
for the ARM library. The ARM library calls this during startup, and
it calls `__mbed_user_setup_stackheap`.
* The default weak definition of `__mbed_user_setup_stackheap` does not
modify SP, so we remain on the boot stack, and the heap is set to
the region described by `ARM_LIB_HEAP`. If `ARM_LIB_HEAP` doesn't
exist, then the heap is the space from the end of the used data in
`RW_IRAM1` to the start of `ARM_LIB_STACK`.
* Targets can override `__mbed_user_setup_stackheap` if they want.
Currently only Renesas (ARMv7-A class) devices do.
* If microlib is in use, then it doesn't call `__user_setup_stackheap`.
Instead it just finds and uses `ARM_LIB_STACK` and `ARM_LIB_HEAP`
itself.
For STM32 platforms that embed an OSPI IP, we're offering
a QSPI fallback support with this commit.
When OSPI is supported in mbed, we can consider adding full
OSPI support
To have the flexibilty in application; to use any of the section
(data/bss/heap) without updating linker script in every use case,
following decisions are made:
1. Fixed size and small sections moved to SRAM2 (32K)
Vectors
Crash data
Remaining section - RW / ZI
2. Large memory space should be used for variable sections
RW/ZI
Heap - (Minimum - 0x12000)
Stack - At bottom
To have the flexibilty in application; to use any of the section
(data/bss/heap) without updating linker script in every use case,
following decisions are made:
1. Fixed size and small sections moved to SRAM2 (32K)
Vectors
Crash data
Stack
Remaining section - Heap memory
2. Large memory space should be used for variable sections
Data
BSS
Heap - Remaining section
Heap is moved to the end of both sections as GCC allocates till 4K boundary,
if end of heap is not aligned to 4K, that chunk of memory will go unutilized
Instead of user defined symbols in assembly files or C files,
use linker scripts to add heap and stack - this is inconsistent
with ARM std linker scripts
--legacyalign, --no_legacyalign are deprecated from ARMC6 compiler, in order to
remove deprecated flags all linker files should strictly align to 8-byte boundary
Przemyslaw Stekiel
Martin Kojtal
Kevin Bracey
jeromecoutant
Vincent Veron
Anna Bridge
Juho Eskeli
Deepika
Marcus Chang
Ashok Rao
Lin Gao
Russ Butler
Senthil Ramakrishnan
Maciej Bocianski
adustm
Martin Kojtal
bcostm