Forum Discussion
ContributorDMA plan on the Agilex5
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.
Occasional ContributorHello
I couldn't find any example design exactly as the one you want to create, but I was able to create a design which is based on our Agilex 5 GHRD. This design is very similar to the CONFIG B that you have. The only differences is that I connect the OCRs blocks to the HPS2FPGA bridge instead of the LWHPS2FPGA bridges as this is how we do it in our GHRD. Also we keep the interrupt in the MSGDMA disconnected.
I am still trying to verify the functionality of the design from Linux created also from the GSRD of the Agilex 5 device (Premium Dev Kit).
To verify this I am using the devmem2 command to write to the OCRs and also to the registers in the MSGDMA. So far I can confirm the writing/reading to/from the OCRs works fine. The configuration that I am using the MSGDMA component is the same than the one provided in the Bridges examples that I shared earlier.
New ContributorHi Ronaldo,
Thanks for your input!
I look forward to hearing if you can verify your design.
Many thanks!
- RolandoS_Altera
Hello
I was able to validate the move of a set of data in read OCRAM to the write OCRAM through the MSGDMA using the U-Boot commands (this is based on the bridge example page that I shared earlier). I still have not been able to exercise this it in Linux.
The snipet of how I tested this in U-Boot is the following:
#MEMORY LOCATIONS
#read_ocr=0x40000000
#write_ocr=0x40040000#msgdma_descriptorlave=0x20020000
#msgdma_csr=0x20020020
#msgdma_response=0x20020040#msgdma offsets
#msgdma_csr_control=0x4
#msgdma_descriptorlave_read_high=0x14
#msgdma_descriptorlave_write_low=0x4
#msgdma_descriptorlave_write_high=0x18
#msgdma_descriptorlave_length=0x8
#msgdma_descriptorlave_burst=0xc
#msgdma_descriptorlave_control=0x1csetenv autoload no
dhcp
setenv serverip 10.244.157.112tftp ${loadaddr} ghrd_a5ed065bb32ae6sr0.core.rbf
bridge disable
fpga load 0 ${loadaddr} ${filesize}
bridge enable# Read SysID (should read 0xACD5CAFE)
md 0x20010000 1
# Write to Read OCR
mw 0x40000000 0xcafecafe 0x10
# Check 1st set of data
md 0x40000000 4
# Stop dispatcher
mw 0x20020024 0x1
# Stop descriptors
mw 0x20020024 0x20
# Reset Dispatcher
mw 0x20020024 0x2# Write dma_read_pointer_low
mw 0x20020000 0x40000000
# Write dma_read_pointer_high
mw 0x20020014 0x0
# Write dma_write_pointer_low
mw 0x20020004 0x40040000
# Write dma_write_pointer_low
mw 0x20020018 0x0
# Write length in bytes 512
mw 0x20020008 0x200
# Write Burst counts 32, sequence number = 1
mw 0x2002000c 0x20200001# Check status
md 0x20020020 1# Control, wait for resp
mw 0x2002001c 0x02000000
sleep 1
# Control, wait for resp and go
mw 0x2002001c 0x82000000# Check status (Should read 0x2)
md 0x20020020 1# Read back (should read 0xcafecafe in each location)
md 0x40040000 10
