Lichee Pi 4A GMAC driver

[Gilbert Gilbs]

Hi,

I'm the happy owner of a Lichee Pi 4A by Sipeed, a RISC-V SBC based on the
TH1520 SoC by Alibaba. Very basic support for this board was added in 5f3a7fdb.
For now it's just able to chainload mainline U-Boot from vendor's fork of
U-Boot.

As an experiment, I started porting the glue layer for the GMAC into U-Boot,
taking inspiration from the implementation that got merged into the net branch
of Linux recently[1]. I eventually got the driver in a working state, but I had
to rely on two suspicious workarounds that I'm unsure how to address. I'd like
to discuss them here first before submitting a patch (if you're interested):

1. The designware driver can only read/write RX/TX DMA buffers from/to the 4GB
   address space, and I guess this is a hardware limitation. After chainloading
   U-Boot, these buffers are consistently allocated beyond the 4GB space making
   the driver inoperative. Is there a generic way of "forcing" U-Boot to
   allocate these DMA buffers in the 4GB address space? I believe it should be
   possible by dynamically allocating the buffers and using something like
   LMBs, but that sounds like a big and risky undertaking. For the time being,
   I've arbitrarily reduced the amount of RAM in the FDT to circumvent the
   issue, but it is completely not acceptable.

2. Some RX packets are corrupted because U-Boot occasionally modifies packets
   in-place, and those changes are flushed from the CPU data cache later, when
   the same RX buffer gets recycled. My current fix consists in invalidating
   the dcache of the whole buffer when freeing the packet in the designware
   driver. While this works fine, I was wondering if this is a common thing to
   do in drivers relying on DMA, and if there is a more efficient/common way to
   tackle this problem. I'm not aware of non-cached memory on this device that
   we could use.

Thank you in advance,
Nils

[1] https://github.com/torvalds/linux/commit/f3c05bcddd5db130300e5ebaf27d355dd441d7e6