Nano Dev Kit B01 + Raspi HQ cam doesn't work with v4l2-ctl (JetPack 4.6)

Hello,

we’ve recently flashed a brand new Nano Dev Kit (B01) with JetPack 4.6 and configured its CSI ports to support IMX477 via the jetson-io.py. The Raspberry Pi HQ Camera (with the resistor R8 removed) can be found by v4l2-ctl and can also stream using nvarguscamerasrc.

BUT it failed streaming using v4l2-ctl. For streaming we used
v4l2-ctl -d /dev/video0 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw --verbose
and
v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw --verbose.
Only in few cases, it worked. In most cases, it just hanged. While hanging, there were constantly
video4linux video0: frame start syncpt timeout!0
errors logged in the Kernel log, which means that the frame start signal on the MIPI lane was not received by the driver (if I am not mistaken).

We’ve verified that both the camera and the MIPI cable are fine. Could you please suggest us what could be the cause to this problem and how to fix it? Any help will be appreciated. Thanks!

Sorry for the late resposne, we will have the investigation to do the updat soon.

Thanks for the response. I am working with zhuda on this. Here’s some additional information for you:
We have actually tried 3 Nano Developer kits, all with JetPack 4.6 installed and on one of them the camera works well with v4l2-ctl, but on the other two we get the errors mentioned by zhuda most of the time. We have several cables and RaspI HQ cameras and have tried many combinations with our boards. We have also cloned the SD card to rule out any differences in the installation status.
It appears as if JetPack 4.6 solves the problem for other users (see Nano 2GB + Raspi HQ Cam nvarguscamerasrc working but not v4l2-ctl - #19 by JerryChang) but, at least for us, it appears to be dependent on the particular DevKit hardware being used.

What’s about the 3840x2160 this mode?

@ShaneCCC, I see the same results on two of my identical 2GB Nano dev kits with the Arducam IMX477 Mini. With the stock Nvidia drivers, both on the latest L4T, I am only able to get v4l2-ctl working with one of them. I’ve tried both sensor modes (3840x2160 and 1920x1080 that the stock Nvidia driver provides). Let me know if there’s any particular debug I can get you. I also see those same video4linux video0: frame start syncpt timeout!0 messages on the non-working rig. I had heard that v4l2 doesn’t like to work after nvarguscamerasrc has been initialized, so I tried a fresh reboot with the nvargus-daemon disabled, and got the same results. Happy to help, just let me know what I can do. Thanks!

@ShaneCCC, both 3840x2160 and 1920x1080 have the same problem as described above.

As a side note, it would be great to have the full resolution 4032x3040 30fps sensor mode available as it is in the original RidgeRun and current Arducam drivers. This 4:3 aspect ratio is extremely valuable for certain use-cases. Understandably at that throughput, v4l2 may have bandwidth issues transporting the raw bayer data. However, that sensor mode doesn’t have any issues when used in Gstreamer. Maybe there’s something different about getting raw bayer->system memory vs. raw bayer->ISP Debayer->system memory (which is what Gstreamer is doing). Even if that were the reason why v4l2 has trouble with this sensor resolution, it wouldn’t be an issue if it were possible to control the framerate via v4l2-ctl so that we could lower the bandwidth pressure, but that control doesn’t seem to take effect across any sensor mode (tested on both drivers - Nvidia and Arducam). However, unlike v4l2, Gstreamer is able to control the framerate correctly (down to 2fps and up to 60fps for 1920x1080).

I just try the dual IMX477 connect to Nano and v4l2-ctl have problem on video1 but without problem on video0.