I’m using the Orin Nano developer kit, and the camera is connected to the connector J20. This camera doesn’t have an I2C interface, and only the MIPI data lanes are connected. STREAM_ON and STREAM_OFF commands are sent externally to the camera. The goal is to receive the MIPI data through tegra-capture-vi.
Please provide the details to configure the device tree changes without an i2c-based camera sensor.
You can just use any of reference sensor driver as template and remove all of the i2c read/write code for it.
Have a search in the forum to reference.
Thanks
I am able to create the /dev/video0 device after inserting the kernel module. When I run the below command to capture the frame.
v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=frame.bin --stream-count=1
The frames are not captured and check the dmesg log for your reference.
dmesg_log2_09Jul23.txt (5.0 KB)
trace1_09Jul23.txt (4.2 KB)
Please check the captured trace log.
Camera sensor sends the MIPI data over 2 lane configuration with speed of 2.Gbps. Please find the attached device tree
custom-camera.dtsi (11.6 KB)
Set the lane_polarity=6
Have a check the device tree of IMX477 for much detail information.
Thanks
rtcpu_nvcsi_intr: tstamp:26965847666 class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x00000008
How to know the value of the status (0x00000008) and where can I get the information about the PHY_INTR0 register
Check the REG NVCSI_PHY_0_CILA_INTR_0_STATUS_CILA_0 in TRM.
I have connected my camera sensor to J21 of the Orin Nano developer kit. From the specifications, it has been mentioned that the J21 supports 1X2 and 1X4 lanes.
The CSI3 or CSI2 which port-index should be configured for 2-lane settings.
Did you add lane_polarity=6 to your camera dts to check??
Yes I added the lane_polarity property to Device tree file. When I started to capture the kernel crashed and device goes for reset.
From the camera sensor to Orin nano, c
trace_log1_12Jul23.txt (4.7 MB)
onnected the CSI2 of J21 connector. Still the frames are not captured. Please check the attached trace log.
The trace log tell CHANSEL_SHORT_FRAME that could be the output size(height) less than driver report.
The below is the mode 3 configurations in the device tree node.
mode3 {
mclk_khz = “104250”;
num_lanes = “2”;
tegra_sinterface = “serial_c”;
phy_mode = “DPHY”;
discontinuous_clk = “yes”;
dpcm_enable = “false”;
cil_settletime = “0”;
dynamic_pixel_bit_depth = “12”;
csi_pixel_bit_depth = “12”;
mode_type = “bayer”;
pixel_phase = “bggr”;
active_w = "640";
active_h = "1152";
readout_orientation = "0";
line_length = "640";
inherent_gain = "1";
mclk_multiplier = "4";
pix_clk_hz = "416666666";
min_gain_val = "0";
max_gain_val = "48";
gain_step_pitch = "0.3";
min_hdr_ratio = "1";
max_hdr_ratio = "1";
min_framerate = "1.5";
max_framerate = "30";
min_exp_time = "30";
max_exp_time = "660000";
embedded_metadata_height = "1";
};
Response for the lsupported formats.
v4l2-ctl -d /dev/video0 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture
[0]: 'BG12' (12-bit Bayer BGBG/GRGR)
Size: Discrete 256x320
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 1280x320
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 512x512
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 640x1152
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 512x640
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 2048x640
Interval: Discrete 0.033s (30.000 fps)
Size: Discrete 2560x640
Interval: Discrete 0.033s (30.000 fps)
The driver supports the 640x1152 resolution.
You can modify your sensor driver to report less line to narrow down it.
Beside I would suggest remove all of others modes to debug it.
Camera sensor is sending the MIPI CSI-2 data with speedof 2.5Gbps. How to send the deskew signal for Orin nano.
Check with vendor for it. Suppose could be some REG configure.
Thanks
2.5 Gbps with 2 lane and 12 Bpp
pixel_clk_hz = sensor data rate per lane (Mbps) * number of lanes / bits per pixel
= 2.5 Gbps * 2 / 12
= 2500 Mbps * 2 / 12
= 416666666
Can you just confirm whether the calculated value for pixel_clk_hz is correct.
The pix_clk_hz shouldn’t the key point.
The SOF/EOF for embedded header data is received and CHANSEL_PXL_EOF is not received.
CHANSEL_SHORT_FRAME and CHANSEL_NOMATCH are still showing in the trace logs.
Please check the attached log
trace_log3_18Jul23.txt (18.0 KB)
Can you please point out the register name in the TRM for below error.
tag:CHANSEL_NOMATCH channel:0x04 frame:0 vi_tstamp:263016863808 data:0x0000000000000249