Hello, On Sat, Aug 12, 2023 at 08:31:56PM +0200, Massimo Pegorer wrote: > Hi Harry, > > Il giorno lun 7 ago 2023 alle ore 11:02 Harry Waschkeit < > harry.waschk...@conplement.de> ha scritto: > > > 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. > > > Do you need USB boot devices? If not, I would build U-Boot without USB > support.
That would be great workaround, However, enabling a device should not break the board. If that's the case the driver is clearly broken. Also rPi typically uses USB keyboard for boot-time input which makes the workaround not so great. Thanks Michal > > Massimo > > > 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-halted-endpoint-handling > > (2) > > https://lore.kernel.org/all/3d4ece94-932a-25dd-ef29-0ddfb4a51...@denx.de/T/ > > (3) > > > > https://source.denx.de/u-boot/u-boot/-/commit/e4b6ebd3de982ae7185dbf689a030e73fd06e0d2 > > > > -- > > i.A. Harry Waschkeit > > Senior Embedded Engineer > > conplement AG > > Südwestpark 92 > > 90449 Nürnberg > > > > Handelsregister: HRB 22863 > > Registergericht: Nürnberg > > Vertreten durch: Britta Waligora und Thomas Wahle > > Vorsitzender des Aufsichtsrates: Lorenz von Schröder > > > >