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