Sharing USB devices on the NVIDA Orin Devkit

Submitted by prj_do_dev on #1

Hello,

From my own ubuntu PC, I am trying to access USB devices on an NVIDA Orin devkit that is connected to another ubuntu PC, by using VirtualHere. The PCs are locally connected through wired Ethernet and the communication is quite stable. 

The Orin devkit has two USB interfaces, one for TTY serial communication and the other for flashing the board. As far as the serial communication is concerned, VirtualHere works fine and there seems to be no problem. However, when I attempt to flash the Orin devkit using NVIDIA's utility program (flash_bsp_images.py), it fails due to timeout in the first bulk write transfer, while waiting for the device to respond.

Since the core part of the utility source code is not made public, it is difficult to suppose what is actually going on during the timeout process. But it seems that the bulk transfer is not recognized by the USB device on the Orin devkit.

If you have ever seen this sort of problem, could you provide some hists for more investigation? 

Any suggestion would be appreciated. 

------

P.S. I have attached a fragment of the USB transaction log captured on the server side by tshark with usbmon, where Frame 55 corresponds to the bulk write transfer and Frame 56 might be the response from libusb due to timeout.

Frame 55: 8256 bytes on wire (66048 bits), 8256 bytes captured (66048 bits) on interface usbmon1, id 0
   Section number: 1
   Interface id: 0 (usbmon1)
       Interface name: usbmon1
   Encapsulation type: USB packets with Linux header and padding (115)
   Arrival Time: Jul  1, 2026 10:55:20.932195000 JST
   UTC Arrival Time: Jul  1, 2026 01:55:20.932195000 UTC
   Epoch Arrival Time: 1782870920.932195000
   [Time shift for this packet: 0.000000000 seconds]
   [Time delta from previous captured frame: 0.005021000 seconds]
   [Time delta from previous displayed frame: 0.005021000 seconds]
   [Time since reference or first frame: 17.426135000 seconds]
   Frame Number: 55
   Frame Length: 8256 bytes (66048 bits)
   Capture Length: 8256 bytes (66048 bits)
   [Frame is marked: False]
   [Frame is ignored: False]
   [Protocols in frame: usb]
USB URB
   [Source: host]
   [Destination: 1.30.1]
   URB id: 0xffff8e0b63bb6e40
   URB type: URB_SUBMIT ('S')
   URB transfer type: URB_BULK (0x03)
   Endpoint: 0x01, Direction: OUT
       0... .... = Direction: OUT (0)
       .... 0001 = Endpoint number: 1
   Device: 30
   URB bus id: 1
   Device setup request: not relevant ('-')
   Data: present ('\0')
   URB sec: 1782870920
   URB usec: 932195
   URB status: Operation now in progress (-EINPROGRESS) (-115)
   URB length [bytes]: 8192
   Data length [bytes]: 8192
   [bInterfaceClass: Vendor Specific (0xff)]
   Unused Setup Header
   Interval: 0
   Start frame: 0
   Copy of Transfer Flags: 0x00000000
       .... .... .... .... .... .... .... ...0 = Short not OK: False
       .... .... .... .... .... .... .... ..0. = ISO ASAP: False
       .... .... .... .... .... .... .... .0.. = No transfer DMA map: False
       .... .... .... .... .... .... ..0. .... = No FSBR: False
       .... .... .... .... .... .... .0.. .... = Zero Packet: False
       .... .... .... .... .... .... 0... .... = No Interrupt: False
       .... .... .... .... .... ...0 .... .... = Free Buffer: False
       .... .... .... .... .... ..0. .... .... = Dir IN: False
       .... .... .... ...0 .... .... .... .... = DMA Map Single: False
       .... .... .... ..0. .... .... .... .... = DMA Map Page: False
       .... .... .... .0.. .... .... .... .... = DMA Map SG: False
       .... .... .... 0... .... .... .... .... = Map Local: False
       .... .... ...0 .... .... .... .... .... = Setup Map Single: False
       .... .... ..0. .... .... .... .... .... = Setup Map Local: False
       .... .... .0.. .... .... .... .... .... = DMA S-G Combined: False
       .... .... 0... .... .... .... .... .... = Aligned Temp Buffer: False
   Number of ISO descriptors: 0
Leftover Capture Data [truncated]: 42435442c0bbc7c2bb9d7552593db97bd63005fe81b630565a48cce8793454cd7fc7b0d6cc5ce1872a9b362017384753a5d58a04e34724a6163795f16657c60767b45a9a00000000000000000000000000000000000000000000000000000000000000000000

