Radar data through MIPI CSI-2 interface without I2C - Device-tree issues

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
, ,
1

Hi all,
I am trying to configure my Jetson Nano to read a radar data stream over MIPI interface.
My sensor does not use I2C interface but instead is programmed through SPI with a self contained app, while the driver should just care about receiving the data stream.

My issue is referred also in these posts:

Jetson AGX Xavier and TI MMWAVE Radar raw data capture over CSI
https://forums.developer.nvidia.com/t/receives-csi-data-without-i2c-and-device-tree-questions-for-none-camera-sensor

At first, I tried to reverse-engineer the dtb that was being flashed in a dts and start modifying from there.
This approach led me to a /dev/video0 showing up but no data was being received, cause I used the imx185.c file as template and I did not disable plugin manager, so I decided to start again from the actual dts sources.

I am using r32.6.1, so I downloaded sources and followed the guide:

at Using the Main Platform Device Tree File it’s told to change some files that are not in my folders.
So I changed these instead:
tegra210-porg-p3448-common.dtsi → remove “porg-plugin-manager/tegra210-porg-plugin-manager.dtsi”
tegra210-jetson-cv-base-p2597-2180-a00.dts → replace “jetson-platforms/tegra210-jetson-cv-camera-modules.dtsi” with a file that is a copy of this but includes also my sensor configuration (“my_sensor.dtsi”).

I think this is wrong though, because the dts file seems to refer to a different platform and I think it is not even included when building “tegra210-p3448-0000-p3449-0000-b00.dtb” through the ./nvbuild.sh script.

I modified that file because it’s the only file referring to “camera-modules” .

Result: obviously, /dev/video0 is not even showing up anymore.

What are the files that should be changed instead?

3

I think you can continuous use the first method and enable the debug print in csi2_fops.c/vi2_fops.c to check the error message for the capture failed.

4

Hi ShaneCCC, thanks for the reply.
I already had put printk into the kernel, and this is the output I get when I insert driver (from 128.186120) and when I $ cat /dev/video0 (from 128.188587):

