I face similar problems (with a different use case) on an STM32F4. The thing is that although the linker script belongs to the board logic and thus it is freely customizable, the heap regions are hard-coded in the arch files.
So, I started working on PR #2277 ( https://github.com/apache/incubator-nuttx/pull/2277), but unfortunately I had to pause the development on this. The idea is similar to what you describe here. Everything can be defined in the linkerscript (addresses, order, sizeses etc). I was thinking a lot of any alternatives on this. I came to the conclusion that Kconfig is the wrong tool for this job. You lose all compile-time (and CI) checks and can easily be misconfigured. I am also afraid that we will end up with a few dozen "hacks" like above or like STM32_CCMEXCLUDE (I never liked this option....). And no matter what you do, you will never be able to satisfy any crazy memory mappings that any project may need. A similar issue to this is Issue #2001 ( https://github.com/apache/incubator-nuttx/issues/2001). This was my first crash while trying out NuttX :) In short, there is the assumption that the main stack will always reside between BSS and Heap, again being very restrictive. Στις Παρ, 26 Μαρ 2021 στις 5:46 μ.μ., ο/η Nathan Hartman < hartman.nat...@gmail.com> έγραψε: > On Fri, Mar 26, 2021 at 11:41 AM Gregory Nutt <spudan...@gmail.com> wrote: > > > Missing bit of logic: > > > > >> Speaking of the linker, is there a way to use a combination of the > > >> linker script and __attribute__ incantations in the code to detect > > >> automatically the size that g_sram4_reserve should be and entirely > > >> eliminate the need for the user to specify the start and end of each > > >> region in Kconfig? > > > > > > Are you thinking of something like this in the linker script: > > > > > > .sram4_reserve : > > > { > > > _sram4_reserve_begin = ABSOLUTE(.); > > > *(.sram4) > > > _sram4_reserve_end = ABSOLUTE(.); > > > } > > > > > > And in the C code: > > > > > We need to lie to C and tell it what to think those symbols are: > > > > EXTERN const uint32_t _sram4_reserve_begin > > EXTERN const uint32_t _sram4_reserve_begin > > > > Ah, yes, otherwise those symbols would be undefined. Later the linker will > resolve them to the correct addresses. > > > > #define SRAM4_RESERVE_BEGIN &_sram4_reserve_begin > > > #define SRAM4_RESERVE_END &_sram4_reserve_end > > > > > > The implied size depends on the size of all .sram4 sections. I assume > > > this would be positioned at the beginning of SRAM4 and the size of the > > > region that could be added to the heap would be SRAM4_RESERVE_END > > > through SRAM_END. > > > > > You can see this same kind of thing in, for example, > > arch/arm/src/common/arm_internal.h > > > > Great! Thanks > > Nathan >
