Orin Nano and tc358743 capture issue

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

I’m getting the "vi_capture_control_message: NULL VI channel received " error when I try to capture from either of my tc358743’s connected to my Orin Nano on Xavier NX DevKit.

I’ve tried to find a solution in the forum but haven’t found an actual answer or one that was relevant to Orin and tc358743.

The OS was built from SDK Manager using JetPack 5.1.2 on Jetson Orin Dev board, L4T 35.4.1

cat /etc/nv_tegra_release
# R35 (release), REVISION: 4.1, GCID: 33958178, BOARD: t186ref, EABI: aarch64, DATE: Tue Aug  1 19:57:35 UTC 2023
uname -a
Linux orindev-15 5.10.120-tegra #1 SMP PREEMPT Tue Sep 26 21:30:21 EDT 2023 aarch64 aarch64 aarch64 GNU/Linux

I see the video signal :

v4l2-ctl --query-dv-timings -d /dev/video0
	Active width: 1280
	Active height: 720
	Total width: 1650
	Total height: 750
	Frame format: progressive
	Polarities: -vsync -hsync
	Pixelclock: 74250000 Hz (60.00 frames per second)
	Horizontal frontporch: 0
	Horizontal sync: 370
	Horizontal backporch: 0
	Vertical frontporch: 0
	Vertical sync: 30
	Vertical backporch: 0
	Standards:
	Flags:

Then I run my capture command and see the following in dmesg :

v4l2-ctl --device /dev/video0 --stream-mmap --set-fmt-video=width=1280,height=720,pixelformat=UYVY --stream-to=frame.raw --stream-count=10 --verbose

[  152.584202] (NULL device *): vi_capture_control_message: NULL VI channel received
[  152.591931] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[  152.602606] (NULL device *): vi_capture_control_message: NULL VI channel received
[  152.610326] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[  152.621185] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel

And this is the trace :

cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 226690/226690   #P:6
#
#                                _-----=> irqs-off
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| /     delay
#           TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
#              | |         |   ||||      |         |
     kworker/2:6-139     [002] ....  6928.747538: rtcpu_string: tstamp:217373554341 id:0x04010000 str:"VM0 deactivating."
        v4l2-ctl-2809    [000] ....  6988.614715: tegra_channel_open: vi-output, tc358743 9-000f
        v4l2-ctl-2809    [000] ....  6988.633250: tegra_channel_set_power: tc358743 9-000f : 0x1
        v4l2-ctl-2809    [000] ....  6988.633254: tegra_channel_set_power: 13e40000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-2809    [000] ....  6988.633259: csi_s_power: enable : 0x1
        v4l2-ctl-2809    [000] ....  6988.634636: tegra_channel_capture_setup: vnc_id 0 W 1280 H 720 fmt 13
        v4l2-ctl-2809    [001] ....  6988.643343: tegra_channel_set_stream: enable : 0x1
        v4l2-ctl-2809    [001] ....  6988.654533: tegra_channel_set_stream: 13e40000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-2809    [001] ....  6988.654535: csi_s_stream: enable : 0x1
        v4l2-ctl-2809    [001] ....  6988.654919: tegra_channel_set_stream: tc358743 9-000f : 0x1
     kworker/2:6-139     [002] ....  6988.682145: rtcpu_string: tstamp:219246145149 id:0x04010000 str:"VM0 activating."
     kworker/2:6-139     [002] ....  6988.682148: rtcpu_vinotify_event: tstamp:219246630498 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:7015881911936 data:0x759d580010000000
     kworker/2:6-139     [002] ....  6988.682149: rtcpu_vinotify_event: tstamp:219246630783 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:7015881921696 data:0x0000000031000001
     kworker/2:6-139     [002] ....  6988.682150: rtcpu_vinotify_event: tstamp:219246631070 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:7015882028352 data:0x759d550010000000
     kworker/2:6-139     [002] ....  6988.682150: rtcpu_vinotify_event: tstamp:219246631316 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:7015882038240 data:0x0000000031000002
     kworker/2:6-139     [002] ....  6988.682152: rtcpu_nvcsi_intr: tstamp:219246696942 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x02000000
     kworker/2:6-139     [002] ....  6988.682152: rtcpu_nvcsi_intr: tstamp:219246697510 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x10000004
     kworker/2:6-139     [002] ....  6988.682153: rtcpu_nvcsi_intr: tstamp:219246698095 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:6-139     [002] ....  6988.682153: rtcpu_nvcsi_intr: tstamp:219246699240 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:6-139     [002] ....  6988.682153: rtcpu_nvcsi_intr: tstamp:219246699791 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000004
     kworker/2:6-139     [002] ....  6988.682154: rtcpu_nvcsi_intr: tstamp:219246700421 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000004

