DMA plan on the Agilex5
- 7 months ago
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.