All usb devices not work, see log: xHCI host not responding to stop endpoint command

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
,
1

My orin nano information is below:
Model: NVIDIA Orin Nano Developer Kit - Jetpack 5.1.1 [L4T 35.3.1]
NV Power Mode[1]: 7W
Serial Number: [XXX Show with: jetson_release -s XXX]
Hardware:

  • 699-level Part Number: 699-13767-0005-300 K.2
  • P-Number: p3767-0005
  • Module: NVIDIA Jetson Orin Nano (Developer kit)
  • SoC: tegra23x
  • CUDA Arch BIN: 8.7
  • Codename: P3768
    Platform:
  • Machine: aarch64
  • System: Linux
  • Distribution: Ubuntu 20.04 focal
  • Release: 5.10.104-tegra
  • Python: 3.8.10
    jtop:
  • Version: 4.2.1
  • Service: Active
    Libraries:
  • CUDA: 11.4.315
  • cuDNN: 8.6.0.166
  • TensorRT: 8.5.2.2
  • VPI: 2.2.7
  • Vulkan: 1.3.204

When our application is forced to exit, we saw the USB error: xHCI host not responding to stop endpoint command. Then all usb devices do not work any more.

Our application uses some USB devices like USB camera, touch screen etc. The syslog is attached, the error happened at about May 20 13:51:31 timestamp.

How to debug this issue and how can we recover from this error to make USB devices work again without reboot?

Some errors are copied below.

8962 May 20 13:51:31 txkj-desktop kernel: [17248.991393] tegra-xusb 3610000.xhci: xHCI host not responding to stop endpoint command.
8963 May 20 13:51:31 txkj-desktop kernel: [17248.999655] tegra-xusb 3610000.xhci: USBSTS:
8964 May 20 13:51:31 txkj-desktop kernel: [17249.004059] tegra-xusb 3610000.xhci: xHCI host controller not responding, assume dead
8965 May 20 13:51:31 txkj-desktop kernel: [17249.012143] tegra-xusb 3610000.xhci: HC died; cleaning up
8966 May 20 13:51:31 txkj-desktop kernel: [17249.017755] tegra-xusb 3610000.xhci: hcd_reinit is disabled or in progress
8967 May 20 13:51:31 txkj-desktop kernel: [17249.017842] usb 1-2: USB disconnect, device number 2
8968 May 20 13:51:31 txkj-desktop kernel: [17249.017849] usb 1-2.1: USB disconnect, device number 4
8969 May 20 13:51:31 txkj-desktop kernel: [17249.018321] usb 2-1: USB disconnect, device number 2
syslog_all_usb_disconn.zip (80.2 KB)

3

The BSP seems too old. Please move to newer BSP.

4

What is the best BSP version you suggest, is the newest version OK?

There are potential changes/fixes for those USB issues in recent releases, right?

5

Please use latest one. New one might have usb firmware update.

6

So we should use Jetpack 6.0, JetPack 6.0 Production Release - Announcement ?

7

If all your previous development were on rel-35, then use jetpack5.1.3… jetpack6 has lots of change…

8

OK. We will use jetpack 5.1.3 instead of jetpack 6.

9

When I used Jetpack 5.1.1, I built uefi bootloader with r35.3.1-updates. Now if I used jetpack 5.1.3, should I use r35.5.0-updates to build uefi?

I saw NVIDIA-Jetson only has r35.3.1-updates combination, can I use this combination and use r35.5.0-updates to pick up edk2-nvidia repo for my r35.5.0 release?

10

I saw many combinations in this wiki: Combos · NVIDIA/edk2-nvidia Wiki · GitHub, include some r35.5.

But I checked .edkrepo/nvidia/edk2-nvidia/Jetson/NVIDIAJetsonManifest.xml, I only saw below combinations. I did not see any r35.5 combinations.

<Combination name="rel-34" description="The rel-34 codeline">
<Combination name="rel-34-updates" description="The rel-34 codeline, plus updates">
<Combination name="rel-35" description="The rel-35 codeline">
<Combination name="rel-35-updates" description="The rel-35 codeline, plus updates">
<Combination name="jetson-r35.1" description="The jetson-r35.1 release">
<Combination name="r35.2.1" description="The r35.2.1 release">
<Combination name="r35.2.1-updates" description="The r35.2.1 release, plus updates">
<Combination name="r35.3.1" description="The r35.3.1 release">
<Combination name="r35.3.1-updates" description="The r35.3.1 release, plus updates">
11

image
image320×521 15 KB

12

This is edk2-nvidia tags. I can checkout to r35.5.0 tag for edk2-nvidia git repo. But other repo’s like edk2-non-osi, edk2-nvidia-non-osi, edk2-platforms etc has no r35.5.0 tag.

I tried to checkout edk2-nvidia to r35.5.0 and build uefi, but got failure as below.
INFO - Active Platform = /build/nvidia-uefi-r35.3.1-updates/edk2-nvidia/Platform/NVIDIA/Jetson/Jetson.dsc
INFO -
INFO -
INFO - build.py…
INFO - /build/nvidia-uefi-r35.3.1-updates/edk2-nvidia/Platform/NVIDIA/Jetson/Jetson.dsc(139): error 000E: File/directory not found in workspace
INFO - MdeModulePkg/Library/VarSetCallbacksLibNull/VarSetCallbacksLibNull.inf is not found in packages path:
INFO - /build/nvidia-uefi-r35.3.1-updates/edk2/BaseTools
INFO - /build/nvidia-uefi-r35.3.1-updates/edk2
INFO - /build/nvidia-uefi-r35.3.1-updates/edk2-platforms
INFO - /build/nvidia-uefi-r35.3.1-updates/edk2-nvidia
INFO - /build/nvidia-uefi-r35.3.1-updates/edk2-nvidia-non-osi
INFO - /build/nvidia-uefi-r35.3.1-updates/edk2-non-osi
INFO - /build/nvidia-uefi-r35.3.1-updates/edk2-platforms/Features/Intel/OutOfBandManagement
INFO -
INFO -
INFO - - Failed -
INFO - Build end time: 07:36:25, May.27 2024
INFO - Build total time: 00:00:00
INFO -
INFO - ------------------------------------------------
INFO - --------------Cmd Output Finished---------------
INFO - --------- Running Time (mm:ss): 00:00 ----------
INFO - ----------- Return Code: 0x0000000e ------------
INFO - ------------------------------------------------
ERROR - Build.py #000 from /build/nvidia-uefi-r35.3.1-updates/edk2-nvidia/Platform/NVIDIA/Jetson/Jetson.dsc(139): File/directory not found in workspace
CRITICAL - Build failed

13

Honestly, I don’t think your issue here is important or related to original issue.

Why not just directly flash your whole board to jetpack5.1.3?

14

Because we have had other changes in UEFI bootloader for jetpack 5.1.1. If we upgrade to jetpack 5.1.3, we dont want to lose our changes in UEFI.

15

That is not the problem we care about in this topic. You could file new one for your UEFI things.

16

OK. I just filed a new one How to build UEFI bootloaer for jetpack 5.1.3(R35.5.0).

18

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.