I am porting a camera driver to a AGX Orin system, and streaming via v4l2-ctl already works. However, trying nvarguscamerasrc leads to the dreaded No cameras available message.
The nvargus-daemon debug log contains this error message when trying to open the camera in question:
SCF: Error BadParameter: NvCameraIspInitialize failed (in src/services/autocontrol/NvCameraIspDriver.cpp, function initialize(), line 160)
What does this error mean? Which parameter is checked in line 160?
Thank you!
*** Please note that this reply is generated by LLM automatically ***
The error message you’re encountering is likely related to the camera driver not being properly configured or supported by the nvargusdaemon. The nvargusdaemon is a service that manages the camera interface on NVIDIA Jetson devices.
The error message you’re seeing is likely due to a mismatch between the camera driver’s configuration and the expectations of the nvargusdaemon. The nvargusdaemon is a complex system that relies on various parameters and configurations to function correctly.
The line 160 you’re referring to is likely a reference to a specific line of code in the nvargusdaemon’s source code. Without access to the source code, it’s difficult to determine exactly which parameter is being checked. However, based on the context, it’s likely that the parameter being checked is related to the camera driver’s configuration or capabilities.
To troubleshoot this issue, you can try the following steps:
v4l2-ctl command with the -d option to specify the device and the -c option to specify the configuration.nvargus-daemon command with the -c option to specify the configuration.v4l2-ctl command with the -d option to specify the device and the -C option to specify the capabilities.In terms of comparing with other Jetson devices, the AGX Orin has a different camera interface and configuration compared to other Jetson devices. The AGX Orin uses a different camera driver and has different configuration options compared to other Jetson devices.
Here’s a comparison of the camera interfaces and configurations for different Jetson devices:
tegra-camera driver and has a different configuration compared to the AGX Orin.tegra-camera driver and has a similar configuration to the AGX Orin, but with some differences.tegra-camera driver and has a different configuration compared to the AGX Orin.In terms of the nvargusdaemon, it’s a common service across all Jetson devices, but the configuration and capabilities may vary depending on the device and camera driver.
To resolve the issue, you may need to modify the camera driver’s configuration or the nvargusdaemon’s configuration to match the expectations of the other component. You may also need to update the camera driver or the nvargusdaemon to a newer version that supports the necessary capabilities.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
hello tim.cassens,
may I know which Jetpack public release version you’re working with?
is this bring-up issue of porting issue? did you verify the camera stream at any previous Jetpack?
in general, that’s device tree problem when you’ve verify camera stream via v4l2 standard IOCTL.
please review the sensor mode settings, Property-Value Pairs.
it sometimes due to an incorrect Sensor Pixel Clock, please double check your pixel clock rate,
FYI, I usually using sensor CSI lane output rate for calculation.
for instance, pixel_clk_hz = sensor data rate per lane (Mbps) * number of lanes / bits per pixel
besides,
you may also give it another try to execute the commands below for boosting all the VI/CSI/ISP clocks.
sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
Hello Jerry,
this is with JetPack 6.0.
The driver (and camera parts of the device tree) works perfectly fine with Orin NX on many different carrier boards.
This is the first time we try an AGX Orin though.
A wrong pixel clock setting should really lead to image timeout rather than no-cameras-available, right?
To me, it looks like there is some validation going on, hence the question what exactly is checked in line 160.
hello tim.cassens,
let me examine your device tree,
please dump device tree into dts formats, please share the results for reference,
for instance,
$ sudo dtc -I fs -O dts /sys/firmware/devicetree/base > /tmp/123.dts
123.zip (45.9 KB)
Here it is.
hello tim.cassens,
please try revise your device tree property for confirmation.
here’re several suggestions within tegra-camera-platform{}.
(1) JP-6 has some updates, please remove devname property from tegra-camera-platform{} field.
(2) please update the sysfs-device-tree, please use /sys/firmware/devicetree/base/xxx instead of the symbolic path /proc/device-tree/xxx.
(3) please revise position property to have unique string for each camera.
for instance, you may assign below position property for your 8-cam system.
bottomleft // video0
centerleft // video1
centerright // video2
topleft // video3
bottomright // video4
topright // video5
bottomcenter // video6
topcenter // video7
(4) furthermore, it looks you’ve enable Jetson Virtual Channel with GMSL Camera Framework.
please note that, you must set the vc-id property for each sensor to match the vc_id property in the sensor mode device node.
you’ll need to set them in the tegra-capture-vi{} and also sensor properties.
please see-also reference driver, $public_sources/JP-6/kernel_src/hardware/nvidia/t23x/nv-public/overlay/tegra234-camera-ar0234-a00.dtsi
Thank you for the suggestions, I will give them a try.
The position field was indeed the problem; with that changed, nvarguscamerasrc finds the cameras.
How exactly is that validated? Is there a complete list of valid position names somewhere?
hello tim.cassens,
please refer to developer guide, Module Properties for the details of position property.
as you can see of CSI Connectivity, it supports up-to 16-cam with ISP, unfortunately, we did update the documentation to include all of them.
anyways, here’s a full list of camera position names.
| position property | video nodes |
|---|---|
| bottomleft | video0 |
| centerleft | video1 |
| centerright | video2 |
| topleft | video3 |
| bottomright | video4 |
| topright | video5 |
| bottomcenter | video6 |
| topcenter | video7 |
| frontcenter | video8 |
| rearcenter | video9 |
| leftcenter | video10 |
| rightcenter | video11 |
| frontleft | video12 |
| frontright | video13 |
| rearleft | video14 |
| rearright | video15 |
Thank you. I was looking for a list like that for a long time.
I also tried to remove the devname entries; however, that leads to no-cameras-available again.
nvargus-daemon logs for the camera that is supposed to work:
addSourceByIndex: index 0 and guid 0ud
NvPclOpen: ++++++++++++++++++++++
NvPclStateControllerOpen: Found GUID 0 match at index[5]
NvPclHwInitializeModule: allocate overrides pathname @ 0xffffb4935750
NvPclHwInitializeModule: allocate overrides pathname @ 0xffffb496ada0
NvPclHwInitializeModule: allocate overrides pathname @ 0xffffb496ad10
NvPclHwInitializeModule: allocate overrides pathname @ 0xaaaaf10f0e10
NvPclHwInitializeModule: allocate overrides pathname @ 0xffffb49f17a0
NvPclHwInitializeModule: allocate overrides pathname @ 0xffffb49f1010
LoadOverridesFile: looking for override file [/Calib/camera_override.isp] 1/16
CheckOverridesPermissions: stat(/Calib/camera_override.isp) call failed
LoadOverridesFile: looking for override file [/data/vendor/nvcam/settings/camera_overrides.isp] 2/16
CheckOverridesPermissions: stat(/data/vendor/nvcam/settings/camera_overrides.isp) call failed
LoadOverridesFile: looking for override file [/opt/nvidia/nvcam/settings/camera_overrides.isp] 3/16
CheckOverridesPermissions: stat(/opt/nvidia/nvcam/settings/camera_overrides.isp) call failed
LoadOverridesFile: looking for override file [/var/nvidia/nvcam/settings/camera_overrides.isp] 4/16
CheckOverridesPermissions: override file [/var/nvidia/nvcam/settings/camera_overrides.isp] has correct owner and mode
---- imager: Found override file [/var/nvidia/nvcam/settings/camera_overrides.isp]. ----
Imager: looking for override file [/mnt/factory/camera/factory.bin] 1/16
Imager: looking for override file [/Calib/factory.bin] 2/16
Imager: looking for override file [/Calib/calibration.bin] 3/16
Imager: looking for override file [(null)] 4/16
Imager: looking for override file [(null)] 5/16
Imager: looking for override file [(null)] 6/16
Imager: looking for override file [(null)] 7/16
Imager: looking for override file [(null)] 8/16
Imager: looking for override file [(null)] 9/16
Imager: looking for override file [(null)] 10/16
Imager: looking for override file [(null)] 11/16
Imager: looking for override file [(null)] 12/16
Imager: looking for override file [(null)] 13/16
Imager: looking for override file [(null)] 14/16
Imager: looking for override file [(null)] 15/16
Imager: looking for override file [(null)] 16/16
Imager: looking for override file [/data/vendor/nvcam/settings/factory.bin] 1/16
Imager: looking for override file [/data/vendor/nvcam/settings/topleft_tis_ar0234.bin] 2/16
Imager: looking for override file [/opt/nvidia/nvcam/settings/topleft_tis_ar0234.bin] 3/16
Imager: looking for override file [/var/nvidia/nvcam/settings/topleft_tis_ar0234.bin] 4/16
Imager: looking for override file [(null)] 5/16
Imager: looking for override file [(null)] 6/16
Imager: looking for override file [(null)] 7/16
Imager: looking for override file [(null)] 8/16
Imager: looking for override file [(null)] 9/16
Imager: looking for override file [(null)] 10/16
Imager: looking for override file [(null)] 11/16
Imager: looking for override file [(null)] 12/16
Imager: looking for override file [(null)] 13/16
Imager: looking for override file [(null)] 14/16
Imager: looking for override file [(null)] 15/16
Imager: looking for override file [(null)] 16/16
NvPclCreateDriver: Found NvPcl Driver Hal dev_name match (v4l2_sensor)
NvPclCreateDriver: Found a Driver name match (v4l2_sensor)
NvPclConnectDrivers: hImager was NULL, creating new imager
NvPclInitializeDrivers: v4l2_sensor ++++++++++++++++++
OFDPropertyGetString: could not read property [devnode-bus]
(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 111)
NvPclDriverInitializeData: Unable to initialize driver v4l2_sensor
NvPclInitializeDrivers: error: Failed to init camera sub module v4l2_sensor
NvPclStartPlatformDrivers: Failed to start module drivers
NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0xaaaaf10f0e10
NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0xffffb49f17a0
NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0xffffb49f1010
NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0xffffb4935750
NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0xffffb496ada0
NvPclCloseModuleDrivers: deallocate/free overrides pathname @ 0xffffb496ad10
NvPclStateControllerOpen: Failed ImagerGUID 0. (error 0xA000E)
NvPclStateControllerClose: Module topleft_tis_ar0234 closed
NvPclOpen: PCL Open Failed. Error: 0xf
NvPclClose: ++++++++++++++++++++++
NvPclClose: ----------------------
NvPclOpen: ----------------------
SCF: Error BadParameter: Sensor could not be opened. (in src/services/capture/CaptureServiceDeviceSensor.cpp, function getSourceFromGuid(), line 725)
SCF: Error BadParameter: (propagating from src/services/capture/CaptureService.cpp, function addSourceByGuid(), line 453)
SCF: Error BadParameter: (propagating from src/api/CameraDriver.cpp, function addSourceByIndex(), line 347)
SCF: Error BadParameter: (propagating from src/api/CameraDriver.cpp, function getSource(), line 519)
OK it looks like if I remove the symlink from sysfs-device-tree, I can indeed remove devname.
Nice catch with the missing vc-id; good thing I was only testing camera 0 so far.