Error in nvarguscamerasrc: No cameras available

[alejandro.concepcion]

Hi,

We are working in a custom board for the Xavier AGX SoM. Taking the IMX390 dtsi files as examples (tegra194-p2822-0000-camera-imx390-a00.dtsi and tegra194-camera-imx390-a00.dtsi), we have created some dtsi files that describe our cameras setup. We had to remove the tca9546@70 as this is not available in our design.

Then problem is that, when trying to test the cameras using gst-launch, we get this error:

xavier@tegra-ubuntu:~$ gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM), width=(int)1928, height=(int)1208' ! nvvidconv flip-method=0 ! 'video/x-raw,format=(string)I420' ! xvimagesink -e
nvbuf_utils: Could not get EGL display connection
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:521 No cameras available

However, we can see the /dev/video* device files, and we can read frames using the V4L2 API.

xavier@tegra-ubuntu:~$ v4l2-ctl -V --set-fmt-video=width=1928,height=1208,pixelformat=RG12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video0
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 34.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 33.83 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Format Video Capture:
	Width/Height      : 1928/1208
	Pixel Format      : 'RG12'
	Field             : None
	Bytes per Line    : 3856
	Size Image        : 4658048
	Colorspace        : sRGB
	Transfer Function : Default (maps to sRGB)
	YCbCr/HSV Encoding: Default (maps to ITU-R 601)
	Quantization      : Default (maps to Full Range)
	Flags             :

So, our guess is that we’re missing something in the dev tree that affects to the nvarguscamerasrc plugin, but can’t find exactly the problem.

Does anyone know which dtsi files may affect to the tegra camera framework? apart from the ones related to the sensor (tegra194-p2822-0000-camera-imx390-a00.dtsi and tegra194-camera-imx390-a00.dtsi).

Thanks

[alejandro.concepcion]

We have some updates regarding this topic…

There was one property we hadn’t modified and it seems we have to. This property is ‘devname’, and is defined inside the node ‘drivernode0’ in one of the sensor dtsi file.

...
			module0 {

				drivernode0 {
					/* Declare PCL support driver (classically known as guid)  */
					pcl_id = "v4l2_sensor";
					/* Driver v4l2 device name */
					devname = "ar0231 2-001b";
					/* Declare the device-tree hierarchy to driver instance */
					proc-device-tree = "/proc/device-tree/i2c@3180000/ar0231_a@1b";
				};
				drivernode1 {
					/* Declare PCL support driver (classically known as guid)  */
					pcl_id = "v4l2_lens";
					proc-device-tree = "/proc/device-tree/lens_ar0231@A6V26/";
				};
			};
...

Before, that property was set to “ar0231 30-001b”, where apparently “30” was meant for the I2C bus created through the I2C switch tca9546@70… By changing that to “2” we don’t see the error “No cameras available” anymore when running gst-launch:

xavier@tegra-ubuntu:~$ gst-launch-1.0 nvarguscamerasrc sensor-id=1 ! 'video/x-raw(memory:NVMM), width=(int)1928, height=(int)1208' ! nvvidconv flip-method=0 ! 'video/x-raw,format=(string)I420' ! xvimagesink -e
nvbuf_utils: Could not get EGL display connection
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
GST_ARGUS: Creating output stream
CONSUMER: Waiting until producer is connected...
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 1928 x 1208 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 48.000000; Exposure Range min 110000, max 166577000;

GST_ARGUS: Running with following settings:
   Camera index = 1 
   Camera mode  = 0 
   Output Stream W = 1928 H = 1208 
   seconds to Run    = 0 
   Frame Rate = 29.999999 
GST_ARGUS: PowerService: requested_clock_Hz=30568440
GST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.

However, it doesn’t show anything in the screen and the kernel log shows these messages:

[  230.975505] tegra194-vi5 15c10000.vi: no reply from camera processor
[  230.975681] tegra194-vi5 15c10000.vi: vi capture get status failed
[  232.481150] fence timeout on [ffffffc3b20419c0] after 1500ms

Again, it works when reading the camera through V4L2 API.

[waisskharni.sm]

Hi Alejandro,
Can you reconfirm the device tree parameters are mentioned specific to your sensor mode? Ensure that the active_w, active_h, tegra_s_interface and num_lanes are properly mentioned.
These parameters are usually not required when acquiring frames via V4L2 API, but it will be used by the libArgus library when acquiring frames.

[D3_growe]

Do you have serdes hardware between the camera and the Jetson or is it directly connected via CSI?

Often when v4l2 works and argus does not it’s an indicator that the clocks aren’t right. If you are using serdes hardware checked serdes_pix_clk_hz. If you are directly connected look at pix_clk_hz to be sure that you have the correct values.

[alejandro.concepcion]

Hi waisskharni, D3_growe

Can you reconfirm the device tree parameters are mentioned specific to your sensor mode? Ensure that the active_w, active_h, tegra_s_interface and num_lanes are properly mentioned.

Right, these paremeters are also defined inside the mode* nodes of the sensor.

Do you have serdes hardware between the camera and the Jetson or is it directly connected via CSI?

Yes, we have a serder hardware in between.

Often when v4l2 works and argus does not it’s an indicator that the clocks aren’t right. If you are using serdes hardware checked serdes_pix_clk_hz. If you are directly connected look at pix_clk_hz to be sure that you have the correct values.

Actually, I would say that the current values are correct. The thing is that we already tested this pair of dtsi files for the sensor (equivalent to tegra194-p2822-0000-camera-imx390-a00.dtsi and tegra194-camera-imx390-a00.dtsi) in the AGX Xavier evalkit for the same cameras and deserializer, and it was working fine there… The only differences is that when we brought those files to the dev tree of our custom board we had to:

1. Remove the mux in between
2. Change the CSI port index as the cameras are connected to the second CSI port in the custom board
3. Modify this devname property in drivernode

However, for the custom board we did change other dtsi files from the evalkit, which were not related to the camera subsystem (at least apparently)… But I also wonder now if maybe we removed some properties related to the cameras by mistake…

[D3_growe]

Ah, I see now. I didn’t fully understand that you had all of this working prior to using a custom carrier board.

I’ve had success in the past by decompiling the active DTB on the target. I’ve been surprised more than once that what I thought was on the hardware wasn’t really.

Is the port-index correct in both the nvsci and vi device tree nodes? Maybe, as Waiss Kharni suggested, tegra_s_interface is still using the old CSI interface name?

[alejandro.concepcion]

Yeaaah! That was the problem…

I only updated the port-index property of nvsci and vi and forgot about the tegra_sinterface property inside mode0… It’s funny it has several locations where to put the same info…

Thanks a lot guys!