Date: Wed, 31 Jan 2024 10:12:03 -0800 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD ARM List <freebsd-arm@freebsd.org> Subject: RPi5 and EDK2 ( https://github.com/worproject/rpi5-uefi ): USB-is-broken notes Message-ID: <C28D4CE6-DA35-4FA5-83E3-1BAC0412FA18@yahoo.com> References: <C28D4CE6-DA35-4FA5-83E3-1BAC0412FA18.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
=E2=80=A2 Flashed stock RPI OS and checked USB -> OK
=E2=80=A2 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
=E2=80=A2 Changed the generic-xhci device back to snps,dwc3 with =
original quirks, in case the VPU FW didn't take care of that -> =
Corruption
=E2=80=A2 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:
=E2=80=A2 full RP1 PCIe in Linux with FDT uses MSIs
=E2=80=A2 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
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C28D4CE6-DA35-4FA5-83E3-1BAC0412FA18>