Hoping someone can help with a weird issue. I’ve got an Arducam 16MP UVC camera (USB ID 0c45:636d) that works perfectly on my Linux desktop but refuses to stream on an Nvidia Orin AGX running JetPack L4T.
It shows up at /dev/video4, and everything looks normal right up until the stream starts. v4l2-ctl --list-formats-ext lists all the expected modes, opening the device works, setting formats and frame intervals all succeed without errors. Buffers get allocated via uvc_v4l2_mmap.
The problem: VIDIOC_STREAMON returns -EPROTO every time. Here’s what dmesg looks like:
uvcvideo: Trying format 0x47504a4d (MJPG): 1280x720.
uvcvideo: Using default frame interval 33333.3 us (30.0 fps).
uvcvideo: Setting frame interval to 1/30 (333333).
uvcvideo: Device requested 1600 B/frame bandwidth.
uvcvideo: Selecting alternate setting 4 (1600 B/frame bandwidth).
Then after about a second, no frames at all and I get this:
I’ve tried different USB ports, different cables, different framerates, different resolutions — no luck on the Orin AGX. Same camera, same cable works fine on my x86 desktop.
Does anyone know if there’s updated UVC firmware for this Arducam (0c45:636d) that addresses Jetson compatibility? Or are there known quirks/patches needed in the uvcvideo driver for this device on the Jetson kernel?
First, the fact that the camera enumerates as /dev/video4 rather than /dev/video0 tells me there are other video devices present on the system. The camera hardware itself seems fine given it works on your desktop, and the bandwidth negotiation appears to complete successfully — alternate setting 4 at 1600 B/frame gets selected without issue. The -EPROTO hits right when the host controller tries to actually start the isochronous stream.
Before diving into driver patches or firmware, can you tell me: how many camera modules total do you have connected to the Jetson AGX Orin right now? What else is on the USB bus?
That’s almost certainly where the problem is. Five cameras on the Jetson AGX Orin simultaneously is a lot for the USB subsystem to handle.
Here’s my reasoning: the uvcvideo driver negotiates bandwidth with the device just fine — you can see alternate setting 4 being selected — but when the host controller tries to reserve and schedule that isochronous bandwidth, it fails with -EPROTO. On a desktop with a different USB controller topology and fewer competing devices, there’s enough headroom. On the Orin with four other cameras already consuming isochronous endpoints and bus resources, there isn’t.
This could be either USB bandwidth contention (the Orin’s host controller running out of isochronous bandwidth across the bus) or power delivery — five cameras drawing bus power can easily exceed what the Orin’s USB ports can supply reliably.
Here’s what I’d like you to try:
Disconnect all the RealSense cameras and the other USB cameras entirely.
Keep only the Arducam USB camera connected to the Orin AGX.
Test whether the Arducam can stream normally in this standalone configuration — no VIDIOC_STREAMON -EPROTO.
This will tell us definitively whether it’s a resource conflict versus something else going on with the platform or driver. Please report back what you find.