Problem upon startup with halted USB device on RaspberryPi 4

Tue Aug 15 13:49:26 CEST 2023

Il giorno lun 14 ago 2023 alle ore 11:11 Harry Waschkeit <
Harry.Waschkeit at conplement.de> ha scritto:

> Am 13.08.23 um 19:37 schrieb Michal Suchánek:
> > Hello,
>
> Hi again,
>
> thanks for your answers!
>
> > 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.
>
> Yeah, I am aware of that possibility, thanks for your hint anyway, but ...
>
> >
> > That would be great workaround, However, enabling a device should not
> > break the board. If that's the case the driver is clearly broken.
>

Of course, mine is just a workaround, nothing more. To make hardware combo
working, and just for specific use case (if I properly understood). Not for
typical
usage of rPi. About the driver: can be broken, or the root cause can be the
PCIe-to-USB bridge misbehaving, or both.

> Also rPi typically uses USB keyboard for boot-time input which makes the
> > workaround not so great.

For U-Boot booting phase, or later on for Linux or other OS boot phase? I do
not know too much about this specific board.

> ... but as Michal pointed out, the rpi - at least rpi 400 - should be
> considered to regularly use USB devices for normal operation, so
> completely disabling USB is not really an option here.
>

Disabling USB support in U-Boot (via defconfig) would not affect Linux (or
other OS) USB functions in any way, if this is what you are concerning about
with "completely disabling USB".

My USB knowledge is too little to point the finger on the problem but my
> guess still is that U-Boot is only using a part of Linux's USB driver
> for bringing up devices, thereby omitting some of the error handling
> which would be done in the Linux kernel in some (maybe concurrent) way.
>

I suggest to address this email also directly to maintainers:

./scripts/get_maintainer.pl drivers/usb/host/xhci-ring.c
Bin Meng <bmeng.cn at gmail.com> (maintainer:USB xHCI)
Marek Vasut <marex at denx.de> (maintainer:USB)
u-boot at lists.denx.de (open list)

Regards,
Massimo

And given the bunch of boot messages "WARN halted endpoint." with the
> patch I mentioned, chances are that the patch is either not the right
> one or at least incomplete.
> But the general approach to ignore halted endpoints appears completely
> reasonable to me when it avoids a hanging of boot looping system.
> I cannot tell whether there should instead be some cleverer treatment to
> get such a device running ("Reset Endpoint" from what I read), though.
>
> Regards,
> Harry
>
> > 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
> >>>
> >>>
>
> --
>
> #GernePerDu #CallMeByMyFirstName*
>
> i.A. Harry Waschkeit*
> Senior Embedded Engineer
>
> *conplement AG*
> Südwestpark 92
> 90449 Nürnberg
>
>
>
>   Telefon IconTelefon: +49 911 25 50 976-862
> Handy IconMobil:    +49 173 38 29 258
>
> _harry.waschkeit at conplement.de
> _www.conplement.de<http://www.conplement.de/>
>
>
>
> Bild mit conplement Logo mit Claim Picture of conplement Logo with Claim
> Ein Bild, um bei Klick auf das Bild zum Download eines Whitepapers zu
> gelangen für das Thema "Remote-Updates für Embedded Linux Systeme"
> Picture linked to a landing page to download the Whitepaper “Remote
> Updates for Embedded Linux Systems”<https://hubs.ly/Q01tz75q0>
>
>   Besuchen Sie uns auf Social Media:
>
> LinkedIn
> Link<https://www.linkedin.com/company/conplement-ag/>         Instagram
> Link<https://www.instagram.com/conplementag/?hl=de>         XING
> Link<https://www.xing.com/companies/conplementag/updates>
>
>
> Handelsregister: HRB 22863
> Registergericht: Nürnberg
> Vertreten durch: Britta Waligora und Thomas Wahle
> Vorsitzender des Aufsichtsrates: Lorenz von Schröder
>
> *E-Mail Disclaimer *
> Der Inhalt dieser E-Mail einschließlich aller Anhänge ist vertraulich
> und ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie
> nicht der vorgesehene
> Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten
> Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung,
> Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig
> ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in
> Verbindung zu setzen sowie die Originalnachricht zu löschen und alle
> Kopien hiervon zu vernichten.
> Dafür vielen Dank im Voraus.
>
>
>