There is a smart way to fix this problem I learned from the CMSIS package,
and is used in our chip for several years.
The key idea is create the array directly inside link script, like this:
.copy.table : {
_scopytable = ABSOLUTE(.);
LONG(LOADADDR(.cpram1.data))
LONG(ADDR(.cpram1.data))
LONG(ADDR(.cpram1.data) + SIZEOF(.cpram1.data))
_ecopytable = ABSOLUTE(.);
} > flash
.zero.table : {
_szerotable = ABSOLUTE(.);
LONG(_cpram0_sbss)
LONG(_cpram0_ebss)
LONG(ADDR(.cpram1.bss))
LONG(ADDR(.cpram1.bss) + SIZEOF(.cpram1.bss))
_ezerotable = ABSOLUTE(.);
} > flash
And then iterate through these tables in the startup:
https://github.com/FishsemiCode/nuttx/blob/song-u1/arch/arm/src/song/song_start.c#L56-L84
https://github.com/FishsemiCode/nuttx/blob/song-u1/arch/arm/src/song/song_start.c#L225-L237
The similar approach can be applied to the heap too.
This method can support:
1. Any humber of memory region
2. Only need provide the info in one place(link script)
3. Adjust the boundary automatically by linker
On Fri, Mar 26, 2021 at 12:25 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com>
wrote:
> In my case I define in the linkerscript all regions that "I will ever
> need", so they are always there.
> The startup code can always find the predetermined symbols.
>
> If I don't use a region, I set it to DONT_LINK. Since it's size will be 0,
> the start up code will ignore it.
>
> I know, it's not the most elegant solution, but it's simple and working. I
> cannot image a system with 50 different heap regions, so it doesn't need to
> scale.
>
> Alternatively, the number (or names) of regions can be a Make.defs list.
> Every board has a Make.defs that defines the platform specifics, so it's a
> good candidate IMO.
> (I think I have done this in the past in a similar way, but I don't have
> access to this code anymore).
>
>
> On Fri, Mar 26, 2021, 20:56 Xiang Xiao <xiaoxiang781...@gmail.com> wrote:
>
> > 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
> > >> >
> > >>
> > >
> >
>
