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/f3c05bcddd5db130300e5ebaf27d355dd44...