Kernel can not boot after enable camera

According to the picture uploaded, can I set THS to 400ns?
Why can not use cil_settletime auto-calibrate?

Jerry:
Our sensor output YUV format data.
Can XAVIER receive YUV image?

hello ycl,

you may refer to TRM for the formula of THS settle time,
for example,

85ns + 6 * UI < (Ths-settle-programmed + 6) * lp clock periods < 145ns + 10 * UI

CSI brick is able to support YUV formats. please enable v4l2 standard control or v4l2src plugin to access that.
please refer to Camera Architecture Stack, libargus works with Jetson ISP so it only support with bayer raw formats.
thanks

There are no start-of-frame and end-of-frame signal in our logs. Is it because our config is rawdata?

How to change rgb to yuv?
In device tree,
mode0 {/mode IMX390_MODE_1920X1080_CROP_30FPS/
mclk_khz = “24000”;
num_lanes = “2”;
tegra_sinterface = “serial_a”;
vc_id = “0”;
discontinuous_clk = “no”;
dpcm_enable = “false”;
cil_settletime = “0”;
dynamic_pixel_bit_depth = “12”;
csi_pixel_bit_depth = “12”;
mode_type = “bayer”;
pixel_phase = “rggb”;
… …

we change

csi_pixel_bit_depth = “12”;
mode_type = “bayer”;
pixel_phase = “rggb”;
to
csi_pixel_bit_depth = “16”;
mode_type = “yuv”;
pixel_phase = “uyuv”;
Is the changes above OK?

But in code

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, “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;

There are only yuv 16bit config. OUr camera output yuv 8bit. Could I select yuv_uyvy16?

hello ycl,

it’s because memory were allocated with T_R16_I. you may check TRM for more details.

are you able to enable test-pattern-generator on your Ser/Des chip?
please also contact with your bridge vendor to ask the steps to enable test-pattern-generator, it’s useful for issue narrow-down.

please also refer to below similar discussion threads for reference,
such as

After I enabled test-pattern-generator, image data was output from max96712. The new log is in this attachment.

There are also many errors, such as the following:

 kworker/0:0-4     [000] ....   237.555296: rtcpu_vinotify_event: tstamp:7768803730 tag:CSIMUX_FRAME channel:0x00 frame:0 vi_tstamp:7768470465 data:0x00400060
 kworker/0:0-4     [000] ....   237.555297: rtcpu_vinotify_event: tstamp:7768803875 tag:FS channel:0x00 frame:0 vi_tstamp:7768486658 data:0x00000010
 kworker/0:0-4     [000] ....   237.555298: rtcpu_vinotify_event: tstamp:7768804045 tag:CHANSEL_NOMATCH channel:0x01 frame:0 vi_tstamp:7768514466 data:0x000003c9

 kworker/0:0-4     [000] ....   226.411199: rtcpu_vinotify_error: tstamp:7420568289 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:7420565045 data:0x00000001

 kworker/0:0-4     [000] ....   226.411196: rtcpu_nvcsi_intr: tstamp:7420565363 class:GLOBAL type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004
 kworker/0:0-4     [000] ....   226.411197: rtcpu_nvcsi_intr: tstamp:7420565363 class:CORRECTABLE_ERR type:STREAM_VC phy:0 cil:0 st:0 vc:0 status:0x00000004


 kworker/0:0-4     [000] ....   226.411183: rtos_queue_send_from_isr_failed: tstamp:7420537558 queue:0x0bcb8a60[log1.zip|attachment](upload://sa0rPyOas5tOZVxuFRRLi9q8nUf.zip) (2.9 MB)

log1.zip (2.9 MB)

hello ycl,

tag:CSIMUX_FRAME channel:0x00 frame:0 vi_tstamp:7768470465 data:0x00400060

it shows an error FE_CSI_FAULT, please check why you’re not shown frame-end here.

tag:CHANSEL_NOMATCH channel:0x01 frame:0 vi_tstamp:7768514466 data:0x000003c9

this no match error report the data type is NvCsiDataType_YUV422_8, are you define the stream data type as YUV422 8-bit?
thanks

tegra194-camera-ar0233-a00.dtsi (14.4 KB)

The attachment is my config file.
How to check frame-end?

I set YUV as bellowing:
dynamic_pixel_bit_depth = “16”;
csi_pixel_bit_depth = “16”;
mode_type = “yuv”;
pixel_phase = “uyvy”;

Hi, Jerry
What does FE_CSI_FAULT mean? Where can I find the meanings of error codes such as FE_CSI_FAULT?

hello ycl,

you should have device tree configurations to match the actual CSI signaling,
there’s reported data type shows NvCsiDataType_YUV422_8; you should also have extend the VI support formats.
please also refer to Topic 74804, and Topic 69251 for reference, thanks

Jerry:
I changed mipi csi device tree, It seemed that there were FE frames.
Please help check the log.1 (398.4 KB)

CHANSEL_NOMATCH: 0x000003c9
bit0 : no_match
bit3 : CTYPE: LS = 0x4
bit9 bit8 bit7 bit6 : 0x1e=30, NvCsiDataType_YUV422_8

There still are yuv format problems. Can you explain explicitly how to set YUV422 8bit?

hello ycl,

please update VI kernel drivers to extend the support formats.
for example,
$L4T_Sources/r32.4.4/Linux_for_Tegra/source/public/kernel/nvidia/drivers/media/platform/tegra/camera/sensor_common.c
$L4T_Sources/r32.4.4/Linux_for_Tegra/source/public/kernel/nvidia/drivers/media/platform/tegra/camera/camera_common.c

since the reported data type shows NvCsiDataType_YUV422_8.
you may update the kernel driver to report the fourcc as 8-bit YUV,
for example,

#define V4L2_PIX_FMT_HI240   v4l2_fourcc('H', 'I', '2', '4') /*  8  8-bit color   */
#define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV 4:2:0 16x16 macroblocks */

Jerry:
camera output format is YUV422 8bit UYVY.
In videodev2.h, I think I can only choose th following V4L2_PIX_FMT_UYVY,
#define V4L2_PIX_FMT_UYVY v4l2_fourcc(‘U’, ‘Y’, ‘V’, ‘Y’) /* 16 YUV 4:2:2 */

#define V4L2_PIX_FMT_HI240 v4l2_fourcc(‘H’, ‘I’, ‘2’, ‘4’) /* 8 8-bit color /
This is 8-bit color, not yuv.
#define V4L2_PIX_FMT_HM12 v4l2_fourcc(‘H’, ‘M’, ‘1’, ‘2’) /
8 YUV 4:2:0 16x16 macroblocks */
This is yuv 420.

hello ycl,

please refer to TC358840 bride driver, which could configure as UYVY or ABGR32.
the device tree settings there simply define port bindings, let driver side to handle other stuffs.
for example,
$L4T_Sources/r32.4.4/Linux_for_Tegra/source/public/hardware/nvidia/platform/t19x/common/kernel-dts/t19x-common-modules/tegra194-camera-imx274-hdmi.dtsi

In function vi5_capture_dequeue of vi5_fops.c,
I add one log print:
} else if (descr->status.status != CAPTURE_STATUS_SUCCESS) {
if ((descr->status.flags
& CAPTURE_STATUS_FLAG_CHANNEL_IN_ERROR) != 0) {
chan->queue_error = true;
dev_err(vi->dev, “uncorr_err: flags %d, err_data %d\n”,
descr->status.flags, descr->status.err_data);
} else {
dev_warn(vi->dev,
“descr->status.status = %d ########################byd test##########”, descr->status.status);

dev_warn(vi->dev,
"corr_err: discarding frame %d, flags: %d, "
“err_data %d\n”,
descr->status.frame_id, descr->status.flags,
descr->status.err_data);
buf->vb2_state = VB2_BUF_STATE_REQUEUEING;
goto done;
}

and got the following loop logs:

[ 60.912258] tegra194-vi5 15c10000.vi: descr->status.status = 14 ########################byd test##########
[ 60.912463] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 16384
[ 60.945573] tegra194-vi5 15c10000.vi: descr->status.status = 14 ########################byd test##########
[ 60.945807] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 16384
[ 60.978930] tegra194-vi5 15c10000.vi: descr->status.status = 14 ########################byd test##########
[ 60.979190] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 16384
[ 61.012211] tegra194-vi5 15c10000.vi: descr->status.status = 14 ########################byd test##########
[ 61.012415] tegra194-vi5 15c10000.vi: corr_err: discarding frame 0, flags: 0, err_data 16384

descr->status.status = 14 means CAPTURE_STATUS_FALCON_ERROR

(1)What does CAPTURE_STATUS_FALCON_ERROR mean?

(2)What is RTCPU?
Why many logs are from RTCPU?
Is RTCPU another soc devoted to mipi data?
For example,
kworker/0:0-4 [000] … 237.555297: rtcpu_vinotify_event: tstamp:7768803875 tag:FS channel:0x00 frame:0 vi_tstamp:7768486658 data:0x00000010

20210224 (488.9 KB)

The attachment 20210224 is our RTCPU log, which is got from thr following commands:
echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 2 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace

Can you help us to analyze it and find the problem?

hello ycl,

there’s CHANSEL_SHORT_FRAME failure, which indicate the signaling did not match VI engine’s expectation.
for example,

rtcpu_vinotify_event: tstamp:6430976550 tag:CHANSEL_SHORT_FRAME channel:0x01 frame:0 vi_tstamp:6430972814 data:0x00000000

short frame errors means the image sensor outputs a smaller frame as the one registered through the V4L2 driver.
please have a try to modify active regions, you may adjust the active_h for verification.
thanks