memory allocation for DMA (how to make bdbuf use non-cacheable region for SD card read and write reuqest)

Gedare Bloom gedare at
Wed Sep 2 13:50:02 UTC 2015

MMU/MPU settings are BSP-specific currently. You'd have to dig into
the BSP to see how it sets up the memory regions. They are normally
setup at link-time and installed early in the boot sequence and never
changed. I don't think there is a generic way to request non-cacheable
memory, but you can explicitly invalidate/flush cache (subject to CPU
support) if you know at what time you want the cache to be cleared
out, e.g. during DMA setup might work.

On Wed, Sep 2, 2015 at 9:33 AM, Chan Kim <ckim at> wrote:
> Hi, rtems users,
> this morning I found the block dev buffer from bdbuf is assigned in cacheable memory.
> (the CPU sometimes didn't see the DMA'd data from the SD card, this being affected by printk and following flushing).
> So I tried setting the page table so that the buffer coming from the bdbuf is non-cacheable, and then I could remove rtems_task_wake_after(1) at a place (because the read data from SD card is surely seen by the core) immensely reducing the processing time. (20 secs => 3 secs for file write.)
> My question is :  how come the buffer used for SD card read or write request from the bdbuf is allocated in cacheable memory? I guess there should be setting that tells bdbuf to use some area that the bsp assigned for DMA(non-cacheable). Or , maybe I should map the buffer address to non-cacheable adderss and copyit myself?(should be slow). What is the correct method?
> Thanks!
> Chan Kim
> _______________________________________________
> users mailing list
> users at

More information about the users mailing list