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
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.
1 Like
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.
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.
Hi waisskharni, D3_growe
Right, these paremeters are also defined inside the mode* nodes of the sensor.
Yes, we have a serder hardware in between.
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:
- Remove the mux in between
- Change the CSI port index as the cameras are connected to the second CSI port in the custom board
- 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ā¦
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?
1 Like
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!
1 Like