I can get the raw data without any error. After demosaicing I can get a correct picture. However, when I run gst-launch-1.0, I can get only this error:
nvidia@tegra-ubuntu:~$ gst-launch-1.0 nvcamerasrc ! 'video/x-raw(memory:NVMM), width=3264, height=2448, framerate=30/1, format=NV12' ! nvvidconv flip-method=2 ! nvegltransform ! nveglglessink
Setting pipeline to PAUSED ...
Socket read error. Camera Daemon stopped functioning.....
gst_nvcamera_open() failed ret=0
ERROR: Pipeline doesn't want to pause.
Got context from element 'eglglessink0': gst.egl.EGLDisplay=context, display=(GstEGLDisplay)NULL;
ERROR: from element /GstPipeline:pipeline0/GstNvCameraSrc:nvcamerasrc0: GStreamer error: state change failed and some element failed to post a proper error message with the reason for the failure.
Additional debug info:
gstbasesrc.c(3354): gst_base_src_start (): /GstPipeline:pipeline0/GstNvCameraSrc:nvcamerasrc0:
Failed to start
Setting pipeline to NULL ...
Caught SIGSEGV
#0 0x0000007f941ae130 in pthread_join (threadid=547890934272,
#1 0x0000007f94264e40 in ?? () from /lib/aarch64-linux-gnu/libglib-2.0.so.0
#2 0x0000000000000011 in ?? ()
Spinning. Please run 'gdb gst-launch-1.0 1960' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
The jetpack version is R28.1, and the camera sensor is OV8856, an 8MP mipi sensor. I’ve developed several camera sensor drivers for TX2, in my previous experience, after the drivers worked with v4l2-ctl, they should work with gst-launch-1.0 as well except this one.
Could anyone help me? Thanks a lot.
Did you launch the APP from ssh? Please try on the tegra ubuntu OS. If still not working please enable more log by Jetson TX2 Camera BringUp - eLinux.org “To enable logs from user-space for more details”
ERROR: from element /GstPipeline:pipeline0/GstNvCameraSrc:nvcamerasrc0: GStreamer error: state change failed and some element failed to post a proper error message with the reason for the failure.
After compared the logs of a working sensor and a failed sensor, I believe the following error is the key. I’m just confused that why it said V4L2Device is not available while I can capture the image via v4l2-ctl?
(NvOdmDevice) Error ModuleNotPresent: V4L2Device not available (in dvs/git/dirty/git-master_linux/camera-partner/imager/src/V4L2Device.cpp, function findDevice(), line 231)
(NvOdmDevice) Error ModuleNotPresent: (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/V4L2Device.cpp, function initialize(), line 54)
(NvOdmDevice) Error ModuleNotPresent: (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function initialize(), line 97)
NvPclDriverInitializeData: Unable to initialize driver v4l2_sensor
NvPclInitializeDrivers: error: Failed to init camera sub module v4l2_sensor
NvPclStartPlatformDrivers: Failed to start module drivers
tegra-camera-platform {
compatible = "nvidia, tegra-camera-platform";
/**
* The general guideline for naming badge_info contains 3 parts, and is as follows,
* The first part is the camera_board_id for the module; if the module is in a FFD
* platform, then use the platform name for this part.
* The second part contains the position of the module, ex. “rear” or “front”.
* The third part contains the last 6 characters of a part number which is found
* in the module's specsheet from the vender.
*/
modules {
module0 {
badge = "e3326_front_P5V27C";
position = "rear";
orientation = "1";
drivernode0 {
/* Declare PCL support driver (classically known as guid) */
pcl_id = "v4l2_sensor";
/* Driver's v4l2 device name */
devname = "ov5693 6-0036";
/* Declare the device-tree hierarchy to driver instance */
proc-device-tree = "/proc/device-tree/host1x/i2c@546c0000/ov5693_c@36";
};
drivernode1 {
/* Declare PCL support driver (classically known as guid) */
pcl_id = "v4l2_lens";
proc-device-tree = "/proc/device-tree/e3326_lens_ov5693@P5V27C/";
};
};
};
};
As some additional information, there is a kernel build target (after configuring) for “make dtbs”. This assembles a number of “.dts” and “.dtsi” files, and then does the equivalent of what you find in that above URL. The Jetson itself essentially has a binary format on it which is a result of that kernel build target, and this can be reverse compiled. There may be some very slight edits in CBOOT to the one actually in a partition, but much of it is an exact copy. It depends on the release. The dts “source” form is human readable. The dtb “binary” format is what the system reads.
Important: “make dtbs” is 100% independent of the actual kernel and kernel build. Changing the device tree in no way changes the kernel code in any direct manner. However, drivers make reference to some symbols, and the device tree is how the driver looks up the value belonging to that symbol. So the two work together, but only at run time…changing data values rather than logic.
Hello,
Where can I find the devname in kernel sensor driver ?
For example devname is “ov5693 6-0036” in my device tree. Do I need to find the same string in driver source code ? Could you please spesify spesific source file if you could ?
Someone else will need to answer that, but as a general tip, some hardware is “plug n play”, meaning the hardware self-reports what it is and where to find it…then a driver can be installed to the device. In the case of hardware being described in a device tree the tree will often describe where to find the hardware and what the hardware is compatible with…the things which are missing when a device cannot self-report. This often includes an association of device name with device driver, along with some method of finding the device (e.g., a physical address).
Someone else will need to answer the specifics of your question since I don’t work with cameras.