ContributorDMA plan on the Agilex5
I am looking to build a very basic mSGDMA example design and test it on the Agilex-V.
The plan is to program software on the SoC (running linux), which will tell a DMA (memory-mapped to memory-mapped) to move data from one on-chip-memory block to another.
I have two ideas for a design, sketched out below:
My hope is that with design B, I might be able to:
1: use /dev/mem to read from ocm_write (record initial state)
2: use /dev/mem to write to ocm_read (write a simple pattern)
3: initiate a transfer from ocm_read to ocm_write using the DMA
4: use /dev/mem to read from ocm_write (check to see if the state has changed)
So far, I have compiled both designs A and B using only Intel IP. I have not included any custom verilog based drivers. Nothing is tested yet on hardware.
I am making this post to hopefully get some more opinions/sanity checks that this is not barking up the wrong tree - so in that respect, does this plan seem reasonable?
Many thanks!
K
Hi,
Q1: "Would this [UART firmware programming] be achievable via device tree edits?"
Not directly. The device tree (DT) describes the hardware for Linux — it’s used by the kernel to understand available peripherals like UART, memory regions, DMA, etc. It does not affect how bootloaders or firmware tools work.
In terms of UART firmware burning, DT changes won’t enable UART-based firmware flashing unless:
You're writing a custom bootloader or application that reads firmware data via UART and writes it to flash.
You use DT to mark certain memory regions as non-cached (helpful if the loader runs under Linux).
Q2: "If I understand correctly, you are saying that /dev/mem does not flush/handle cache in any way?"
Correct.
/dev/mem provides raw access to physical memory — but:It bypasses Linux’s cache coherency management.
Reads/writes using /dev/mem do not flush or invalidate the CPU cache.
This means if DMA wrote data to memory, but cache holds stale data, a read from /dev/mem may show incorrect results unless:
You manually flush/invalidate the cache in user space (not trivial).
Or you map the memory as non-cacheable (preferred approach).
Recommendations for DMA Testing with Cache Coherency:
Use dma-coherent memory:
In DT: use dma-coherent; or map memory via dma_alloc_coherent() if in kernel driver.
Mark OCM region as non-cacheable via DT:
E.g., using no-map; and specifying memory-region entries.
Avoid caching in /dev/mem mappings:
Use mmap() with O_SYNC and MAP_SHARED to minimize caching.
Flush/invalidate cache manually:
Possible from kernel space.
User-space solutions are hacky and not guaranteed.
