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() from?
up_addregion(). It is normally in the same file as up_allocateheap()
Right now, arm_addregion() in
arch/arm/src/stm32h7/stm32_allocateheap.c is unconditionally setting
up heap regions. I think that customizing it for my particular
situation is an ugly hack.
It is customized in all MCUs that have complex RAM maps. Using with a
Kconfig setting that defines the start and end of RAM regions. So only
the configured part of the RAM region is added to the heap.
I don't think the is ugly in the C code. It is just a change in the
naming so that the start and size start with CONFIG_
Or, I can leave the OS alone, and in my board config, set
CONFIG_MM_REGIONS = 1 so arm_addregion() does nothing; then from
somewhere (board_late_initialize()?) call mm_addregion() to customize
other regions. This also feels like an ugly hack to me.
Seems a little uglier only because other boards would have to do the same.
Option 3, I add a new Kconfig to exclude SRAM4 from the heap, as is
already being done for DTCM RAM with CONFIG_STM32H7_DTCMEXCLUDE.
Yep. I should have read futher before responding.
Option 4, I like the Granule Allocator option; If I understand
correctly, to use the granule allocator, I need to exclude SRAM4 from
the heap (like option 3) + create a g_dmaheap in .sram4, and init the
granule allocator from board init code. Is that correct?
Yes, there should be some good examples for STM32. The granule
allocator is nice because you can configure it so that each DMA region
is automatically aligned to the cache line size and automatically forced
to be multiples of the cache line size in size.
I think SPI1 thru SPI5 are unaffected because (I think) their static
allocations end up in .bss and automatically excluded from all heaps;
but because g_spi6_txbuf and g_spi6_rxbuf have locate_data(".sram4"),
they end up in the heap.
We might have other __attribute__ ((section (".insert_name_here")))
buffers in other files that suffer the same problem.
Using the granule allocate would solve that too.
