JetsonTK1 soc_camera driver problem

I am developing soc_camera sensor driver. Camera video format is UYVY 1080p 60 fps. I am using 4 lane CSIA.

I can successfully insert driver and probe tegra_camera will give /dev/video0.

But i am getting green image(0x00 data) using yavta.

After modprobe of tegra_camera first yavta capture not giving any CSI error but output green image.

root@tegra-ubuntu:/home/ubuntu/yavta# ./yavta /dev/video0 -c1 -n1 -s1920x1080 -fUYVY -Ftpg5.yuvDevice /dev/video0 opened.
Device `vi' on `' (driver 'vi.0') is a video capture (without mplanes) device.
Video format set: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4147200
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4147200
1 buffers requested.
length: 4147200 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0xb6a15000.
0 (0) [-] none 0 4147200 B 1464949170.823028 158.000886 0.011 fps ts mono/EoF
Captured 1 frames in 0.003167 seconds (315.723737 fps, 1309369480.754428 B/s).
1 buffers released.

But from 2nd capture yavta gives CSI errors and output image is green.

root@tegra-ubuntu:/home/ubuntu/yavta# ./yavta /dev/video0 -c1 -n1 -s1920x1080 -fUYVY -Ftpg6.yuv
Device /dev/video0 opened.
Device `vi' on `' (driver 'vi.0') is a video capture (without mplanes) device.
Video format set: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4147200
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4147200
1 buffers requested.
length: 4147200 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0xb6a76000.
0 (0) [E] none 0 4147200 B 1464949694.595386 681.773251 0.010 fps ts mono/EoF
Captured 1 frames in 2.712552 seconds (0.368656 fps, 1528891.870254 B/s).
1 buffers released.
[  681.482282] TEGRA_CSI_CSI_CIL_A_STATUS 0x00000010
[  681.487244] TEGRA_CSI_CSI_CILA_STATUS 0x00040041
[  681.492021] TEGRA_CSI_CSI_CIL_B_STATUS 0x00000000
[  681.496990] TEGRA_CSI_CSI_CIL_C_STATUS 0x00000000
[  681.502023] TEGRA_CSI_CSI_CIL_D_STATUS 0x00000000
[  681.507089] TEGRA_CSI_CSI_CIL_E_STATUS 0x00000000
[  681.512081] TEGRA_CSI_CSI_PIXEL_PARSER_A_STATUS 0x00004081
[  681.517723] TEGRA_CSI_CSI_PIXEL_PARSER_B_STATUS 0x00000000
[  681.523620] TEGRA_VI_CSI_0_ERROR_STATUS 0x00000004
[  681.528578] TEGRA_VI_CSI_1_ERROR_STATUS 0x00000000
[  681.733336] vi vi.0: CSI_A syncpt timeout, syncpt = 12, err = -11

My i2c sensor initialization looks good.
So is problem with driver side or hardware side?

Hi,

We have same issue about MIPI-CSI green image. But we use ov10633 and Toshiba TC358746XBG parallel to mipi bridge output YUV422 8bit data to TK1. Please help to confirm the issue, any suggestion or direction will be appreciated. Thanks.

From the register status, looks like the real height of sensor/bridge output is not(should be smaller than) 1080, which subsequently triggered lane error and header error.
Could you please check the active pixel array of sensor/bridge output?

Hi, nVConan,

Thanks for your reply.

As RiteshPanchal memtion, “After modprobe of tegra_camera first yavta capture not giving any CSI error but output green image.” We also face green image issue when use yavta or V4L2 API to capture TK1 MIPI-CSI image. Is the issue from hardware, soc_camera driver or tegra_camera driver?

Hi, nVConan,

Should we need to set TK1 MIPI-CSI parameters ?
For example, TLPX (Length of any low power state period), THS-PREPARE, THS-ZERO, etc.
Or other parameters need to adjust according to different sensor/bridge ?

If available, please let us know to overcome this issue. thanks.

We don’t need to adjust mipi timing parameters.
Is that possible to scope the output of the bridge after programming done?

Hi, nVConan,
Here is data and clock waveform from Toshiba TC358746XBG parallel to mipi bridge(clock.jpg and data.jpg)
clock.jpg
data.jpg

clock.jpg

data.jpg

Hi, nVConan,

The attached file is Toshiba TC358746XBG colorbar, non-continuous mode, 720p, YUV422 parameter setting.
I’m not sure this table suitable TK1 MIPI-CSI. Could you help to confirm this table? Thanks.

Hi Drexler,

