Discrepancy in CPHY Pin Mapping Documentation - Jetson Thor Design Guide

Hello Nvidia,

I have identified a discrepancy in the CPHY pin connections documented in the Jetson Thor Series Modules Design Guide (DG12084001_v1.2.pdf).

Documented Pin Connections:

  1. Figure 10-2. Camera CSI C-PHY Connections:
  • CSI_0_CLK_N connects to CPHY_01_A
  • CSI_0_D1_P connects to CPHY_01_B
  • CSI_0_D1_N connects to CPHY_01_C

  1. Table 10-1. Jetson Thor CSI Pin Description:
  • CSI0_CLK_N connects to CPHY Lane 1: C
  • CSI0_D1_P connects to CPHY Lane 1: A
  • CSI0_D1_N connects to CPHY Lane 1: B

My Questions:

  1. Which mapping (Figure 10-2 or Table 10-1) is the correct one for the physical pin connections?
  2. Our custom carrier board was designed based on the mapping in Figure 10-2. During debugging, we are encountering the following errors in the kernel trace log:
kworker/11:1-145 [011] ..... 1003.879920: rtcpu_nvcsi_intr: tstamp:1030300663207 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000080
kworker/11:1-145 [011] ..... 1003.879921: rtcpu_nvcsi_intr: tstamp:1030301722578 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x20000080

The status codes 0x00000080 and 0x20000080 often point to issues like incorrect lane mapping or signal integrity problems potentially related to the pin assignment. Is it possible to remap these CPHY lane connections through software configuration? If so, how can we adjust the configuration to align with the hardware mapping we used (based on Figure 10-2)?

Hello,

Jetpak: R38.2.1

When i modify the csi5_fops.c file as follows

/* Lane polarity */
if (!is_cphy) {
    unsigned int index = 0;
    printk("-----------------------------------------------------DPHY\n");
    for (index = 0; index < NVCSI_BRICK_NUM_LANES; index++)
        brick_config.lane_polarity[index] = (lane_polarity >> index) & (0x1);
} else {
    printk("-----------------------------------------------------CPHY\n");
    // Attempted polarity mapping based on potential Figure 10-2 interpretation
    brick_config.lane_polarity[0] = NVCSI_CPHY_POLARITY_ABC; // Lane 0: A->A, B->B, C->C
    brick_config.lane_polarity[1] = NVCSI_CPHY_POLARITY_BCA; // Lane 1: A->B, B->C, C->A
}

the trace log now shows a different status code

rtcpu_nvcsi_intr: tstamp:3219561899418 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x20000000

However, despite the change in the status code, the camera still fails to output an image. The video stream does not appear.

Could you please help analyze the cause?

dmesg log:
dmesg_log.txt (11.3 KB)

trace log:
trace_log.txt (35.8 KB)

CPHY polarity swizzle support is not yet available. Expected to be supported in future releases.

Hi sgursal,

I’ve made further modifications.

/* Lane polarity */
if (!is_cphy) {
    unsigned int index = 0;
    printk("-----------------------------------------------------DPHY\n");
    for (index = 0; index < NVCSI_BRICK_NUM_LANES; index++)
        brick_config.lane_polarity[index] = (lane_polarity >> index) & (0x1);
} else {
    printk("-----------------------------------------------------CPHY\n");
    brick_config.lane_polarity[0] = NVCSI_CPHY_POLARITY_ABC; 
    brick_config.lane_polarity[1] = NVCSI_CPHY_POLARITY_CAB; 
}

I can now successfully retrieve the camera frame rate using the v4l2-ctl command:

nvidia@nvidia:~$ v4l2-ctl -V --set-fmt-video=width=4056,height=3040 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=10000000 -d /dev/video6
Format Video Capture:
        Width/Height      : 4056/3040
        Pixel Format      : 'RG10' (10-bit Bayer RGRG/GBGB)
        Field             : None
        Bytes per Line    : 8112
        Size Image        : 24660480
        Colorspace        : sRGB
        Transfer Function : Default (maps to sRGB)
        YCbCr/HSV Encoding: Default (maps to ITU-R 601)
        Quantization      : Default (maps to Full Range)
        Flags             :
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 39.41 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 39.41 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 39.41 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 39.41 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 39.41 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 39.41 fps

The trace log during this v4l2-ctl streaming now shows:

kworker/1:1-121     [001] .....   610.196768: rtcpu_nvcsi_intr: tstamp:636440747682 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x40000000
kworker/1:1-121     [001] .....   610.196770: rtcpu_nvcsi_intr: tstamp:636440771913 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x20000000

But when I run argus_camera -d 6 , it fails to display the camera image. The trace log during this failure shows the original error codes again:

 kworker/1:1-121     [001] .....  1193.072193: rtcpu_nvcsi_intr: tstamp:1219335518226 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000080
 kworker/1:1-121     [001] .....  1193.072194: rtcpu_nvcsi_intr: tstamp:1219336156560 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x20000080

Thank you for any insights on resolving the argus_camera issue.

v4l2-ctl trace log:
v4l2_trace_log.txt (99.2 KB)

argus_camera trace log:
argus_trace_log.txt (59.0 KB)

@sgursal @ShaneCCC

Referring to the AGX Orin register settings mentioned in the forum post.
Is it possible to provide the devmem command for CPHY polarity swizzle on AGX Thor to fix argus_camera display?

hello norman_xu,

FYI, there’s correction of [Figure 10-2. Camera CSI C-PHY Connections],
the pattern should be CPHY_01_C/CPHY_01_A/CPHY_01_B, which as same as Table 10-1. Thor CSI pin description.

may I know which PHY you’re asking?
for instance,
NVCSI_PHY_0_NVCSI_CIL_A_POLARITY_SWIZZLE_CTRL_0 //Offset: 0x473a
NVCSI_PHY_1_NVCSI_CIL_A_POLARITY_SWIZZLE_CTRL_0 //Offset: 0x873a

Hi JerryChang,

Thank you for the reply.

Brick: PHY 0, Mode: C-PHY

Could you share the full register addresses (base address + offset) since we lack the TRM documentation?

Argus pipeline don’t support lane swizzle.

Your modification in csi5_fops.c/vi5_fops.c only for v4l2-ctl but Argus.

Thanks

hello norman_xu,

0x8188000000 is the NVCSI engine base address. NVCSI_PHY_0_NVCSI_CIL_A_POLARITY_SWIZZLE_CTRL_0’s address = 0x818800473a
swizzle control same as Orin’s spec, please give it a try, thanks

Hi JerryChang,

But 0x818800473a is invalid and cannot be read.

hello norman_xu,

when you access to NVCSI engine 0x8188000000 it’s shown 0xff.., it means it cannot be accessed.

Hi jerry,

Is OEM firewall disable required? Could you share the AGX Thor approach?

hello norman_xu,

for testing.. you may disable SCR_CONFIG from board configuration file, and then re-flash a target.
for instance,
jetson-agx-thor-devkit.conf: SCR_CONFIG="tegra264-mb2-bct-firewall-p3834-xxxx-p4071-0000.dts";

Hi jerry,

Still unable to access address 0x818800473a after re-flashing the system.

flash log:
flash_log.txt (5.4 MB)

Fixed by changing hardware to match Table 10-1 configuration. Thank you for the support.