Am 15.08.23 um 13:49 schrieb Massimo Pegorer:
>
>
> Il giorno lun 14 ago 2023 alle ore 11:11 Harry Waschkeit
> <harry.waschk...@conplement.de <mailto:harry.waschk...@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.waschk...@conplement.de
> <mailto: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.
>
> 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...@gmail.com <mailto:bmeng...@gmail.com>>
> (maintainer:USB xHCI)
> Marek Vasut <ma...@denx.de <mailto:ma...@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-0ddfb4a51...@denx.de/T/
> <https://lore.kernel.org/all/3d4ece94-932a-25dd-ef29-0ddfb4a51...@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
