RPi5 and EDK2 ( https://github.com/worproject/rpi5-uefi ): USB-is-broken notes

QUOTE
USB is unreliable and may cause data corruption on all supported OSes. We're currently investigating this issue, see: #3.
END QUOTE

So what I've reported for FreeBSD is not unique.

The best details for now (from that #3):

QUOTE of mariobalanica :
Yep, I've recently done some testing in Linux and seen corruption there as well. Unfortunately I haven't been able to consistently reproduce it across different configurations. There were moments when I could transfer dozens of gigabytes and it would all be fine - only sometimes would it actually start corrupting data badly.

Here's what I've tried, roughly:
    • Flashed stock RPI OS and checked USB -> OK

    • Modified DTB to expose a single USB controller as generic-xhci and hide the rest of the RP1 PCIe bus, relying on the VPU FW PCIe setup (to replicate what UEFI does) -> Corruption

    • Changed the generic-xhci device back to snps,dwc3 with original quirks, in case the VPU FW didn't take care of that -> Corruption

    • Reverted all the changes -> OK

Then I recompiled the RPi kernel to add ACPI support in and booted RPi OS via EDK2. Same story: ACPI is bad, FDT is good as long as I don't do the modifications above.

EDK2 itself appears to be unaffected, all transferred data came back good.
The only notable difference (that I'm currently aware of) between exposing the full RP1 PCIe bus vs. just the XHCI controller as a simple platform device is interrupts:

    • full RP1 PCIe in Linux with FDT uses MSIs

    • XHCI platform device uses the shared legacy INTA

I suspect the RP1 XHCI edge-triggered interrupts don't translate very well to level ones. This would be bad news for ACPI, since the MSI controller here is (unsurprisingly) non-standard and we're forced to use legacy interrupts.

This might also explain why EDK2 is not affected, as it uses polling instead.
END QUOTE

===
Mark Millard
marklmi at yahoo.com