Hey all, following my recent post at:
We’ve successfully managed to get our custom orin NX carrier board working, and have tested its mipi-csi ports (4 of them) with 1->4 IMX219 cameras without issues, so that hardware itself is validated.
Now we are attempting to port our custom GREY8 1280x480 output camera:
- we’ve ported our attached .dts from xavier to orin following the successful DTS we’ve established for the IMX219
- the driver was updated to respect the new register conventions and general api changes between xavier and orin nx (it has very few responsibilities besides sending start/stop stream which have been validated)
- we’ve modified the source files sensor_common.c (pixel_t string parser), vi5_formats.h (adding our own GREY8 format), and camera_common.c to add GREY to the color table (the three modified files are attached, this modification was a requirement back on Xavier as well.
- we have thoroughly confirmed that the I2C exchange works (from our fpga-sided logs, stream begins exactly as needed, we do see mipi-LS activity on the data lines, HS is too fast to be viewable).
So right now hardware wise all is set, but we’re hitting an issue with actually getting the frames in, we’re getting timed out:
v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=480,pixelformat=GREY --stream-mmap --stream-count=5
[ 124.266749] atto640 9-0055: atto640_start_streaming: Successfully set ATTO640D SoS
[ 126.945559] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 126.945582] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 126.946470] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 129.505335] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
...
[ 144.833341] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 144.833361] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 144.834779] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 144.835100] atto640 9-0055: atto640_stop_streaming: Successfully set ATTO640D EoS
unlike the VI wiring issue from the IMX219, here the rtcpu log does show that some activity is found on the data lines, so ti’s not just a mere mis-wiring issue (which would be strange given the same mipi topology has been validated with IMX219).
RCE logs:
root@tegra-ubuntu:~# cat /sys/kernel/debug/tracing/trace | head -n 80
# tracer: nop
#
# entries-in-buffer/entries-written: 159556/159556 #P:4
#
# _-------=> irqs-off
# / _------=> need-resched
# | / _-----=> need-resched-lazy
# || / _----=> hardirq/softirq
# ||| / _---=> preempt-depth
# |||| / _--=> preempt-lazy-depth
# ||||| / _-=> migrate-disable
# |||||| / delay
# TASK-PID CPU# ||||||| TIMESTAMP FUNCTION
# | | | ||||||| | |
kworker/3:1-48 [003] ....... 1270.605347: rtcpu_string: tstamp:40374326286 id:0x04010000 str:"VM0 deactivating."
v4l2-ctl-2628 [000] ....... 1295.603268: tegra_channel_open: vi-output, atto640 9-0055
v4l2-ctl-2628 [003] ....... 1295.614929: tegra_channel_set_power: atto640 9-0055 : 0x1
v4l2-ctl-2628 [003] ....... 1295.615000: camera_common_s_power: status : 0x1
v4l2-ctl-2628 [003] ....... 1295.615006: tegra_channel_set_power: 13e00000.host1x:nvcsi@15a00000- : 0x1
v4l2-ctl-2628 [003] ....... 1295.615008: csi_s_power: enable : 0x1
v4l2-ctl-2628 [003] ....... 1295.615612: tegra_channel_capture_setup: vnc_id 0 W 1280 H 480 fmt 5
vi-output, atto-2629 [000] ....... 1295.624419: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:2629 tid:2629
vi-output, atto-2629 [000] ....... 1295.624430: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:2629 tid:2629
vi-output, atto-2629 [000] ....... 1295.624431: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:2629 tid:2629
vi-output, atto-2629 [000] ....... 1295.624432: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:0 pid:2629 tid:2629
v4l2-ctl-2628 [003] ....... 1295.624587: tegra_channel_set_stream: enable : 0x1
v4l2-ctl-2628 [003] ....... 1295.625984: tegra_channel_set_stream: 13e00000.host1x:nvcsi@15a00000- : 0x1
v4l2-ctl-2628 [003] ....... 1295.625986: csi_s_stream: enable : 0x1
v4l2-ctl-2628 [003] ....... 1295.626285: tegra_channel_set_stream: atto640 9-0055 : 0x1
kworker/3:1-48 [003] ....... 1295.653336: rtcpu_string: tstamp:41156696718 id:0x04010000 str:"VM0 activating."
kworker/3:1-48 [003] ....... 1295.653341: rtcpu_vinotify_event: tstamp:41157216613 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1317020441824 data:0x799d580010000000
kworker/3:1-48 [003] ....... 1295.653341: rtcpu_vinotify_event: tstamp:41157216752 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1317020448224 data:0x0000000031000001
kworker/3:1-48 [003] ....... 1295.653341: rtcpu_vinotify_event: tstamp:41157216906 cch:0 vi:0 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:1317020451232 data:0x0000000007020001
kworker/3:1-48 [003] ....... 1295.653342: rtcpu_vinotify_event: tstamp:41157217040 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1317020493472 data:0x799d550010000000
kworker/3:1-48 [003] ....... 1295.653342: rtcpu_vinotify_event: tstamp:41157217191 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1317020500000 data:0x0000000031000002
kworker/3:1-48 [003] ....... 1296.717559: rtcpu_nvcsi_intr: tstamp:41190182072 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x10000000
...
kworker/3:1-48 [003] ....... 1296.717578: rtcpu_nvcsi_intr: tstamp:41190232058 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x10000000
This camera worked just fine on Xavier NX, and we know the orin carrier is good since the IMX219 work at much higher frequencies, so why does the RCE trace indicate a potential MIPI signaling issue? Does orin have tighter mipi csi signaling requirements that may not be met by our soft mipi fpga IP?
Bit 28 of this error code seems to be INTR_CIL_DATA_LANE_CONTROL_ERR which would indicate an illegal mipi-csi state during the initial handshake, did the behaviour of this part of the PHY change between xavier and orin?
I did attempt to change the settle time in the DTS from auto (0) to a manual value (33) without any clear change.
Or is it maybe like on Xavier where some type of CRC checking is active? on Xavier we needed a custom RTCPU firmware image supplied by nvidia to disable it, could it be the source of the issue here as well?
I have attached the relevant DTS, as well as the old DTS of our xavier platform.
dtsi1.zip (9.2 KB)