NvArgusCameraSrc No Cameras Available

Hi,

We are trying to update from JP 3.3 to 4.2 for the Jetson Tx2 with our custom carrier board. NvArgusCameraSrc no longer functions. See the error output:

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

V4l2 works fine:

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 60.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

The changes we make to the device tree are nearly identical (remove plugin-manager, use sensor directly). The sensor is still connected with:

tegra-camera-platform {
		compatible = "nvidia, tegra-camera-platform";

My question is: is this a device tree error? How do I fix this? Why would this work on 3.3 but not on 4.2?

Could you enable logs from user-space for more details

https://elinux.org/Jetson_TX2/28.1_Camera_BringUp

I enabled logs. This gist https://gist.github.com/CreagerAI/48486d6117bb0c2bc3d642d3cfb95d72
contains the trace logs and the output from /usr/sbin/nvargus-daemon. Nothing useful populated in the kernel log (dmesg).

In case it’s useful, here is the gStreamer command and the output:

# gst-launch-1.0 nvarguscamerasrc num-buffers=200 ! 'video/x-raw(memory:NVMM),width=1920, height=1080, framerate=30/1, format=NV12' ! omxh264enc ! qtmux ! filesink location=test.mp4 -e
nvbuf_utils: Could not get EGL display connection
nvbuf_utils: ERROR getting proc addr of eglCreateImageKHR
nvbuf_utils: ERROR getting proc addr of eglDestroyImageKHR
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
Framerate set to : 30 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block : BlockType = 4 
New clock: GstSystemClock
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4 
H264: Profile = 66, Level = 40 
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:521 No cameras available

And additional info: this only occurs when you try to disable the camera-plugin-manager and the camera-modules. As far as I can tell, trying to tie the sensor directly into the device tree per Nvidia’s documentation does not work as expected.

Do you have x11?
Have a reference to below topic for the “nvbuf_utils: Could not get EGL display connection”

https://devtalk.nvidia.com/default/topic/1046131

So the EGL display errors only occur when I try to modify the kernel and copy the Image to the device. I may be missing some critical step.

When I use the default Image in /boot, I do not get the EGL errors.

I still do get the No Cameras Available error, however. This is what output looks like from nvargus-daemon:

/usr/sbin/nvargus-daemon 
=== NVIDIA Libargus Camera Service (0.97.3)=== Listening for connections...^[^Y=== gst-launch-1.0[7091]: Connection established (7F7F3A51D0)OFParserGetVirtualDevice: NVIDIA Camera virtual enumerator not found in proc device-tree
---- imager: No override file found. ----
(NvCamV4l2) Error ModuleNotPresent: V4L2Device not available (in /dvs/git/dirty/git-master_linux/camera/utils/nvcamv4l2/v4l2_device.cpp, function findDevice(), line 256)
(NvCamV4l2) Error ModuleNotPresent:  (propagating from /dvs/git/dirty/git-master_linux/camera/utils/nvcamv4l2/v4l2_device.cpp, function initialize(), line 60)
(NvOdmDevice) Error ModuleNotPresent:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function initialize(), line 105)
NvPclDriverInitializeData: Unable to initialize driver v4l2_sensor
NvPclInitializeDrivers: error: Failed to init camera sub module v4l2_sensor
NvPclStartPlatformDrivers: Failed to start module drivers
NvPclStateControllerOpen: Failed ImagerGUID 0. (error 0xA000E)
NvPclOpen: PCL Open Failed. Error: 0xf
SCF: Error BadParameter: Sensor could not be opened. (in src/services/capture/CaptureServiceDeviceSensor.cpp, function getSourceFromGuid(), line 582)
SCF: Error BadParameter:  (propagating from src/services/capture/CaptureService.cpp, function addSourceByGuid(), line 437)
SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function addSourceByIndex(), line 295)
SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function getSource(), line 458)
Acquiring SCF Camera device source via index 0 has failed. === gst-launch-1.0[7091]: CameraProvider initialized (0x7f786da510)^C

In my device tree, I removed the plugin manager, camera modules, and used my imx274 dtsi directly, as per the documentation. The only other modification I had to make is removing the tca9546@70, since that does not exist on my carrier board. On Jetpack 3.3 this was not an issue to remove.

Remove the camera plugin manager only others need to leave. Please confirm it.

tegra210-jetson-cv-camera-plugin-manager.dtsi

Everything is working. The solution involved adding status=“okay” in the corresponding locations to the camera modules dtsi. I also had to remove the has-eeprom and the fuse_id_start addr. When building the kernel, I had to build the modules and make sure to install on the board. It’s important to note that nvidia download center links to gcc 4.8.5 but I had to go find the linaro gcc 7+ compiler in order to successfully compile the kernel.

All of this has led to a successful nvarguscamerasrc capture at 4K and 1080p. I hope this helps others.

Hi,

I was having similar issues on JetPack-4.2. I was not able to capture using nvarguscamerasrc but everything works good with v4l2 and also I was having issues with the graphic interface.

I confirmed that those issues appears if I used a kernel image compiled with the sources. then I verified that the problem was in the modules directory name. This compiled image was failing searching the modules because it the modules directory had a different name.

By default the original JetPack-4.2 installation generates a “4.9.140-tegra” directory and the kernel image will search this directory to load the modules.
The problem is that when you generate your own image by compiling the sources, this image will search the modules in “4.9.140” directory. So, you should also compile and install the modules in order to fix this problem.

Running "uname -a", you can check the modules id name that your image will search and it should match with the modules directory located in /lib/modules.
A quick fix that you can do is rename the 4.9.140-tegra directory to 4.9.140.

1 Like