Frame 56: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface usbmon1, id 0
   Section number: 1
   Interface id: 0 (usbmon1)
       Interface name: usbmon1
   Encapsulation type: USB packets with Linux header and padding (115)
   Arrival Time: Jul  1, 2026 10:55:31.416748000 JST
   UTC Arrival Time: Jul  1, 2026 01:55:31.416748000 UTC
   Epoch Arrival Time: 1782870931.416748000
   [Time shift for this packet: 0.000000000 seconds]
   [Time delta from previous captured frame: 10.484553000 seconds]
   [Time delta from previous displayed frame: 10.484553000 seconds]
   [Time since reference or first frame: 27.910688000 seconds]
   Frame Number: 56
   Frame Length: 64 bytes (512 bits)
   Capture Length: 64 bytes (512 bits)
   [Frame is marked: False]
   [Frame is ignored: False]
   [Protocols in frame: usb]
USB URB
   [Source: 1.30.1]
   [Destination: host]
   URB id: 0xffff8e0b63bb6e40
   URB type: URB_COMPLETE ('C')
   URB transfer type: URB_BULK (0x03)
   Endpoint: 0x01, Direction: OUT
       0... .... = Direction: OUT (0)
       .... 0001 = Endpoint number: 1
   Device: 30
   URB bus id: 1
   Device setup request: not relevant ('-')
   Data: not present ('>')
   URB sec: 1782870931
   URB usec: 416748
   URB status: No such file or directory (-ENOENT) (-2)
   URB length [bytes]: 0
   Data length [bytes]: 0
   [Request in: 55]
   [Time from request: 10.484553000 seconds]
   [bInterfaceClass: Vendor Specific (0xff)]
   Unused Setup Header
   Interval: 0
   Start frame: 0
   Copy of Transfer Flags: 0x00000000
       .... .... .... .... .... .... .... ...0 = Short not OK: False
       .... .... .... .... .... .... .... ..0. = ISO ASAP: False
       .... .... .... .... .... .... .... .0.. = No transfer DMA map: False
       .... .... .... .... .... .... ..0. .... = No FSBR: False
       .... .... .... .... .... .... .0.. .... = Zero Packet: False
       .... .... .... .... .... .... 0... .... = No Interrupt: False
       .... .... .... .... .... ...0 .... .... = Free Buffer: False
       .... .... .... .... .... ..0. .... .... = Dir IN: False
       .... .... .... ...0 .... .... .... .... = DMA Map Single: False
       .... .... .... ..0. .... .... .... .... = DMA Map Page: False
       .... .... .... .0.. .... .... .... .... = DMA Map SG: False
       .... .... .... 0... .... .... .... .... = Map Local: False
       .... .... ...0 .... .... .... .... .... = Setup Map Single: False
       .... .... ..0. .... .... .... .... .... = Setup Map Local: False
       .... .... .0.. .... .... .... .... .... = DMA S-G Combined: False
       .... .... 0... .... .... .... .... .... = Aligned Temp Buffer: False
   Number of ISO descriptors: 0

 

Submitted by Michael on Thu, 2026/07/02 - 08:30

#2

I have heard of this before.  If the usb device is resetting and being flashed immediately linux will issue a SET_ADDRESS request on the device (even though its not unplugged) and this could confuse things.  Can you plug the devkit into a real windows pc as the virtualhere server instead and see if that makes a difference, just for a test. Windows will not reissue a SET_ADDRESS request if the device is not physically replugged. 

Alternatively it could be perhaps a latency issue e.g the reset and firmware write requires timing below the network latency for events to happen.

Submitted by prj_do_dev on Thu, 2026/07/02 - 14:25

#3

Thank you for your quick response.

Unfortunately, since the devkit flashing tool can be used only in Linux (Ubuntu) PSs, I cannot try the test you suggested for checking if any difference arises between Linux and Windows PCs.

Instead I will examine the possibility of a latency issue by taking a closer look at USB traces captured both in the normal case and error case. In any event, please let me inform you of the results in due course.

 

Submitted by Michael on Thu, 2026/07/02 - 15:01

#4

The Server OS is irrelevant to the client, it will still work on windows as the server. You can still run the client on Linux.

Anyway if you want to stay with a Linux server try this: 

sudo systemctl stop virtualhere

vi /usr/local/etc/virtualhere/config.ini

add the line

ClaimPorts=1

Save (esc :wq)

systemctl start virtuahere

Then try to flash via virtualhere. Does that work now?

 

Submitted by prj_do_dev on Thu, 2026/07/02 - 18:44

#5

Thank you for your advice. I have tried it but found the same problem still persists. I have also tried USB/IP instead of VirtualHere and it turned out that the flashing process timeouts similarly in both cases.

So I thought the USB over IP approach might be impractical for flashing NVIDIA devkits and asked "Claude AI" about this point. According to Claude, the flashing process, especially its RCM boot ROM phase, is so timing critical that it occasionally fails even if the devkit is directly connected. Taking this into account, now I began to examine alternative ways other than remote USB sharing. (for instance, physical/electrical USB extenders)

In any ways, thank you for your assistance this time. I hope you could help me again when I need it in the future.