In other posts that have this issue, I often see the PHY_INTR0 statuses called by their name - where can I find what these mean ?

One thing I noticed when running v4l2-compliance -v -d /dev/media0 is this error in the Media Driver Info section :

Media Driver Info:
	Driver name      : tegra-camrtc-ca
	Model            : NVIDIA Tegra Video Input Device
	Serial           :
	Bus info         :
	Media version    : 5.10.120
	Hardware revision: 0x00000003 (3)
	Driver version   : 5.10.120
Interface Info:
	ID               : 0x0300000b
	Type             : V4L Video
Entity Info:
	ID               : 0x00000009 (9)
	Name             : vi-output, tc358743 9-000f
	Function         : V4L2 I/O
	Pad 0x0100000a   : 0: Sink
	  Link 0x0200000f: from remote pad 0x1000003 of entity '13e40000.host1x:nvcsi@15a00000-' (FAIL: Unknown sub-device (0002000a)): Data, Enabled

I could not figure out where to start troubleshooting the unknown sub-device, as media-ctl -p -d /dev/media0 looked normal :

Media controller API version 5.10.120

Media device information
------------------------
driver          tegra-camrtc-ca
model           NVIDIA Tegra Video Input Device
serial
bus info
hw revision     0x3
driver version  5.10.120

Device topology
- entity 1: 13e40000.host1x:nvcsi@15a00000- (2 pads, 2 links, 0 routes)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
	pad0: Sink
		<- "tc358743 9-000f":0 [ENABLED]
	pad1: Source
		-> "vi-output, tc358743 9-000f":0 [ENABLED]

- entity 4: 13e40000.host1x:nvcsi@15a00000- (2 pads, 2 links, 0 routes)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev1
	pad0: Sink
		<- "tc358743 10-000f":0 [ENABLED]
	pad1: Source
		-> "vi-output, tc358743 10-000f":0 [ENABLED]