[  128.186120] SET MODE CALLED
[  128.186127] TEGRA_CAMERA_CID_GAIN - ctrl: ffffffc0f3f44800 min_gain_val: 0 max_gain_val: 480 step_gain_val: 3 default_gain: 0
[  128.186129] __v4l2_ctrl_modify_range
[  128.186132] __v4l2_ctrl_modify_range ctrl->type:5
[  128.186133] __v4l2_ctrl_modify_range check_range
[  128.186136] TEGRA_CAMERA_CID_FRAME_RATE
[  128.186138] __v4l2_ctrl_modify_range
[  128.186140] __v4l2_ctrl_modify_range ctrl->type:5
[  128.186142] __v4l2_ctrl_modify_range check_range
[  128.186146] TEGRA_CAMERA_CID_FRAME_RATE - ctrl: ffffffc0f79e2e00 min_framerate: 20000000 max_framerate: 30000000 step_framerate: 1 default_framerate: 28000000
[  128.186147] __v4l2_ctrl_modify_range
[  128.186149] __v4l2_ctrl_modify_range ctrl->type:5
[  128.186150] __v4l2_ctrl_modify_range check_range
[  128.186153] START STREAM CALLED
[  128.186271] STOP STREAM CALLED
[  128.186439] vi2_channel_setup_queue
[  128.186698] vi2_channel_start_streaming
[  128.186888] tegra_channel_kthread_capture_start
[  128.186891] tegra_channel_capture_frame
[  128.186893] tegra_channel_capture_frame_single_thread
[  128.188556] SET MODE CALLED
[  128.188561] TEGRA_CAMERA_CID_GAIN - ctrl: ffffffc0f3f44800 min_gain_val: 0 max_gain_val: 480 step_gain_val: 3 default_gain: 0
[  128.188563] __v4l2_ctrl_modify_range
[  128.188566] __v4l2_ctrl_modify_range ctrl->type:5
[  128.188567] __v4l2_ctrl_modify_range check_range
[  128.188570] TEGRA_CAMERA_CID_FRAME_RATE
[  128.188572] __v4l2_ctrl_modify_range
[  128.188574] __v4l2_ctrl_modify_range ctrl->type:5
[  128.188576] __v4l2_ctrl_modify_range check_range
[  128.188579] TEGRA_CAMERA_CID_FRAME_RATE - ctrl: ffffffc0f79e2e00 min_framerate: 20000000 max_framerate: 30000000 step_framerate: 1 default_framerate: 28000000
[  128.188581] __v4l2_ctrl_modify_range
[  128.188583] __v4l2_ctrl_modify_range ctrl->type:5
[  128.188585] __v4l2_ctrl_modify_range check_range
[  128.188587] START STREAM CALLED
[  128.188594] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93500a0
[  128.188597] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93500a0
[  128.188601] syncpt_op().update_min val=34
[  128.188603] syncpt_poll=0
[  128.390101] nvhost_syncpt_wait_timeout_ext master=ffffffc0f9350018 sp=ffffffc0f93500a0 pnvts=ffffffc075207d28 ret=-11
[  128.390107] nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f9511c00 chan->syncpt[index][0]=12  thresh[index]=35 chan->timeout=50
[  128.390115] video4linux video0: frame start syncpt timeout!0
[  128.396013] tegra_channel_capture_frame
[  128.396015] tegra_channel_capture_frame_single_thread
[  128.396031] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93500a0
[  128.396033] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93500a0
[  128.396036] syncpt_op().update_min val=35
[  128.396039] syncpt_poll=0
[  128.598081] nvhost_syncpt_wait_timeout_ext master=ffffffc0f9350018 sp=ffffffc0f93500a0 pnvts=ffffffc075207d28 ret=-11
[  128.598087] nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f9511c00 chan->syncpt[index][0]=12  thresh[index]=36 chan->timeout=50
[  128.598094] video4linux video0: frame start syncpt timeout!0
[  128.604708] tegra_channel_capture_frame
[  128.604710] tegra_channel_capture_frame_single_thread
[  128.604723] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93500a0
[  128.604726] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93500a0
[  128.604730] syncpt_op().update_min val=36
[  128.604733] syncpt_poll=0
[  128.806091] nvhost_syncpt_wait_timeout_ext master=ffffffc0f9350018 sp=ffffffc0f93500a0 pnvts=ffffffc075207d28 ret=-11
[  128.806098] nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f9511c00 chan->syncpt[index][0]=12  thresh[index]=37 chan->timeout=50
[  128.806105] video4linux video0: frame start syncpt timeout!0
[  128.812669] tegra_channel_capture_frame
[  128.812672] tegra_channel_capture_frame_single_thread
[  128.812684] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93500a0
[  128.812687] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93500a0
[  128.812690] syncpt_op().update_min val=37
[  128.812692] syncpt_poll=0
[  129.014038] nvhost_syncpt_wait_timeout_ext master=ffffffc0f9350018 sp=ffffffc0f93500a0 pnvts=ffffffc075207d28 ret=-11
[  129.014044] nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f9511c00 chan->syncpt[index][0]=12  thresh[index]=38 chan->timeout=50
[  129.014050] video4linux video0: frame start syncpt timeout!0
[  129.020717] tegra_channel_capture_frame
[  129.020719] tegra_channel_capture_frame_single_thread
[  129.020731] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93500a0
[  129.020734] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93500a0
[  129.020738] syncpt_op().update_min val=38
[  129.020740] syncpt_poll=0
[  129.222110] nvhost_syncpt_wait_timeout_ext master=ffffffc0f9350018 sp=ffffffc0f93500a0 pnvts=ffffffc075207d28 ret=-11
[  129.222116] nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f9511c00 chan->syncpt[index][0]=12  thresh[index]=39 chan->timeout=50
[  129.222123] video4linux video0: frame start syncpt timeout!0

This is where I stopped because I started to think this was the wrong path.
Do you need any other debug print?

Note:

  • my vi2_fops struct is based on the imx185 one, but everything inside functions is commented out. This is because…
  • my configuration is set with SPI through a standalone app.
  • I know packets are traversing the CSI2 channel because we captured them with osciloscope.

Regards,
Andrea

5

Enable the dev_dbg print in tegra_csi_status() and tegra_channel_capture_error()

6

Hi ShaneCCC, this is the output now:

