32-bit DMA limit for devices (and drivers)

Andre Przywara andre.przywara at arm.com
Fri Apr 30 13:21:21 CEST 2021


We now see the first Allwinner devices [1] having DRAM located above
4GB in address space (4GB DRAM starting at 1GB). After one fix[2]
this works somewhat fine, but the sun8i-emac network device is still
limited to 32-bit DMA addresses. With U-Boot relocating itself (plus
stack and heap) to the end of DRAM, it now runs completely beyond 4GB
on those machines, so not giving pure 32-bit addresses for buffers
In Linux we handle this easily by just keeping the default DMA
mask at 32 bits, and letting the DMA framework deal with the nasty

I was wondering how this should be handled in U-Boot? The straight
forward solution would be:
- Let the driver allocate the RX and TX buffers separately, placing them
  below 4GB in the address space (using lmb_reserve(), I guess?)
- Use those RX buffers and hand the addresses back to the upper layers.
- We already copy TX packets, so this would also be covered, in this
  situation. Other drivers might need to introduce copying.

This sounds like a common problem, so I was wondering if there is a
more generic solution to this? Maybe there are already platforms or
devices affected? Or should the whole heap and stack be moved below 4GB
(if this is easily possible)?
In our case we make the buffers part of our priv struct, so should
there be an option to let the priv_auto allocation come from below 4GB?

Grateful for any input on this!


[1] https://linux-sunxi.org/X96_Mate
[2] https://lists.denx.de/pipermail/u-boot/2021-April/448327.html

More information about the U-Boot mailing list