Fotis, you define many symbols(e.g. __gp_ram?_bss_start__) in your linker script. My question is how the common init code knows the number of these symbols?
On Fri, Mar 26, 2021 at 9:46 AM Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote: > 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 >> > >> >
