Argus fails to detect IMX477 camera sensor

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Hi Jetson experts,

I’m working on bring-up of Arducam IMX477 camera over a custom board with
DS90UB953 serializer, and D3 Engineering board with DS90UB960 deserializer.
The development board is Jetson AGX. My current platform is based on L4T
32.6.1 release, and the integrated imx477.c driver with some minor
modifications.

I managed to capture frames in bayer format from the sensor using plain v4l2
with the v4l2-ctl --stream-mmap command.

I’m now struggling with Argus integration. Simple gstreamer command like:

gst-launch-1.0 nvarguscamerasrc

gives this error:

Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:725 No cameras available

It turns out that nvarguscamerasrc connects to nvargus-daemon to get camera
capture data. But nvargus-daemon encounters some error in the process. The
logs do not reveal the reason. Since sources for nvargus-daemon are not
publicly available I have no idea what is going on. Here is what the log
shows:

Sep 01 16:15:53 ubuntu nvargus-daemon[6561]: SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function addSourceByIndex(), line 305)
Sep 01 16:15:53 ubuntu nvargus-daemon[6561]: SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function getSource(), line 471)
Sep 01 16:51:31 ubuntu nvargus-daemon[6561]: Acquiring SCF Camera device source via index 0 has failed. === gst-launch-1.0[8037]: CameraProvider initialized (0x7f7480fed0)=== gst-launch-1.0[8037]: CameraProvider destroyed (0x7f7480fed0)=== gst-launch-1.0[8037]: Connection closed (7F7C0F31D0)=== gst-launch-1.0[8037]: Connection cleaned up (7F7C0F31D0)=== gst-launch-1.0[8191]: Connection established (7F7C0F31D0)OFParserListModules: module list: /proc/device-tree/tegra-camera-platform/modules/module0
Sep 01 16:51:31 ubuntu nvargus-daemon[6561]: NvPclHwGetModuleList: No module data found
Sep 01 16:51:32 ubuntu nvargus-daemon[6561]: OFParserGetVirtualDevice: NVIDIA Camera virtual enumerator not found in proc device-tree
Sep 01 16:51:32 ubuntu nvargus-daemon[6561]: ---- imager: Found override file [/var/nvidia/nvcam/settings/camera_overrides.isp]. ----
Sep 01 16:51:32 ubuntu nvargus-daemon[6561]: SCF: Error BadParameter:  (propagating from src/services/capture/CaptureServiceDeviceSensor.cpp, function open(), line 139)
Sep 01 16:51:32 ubuntu nvargus-daemon[6561]: SCF: Error BadParameter:  (propagating from src/services/capture/CaptureServiceDeviceSensor.cpp, function getSourceFromGuid(), line 579)
Sep 01 16:51:32 ubuntu nvargus-daemon[6561]: SCF: Error BadParameter:  (propagating from src/services/capture/CaptureService.cpp, function addSourceByGuid(), line 437)
Sep 01 16:51:32 ubuntu nvargus-daemon[6561]: SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function addSourceByIndex(), line 305)
Sep 01 16:51:32 ubuntu nvargus-daemon[6561]: SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function getSource(), line 471)

I have a similar working setup using Leopard Imaging IMX477 camera, based on
older L4T 32.5.1. The strange thing is that I see similar nvargus-daemon error
messages on the log of the working setup.

I noticed that in the working setup nvargus-daemon created nvcam_cache_*.bin
files under /var/nvidia/nvcam/settings/. In the non-working setup no files are
created.

Any idea what I might be missing?

Thanks.

3

Have a check the devname and proc-device-tree incorrect cause the problem. Make sure the bus # is correct

			module0 {
1639 				badge = "e3333_bottomleft_P5V27C";
1640 				position = "bottomleft";
1641 				orientation = "1";
1642 				drivernode0 {
1643 					pcl_id = "v4l2_sensor";
1644 					devname = "ov5693 30-0036";
1645 					proc-device-tree = "/proc/device-tree/i2c@3180000/tca9548@77/i2c@0/ov5693_a@36";
1646 				};
1647 				drivernode1 {
1648 					pcl_id = "v4l2_lens";
1649 					proc-device-tree = "/proc/device-tree/e3333_lens_ov5693@P5V27C/";
1650 				};
1651 			};
4

Hi Shane,

devname and proc-device-tree look correct to me. Here are the relevant kernel log messages:

[    9.965397] imx477 2-0060: tegracam sensor driver:imx477_v2.0.6
[   10.268348] tegra194-vi5 15c10000.vi: subdev imx477 2-0060 bound

This is the device-tree snippet:

                modules {
                        module0 {
                                status = "okay";
                                badge = "galen_front_IMX477";
                                position = "front";
                                orientation = "1";
                                drivernode0 {
                                        pcl_id = "v4l2_sensor";
                                        devname = "imx477 2-0060";
                                        proc-device-tree = "/proc/device-tree/i2c@3180000/ub960@30/link@0/ub953_0@40/imx477@60";
                                };
                        };
                };

Anything else I should check?

Thanks,
Baruch

5

This looks like not right.

proc-device-tree = “/proc/device-tree/i2c@3180000/ub960@30/link@0/ub953_0@40/imx477@60”;

Should be
proc-device-tree = “/proc/device-tree/i2c@3180000/imx477@60”;

6

Hi Shane,

This is where the imx477 node is in the device-tree hierarchy:

$ ls /proc/device-tree/i2c@3180000/ub960@30/link@0/ub953_0@40/imx477@60
compatible    linux,phandle  name           physical_h  reg
deserializer  mode0          phandle        physical_w  sensor_model
devnode       mode1          physical-addr  ports       status
$ ls /proc/device-tree/i2c@3180000/imx477@60
ls: cannot access '/proc/device-tree/i2c@3180000/imx477@60': No such file or directory
7

Any reason for this define?
Can you move it to imx477 to /proc/device-tree/i2c@3180000/ to try.

8

The reason is that the imx477 sensor is behind serializer (ub953) and deserializer (ub960). We need them to transfer sensor date over coax cable. These ser/des chips also proxy the I2C slave on the imx477 sensor. So this represents the actual hardware. V4L2 works just fine in this setup. Can Argus do that as well? If not, is there an alternative way to inject Bayer frames into the Argus image processing chain?

Thanks,
Baruch

9

I think you both of them can place at the same layer behind the i2c@318000 like reference gmsl + imx390 reference board.