How should DMA-inaccessible TCM be handled on AMD Versal RPU (SDHC / MMC)?

[takumiando]

Hello Zephyr community,

I’m working on enabling the SD/MMC stack on AMD Versal RPU (Cortex-R5F) and I would like to ask for guidance on the correct upstream approach for handling DMA buffers on this platform.

Background / Hardware constraints

On Versal RPU, the memory map has a special characteristic:

• The lowest 128 KB of the RAM address space is overlaid by TCM
• From the RPU’s point of view, normal loads/stores work as expected
• However, the SDHC controller cannot access TCM
• As a result, any DMA buffer placed in the TCM region causes SDHC DMA to fail

This is not a cache-coherency issue; it is a hard accessibility limitation of the SDHC DMA master.

Problem observed in Zephyr

In the current Zephyr SD/MMC stack:

• DMA buffers may be allocated implicitly in normal .bss / .data
• On Versal RPU, this often ends up in TCM, especially for:
  • struct sd_data (driver private state)
  • MMC internal buffers (e.g. EXT_CSD handling via card->card_buffer[])
• When such buffers are used for DMA, the transfer fails or corrupts data

I was able to confirm this by printing buffer addresses; failing DMA transfers consistently used TCM addresses.

What works so far

For experimentation, I managed to make the SD/MMC tests pass by:

• Placing driver-internal DMA objects (ADMA2 descriptor table, bounce buffers) into OCM(.ocm_data)
• Adding a bounce buffer in the SDHC driver specifically for EXT_CSD (512B) transfers, because the MMC stack passes a TCM-backed buffer there

However, this raises design questions.

The design dilemma

From a system perspective:

• Requiring all callers (MMC stack, filesystem, applications) to always allocate DMA buffers outside TCM (e.g. OCM) is not realistic
• TCM is the default and preferred RAM for real-time code on RPU
• Auditing and annotating every buffer in the upper layers does not scale

On the other hand:

• Having opcode-specific bounce logic in the SDHC driver (e.g. “if CMD8 then bounce”) feels hacky and MMC-specific
• Automatically bouncing all DMA transfers would hurt performance and memory usage

Questions to the community

1. What is the preferred Zephyr approach for handling DMA-inaccessible memory regions like TCM?
2. Should this be handled:

• in the SDHC driver (e.g. generic DMA bounce support)?
• in the MMC/SD stack (e.g. EXT_CSD-specific DMA-safe buffers)?
• or via a generic DMA API / memory-region annotation mechanism?

3. Is there an existing precedent in Zephyr for SoCs where:

• CPU can access a memory region
• but DMA masters cannot?

Any guidance on how this should be addressed in an upstream-friendly way would be greatly appreciated.

Thanks in advance,