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>