I have attached the linkerscripts that I was using in some older projects. My intention was to eventually reach NuttX to the same degree of flexibility. Maybe even use linkerscripts like this.
You can define absolutely any region that you may need, in any position and size etc etc. I have also included general-purpose regions, that helped me in cases like the above. It does not support multiple heap regions, but I guess this is a very simple change. Going further, maybe a file like rules.ld can belong to the arch itself, and have the board to only provide the STM32F42xxI.ld like file. This will greatly simplify the initial set-up of the memory map, will reduce the number of (repeated) files along the various boards, and generally make everything more maintainable, I think. Even boards of different arches will be able to retain the same format, provide the same definitions etc... For the time I have to work on some changes/fixes in syslog. I may soon be able to contribute this, but I would greatly appreciate any help. Στις Παρ, 26 Μαρ 2021 στις 6:17 μ.μ., ο/η Fotis Panagiotopoulos < f.j.pa...@gmail.com> έγραψε: > 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 >> >
