Re: Problem upon startup with halted USB device on RaspberryPi 4

[Harry Waschkeit <Harry.Waschkeit@conplement.de>]

Am 15.08.23 um 13:49 schrieb Massimo Pegorer:
> 
> 
> Il giorno lun 14 ago 2023 alle ore 11:11 Harry Waschkeit 
> <Harry.Waschkeit@conplement.de <mailto:Harry.Waschkeit@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@conplement.de
>     <mailto:Harry.Waschkeit@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 <http://get_maintainer.pl> 
> drivers/usb/host/xhci-ring.c
> Bin Meng <bmeng.cn@gmail.com <mailto:bmeng.cn@gmail.com>> 
> (maintainer:USB xHCI)
> Marek Vasut <marex@denx.de <mailto:marex@denx.de>> (maintainer:USB)
> u-boot@lists.denx.de <mailto:u-boot@lists.denx.de> (open list)

yes, thanks for the hint, I should have done this right from the start ...

@Bin and @Marek: even though I decided to deactivate USB in my u-boot 
for the time being, could you please have a look at my observations and 
give me your thoughts about whether and how this problem will be 
addressed in future?

Thanks in advance! :-)

Regards,
Harry

> 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 <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/ <https://lore.kernel.org/all/3d4ece94-932a-25dd-ef29-0ddfb4a51465@denx.de/T/>
>      >>> (3)
>      >>>
>      >>>
>     https://source.denx.de/u-boot/u-boot/-/commit/e4b6ebd3de982ae7185dbf689a030e73fd06e0d2 <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