[  528.519022] START STREAM CALLED
[  528.519036] vi 54080000.vi: Calibrate csi port 0
[  528.519212] STOP STREAM CALLED
[  528.519476] vi2_channel_setup_queue
[  528.519869] vi2_channel_start_streaming
[  528.520254] tegra_channel_kthread_capture_start
[  528.520257] tegra_channel_capture_frame
[  528.520259] tegra_channel_capture_frame_single_thread
[  528.521813] vi 54080000.vi: cil_settingtime was autocalculated
[  528.521818] vi 54080000.vi: csi clock settle time: 13, cil settle time: 10
[  528.521831] SET MODE CALLED
[  528.521834] TEGRA_CAMERA_CID_GAIN - ctrl: ffffffc0e19b6700 min_gain_val: 0 max_gain_val: 480 step_gain_val: 3 default_gain: 0
[  528.521837] __v4l2_ctrl_modify_range
[  528.521838] __v4l2_ctrl_modify_range ctrl->type:5
[  528.521840] __v4l2_ctrl_modify_range check_range
[  528.521842] TEGRA_CAMERA_CID_FRAME_RATE
[  528.521844] __v4l2_ctrl_modify_range
[  528.521846] __v4l2_ctrl_modify_range ctrl->type:5
[  528.521848] __v4l2_ctrl_modify_range check_range
[  528.521851] TEGRA_CAMERA_CID_FRAME_RATE - ctrl: ffffffc0e19b6600 min_framerate: 20000000 max_framerate: 30000000 step_framerate: 1 default_framerate: 28000000
[  528.521853] __v4l2_ctrl_modify_range
[  528.521854] __v4l2_ctrl_modify_range ctrl->type:5
[  528.521856] __v4l2_ctrl_modify_range check_range
[  528.521858] START STREAM CALLED
[  528.521864] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f92648a0
[  528.521866] nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f92648a0
[  528.521870] syncpt_op().update_min val=32
[  528.521872] syncpt_poll=0
[  528.722911]  nvhost_syncpt_wait_timeout_ext master=ffffffc0f9264818 sp=ffffffc0f92648a0 pnvts=ffffffc0e1997d28 ret=-11
[  528.722985]  nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f94cc000 chan->syncpt[index][0]=12  thresh[index]=33 chan->timeout=50
[  528.723055] video4linux video0: frame start syncpt timeout!0
[  528.729570] video4linux video0: TEGRA_VI_CSI_ERROR_STATUS 0x00000000
[  528.729597] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  528.729614] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000000
[  528.729631] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00000000
[  528.731899] vi 54080000.vi: cil_settingtime was autocalculated
[  528.731918] vi 54080000.vi: csi clock settle time: 13, cil settle time: 10
[  528.731955]  tegra_channel_capture_frame
[  528.731961]  tegra_channel_capture_frame_single_thread
[  528.731996]  nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f92648a0
[  528.732010]  nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f92648a0
[  528.732023]  syncpt_op().update_min val=33
[  528.732030]  syncpt_poll=0
[  528.938835]  nvhost_syncpt_wait_timeout_ext master=ffffffc0f9264818 sp=ffffffc0f92648a0 pnvts=ffffffc0e1997d28 ret=-11
[  528.938901]  nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f94cc000 chan->syncpt[index][0]=12  thresh[index]=34 chan->timeout=50
[  528.938970] video4linux video0: frame start syncpt timeout!0
[  528.945500] video4linux video0: TEGRA_VI_CSI_ERROR_STATUS 0x00000000
[  528.945526] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  528.945557] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000000
[  528.945575] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00000000
[  528.948028] vi 54080000.vi: cil_settingtime was autocalculated
[  528.948063] vi 54080000.vi: csi clock settle time: 13, cil settle time: 10
[  528.948121]  tegra_channel_capture_frame
[  528.948130]  tegra_channel_capture_frame_single_thread
[  528.948166]  nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f92648a0
[  528.948175]  nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f92648a0
[  528.948189]  syncpt_op().update_min val=34
[  528.948196]  syncpt_poll=0
[  529.150783]  nvhost_syncpt_wait_timeout_ext master=ffffffc0f9264818 sp=ffffffc0f92648a0 pnvts=ffffffc0e1997d28 ret=-11
[  529.150846]  nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f94cc000 chan->syncpt[index][0]=12  thresh[index]=35 chan->timeout=50

Thanks for your interest.

7

