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(
Hello,
I did a simple sample code using CMake and NuttX as external library:
https://github.com/Phi-Innovations/nuttx-apps/tree/main/example-mqtt
Hope it helps.
I used MQTT-C for it, and I added the sources into my project (not into Nuttx).
It would be nice to have the library integrated into
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
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
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
https://githu
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
wrote:
> Oh, sorry.
> Attached again as .txt. Is it OK now?
>
> > A tool that takes t
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 it
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.
The
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
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
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 sc
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
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 inc
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-
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
regi
On Fri, Mar 26, 2021 at 4:26 AM David Sidrane wrote:
> As you have noted checking at build time only works for in tree
> configurations. The quick fix to add an CONFIG_..._EXCLUDE_SRAM4... (naming
> TBD) and light it in things that select BDMA to SRAM4 would a good to
> addition, and help in some
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 SRAM
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 u
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 y
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, D
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 orig
23 matches
Mail list logo
