Instructions:
DTS parameters are basically the same
Camera Driver has also remained consistent
All versions work fine in JP5.x
However, it is not possible to draw in JP6.1 version
No matter how you adjust the camera parameters of the DTS， camera all can not capture Successful
Hi,
For the camera basic functionality first needs to check the device and driver configuration.
You can reference to below program guide for the detailed information of device tree and driver implementation.
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/CameraDevelopment/SensorSoftwareDriverProgramming.html?highlight=programing#sensor-software-driver-programming
Please refer to Applications Using V4L2 IOCTL Directly by using V4L2 IOCTL to verify basic camera functionality.
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/CameraDevelopment/SensorSoftwareDriverProgramming.html?highlight=programing#to-run-a-v4l2-ctl-test
Once confirm the configure and still failed below link help to get log and some information and some tips for debug.
https://elinux.org/Jetson/l4t/Camera_BringUp#Steps_to_enable_more_debug_messages
Thanks!
hello JiaZW,
you may check developer guide, Camera Driver Porting.
please see-also Topic 310858 for some known changes when porting DTS from JP-5 to JP-6.
besides, please refer to Topic 318537 to debug discarding frame corr_err messages
I have completed the migration of the drivers,
the creation of video devices is normal,
and they have been modified according to Topic 310858.
But I still can’t draw a picture;
There’s no clue at all
compatible = "nvidia,veyecam";
reg = <0x50>;
devnode = "video0";
/* Physical dimensions of sensor */
physical_w = "5.6";
physical_h = "3.1";
/* Define any required hw resources needed by driver */
/* ie. clocks, io pins, power sources */
avdd-reg = "vana";
iovdd-reg = "vif";
/* Enable EEPROM support */
has-eeprom = "0";
mode0 {
mclk_khz = "24000";
num_lanes = "4";
tegra_sinterface = "serial_a";
vc_id = "0";
phy_mode = "DPHY";
discontinuous_clk = "yes";
dpcm_enable = "false";
cil_settletime = "0";
active_w = "1920";
active_h = "1080";
mode_type = "yuv";
pixel_phase = "uyvy";
csi_pixel_bit_depth = "8";
readout_orientation = "0";
line_length = "1920";
inherent_gain = "1";
mclk_multiplier = "5.184";
pix_clk_hz = "124416000";
serdes_pix_clk_hz = "700000000";
hello JiaZW,
please execute $ v4l2-ctl -d /dev/video0 --list-formats-ext to check the sensor supported formats.
please also share your v4l capture pipeline for cross-check all the settings.
hello JiaZW,
could you please try v4l2 IOCTL to test the stream,
for example,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=UYVY --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100
Use this cmd
Also nothing
hello JiaZW,
it looks no validate frames has received,
please try… discontinuous_clk = "no"; or, increase serdes_pix_clk_hz (add 15% or more) for testing.
try a try
I tested it here, and it didn’t work
(1) discontinuous_clk = “no” to
discontinuous_clk = “yes”
Have the same effect
(2) serdes_pix_clk_hz
700M
750M
800M
With the same effect
Is there anything else I can do ？
hello JiaZW,
is it possible to arrange hardware sources to probe the high speed MIPI signaling to examine the waveform?
This one’s been tested, too. MIPI is normal
hello JiaZW,
how about running with below?
$ gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=300 ! 'video/x-raw, width=1920, height=1080, framerate=30/1, format=UYVY' ! nvvidconv ! fpsdisplaysink text-overlay=0 name=sink_0 video-sink=fakesink sync=0 -v