The status are 0 that could be incorrect port-index in device tree or sensor didn’t output signal to Nano.

8

Hi ShaneCCC,

thanks to your input I obtained a different error.

[  221.878968] video4linux video0: frame start syncpt timeout!0
[  221.886633] video4linux video0: TEGRA_VI_CSI_ERROR_STATUS 0x00000000
[  221.886669] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[  221.886698] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000010
[  221.886739] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00040040
[  221.886954] vi 54080000.vi: csi clock settle time: 13, cil settle time: 85

According to this post [CSI error - explanation] the problem is relative to cil_settime in device-tree.
At first I had put 0, so that it could be auto computed, but the line read

vi 54080000.vi: csi clock settle time: 13, cil settle time: 10

So I thought putting a number higher than 13 would solve the issue.
As you can see above, the error remains the same.
This happens before I even run my standalone app, and running it does not change anything.

Am I looking in the right direction?

9

This error tell. Please make sure the sensor output as MIPI spec.

CILA_CTRL_ERR: Control Error. Set when CIL-A detects LP state 01 or 10 followed by a stop state (LP11)
instead of transitioning into the Escape mode or Turn Around mode (LP00).
11

Hi ShaneCCC,

sorry for the late answer. I would like to add some details before closing the post:
last time I did not completely describe the error.
I tried lots of configurations, found this:
When I set the port bindings inside vi, nvcsi to != 0 → cat /dev/video0 shows CIL=0x10 CILX=0x40, plus I get a MIPI calibration timeout error. So I think these bindings are wrong.
When I set the bindings inside vi, nvcsi to = 0 → regardless of port number inside cam_i2c_mux (0,1,2,3,4) I get:

[   98.402722] video4linux video0: frame start syncpt timeout!0
[   98.408545] video4linux video0: TEGRA_VI_CSI_ERROR_STATUS 0x00000000
[   98.408552] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[   98.408557] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000010
[   98.408563] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00040040
[   98.408608] vi 54080000.vi: csi clock settle time: 13, cil settle time: 20
[   98.408713]  tegra_channel_capture_frame
[   98.408715]  tegra_channel_capture_frame_single_thread
[   98.408727]  nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93090a0
[   98.408730]  nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93090a0
[   98.408733]  syncpt_op().update_min val=68
[   98.408735]  syncpt_poll=0
[   98.610740]  nvhost_syncpt_wait_timeout_ext master=ffffffc0f9309018 sp=ffffffc0f93090a0 pnvts=ffffffc0b77b3d28 ret=-11
[   98.610748]  nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f951cc00 chan->syncpt[index][0]=12  thresh[index]=69 chan->timeout=50
[   98.610755] video4linux video0: frame start syncpt timeout!0
[   98.616483] video4linux video0: TEGRA_VI_CSI_ERROR_STATUS 0x00000000
[   98.616493] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[   98.616499] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000010
[   98.616505] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00040041
[   98.616556] vi 54080000.vi: csi clock settle time: 13, cil settle time: 20
[   98.616572]  tegra_channel_capture_frame
[   98.616574]  tegra_channel_capture_frame_single_thread
[   98.616585]  nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93090a0
[   98.616591]  nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93090a0
[   98.616595]  syncpt_op().update_min val=69
[   98.616599]  syncpt_poll=0
[   98.818795]  nvhost_syncpt_wait_timeout_ext master=ffffffc0f9309018 sp=ffffffc0f93090a0 pnvts=ffffffc0b77b3d28 ret=-11
[   98.818802]  nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f951cc00 chan->syncpt[index][0]=12  thresh[index]=70 chan->timeout=50
[   98.818809] video4linux video0: frame start syncpt timeout!0
[   98.825350] video4linux video0: TEGRA_VI_CSI_ERROR_STATUS 0x00000000
[   98.825357] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000000
[   98.825362] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000000
[   98.825366] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00000000
[   98.825419] vi 54080000.vi: csi clock settle time: 13, cil settle time: 20
[   98.825433]  tegra_channel_capture_frame
[   98.825434]  tegra_channel_capture_frame_single_thread
[   98.825445]  nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93090a0
[   98.825448]  nvhost_get_syncpt_owner_struct id=12 sp=ffffffc0f93090a0
[   98.825451]  syncpt_op().update_min val=70
[   98.825453]  syncpt_poll=0
[   99.026772]  nvhost_syncpt_wait_timeout_ext master=ffffffc0f9309018 sp=ffffffc0f93090a0 pnvts=ffffffc0b77b3d28 ret=-11
[   99.026778]  nvhost_syncpt_wait_timeout_ext index =0 chan->vi->ndev=ffffffc0f951cc00 chan->syncpt[index][0]=12  thresh[index]=71 chan->timeout=50

