V4L2 camera stream works on 3/4 csi-ports, Argus (with GStreamer) works on 4/4 csi-ports

Continuing the discussion from GStreamer working but v4l2-ctl is not:

Hello,
I linked to you my post from some time ago, where I had the same problem with Jetson NX. Since we used a custom carrier board back then, we did not know if the problem was only with the custom carrier boards, but now we use the Jetson AGX with the Nvidia devkit and get the same kind of problem.

GStreamer with Argus is working on every port, but V4L2 stream fails on one port. All the other ports are working.

With NX it was serial_e not working, while with AGX it is serial_g not working.

Have you a working example of Jetson AGX devkit with a working 4-lane sensor on serial_g csi port?
Can you test it with v4l2-ctl command and point me to the working example?

Best regards,
Johannes

Have reference to tegra194-camera-e3333-a00.dtsi to confirm the port-index in device tree configure.

Thanks

I looked at the device tree and I see that you use 6 2-lane sensors.
In this order: A, B, C, D, E, G
So F is missing. Does that mean for 4 4-lane sensors, I would have:
A(-B), C(-D), E(-G), F(-H)

If that is not correct, what would be the right order for 4 4-lane sensors?

Should be AB, CD, EF, GH for 4 x4 lanes sensors.

Thanks

Of course, that is what I was thinking at first because it would make sense that way. But why is your example missing the F?

E/F only support one sensor no matter x1/x2/x4 due to only have one channel for this brick doesn’t like A/B, C/D below is from sensor programing guilde.

Port index is used to specify the connection between two different modules. For the VI (video input) module, the port index represents the input stream. For the CSI module, it represents the actual CSI port to which the camera is connected.

The following diagrams show the port index mapping for different Jetson platforms.

  • NVIDIA® Jetson AGX Xavier™ series:

You are right! Your diagram hints at the correct solution. That was my mistake.
For me, a more understandable explanation came from this answer, since it describes exactly which components in my device tree I had to modify to make it work.

Interesting it is, that with my mistake, the argus API was working totally fine, so it seems if that is the case people made the same mistake as I did.