Sorry for the late response, have you managed to get issue resolved or still need the support? Thanks
Hi @kayccc,
The issue is still there unfortunately. Sometime it can work after a certain retries of gst-launch but the number of retries until the successful capture is quite random. I might wait for next Jetpack release to test again as I don’t think there’s big change in the kernel BSP btw the working Jetpack-4.5.1 and the faulty BSP Jetpack-4.6.1 and my driver is exactly the same in the 2 versions.
Regards,
K.
Check it able output test pattern to verify.
Hi @ShaneCCC ,
Yes, it is able to output the test pattern (Color Bar), the only doubt is that I am not sure that it was a stream of test pattern or only some first images of the test pattern. However, it does show the test pattern right after launching the gstreamer command, while with images from real scene, first frames seem to be discarded and gstreamer shows nothing.
Best Regards,
Khang
If test pattern without problem that tell the adv7280 to NX without problem.
Hi @ShaneCCC ,
It seemed that only first frame(s) is/are captured. Running following command does not report any fps as it is blocking :
v4l2-ctl --device /dev/video1 --set-fmt-video=width=720,height=507,pixelformat=UYVY,field=interlaced --set-ctrl bypass_mode=0 --stream-mmap --stream-count=200
Best Regards,
K.
Test pattern?
Any different in the trace log?
Hi @ShaneCCC ,
Test pattern?
Yes.
Attached are the logs with test pattern enabled by following steps :
Root console :
root@JetsonXNX:/home/toto/Workspace# ./max_clock.sh
vi clock rate is:460800000
isp clock rate is:576000000
emc clock rate is:1600000000
nvcsi clock rate is:314000000
User console :
./i2c_set_regs.sh 8 ADV7280M_ColorBar_480p.txt && gst-launch-1.0 v4l2src device=/dev/video1 ! xvimagesink
or
./i2c_set_regs.sh 8 ADV7280M_ColorBar_480i.txt && gst-launch-1.0 v4l2src device=/dev/video1 ! xvimagesink
Best Regards,
K
toto_progressive.txt (5.0 MB)
for following setting :
ADV7280M_ColorBar_480p.txt (1.0 KB)
And
toto_interlaced.txt (570.2 KB)
for following setting :
ADV7280M_ColorBar_480i.txt (679 Bytes)
The trace log tell the SPURIOUS data after the SOF. That could be the user define data cause the problem.
Have a check with vendor if able to disable the user define data package for trying.
kworker/1:2-1918 [001] … 457.471648: rtcpu_vinotify_error: tstamp:14760981581 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:14760980728 data:0x00010000
Hi @ShaneCCC ,
Thanks for your suggestion. I will check the registers settings ( ADV7280M_ColorBar_480p.txt
or ADV7280M_ColorBar_480i.txt
) first. But, I am confused that I was working with previous jetpack release (r32.5.1) with same configuration, still.
Regards,
Khang
On the same platform?
Maybe you can try modify the VI driver to ignore the err to try. Remove the goto uncorr_err;
static void vi5_capture_enqueue(struct tegra_channel *chan,
395 struct tegra_channel_buffer *buf)
396 {
397 int err = 0;
398 unsigned int vi_port;
399 unsigned long flags;
400 struct tegra_mc_vi *vi = chan->vi;
401 struct vi_capture_req request[2] = {{
402 .buffer_index = 0,
403 }, {
404 .buffer_index = 0,
405 }};
406
407 for (vi_port = 0; vi_port < chan->valid_ports; vi_port++) {
408 vi5_setup_surface(chan, buf, chan->capture_descr_index, vi_port);
409 request[vi_port].buffer_index = chan->capture_descr_index;
410
411 err = vi_capture_request(chan->tegra_vi_channel[vi_port], &request[vi_port]);
412
413 if (err) {
414 dev_err(vi->dev, "uncorr_err: request dispatch err %d\n", err);
415 goto uncorr_err;
416 }
417
418 spin_lock_irqsave(&chan->capture_state_lock, flags);
419 if (chan->capture_state != CAPTURE_ERROR) {
420 chan->capture_state = CAPTURE_GOOD;
421 chan->capture_reqs_enqueued += 1;
422 }
423 spin_unlock_irqrestore(&chan->capture_state_lock, flags);
424 buf->capture_descr_index[vi_port] = chan->capture_descr_index;
425 }
426 chan->capture_descr_index = ((chan->capture_descr_index + 1)
427 % (chan->capture_queue_depth));
428
429 spin_lock(&chan->dequeue_lock);
430 list_add_tail(&buf->queue, &chan->dequeue);
431 spin_unlock(&chan->dequeue_lock);
432
433 wake_up_interruptible(&chan->dequeue_wait);
434
435 return;
436
437 uncorr_err:
438 spin_lock_irqsave(&chan->capture_state_lock, flags);
439 chan->capture_state = CAPTURE_ERROR;
440 spin_unlock_irqrestore(&chan->capture_state_lock, flags);
441 }
442
On the same platform?
Yes, on the same custom board based on Jetson Xavier NX module (same module as well).
As per your suggestion, I modified the vi5_fops.c as below :
diff --git a/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c b/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c
index 71a9b48de..56a1f8a2e 100644
--- a/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c
+++ b/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c
@@ -359,7 +359,7 @@ static void vi5_capture_enqueue(struct tegra_channel *chan,
if (err) {
dev_err(vi->dev, "uncorr_err: request dispatch err %d\n", err);
- goto uncorr_err;
+// goto uncorr_err;
}
spin_lock_irqsave(&chan->capture_state_lock, flags);
@@ -381,7 +381,7 @@ static void vi5_capture_enqueue(struct tegra_channel *chan,
return;
-uncorr_err:
+//uncorr_err:
spin_lock_irqsave(&chan->capture_state_lock, flags);
chan->capture_state = CAPTURE_ERROR;
spin_unlock_irqrestore(&chan->capture_state_lock, flags);
However, I was not able to stream still. And the error has always been :
[ 106.219027] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 0, err_data 131072
[ 106.234901] tegra194-vi5 15c10000.vi: corr_err: discarding frame 2, flags: 0, err_data 131072
[ 106.239106] tegra194-vi5 15c10000.vi: corr_err: discarding frame 1, flags: 0, err_data 131072
[ 106.255611] tegra194-vi5 15c10000.vi: corr_err: discarding frame 2, flags: 0, err_data 131072
not the one related to the modified code :
dev_err(vi->dev, "uncorr_err: request dispatch err %d\n", err);
Regards,
K
Hi @ShaneCCC,
Another observation is that with following command for measuring fps, it seems that there’s some first frames are captures (as I said before) and the numbers of captured frames (represented by < ) are random :
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video1
<<<<<<<<<<<<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video1
<<<<<<<<<<<<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video1
<<<^C
l4es@JetsonXNX:~/Workspace$ v4l2-ctl --set-fmt-video=width=720,height=507,pixelformat=uyvy --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 -d /dev/video1
<<<<^C
^C = I forced to exit the command when it did not progress anymore.
Hi @ShaneCCC ,
By the way, do you think that following issue is relevant : IMX219 Raw8 mode on the XavierNX: Disabling CRC - #9 by ShaneCCC ?
I am not sure if it disable the SPURIOUS too, Could you please help to try it.
Thanks
Hi @ShaneCCC ,
I applied the same patch for drivers/media/platform/tegra/camera/nvcsi/csi5_fops.c as you proposed here : IMX219 Raw8 mode on the XavierNX: Disabling CRC - #9 by ShaneCCC. The issue still persists.
But I wondered if I would need to update the camera-rtcpu-rce.img as it seems to be the same version btw Jetpack-4.5 and Jetpack-4.6.
Regards,
Khang
Yes, the rtcpu firmware must need update.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.