explaination:

  • before my application makes the radar device trigger frames, I have CILX error 0x40040 (CIL=0x10).
  • as soon as my application starts the trigger, CILX error = 0x40041(CIL=0x10).
  • after that, all readings are always 0x0 (both CILX and CIL).

Can you help me understand what is going on here?
I think the CILX error was only related to the fact that the radar was not emitting frames.

Best regards,
Andrea

12

The error tell the MIPI timing doesn’t match the MIPI spec.

Thanks

13

Hi ShaneCCC,

we did a deep dive in the radar parameters and there was actually some misconfiguration.
We now configured the sensor to output a predefined pattern and were able to prove with the oscilloscope that the output is as expected.

This is the sensor output configuration:
A) 512samples (=w), 128chirps(=h)
B) 16 bits of pattern data (= 1 sample)
C) 2 MIPI CSI lanes
D) clock: 150 MHz DDR → 1 bit = 3.333 ns

On the oscilloscope we see 13654ns worth of data → expected from:
64 x 4 x 2(A) x 3.333(D) x16(B) / 2(C)=13651ns → this is OK.

This is device tree configuration:

a) active_w = line_length = 512 ; active_h=128 (->A)
b) pixel_clk_hz = 37500000 (150M*2 (DDR) * 2(CSI LANES) / 16 = 37.5M)
c) csi_pixel_bit_depth = dynamic_pixel_bit_length = 16
d) mode_type=yuv ; pixel_phase=yuyv (just picked a format with 16 bits)
e) num_lanes = 2

Still we are having errors on Jetson CSI’s driver ( in particular, same as above but different error numbers when the frame is triggered):

$ v4l2-ctl --set-fmt-video=width=512,height=128,pixelformat=YUYV --stream-mmap --set-ctrl=sensor_mode=0 --stream-count=100 -d /dev/video0

TRIGGERED
[  568.802013] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000012
[  568.802032] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00060061
[  569.217999] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000013
[  569.218016] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00070060
[  569.426300] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000003
[  569.426351] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00030020
[  569.633801] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000013
[  569.633851] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00060060
[  570.897957] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000002
[  570.897973] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00020020

NOT TRIGGERED
[  579.633971] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000011
[  579.633989] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00040040

Seems to me that the various error states are just telling that there are timing issues.

Do you have any suggestion on what to tweak?

14

Looks like the settle time problem.

mipi_timeing
mipi_timeing2126×1353 148 KB

15

awr_CIL_logs.txt (414.0 KB)
Hi ShaneCCC,

I brute forced all the cil_settletime configurations in the acceptable range span, which for Jetson Nano is:

image

I tried all values from 5 to 37.
Errors are varying, seems that best interval is 30-33.
Attached you can find the log.
awr_CIL_logs.txt (623.7 KB)

I am wondering if this could be a pixel parsing error.
I cannot set raw data in the device tree because the interpreter of that parameter in the kernel is:

