DMA memory data race?

Stefan Kalkowski stefan.kalkowski at
Mon Sep 27 09:38:16 CEST 2021

Hello Stefan,

On Fri, Sep 24, 2021 at 11:06:27AM +0200, Stefan Thöni wrote:
> Hello Genodians
> While implementing our driver for the i.MX8 CAAM device, I experience
> some problems with DMA using the following steps:
> a) Allocate DMA memory using alloc_dma_buffer from the platform session.
> b) Fill the DMA memory with some data.
> c) Tell the hardware to work with the data by register write.
> d) Look at the result code provided by the hardware.
> I observe an error result code from the hardware indicating the DMA read
> failed or returned the wrong data, unless I insert some time-consuming
> code (like a call to Genode::log or just a burning cycles) between b)
> and c).

Did you inserted a data-memory barrier in between b and c? This is
mandatory if you want all data-writes to succeed before signaling the
hardware that the DMA buffer is ready.

> I think the problem could be a data race between the CPU filling the RAM
> and the device reading it by DMA. On the other hand, I provide the
> UNCACHED argument to alloc_dma_buffer which should, if my understanding
> is correct, be reflected in the page table disabling the cache thus
> avoiding this problem.

You are right, as long as the DMA memory is allocated as uncached
memory, you shouldn't observe caching issues. Otherwise, this would
have been my first guess.


> What am I missing?
> Kind regards
> Stefan

pub ECDSA 512/D4E372A6 2021-03-03 Stefan Thöni <stefan.thoeni at>
> sub  ECDH 512/04378363 2021-03-03

> _______________________________________________
> Genode users mailing list
> users at

Stefan Kalkowski
Genode labs |

More information about the users mailing list