Hi, I’m using a Sony IMX298 USB UVC Camera on Linux and it’s basically working intermittently — it runs for a while, then drops, and sometimes it doesn’t come back until I re-plug it. I have four things I’m trying to figure out:
How can I read the firmware version from the camera? Is there some API or Linux command for that, or some utility you’d recommend?
How do I upgrade the firmware on the camera — again through API/Linux commands or some utility tool?
Is there any way to read memory/storage information from the camera?
Does this camera also support UART/SPI, aside from the UVC interface?
Right now the camera is plugged into a Linux box and I’m following the video instructions from the docs. No custom code on my side yet, just standard tools. Any pointers would help, the instability is what’s blocking me most.
Thanks for the detailed list. Let me go through your four points:
Firmware version — this is read out through the burning tool, not through a standard V4L2/UVC call. There’s no generic Linux command that exposes the sensor/module firmware string. I’ve sent you the burning tool package through private message; check it when you get a chance.
Firmware upgrade — same tool handles the flashing. There isn’t a Linux API for upgrading it.
Memory/storage information — this isn’t supported for reading on this camera. There’s no storage/parameter region exposed to the host.
UART/SPI — not supported on this module. It’s UVC over USB only.
So really only #1 and #2 are actionable, and both go through the burning tool.
On the instability: which device is it unstable on, and does it behave the same way on other devices/hosts? That will tell us whether it’s host-side (power/USB) or the module itself. Also, what have you already tried in terms of commands? Even a lsusb and a dmesg tail right after a drop would help.
$ lsusb
Bus 001 Device 012: ID 0bda:xxxx Realtek Semiconductor Corp. USB Camera
$ v4l2-ctl --list-devices
USB Camera: USB Camera (usb-0000:00:14.0-2):
/dev/video0
/dev/video1
$ v4l2-ctl -d /dev/video0 --all
Driver Info:
Driver name : uvcvideo
Card type : USB Camera
Bus info : usb-0000:00:14.0-2
Driver version : 5.15.0
Capabilities : 0x84a00001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Format Video Capture: Width/Height : 1920/1080, Pixel Format : ‘YUYV’
Nothing in that output gives me a firmware version. I also grepped around /sys/class/video4linux and /sys/bus/usb/devices for any version-ish attribute — nothing useful.
When it drops, dmesg shows stuff like:
[ 812.441223] usb 1-2: USB disconnect, device number 12
[ 812.443010] uvcvideo: Failed to resubmit video URB (-19).
[ 813.900455] usb 1-2: new high-speed USB device number 13 using xhci_hcd
It seems to drop every few minutes under load. It also did the same thing on a second Linux machine I tested, so it isn’t just this host.
Forgot to add — I tried lsusb -v -d 0bda:xxxx and there’s no iSerial or firmware/bcdDevice string that maps to a firmware revision. Also tried ffmpeg capture for 10 minutes (ffmpeg -f v4l2 -i /dev/video0 -t 600 out.mp4) and it dies partway with the same disconnect. So no luck reading firmware through the UVC path.
That’s consistent with what I’d expect — firmware version isn’t exposed over UVC, so the burning tool is the only way to read/flash it.
For the disconnects, a few things worth ruling out on the Linux side:
USB autosuspend: check cat /sys/module/usbcore/parameters/autosuspend and try disabling it, plus echo -1 > /sys/bus/usb/devices/1-2/power/autosuspend_delay_ms if the attribute exists.
Port/power: high-speed UVC with 1080p YUYV eats a lot of bandwidth. Try a different port (preferably direct to the root hub), a short cable, and a powered hub if you have one. Also try forcing USB2 vs USB3 to see if the behavior changes.
Bandwidth/format: 1920x1080 YUYV is uncompressed and very heavy. Try v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat=YUYV or an MJPG format (v4l2-ctl --list-formats-ext will show what’s available) and see if it stays up longer.
Logs: journalctl -k -f while it runs, and if you can, capture a usbmon trace around a drop.
Can you try those and let me know which ones change anything? Also confirm whether Windows/another OS showed the same drops, or only Linux.
Tried the list. Results are mixed and mostly not good:
Autosuspend was already -1 (disabled), so that’s not it.
Different ports: tried a rear USB3 port, a front USB2 header, and a powered hub. Same behavior, drop after ~3–8 minutes.
Cable: swapped to a shorter one, no change.
Formats: v4l2-ctl --list-formats-ext shows MJPG and YUYV options. MJPG at 1080p survives a bit longer, maybe 15–20 minutes, but it still eventually disconnects with the same Failed to resubmit video URB (-19) followed by a re-enumeration. YUYV at 720p still drops in a few minutes.
journalctl -k -f just repeats the same disconnect/re-enumeration cycle.
The other Linux machine showed the same thing, and I briefly hooked it to a Windows machine and saw it stop mid-stream there too, though I didn’t let it run long enough to be sure.
So nothing on the host side seems to fix it. Should I try the burning tool / firmware route next? Does the tool need Windows, or can I run it from Linux?
Given that it drops on multiple Linux hosts, different ports/cables/hubs, and the same video format narrowing only delays it, host-side tuning doesn’t look like the culprit. The next thing to check is whether the module is on an older firmware build, which is what the burning tool is for. I’ve sent the tool and the current firmware package to you through private message — please check your messages and see if it can run in your environment. If it needs a different OS to run the flasher, let me know and we’ll figure out the flashing side separately.
Before you flash anything, can you send me:
the full lsusb -v -d <vid:pid> output for the camera
a dmesg capture covering one full drop-and-recover cycle
whether the Windows test consistently dropped or only sometimes
That way we have a baseline to compare against after the firmware update.
Summarizing where we are so it’s clear in the thread:
Reading firmware version — not possible over UVC/V4L2. It’s read out with the burning tool, which I’ve sent you via private message.
Upgrading firmware — also done through the burning tool; there’s no Linux API for it. Hold off until you’ve captured the baseline logs above so we can tell whether the update changes the disconnect behavior.
Memory/storage info — not supported on this camera; there’s no readable storage/parameter region exposed to the host.
UART/SPI — not supported; this module is UVC over USB only.
On the instability itself, we haven’t isolated a root cause yet. It reproduces across multiple Linux hosts, in both YUYV and MJPG, and appears to also happen under Windows. Host-side power, autosuspend, port, and cable variations didn’t resolve it. Next step is the firmware/flashing path plus the lsusb -v and dmesg captures so we can compare before and after. Please post those here when you have them and we’ll continue from there.