Hi,
I have a RaspberryPi 4 where on one USB port a Sierra Wireless LTE module (EM7455) is attached via an PCIe-to-USB adapter. The boot image I use gets built by Yocto with the help of poky (kirkstone) and meta-raspberry (beside a few other layers) which incorporates U-Boot 22.01.
When I apply power to the board it will come up until scanning USB devices (for potential boot devices), but then throw a BUG end reset the board. This continues as long as the modem is unplugged. The exact error message is:
scanning bus xhci_pci for devices... WARN halted endpoint, queuing URB anyway. Unexpected XHCI event TRB, skipping... (3af519b0 00000004 13000000 02008401) BUG at drivers/usb/host/xhci-ring.c:503/abort_td()! BUG! resetting ...
Some internet research brought up a patch (1) for drivers/usb/host/xhci-ring.c where halted devices simply get ignored during enumeration:
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index acf437104a..6d995f446e 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -227,7 +227,8 @@ static int prepare_ring(struct xhci_ctrl *ctrl, struct xhci_ring *ep_ring, puts("WARN waiting for error on ep to be cleared\n"); return -EINVAL; case EP_STATE_HALTED: - puts("WARN halted endpoint, queueing URB anyway.\n"); + puts("WARN halted endpoint.\n"); + return -EPIPE; case EP_STATE_STOPPED: case EP_STATE_RUNNING: debug("EP STATE RUNNING.\n");
The driver file itself stems from the Linux sources, so I'm pretty sure that it is correct in that context. Even though I'm not really into USB stuff and therefore I cannot not really follow the discussion for the proposed change, in my eyes the patch could be reasonable for U-Boot nevertheless given that a) in my experience driver code is often used in a simplified way in U-Boot compared to Linux kernel, and b) it's all about board start-up only and not about full OS use with all bells, whistles and full error handling.
Of course, I might be wrong while missing some important other use or corner cases, so I wanted to check here :-)
At least, what I can say: with this patch I see a bunch of these warning messages but the board comes up and is usable in the end by Linux.
fwiw: my internet search also showed another patch labelled in the first place "[PATCH] pi4: fix crash when issuing usb reset" (2) that didn't make it into the particular U-Boot 22.01 but was integrated right after that version in commit "Prepare v2022.04" with hash e4b6ebd3de982ae7185dbf689a030e73fd06e0d2 (3). As I first hoped I could address my problem by just adding this patch I got promptly disappointed. The only thing I gained was to now get endless error messages followed by retries until I power-cycled the board (causing to start all over):
USB XHCI 1.00 scanning bus xhci_pci for devices... WARN halted endpoint, queueing URB anyway. Unexpected XHCI event TRB, skipping... (3afd6b30 00000004 13000000 02008401) XHCI abort timeout WARN halted endpoint, queueing URB anyway. Unexpected XHCI event TRB, skipping... (3afd6b40 00000004 13000000 02008401) XHCI abort timeout WARN halted endpoint, queueing URB anyway. Unexpected XHCI event TRB, skipping... (3afd6b50 00000004 13000000 02008401) XHCI abort timeout WARN halted endpoint, queueing URB anyway. [...]
To me it means that this specific PCIe-to-USB bridge might misbehave somehow, but the final question is: what are the odds to get that patch into official U-boot, or any other fix/quirk to make my hardware combo working?
And also interesting: if I cannot hope for an upstream change, what potential risks I would have to accept when keeping my patch?
Regards, Harry
(1) https://linux-usb.vger.kernel.narkive.com/VW4VTVDU/patch-usb-host-xhci-fix-h... (2) https://lore.kernel.org/all/3d4ece94-932a-25dd-ef29-0ddfb4a51465@denx.de/T/ (3) https://source.denx.de/u-boot/u-boot/-/commit/e4b6ebd3de982ae7185dbf689a030e...