// sensor_common.c
static int extract_pixel_format(
	const char *pixel_t, u32 *format)
{
	size_t size = strnlen(pixel_t, OF_MAX_STR_LEN);

	if (strncmp(pixel_t, "bayer_bggr10", size) == 0)
		*format = V4L2_PIX_FMT_SBGGR10;
	else if (strncmp(pixel_t, "bayer_rggb10", size) == 0)
		*format = V4L2_PIX_FMT_SRGGB10;
	else if (strncmp(pixel_t, "bayer_grbg10", size) == 0)
		*format = V4L2_PIX_FMT_SGRBG10;
	else if (strncmp(pixel_t, "bayer_gbrg10", size) == 0)
		*format = V4L2_PIX_FMT_SGBRG10;
	else if (strncmp(pixel_t, "bayer_bggr12", size) == 0)
		*format = V4L2_PIX_FMT_SBGGR12;
	else if (strncmp(pixel_t, "bayer_rggb12", size) == 0)
		*format = V4L2_PIX_FMT_SRGGB12;
	else if (strncmp(pixel_t, "bayer_gbrg12", size) == 0)
		*format = V4L2_PIX_FMT_SGBRG12;
	else if (strncmp(pixel_t, "bayer_grbg12", size) == 0)
		*format = V4L2_PIX_FMT_SGRBG12;
	else if (strncmp(pixel_t, "rgb_rgb88824", size) == 0)
		*format = V4L2_PIX_FMT_RGB24;
	else if (strncmp(pixel_t, "bayer_wdr_pwl_rggb12", size) == 0)
		*format = V4L2_PIX_FMT_SRGGB12;
	else if (strncmp(pixel_t, "bayer_wdr_pwl_gbrg12", size) == 0)
		*format = V4L2_PIX_FMT_SGBRG12;
	else if (strncmp(pixel_t, "bayer_wdr_pwl_grbg12", size) == 0)
		*format = V4L2_PIX_FMT_SGRBG12;
	else if (strncmp(pixel_t, "bayer_wdr_dol_rggb10", size) == 0)
		*format = V4L2_PIX_FMT_SRGGB10;
	else if (strncmp(pixel_t, "bayer_xbggr10p", size) == 0)
		*format = V4L2_PIX_FMT_XBGGR10P;
	else if (strncmp(pixel_t, "bayer_xrggb10p", size) == 0)
		*format = V4L2_PIX_FMT_XRGGB10P;
	else if (strncmp(pixel_t, "yuv_yuyv16", size) == 0)
		*format = V4L2_PIX_FMT_YUYV;
	else if (strncmp(pixel_t, "yuv_yvyu16", size) == 0)
		*format = V4L2_PIX_FMT_YVYU;
	else if (strncmp(pixel_t, "yuv_uyvy16", size) == 0)
		*format = V4L2_PIX_FMT_UYVY;
	else if (strncmp(pixel_t, "yuv_vyuy16", size) == 0)
		*format = V4L2_PIX_FMT_VYUY;
	else {
		pr_err("%s: Need to extend format%s\n", __func__, pixel_t);
		return -EINVAL;
	}

	return 0;
}

Can I skip the pixel parser and read the CSI data by bypassing it?
I think I have no other option at this point.
This points directly at the first question of the thread: should I change path and start trying to build the dev tree from the other files?
Is there a way to do this from my reversed devtree?

Thanks a lot for your support.
Andrea

16

Didn’t see any error on the pixel parser status.
Still the problem should be the timing issue. You may need to adjust the sensor timing for the error.

17

Hi ShaneCCC,

actually we have a sporadic

TEGRA_CSI_PIXEL_PARSER_STATUS 0x00004000

error, especially in the lower ranges, (up until cil=20).
The TRM reports:

HPA_UNC_HDR_ERR: Uncorrectable Header Error. 
Set when header parser A parses a header with a multi-bit error. 
This error will be detected by the headers ECC, but cannot be corrected. 
The packet will be discarded.

does this change anything?

Furthermore, this is what the sensor device datasheet reports for MIPI timing:

image
image1136×1150 118 KB

It just seems to be compliant to the standard.
I don’t think I can adjust anything there…

Thanks for your support.
Andrea

18

I would like to add, I don’t have a way to access this data received over MIPI.
Is there a way I can bypass any hidden engine and just have access to raw data?

Thanks again.
Kind regards,
Andrea

19

Due to SOT or HPA_UNC_HDR_ERR error that tell the CSI unable to latch any validate data form the MIPI bus that tell can bypass to get the data. Suppose the ths_prepare/ths_zero should be able to adjust from the sensor REG.

Thanks

20

Hi ShaneCCC,

I think I found something that is messing up the acquisition.
If I run the v4l2-ctl with the “verbose” option:

