That may be true, but I think that the dependencies and composition of a board can and should be defined in the Kconfig. Since the board that are in tree in NuttX are standard, it would need to be extensible to support custom HW and the use cases you list. But again that is not compile time, it is link time and there are dependencies that need to be matained.
*From:* Fotis Panagiotopoulos [mailto:f.j.pa...@gmail.com] *Sent:* Friday, March 26, 2021 9:46 AM *To:* dev@nuttx.apache.org *Subject:* Re: How to ensure HEAP will not overlap static DMA buffer? Oh, sorry. Attached again as .txt. Is it OK now? > A tool that takes the Kconfig + chip+ memorymap and make a linker include > file and the config code for the heap may be the way to go. I am pretty sure that a "tool" will not be able to cover all use cases. Over the years I had to make custom scripts to account for: * Bootloaders * Binary blops * Firmware headers * ROM files * DMA buffers * External memories etc etc.. Do you believe that a tool can be made that can handle everything? Στις Παρ, 26 Μαρ 2021 στις 6:37 μ.μ., ο/η David Sidrane < david.sidr...@nscdg.com> έγραψε: I am just thinking out load... I agree this has to come from one place. But I do think it is just the linker file. Currently we have The arch memroymap h files have the base addresses, sizes - This is the Reference manuals counterpart, it covers all the sub members of the chips) The chip.h files that has sizes - This is the Data Sheet counterpart, it covers one or more of the sub members of the chips) The Kconfig - More flexible from a users stand point. The heap c files - buried semantics - not good linker file - the boards usage specific. I like using the linker file, but Kconfig is build time - no file modification Just moving things to the linker file does not fix the ordering or adding issues. (it is link time not compile time) A tool that takes the Kconfig + chip+ memorymap and make a linker include file and the config code for the heap may be the way to go. David -----Original Message----- From: Fotis Panagiotopoulos [mailto:f.j.pa...@gmail.com] Sent: Friday, March 26, 2021 9:17 AM To: dev@nuttx.apache.org Subject: Re: How to ensure HEAP will not overlap static DMA buffer? 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 >
