On Thu, Mar 25, 2021 at 7:54 PM Gregory Nutt <spudan...@gmail.com> 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- SRAM4_START, "SRAM4-B");
Where should I call mm_addregion() from?
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.
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.
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. This
seems more sensible than above, because right now, any STM32H7 build
that uses SPI6 with BDMA will have its DMA buffers (g_spi6_txbuf and
g_spi6_rxbuf) clobbering heap-allocated objects. If I add a new
Kconfig to exclude SRAM4 from the heap, I could also add compile-time
logic in arch/arm/src/stm32h7/stm32_spi.c to trigger an #error
directive if CONFIG_STM32H7_SPI6 and CONFIG_STM32H7_SPI6_DMA_BUFFER
are defined while SRAM4 is included in the heap. That could save some
poor soul a big debugging session; but it will not help if someone
(like me) creates their own DMA buffers.
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?
Other notes:
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.
I looked at SAMA5Dx as you suggested... I see in the README of
boards/arm/sama5/sama5d3x-ek/README.txt the following ominous warning:
Care must be used applied these RAM locations; the graphics
configurations use SDRAM in an incompatible way to set aside
LCD framebuffers.
It seems that's the exact issue I've run into.
Thanks,
Nathan
