Problem upon startup with halted USB device on RaspberryPi 4

[Michal Suchánek]

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.Waschkeit at 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-0ddfb4a51465@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
> >
> >