$ v4l2-ctl --set-fmt-video=width=512,height=128,pixelformat=RG12 --stream-mmap --set-ctrl=sensor_mode=0 --stream-count=1 -d /dev/video0 --verbose
VIDIOC_QUERYCAP: ok
VIDIOC_S_EXT_CTRLS: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: ok
Format Video Capture:
	Width/Height      : 1024/32
	Pixel Format      : 'RG12' (12-bit Bayer RGRG/GBGB)
	Field             : None
	Bytes per Line    : 2048
	Size Image        : 65536
	Colorspace        : sRGB
	Transfer Function : Default (maps to sRGB)
	YCbCr/HSV Encoding: Default (maps to ITU-R 601)
	Quantization      : Default (maps to Full Range)
	Flags             : 
		VIDIOC_REQBUFS returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_STREAMON returned 0 (Success)

And:

$ v4l2-ctl --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
	Type: Video Capture

	[0]: 'RG12' (12-bit Bayer RGRG/GBGB)
		Size: Discrete 1024x4
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 1024x4
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 1024x4
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 1024x4
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 1024x4
			Interval: Discrete 0.033s (30.000 fps)

Something is messing up the frame width/height format (and fps as well…).

This is the relevant device tree part:

mode0 {
                    mclk_khz = "24000";  
                    num_lanes = "2";   
                    tegra_sinterface = "serial_a";
                    phy_mode = "DPHY";
                    discontinuous_clk = "no";
                    dpcm_enable = "false";
                    cil_settletime = "10"; 
                    dynamic_pixel_bit_depth = "12";
                    csi_pixel_bit_depth = "12";
                    mode_type = "bayer";  // Non-Bayer sensor, but there is no other option...
                    pixel_phase = "rggb";
                    active_w = "512";
		    active_h = "128"; // 128 CHIRP
                    readout_orientation = "0";
                    line_length = "512";  // Adjusted for correct timing 2627
                    inherent_gain = "1";
                    [...]
                    pix_clk_hz = "37500000";  // 150M*2 (DDR) * 2(CSI LANES) / 16 = 37.5M
                    [...]
                    framerate_factor = "1000000";
                    min_framerate = "1000000";   /* 10 FPS - measured */
                    max_framerate = "50000000";  /* 50 FPS */
                    step_framerate = "1";
		    default_framerate = "1000000";  /* 10 FPS - measured */
                    [...]
                    embedded_metadata_height = "0";
                };

Where is the v4l2-ctl taking those value from?
I thought they would be passed right away from devtree through driver to the v4l2, but it seems that something is overwriting those values.
Any hints?

EDIT: found the static const struct camera_common_frmfmt struct from which it reads the values.
Fixed to the correct 514 - 128.

Now I get this error once per second (1fps):

[  111.779217] video4linux video0: frame start syncpt timeout!0
[  111.784920] video4linux video0: TEGRA_VI_CSI_ERROR_STATUS 0x00000004
[  111.784927] vi 54080000.vi: TEGRA_CSI_PIXEL_PARSER_STATUS 0x00000080
[  111.784931] vi 54080000.vi: TEGRA_CSI_CIL_STATUS 0x00000000
[  111.784935] vi 54080000.vi: TEGRA_CSI_CILX_STATUS 0x00000000

which means:

PPA_SHORT_FRAME: Set when CSI-PPA receives a short frame. 
This bit gets set even if CSI_PPA_PAD_FRAME specifies that short frames are to be padded to the correct line length.

FRAME_HEIGHT_SHORT_ERROR: Flagged if frame height is smaller than HEIGHT. Write 1 to clear.

I am sure we are sending out 128 chirps (-> that should be the height).
I am not sure the correct width is being taken into account though, since v4l2-ctl says:

	Width/Height      : 514/128
	Bytes per Line    : 1088 #for w=512 goes to 1024, and for 514 -> 1088? why is that?

Could this be to due to the initial problem of the thread?

Thanks.
Kind regards,
Andrea

21

2 bytes per pixel to calculate it.
Like 1280x720 the the bytes per line is 1280x2=2560

22

Yes, but 514*2=1028, why does it say 1088?
If it is auto-computed, why is it a wrong calculation?
Seems to me that the minimum atomic increment it can handle is 32 pixels, just like 32 is the minimum width/height acceptable as reported in the TRM ((512+32)*2=1088).
What if I have a non 32-multiple amount of pixels?

EDIT
I was trying to read the following register to check this HEIGHT parameter:

image
image1153×262 35.2 KB

but the reading fails:

$ sudo busybox devmem 0x54080118 32

0xFFFFFFFF

How can I properly read it?

Best,
Andrea