Heap is defined in linkerscript for FLAT builds.

[fjpanag]

Summary

Currently the heap regions are hardcoded. The code makes assumptions on how the memory regions should be mapped, and calculates the boundaries according to the MCU's available memory.

This creates problems in many cases, where the uses needs a "non-standard" memory map. See issue #2002.

This PR is about refactoring the heap configuration, and have the user define the Heap in the linkerscript. That way anyone will be able to adapt the memory map to their actual needs. NuttX will be able to support any arbitrary memory configuration, and no assumptions will be made about the final application.

Impact

Linkerscripts need to be updated, so they define the new .heap region.

Testing

None yet.

---

Note! This is a draft PR, just a proposition. Please review the concept behind the changes, and not the actual changes.
I am only working on STM32 for now, and I chose STM32F4Discovery board as the "reference board" for these changes.
Nxstyle errors are ignored for the moment.

Things to do:

• Also adapt the heap configuration in PROTECTED & KERNEL builds.
• Add support for multiple heap regions.
• Add support for memories external to the MCU.
• Update all linker scripts.
• Eventually update other MCU families.

[hartmannathan]

How would you envision treating MCUs that have multiple "banks" of SRAM? (I don't know if "bank" is the correct term.) For example, a chip I use, STM32G474x, has:

• SRAM 1, 80 Kbyte at 0x20000000
• SRAM 2, 16 Kbyte at 0x20014000
• CCM SRAM, 32 Kbyte, at 0x10000000 and aliased at 0x20018000

[fjpanag]

Hi @hartmannathan,
I am sorry that there is no progress on this, but I have limited free time lately.

I am thinking of having the number of heap regions defined either in Kconfig, or in board.h.
Then, the linkerscript shall define each region as heap1, heap2 etc. Like:

   .heap1 (NOLOAD) : ALIGN(4) {
        _sheap1 = ABSOLUTE(.);
        . = ORIGIN(h1ram) + LENGTH(h1ram);
        . = ALIGN(4);
        _eheap1 = ABSOLUTE(.);
    } > h1ram

This way the user will be able to set up any memory layout that they like, with multiple heap regions in arbitrary positions.
It wouldn't matter whether each heap region lives within the same RAM bank or not.

[hartmannathan]

Hi @hartmannathan,
I am sorry that there is no progress on this, but I have limited free time lately.

Hello, @fjpanag , no worries. Thanks for your reply

[hartmannathan]

For anyone following along, a related discussion occurred in the dev@ mailing list thread "How to ensure HEAP will not overlap static DMA buffer?" started on 2021/03/25 and archived here: https://lists.apache.org/thread.html/recf2bb9043f8c9f53c10917e2adb2ec64fe35dc5e6f9a695a7ac6ecc%40%3Cdev.nuttx.apache.org%3E