Failed to capture video from Jetson Thor with R38.4 release

Robotics & Edge Computing Jetson Systems Jetson Thor
1

Dear experts, hello.

When I insert the ISX031 MIPI camera into the Thor carrier board, I cannot capture image data through v4l2. I am using the T5000 module and a custom carrier board.

The BSP version is R38.4 release.

v4l2-ctl --set-fmt-video=width=1920,height=1536,pixelformat=UYVY --stream-mmap -d /dev/video0

image

Here is the dmesg information:

dmesg.txt (119.7 KB)

I conducted further troubleshooting, as follows.

sudo su
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 3 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo 1 > /sys/kernel/debug/tracing/trace

v4l2-ctl --stream-mmap -c bypass_mode=0

cat /sys/kernel/debug/tracing/trace

trace.txt (28.6 KB)

dmesg_add.txt (4.5 KB)

image
image1030×343 76.8 KB

Could you give me some advice?

I am certain that the ISX031 camera has MIPI signal output, and it is a camera module with an integrated ISP.

3

hello hemz,

may I know your commands to flash Thor target.
please see-also Topic 360835, Jetson AGX Thor Developer kit does not support CSI configuration.
it’ll not enable camera function if you flashing a board with Thor developer kit board configuration file. (i.e. jetson-agx-thor-devkit.conf)

4

hello JerryChang,

I use this command:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
    upai-pro03-box-a00 internal

upai-pro03-box-a00.conf.txt (3.4 KB)

thanks a lot.

One situation I’d like to confirm with you:‌ My ISX031 camera operates in master mode, meaning it outputs MIPI signals immediately upon power-up, and the ISX031’s MIPI data is already being transmitted before the Thor CSI interface is initialized—could this lead to the CSI being unable to properly receive data frames?

5

hello hemz,

according to upai-pro03-box-a00.conf.txt (3.4 KB).
let me re-cap as below..
DTB_FILE="tegra264-p4071-0000+p3834-0008-nv.dtb";
OVERLAY_DTB_FILE="L4TConfiguration.dtbo,tegra264-p4071-0000+p3834-xxxx-dynamic.dtbo,tegra264-camera-isx031.dtbo";
these were DTB and DTBO files of Jetson AGX Thor Developer kit, which does not support CSI configuration.

please try revise the board configuration,
the device tree overlay for CSI configuration applies to the p3971 SKUs only.

6

hello, JerryChang,

I would like to further confirm,

If I modify the device tree file( tegra264-p4071-0000.dtsi ) as follows:

#include "tegra264-camera-isx031.dtsi"       // Added by hemz

tegra264-camera-isx031.dtsi.txt (16.5 KB)

Is this okay?
Thanks.

7

hello hemz,

please aware that..
the Jetson AGX Thor devkit (i.e. p3834+p4071) and its config jetson-agx-thor-devkit.conf do not have a CSI connector/use-case;
that board is not used for CSI validation.

you should not use jetson-agx-thor-devkit board configuration for a custom carrier board.
instead, please copy a closest-match .conf, such as.. p3834-0008-p3971-0000-ufs.conf, rename it (e.g. my-thor-custom.conf) and adjust the UPHY_CONFIG, EXTERNAL_PT_LAYOUT, EXTERNAL_DEVICE for your actual use-case.
FYI, as you can see.. it’s p3834-0008-p3971-0000-ufs.conf -> p3834-0008-p3971-0000.conf (this is p3971 SKU as mentioned above)
this is the board configuration which are the actual CSI-capable board configs for Thor series.

BTW, see-also developer guide, Generate the Pinmux dtsi Files, to use the Thor pinmux spreadsheet to set CSI lane muxing and GPIOs..etc.

8

hello, JerryChang,

The custom carrier board is a hardware design referenced from the Jetson AGX Thor devkit and includes the Holoscan interface. The only difference is the adoption of a 16-lane CSI interface.

So, my previous conf file was based on the devkit.（jetson-agx-thor-devkit.conf）.

When I reviewed the following device tree files:

tegra264-p4071-0000.dtsi.txt (16.0 KB)

I saw the following content:

host1x@8181200000 {
			status = "okay";

			vi0@8188400000 {
				status = "okay";
			};

			vi0-thi@8188700000 {
				status = "okay";
			};

			vi1@8188c00000 {
				status = "okay";
			};

			vi1-thi@8188f00000 {
				status = "okay";
			};

			isp@8188800000 {
				status = "okay";
			};

			isp-thi@8188b00000 {
				status = "okay";
			};

			isp1@818a800000 {
				status = "okay";
			};

			isp1-thi@818ab00000 {
				status = "okay";
			};

			nvcsi@8188000000 {
				status = "okay";
			};
		};

I thought the CSI interface functionality was already enabled. Is that not the correct understanding?

9

hello hemz,

let’s execute the commands below to dump device tree into dts formats for checking.
for instance, $ sudo dtc -I fs -O dts /sys/firmware/devicetree/base > /tmp/123.dts

10

hello, JerryChang,

I think that the device tree already includes the CSI-related nodes.

123.dts.txt (333.0 KB)

Could you please help me confirm this as well? Thank you!

11

hello hemz,

wait.. does it mean sensor steam went through Holoscan Sensor Bridge Device Setup?
or.. it’s a customize carrier board which utilize CSI-A/4-lane and CSI-C/4-lane configuration?

12

hello, JerryChang,

yes, it’s a customize carrier board which utilize CSI-A/4-lane and CSI-C/4-lane configuration, in my current usage scenario‌.

BTW‌, all 16 lanes of MIPI signals have been routed out, referencing the Orin DevKit‌ (p3971 SKU as mentioned above).

Thank you very much.

14

hello hemz,

here’s a crucial device tree to enable CSI configuration, please refer to below for the compatible property.
for instance, $public_sources/kernel_src/hardware/nvidia/t264/nv-public/overlay/tegra264-p3971-0000+p3834-xxxx-csi.dts

         overlay-name = "Jetson AGX CSI Connector";
         compatible = "nvidia,p3971-0050+p3834-0005", "nvidia,p3971-0080+p3834-0008", "nvidia,p3971-0089+p3834-0008";

hence,
let’s have another quick try by flashing a board with the board config, p3834-0008-p3971-0000-nvme.
please also check.. $ cat /etc/nv_boot_control.conf after system boot-up, which reports TNSPEC and COMPATIBLE_SPEC.