I just checked our vi driver for TK1 R21 release, and found it doesn’t support YUV422 yet
(mainly in vi2_capture_setup_csi_0, vi2_capture_setup_csi_1).

So, you can refer to the implementation in TX1 R23 release to add support for YUV422.

Regarding the MIPI timing you post, I think it should be fine as the receiver(tegra) and transmitter(your bridger) are expected to follow the MIPI spec.

Hello, nVConan,

Thanks for your reply.

I download TX1 R23.2 kernel source and follow drivers/media/platform/soc_camera/tegra_camera/vi2.c “vi2_channel_capture_setup” function to implement YUV422 format in vi2_capture_setup_csi_0 and vi2_capture_setup_csi_1 as follow,

else if ((icd->current_fmt->code == V4L2_MBUS_FMT_UYVY8_2X8) ||
(icd->current_fmt->code == V4L2_MBUS_FMT_VYUY8_2X8) ||
(icd->current_fmt->code == V4L2_MBUS_FMT_YUYV8_2X8) ||
(icd->current_fmt->code == V4L2_MBUS_FMT_YVYU8_2X8)) {
switch (icd->current_fmt->code) {
case V4L2_MBUS_FMT_UYVY8_2X8:
format = TEGRA_IMAGE_FORMAT_T_U8_Y8__V8_Y8;
break;
case V4L2_MBUS_FMT_VYUY8_2X8:
format = TEGRA_IMAGE_FORMAT_T_V8_Y8__U8_Y8;
break;
case V4L2_MBUS_FMT_YUYV8_2X8:
format = TEGRA_IMAGE_FORMAT_T_Y8_U8__Y8_V8;
break;
case V4L2_MBUS_FMT_YVYU8_2X8:
format = TEGRA_IMAGE_FORMAT_T_Y8_V8__Y8_U8;
break;
}
data_type = TEGRA_IMAGE_DT_YUV422_8;
image_size = icd->user_width * 2;

But I am still getting green image using yavta and V4L2 API.
Do I miss something ?

Antmicro tested tc358743 HDMI to CSI-2 bridge on TK1.
http://antmicro.com/Blog/2015/09/jetson-tk1-cameras/
They have added support for YUV422 in vi2.c. And also changed some register write value in vi2.c

So i compiled and used there whole kernel with my tc358748 parallel to mipi driver added.
i have tested my tc358748 driver on TX1 and its working fine.

So now i am getting green image with some pink part instead of plan green image. https://drive.google.com/open?id=0B8d7zQv-G71oai1nYzZ1eEJQZWc

after tegra_camera modprobe i got no error for first yavta capture. But for second capture tk1 hangs before compileting the capture.

I also tried for adding only support for YUV422 in vi2.c without any changes for registers value. This also gives same green image with pink part.

Hi Drexler and Ritesh,

Please follow the suggestion from our release documentation(http://developer.download.nvidia.com/embedded/L4T/r21_Release_v4.0/Tegra_Linux_Driver_Package_Documents_R21.4.tar),
the chapter ‘V4L2 User Guide for Jetson TK1’(V4L2 Tegra Driver Overview --> Tegra V4L2 Camera Driver --> Input data format)

Hello, nVConan,

We can receive and display Toshiba TC358746XBG 720p YUV422 color bar image correctly. Thanks for your help.

We started to use OV10633 via Toshiba TC358746XBG to transfer real camera 720p YUV422 image.
But we faced CSI_A syncpt timeout issue as follow,

[101863.474390] ov10633_s_stream --> ov10633_write_table!
[101863.679996] vi vi.0: CSI_A syncpt timeout, syncpt = 47, err = -11
[101863.687224] TEGRA_CSI_CSI_CIL_A_STATUS 0x00000000
[101863.692554] TEGRA_CSI_CSI_CILA_STATUS 0x00000000
[101863.697923] TEGRA_CSI_CSI_CIL_B_STATUS 0x00000000
[101863.703180] TEGRA_CSI_CSI_CIL_C_STATUS 0x00000000
[101863.708754] TEGRA_CSI_CSI_CIL_D_STATUS 0x00000000
[101863.713720] TEGRA_CSI_CSI_CIL_E_STATUS 0x00000000
[101863.719066] TEGRA_CSI_CSI_PIXEL_PARSER_A_STATUS 0x00000000
[101863.724872] TEGRA_CSI_CSI_PIXEL_PARSER_B_STATUS 0x00000000
[101863.730852] TEGRA_VI_CSI_0_ERROR_STATUS 0x00000000
[101863.735887] TEGRA_VI_CSI_1_ERROR_STATUS 0x00000000
[101863.941181] vi vi.0: CSI_A syncpt timeout, syncpt = 48, err = -11
[101863.948065] TEGRA_CSI_CSI_CIL_A_STATUS 0x00000000
[101863.953056] TEGRA_CSI_CSI_CILA_STATUS 0x00000000
[101863.958014] TEGRA_CSI_CSI_CIL_B_STATUS 0x00000000
[101863.963275] TEGRA_CSI_CSI_CIL_C_STATUS 0x00000000
[101863.968237] TEGRA_CSI_CSI_CIL_D_STATUS 0x00000000
[101863.973141] TEGRA_CSI_CSI_CIL_E_STATUS 0x00000000
[101863.978268] TEGRA_CSI_CSI_PIXEL_PARSER_A_STATUS 0x00000000
[101863.983968] TEGRA_CSI_CSI_PIXEL_PARSER_B_STATUS 0x00000000
[101863.989765] TEGRA_VI_CSI_0_ERROR_STATUS 0x00000008
[101863.994802] TEGRA_VI_CSI_1_ERROR_STATUS 0x00000000

According to TK1 TRM, the TEGRA_VI_CSI_0_ERROR_STATUS 0x8 look like FRAME_HEIGHT_LONG_ERROR: Flagged if frame height is larger than HEIGHT. But we confirmed with OV and Toshiba, the OV10633 and TC358746XBG output 720p image size correctly. I’m getting confuse, why color bar OK but ov10633 NG. Is this dunny pixel or blanking issue? Do we need to adjust MIPI-CSI parameters? Do I miss something?

Be glad to know that tegra can receive the color bar from Toshiba bridge:)
If there are some embedded lines in vertical before frame start or after frame end, we should also take it into account as tegra didn’t know how to skip those embedded data(such as if we have extra 8 lines, then the size should be 1280x728). Seems you didn’t get any ctrl error or parse error, which means mipi timing should be expected.

Antmicro tested tc358743 HDMI to CSI-2 bridge on TK1. And they have added support for YUV in vi.c
http://antmicro.com/Blog/2015/09/jetson-tk1-cameras/

I have replaced media/platform/soc_camera/tegra_camera/vi2.c and media/v4l2-core/v4l2-ioctl.c files to my kernel source.

[ 1478.552586] vi vi.0: CSI_A syncpt timeout, syncpt = 4, err = -11
[ 1478.569450] TEGRA_CSI_CSI_CIL_A_STATUS 0x00000000
[ 1478.582644] TEGRA_CSI_CSI_CILA_STATUS 0x00000000
[ 1478.590815] TEGRA_CSI_CSI_CIL_B_STATUS 0x00000000
[ 1478.595828] TEGRA_CSI_CSI_CIL_C_STATUS 0x00000000
[ 1478.600707] TEGRA_CSI_CSI_CIL_D_STATUS 0x00000000
[ 1478.605551] TEGRA_CSI_CSI_CIL_E_STATUS 0x00000000
[ 1478.610822] TEGRA_CSI_CSI_PIXEL_PARSER_A_STATUS 0x000041b4
[ 1478.616489] TEGRA_CSI_CSI_PIXEL_PARSER_B_STATUS 0x00000000
[ 1478.622195] TEGRA_VI_CSI_0_ERROR_STATUS 0x00000006
[ 1478.627232] TEGRA_VI_CSI_1_ERROR_STATUS 0x00000000

still i am getting the same error first yavta capture no error and on second yavta capture tk1 hangs. And the image of first capture is same as previous image that i have attached in old message.

2nd capture error log

[ 1479.467068] MSELECT error detected! status=0x1
[ 1479.891552] ------------[ cut here ]------------
[ 1479.896384] kernel BUG at drivers/platform/tegra/hier_ictlr/hier_ictlr.c:54!
[ 1479.903624] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM

[ 1479.909647] Modules linked in: tegra_camera videobuf2_dma_contig tc358748 dm_crypt dm_mod bnep rfcomm bluetooth rfkill joydev [last unloaded: nvhost_vi]
[ 1479.924728] CPU: 0 PID: 2536 Comm: kworker/0:1 Not tainted 3.10.40 #6
[ 1479.931449] Workqueue: events tegra_camera_work [tegra_camera]
[ 1479.937375] task: eb0e40c0 ti: e60fa000 task.ti: e60fa000
[ 1479.943050] PC is at tegra_hier_ictlr_irq_handler+0x3c/0x40
[ 1479.948838] LR is at tegra_hier_ictlr_irq_handler+0x3c/0x40
[ 1479.954606] pc : [<c05f9c2c>]    lr : [<c05f9c2c>]    psr: 200001d3
[ 1479.954606] sp : e60fbca8  ip : 00000000  fp : fdc42000
[ 1479.966268] r10: c0cc6c50  r9 : 00000000  r8 : 00000000
[ 1479.971662] r7 : e60fbd58  r6 : 0000009f  r5 : c0b89910  r4 : ed0bb640
[ 1479.978354] r3 : 00000002  r2 : 00010100  r1 : c1df370c  r0 : 00000022
[ 1479.985057] Flags: nzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
[ 1479.992713] Control: 10c5387d  Table: ab12806a  DAC: 00000015
[ 1479.998609] 
[ 1479.998609] PC: 0xc05f9bac:
[ 1480.003036] 9bac  e8bd4010 eaf852c8 e92d4010 e52de004 e8bd4000 e1a04000 e59000a8 ebffffba
[ 1480.012137] 9bcc  e3500000 08bd8010 e1a01004 e8bd4010 eaf85321 e52de004 e8bd4000 e3a00004
[ 1480.021259] 9bec  e12fff1e e92d4008 e52de004 e8bd4000 e1a00001 ebf814a3 e590300c e5931060
[ 1480.030374] 9c0c  f57ff04f e3510000 1a000001 e3a00001 e8bd8008 e3060e44 e34c00a5 eb079907
[ 1480.039488] 9c2c  e7f001f2 e92d40f0 e24dd014 e52de004 e8bd4000 e2805010 e1a06000 e3a01010
[ 1480.048593] 9c4c  e3a020d0 e1a00005 ebf82285 e2504000 0a000058 e1a01004 e1a00005 ebf81524
[ 1480.057705] 9c6c  e3a01c02 e1a00006 e3a02000 ebf81c87 e2501000 0a000051 e1a00005 ebf2d113
[ 1480.066817] 9c8c  e3500000 e5840008 0a000056 e3a01c02 e1a00006 e3a02001 ebf81c7c e2501000

The tc358748 driver is same as working for TX1.

So can you suggest any solution?

Looks like the MSELECT was fixed in the brand new R21.5 release.
https://devtalk.nvidia.com/default/topic/950860/jetson-tk1/jetpack-2-2-1-and-l4t-r21-5-for-jetson-tk1/

You could either install R21.5 or figure out the diff of “drivers/platform/tegra/hier_ictlr/hier_ictlr.c” and patch.

R21.5 solves TK1 hang problem on 2nd yavta capture.

But still i am getting green image and CSI error as posted in previous post.
But if i comment “tegra_io_dpd_disable / enable” in board-ardbeg-sensor.c file. I got now CSI error but only suncpt error.

static int ardbeg_tc358748_power(struct device *dev, int enable)
{
	//if(enable) {
	//	tegra_io_dpd_disable(&csia_io);
	//} else {
	//	tegra_io_dpd_enable(&csia_io);
	//}
	return 0;
}
[   99.894825] vi vi.0: CSI_A syncpt timeout, syncpt = 4, err = -11
[   99.911583] TEGRA_CSI_CSI_CIL_A_STATUS 0x00000000
[   99.920880] TEGRA_CSI_CSI_CILA_STATUS 0x00000000
[   99.933794] TEGRA_CSI_CSI_CIL_B_STATUS 0x00000000
[   99.940875] TEGRA_CSI_CSI_CIL_C_STATUS 0x00000000
[   99.953644] TEGRA_CSI_CSI_CIL_D_STATUS 0x00000000
[   99.962798] TEGRA_CSI_CSI_CIL_E_STATUS 0x00000000
[   99.973795] TEGRA_CSI_CSI_PIXEL_PARSER_A_STATUS 0x00000000
[   99.983737] TEGRA_CSI_CSI_PIXEL_PARSER_B_STATUS 0x00000000
[   99.989307] TEGRA_VI_CSI_0_ERROR_STATUS 0x00000000
[   99.994236] TEGRA_VI_CSI_1_ERROR_STATUS 0x00000000

Drexler got success in YUV colorbar on TC358746.
So can you tell me what changes have you done to get this color bar?
Is there any changes you made in kernel tegra_camera or vi2.c source file taking reference of TX1 source? or any other changes in driver source file?

Auvidea has made us aware that an updated firmware/driver file for their B102/J120 carrier boards to support the Toshiba TC358743 is available via the auvidea.eu website.

Direct link: http://www.auvidea.eu/download/firmware/J120/J120_Kernel_v_1.1.zip

Driver source should be available under the GPL. Note that this carrier/software package is not an NVIDIA product and thus is not supported by NVIDIA.