- entity 7: tc358743 9-000f (1 pad, 1 link, 0 routes)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev2
	pad0: Source
		[stream:0 fmt:UYVY8_1X16/1280x720 field:none colorspace:smpte170m]
		[dv.caps:BT.656/1120 min:640x350@13000000 max:1920x1200@165000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
		[dv.detect:BT.656/1120 1280x720p60 (1650x750) stds: flags:]
		[dv.current:BT.656/1120 1280x720p60 (1650x750) stds: flags:]
		-> "13e40000.host1x:nvcsi@15a00000-":0 [ENABLED]

- entity 9: vi-output, tc358743 9-000f (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
	pad0: Sink
		<- "13e40000.host1x:nvcsi@15a00000-":1 [ENABLED]

- entity 23: tc358743 10-000f (1 pad, 1 link, 0 routes)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev3
	pad0: Source
		[stream:0 fmt:RGB888_1X24/640x480 field:none colorspace:srgb]
		[dv.caps:BT.656/1120 min:640x350@13000000 max:1920x1200@165000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
		[dv.detect:BT.656/1120 720x480p60 (858x525) stds: flags:]
		[dv.current:BT.656/1120 640x480p59 (800x525) stds:CEA-861,DMT flags:has-cea861-vic]
		-> "13e40000.host1x:nvcsi@15a00000-":0 [ENABLED]

- entity 25: vi-output, tc358743 10-000f (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video1
	pad0: Sink
		<- "13e40000.host1x:nvcsi@15a00000-":1 [ENABLED]

Any idea if that might be causing the issue or point to something misconfigured on my end ?

Thank you!

3

hello anomad,

there’re PHY interrupts,
for instance,
PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x02000000
PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x10000004
PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000004

these meant there’re errors with…
(1) DPHY deskew calibration not complete on data-lane. it usually happened when the calibration sequence length is not long enough
(2) It also report DPHY CIL lane alignment failure, this error is detected in the PHY partition that some lanes detected sync words while other lanes not.
(3) Besides, there’re more than one bit error detected on the data-lane sync word. it might be issues with sensor configuration.

4

Hello JerryChang,

This is a tc358743 so it should not need to deskew as the data rate is well below 1.5Gbps. I feel we’re in the same situation as Orin + tc358743 VIFALC_TDSTATE - #11 by nazaraa which does not look like it was ever resolved.

What triggers the dskew calibration check ? It seems several people are under the 1.5Gbps limit but are still having this issue.

Also - how would I track down where

(FAIL: Unknown sub-device (0002000a))

is happening ?

Thank you,

5

hello anomad,

we’ve recently address some camera bugs for JP-5.1.2/l4t-r35.4.1
please see-also below threads to apply the bug fixes for verification.
for example,
Topic 268833, for camera firmware to update deskew algorithm, and also stability fixes,
Topic 268519, to fix memory corruption within libnvargus

6

Hello Jerry thank you for your quick response.

I tried the flash but got an error :
From the command line where I ran flash.sh :

[   6.2782 ] Sending membct and RCM blob
[   6.2800 ] tegrarcm_v2 --chip 0x23 0 --pollbl --download bct_mem mem_rcm_sigheader.bct.encrypt --download blob blob.bin
[   6.2813 ] BL: version 1.2.0.0-t234-54845784-562369e5 last_boot_error: 0
[   6.2825 ] Sending bct_mem
[   6.2967 ] Sending blob
[   6.3477 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --chip 0x23 0 --pollbl --download bct_mem mem_rcm_sigheader.bct.encrypt --download blob blob.bin
Failed to flash/read t186ref.

And on the console output :

[0013.745] E> BL_CARVEOUT: Failed to allocate memory of size 0x36800000 for CO:44.
[0013.752] C> Task 0x20 failed (err: 0x49490303)
[0013.756] E> Top caller module: BL_CARVEOUT, error module: BL_CARVEOUT, reason: 0x03, aux_info: 0x03
[0013.765] C> Boot Info Table status dump :
01111111001110001111111111111111

Full logs available at :

Thank you

7

hello anomad,

may I double confirm the platform you’re using? is it a developer kit?

8

Hello Jerry,

It’s an Orin Nano 8GB on Xavier NX DevKit (we needed the HDMI out for our project).

9

hello anomad,

please update the board configuration to use p3509-a02+p3767-0000.

10

Hello Jerry,

The board is already using p3509-a02+p3767-0000. When I flash the board, I use the command:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device mmcblk1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml"  --showlogs --network usb0 p3509-a02+p3767-0000 internal```
11

hello anomad,

what’s your original commands to flash Orin Nano 8GB on Xavier NX DevKit?

please check this command works normally to generate camera-rtcpu-t234-rce_sigheader.img.encrypt
for example, $ sudo ./flash.sh --no-flash -r -k A_rce-fw jetson-agx-orin-devkit mmcblk0p1

12

Hello Jerry,

I’m still using the process outlined at Sample_fs usage when building your own kernel - #21 by anomad

Trying your flash command returns:

sudo ./flash.sh --no-flash -r -k A_rce-fw jetson-agx-orin-devkit mmcblk0p1
[sudo] password for parallels:
###############################################################################
# L4T BSP Information:
# R35 , REVISION: 4.1
# User release: 0.0
###############################################################################
Board ID() version() sku() revision()
Chip SKU(00:00:00:D0) ramcode() fuselevel(fuselevel_production) board_FAB()
Error: Unrecognized module SKU
13

hello anomad,

that’s due to tegraflash for checking board SKUs. you may workaround it by given board naming manually.
here’s an example.
$ sudo BOARDID=3701 BOARDSKU=0005 FAB=500 ./flash.sh --no-flash -r -k A_rce-fw jetson-agx-orin-devkit mmcblk0p1

you shall see the messages as following, and sign/encrypt rce-fw binary file has created.

[   0.0337 ] Copying camera-rtcpu-t234-rce_sigheader.img.encrypt to /home/jerry/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/bootloader
[   0.0337 ] Signed file: /home/jerry/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/bootloader/camera-rtcpu-t234-rce_sigheader.img.encrypt
*** camera-rtcpu-t234-rce.img has been signed successfully. ***
14

Using the board naming variables gave the expected message that it was signed successfully.

I then ran the command :
sudo BOARDID=3701 BOARDSKU=0005 FAB=500 ./flash.sh -r -k A_rce-fw jetson-agx-orin-devkit mmcblk0p1

But received the same errors as before.

15

hello anomad,

it’s incorrect flash commands with Orin SOM on Xavier NX Carrier.
please refer to Topic 260583 for the steps to update rce-fw by using l4t_initrd_flash.sh.

16

Hello Jerry,

I tried the l44t_initrd_flash.sh command and it failed. It happened much faster than the previous attempt.

17

hello anomad,

it reports communication failed.
for instance,

[   0.0763 ] Sending bct_br
[   0.0816 ] Sending mb1
[   0.0828 ] ERROR: might be timeout in USB write.
[   0.0828 ]
Error: Return value 3
Command tegrarcm_v2 --instance 1-14 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
Cleaning up...

you should check you’ve put device enter recovery mode.
please refer to developer guide, To Determine Whether the Developer Kit Is in Force Recovery Mode.

furthermore,
you may also give it a try to re-create the kernel flash image, to re-flash the target again,
for example,
$ cp bootloader/camera-rtcpu-t234-rce_sigheader.img.encrypt tools/kernel_flash/images/internal/camera-rtcpu-t234-rce_sigheader.img.encrypt
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --no-flash --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml --external-only --append --network usb0 jetson-orin-nano-devkit external
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --network usb0 --flash-only

18

Hello Jerry,

The command failed. The last few lines from the command line were :

[   3.6501 ] tegrahost_v2 --chip 0x23 0 --align uefi_jetson_with_dtb_aligned.bin
[   3.6525 ] tegrahost_v2 --chip 0x23 0 --magicid CPBL --ratchet_blob ratchet_blob.bin --appendsigheader uefi_jetson_with_dtb_aligned.bin zerosbk
[   3.6537 ] adding BCH for uefi_jetson_with_dtb_aligned.bin
[   3.7445 ] tegrasign_v3.py --key None --list uefi_jetson_with_dtb_aligned_sigheader.bin_list.xml --pubkeyhash pub_key.key --sha sha512
[   3.7447 ] Assuming zero filled SBK key
[   3.7543 ] Warning: pub_key.key is not found
[   3.7544 ] tegrahost_v2 --chip 0x23 0 --updatesigheader uefi_jetson_with_dtb_aligned_sigheader.bin.encrypt uefi_jetson_with_dtb_aligned_sigheader.bin.hash zerosbk
[   3.7623 ] Copying enc\/signed file in /home/parallels/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/bootloader/signed
[   3.7625 ] Copying br bct for multi chains
[   3.7626 ] Signed BCT for boot chain A is copied to /home/parallels/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/bootloader/signed/br_bct_BR.bct

[   3.7627 ] Signed BCT for boot chain B is copied to /home/parallels/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/bootloader/signed/br_bct_b_BR.bct

[   3.7644 ] Copying uefi_jetson_with_dtb_sigheader.bin.encrypt to /home/parallels/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/bootloader/signed
[   3.7663 ] Signed file: /home/parallels/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/bootloader/signed/uefi_jetson_with_dtb_sigheader.bin.encrypt
[   3.7693 ] tegraparser_v2 --pt flash.xml.bin --generateflashindex /home/parallels/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/bootloader/signed/flash.xml.tmp flash.idx
[   3.7705 ] File system_root_encrypted.img_ext open failed
Error: Return value 19
Command tegraparser_v2 --pt flash.xml.bin --generateflashindex /home/parallels/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/bootloader/signed/flash.xml.tmp flash.idx
Error: /home/parallels/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/bootloader/signed/flash.idx is not found
Error: failed to relocate images to /home/parallels/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/tools/kernel_flash/images
Cleaning up...

Here are the console and command line captures:

19

hello anomad,

ohh… did you have disk encryption enabled?
above commands did not assume setting ROOTFS_ENC=1 to enable disk encryption.

hence,
please do generate images for external storage device by ROOTFS_ENC=1 and also provide the keys for EKB, -i ekb.key.
for example, $ sudo ROOTFS_ENC=1 l4t_initrd_flash.sh ... -i ./ekb.key...

20

Hello Jerry,

I did not purposefully enable disk encryption- I presume that is the default when building the OS using SDK Manager ?

In looking through the code - is ROOTFS_ENC an environment variable? I do not have that set.

EDIT: Also I do not have a file named ‘ekb.key’ on my dev machine

21

hello anomad,

what’s your command-line to re-flash your platform? you may update those binary update to re-flash the device accordingly.

or…
you may waiting for next public release, those fixes (as mentioned in comment #5) has check-in to rel-35 code-line.
hence, you may expect next Jetpack public release will include those bug fixes.