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
> > >> modifi
Forgot to mention that this applies to GP (general purpose) regions.
Others, like BSS (that you mentioned), DATA, the stacks etc, must always be
there and be unique.
On Fri, Mar 26, 2021, 21:18 Nathan Hartman wrote:
> On Fri, Mar 26, 2021 at 2:34 PM Nathan Hartman
> wrote:
> > FYI my work (in
ime - 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
> includ
On Fri, Mar 26, 2021 at 2:34 PM Nathan Hartman wrote:
> FYI my work (in progress) on this is in the branch
> "stm32h7-fix-heap-clobber" in my fork, in case anyone wants to look...
>
> https://github.com/hartmannathan/incubator-nuttx/tree/stm32h7-fix-heap-clobber
Ok, created PR-3198
r 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-
>&
On Fri, Mar 26, 2021 at 11:21 AM Gregory Nutt wrote:
> > So, if I understand correctly, anyone can declare a static buffer like this:
> >
> > static uint8_t g_spi6_txbuf[SPI6_DMABUFSIZE_ADJUSTED]
> > SPI6_DMABUFSIZE_ALGN locate_data(".sram4");
> >
> > and automatically the heap will not overlap
I really don't see any simpler and more flexible way to define the memory
map than linker scripts.
This is the purpose of the script itself.
On the other hand though, I cannot argue against a tool that I haven't seen
yet...
In any case, I think that we agree that step no 1 is always the same.
On Fri, Mar 26, 2021 at 12:46 PM Fotis Panagiotopoulos
wrote:
> Oh, sorry.
> Attached again as .txt. Is it OK now?
Yes, the files went through this time. Thanks! More below...
> > A tool that takes the Kconfig + chip+ memorymap and make a linker include
> > file and the config code for the heap
,
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
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
>
-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
On Fri, Mar 26, 2021 at 12:25 PM Fotis Panagiotopoulos
wrote:
>
> I have attached the linkerscripts that I was using in some older projects.
The attachment(s) did not come through. Could you resend them with a
.txt extension to get around the filter?
Thanks,
Nathan
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
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 (
On Fri, Mar 26, 2021 at 11:41 AM Gregory Nutt 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
>
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
So, if I understand correctly, anyone can declare a static buffer like this:
static uint8_t g_spi6_txbuf[SPI6_DMABUFSIZE_ADJUSTED]
SPI6_DMABUFSIZE_ALGN locate_data(".sram4");
and automatically the heap will not overlap it?
Yes provided that:
1. The .sram_resevere section is origined at
On Fri, Mar 26, 2021 at 11:14 AM Gregory Nutt wrote:
> > 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
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
On Fri, Mar 26, 2021 at 1:08 AM Gregory Nutt wrote:
> >> Just don't add it to the primary heap: Add the region below and the
> >> region above the DMA buffers with two calls to mm_addregion().
> >>
> >> addregion (DMABUF_END, SRAM4_END - DMABUF_END, "SRAM4-A");
> >>
> >> addregion (SRAM4_START,
Hi Nathan,
I just ran into this, this week on all the H7 boards in PX4.
This was broken by
https://github.com/apache/incubator-nuttx/pull/459/files#diff-8e09d7a85a1cc6cc65e0bb43d7aa751e3caaec9f9d5e824f9b741a1487ec9199L117-L138
I did not catch the implication of that change at the time.
The
Just don't add it to the primary heap: Add the region below and the
region above the DMA buffers with two calls to mm_addregion().
addregion (DMABUF_END, SRAM4_END - DMABUF_END, "SRAM4-A");
addregion (SRAM4_START, DMABUF_START- SRAM4_START, "SRAM4-B");
Where should I call mm_addregion()
On Thu, Mar 25, 2021 at 7:54 PM Gregory Nutt wrote:
>
> Just don't add it to the primary heap: Add the region below and the
> region above the DMA buffers with two calls to mm_addregion().
>
> addregion (DMABUF_END, SRAM4_END - DMABUF_END, "SRAM4-A");
>
> addregion (SRAM4_START, DMABUF_START-
Just don't add it to the primary heap: Add the region below and the
region above the DMA buffers with two calls to mm_addregion().
addregion (DMABUF_END, SRAM4_END - DMABUF_END, "SRAM4-A");
addregion (SRAM4_START, DMABUF_START- SRAM4_START, "SRAM4-B");
You can also create a different heap
24 matches
Mail list logo
