We are currently trying to bring-up the C-PHY interface from MAX96712 on the E3653. We already verified D-PHY interface which was working fine.
We have configured MAX96712 to output on 4 trios with 2.5Gbps.
As we follow Camera Design Guide we patched csi5_fops.c to to the lane swizzle (brick_config.lane_polarity[1] = NVCSI_CPHY_POLARITY_BCA;)
In Device Tree we changed from phy_mode = “DPHY”; to phy_mode = “CPHY”;
When we start a v4l2-ctl capture process, we see initialization works fine (also lane swizzle is applied) but we see only capture timeouts but no other events from NVCSI/VI. Even if we have applied e.g. wrong pixel clock hz configuration etc. we would expect to see at least some PHY_INTR0 errors.
We use the following Jetpack version: R36 (release), REVISION: 5.0, GCID: 43688277, BOARD: generic, EABI: aarch64, DATE: Fri Jan 16 03:50:45 UTC 2026
could you please share the tracing logs in single text file for reference.
besides.. could you please probe the MIPI signaling to confirm there’s sensor streaming output to CSI port.
Probing is really hard on this board. We confirmed with ADI FAE that on MAX96712 PHY0/1 and CSI2_TX1/2 counters are running which confirm that MAX96712 outputs data. Also Video Lock is set. As the board is very small, we need to find a way to probe. W
please double check VI driver for the brick_config.lane_polarity[]
you may review the NVCSI_CIL_A_POLARITY_SWIZZLE_CTRL has configured correctly.
is it possible to reduce the MAX96712 output data-rate, such as 1.0~1.5 Gsps/trio for testing?
please give it a try to boost all the VI/CSI/ISP clocks. you may skip ISP clock settings for gathering frames via v4l2 IOCTL.
for instance,
sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
just an FYI,
let me share some VI tracing logs with a success image capture as an example
here must be one pair of CHANSEL_PXL_SOF/CHANSEL_PXL_EOF to indicate a frame has detected by VI engine.
afterwards, it’s ATOMP_FRAME_DONE to indicate it’s complete writing a frame to memory.
Can I somehow check this register from the driver? I see the brick_config is then used in the csi5_send_control_message, so not entirely clear where the register is actual set.
Regarding speed: Yes, we already tried to reduce speed and boost clocks. We will setup probing next week.
The two mentioned registers in the other thread were already set to max value.
you may give it a try to have register dumps to obtain more CSI details.
you may enable camera stream, and dump PH_WC and PF_CRC to examine the packet. please refer to TRM for details.
such as.. NVCSI_STREAM_0_PH_WC_0 and NVCSI_STREAM_0_PF_CRC_0.
here’re example to check the register from system level.
you should..
– check TRM for [3.1.2 System Address Map] for the base address for NVCSI,
for example, NVCSI 0x15a00000 0x15a4ffff SYSTEM, base=0x15a00000.
– please check the target register offset, NVCSI_STREAM_0_PH_WC_0, Byte Offset= 0x101dc
– calculate the address of PH_WC, 0x15a00000+0x101dc = 0x15a101dc
– enable the camera stream and dump the PH_WC for its register values,
for example, $ sudo ./busybox devmem 0x15a101dc
BTW,
since there’s firewall settings. please see-also Topic 234321 to disable OEM firewall to access NVCSI registers.
this looks incorrect.
you may refer to camrtc-capture.h for the definition of NVCSI lane swizzles.
for instance,
please give it a try to set… brick_config.lane_swizzle = NVCSI_LANE_SWIZZLE_A0A1B0B1;
the errors change to type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x00000008 → intr_cil_data_lane_ctrl_err0_a
I don’t fully understand the reason behind the need for lane polarity change, but it seems to make a difference (Trio 0 → A0A/B/C → CSI0 D0P/N/CLK0P, Trio 1 → A1A/B/C → CSI0 CLK0N/D1P/D1N, Trio 2 → B0A/B/C → CSI1 D0P/D0N/CLK1P).
that’s correct, it means CPHY calibration has done.
may I double check your lane_polarity settings for lane-0 and lane-1?
FYI,
since there’s no other tracing logs. it means VI has not receive a frame.
you should expect it following with CHANSEL_PXL_SOF/CHANSEL_PXL_EOF for a validate frame, and then ATOMP_FRAME_DONE to indicate a frame has written to memory correctly.
let’s double check your sensor pixel clock rate.
you may review your clock rate with CPHY factor.. 16/7 instead of using approximate 2.28.
so.. your data rate should be.. 1200 Mhz * 16 / 7 ~= 2742857143 bits/s/trio.
serdes_pix_clk_hz = 2742857143 * 2 (trio) / 12 (Raw12) ~= 457142857 Hz, which is higher than your settings.
please try update your sensor pixel clock rate for verification.
I changed to the suggested 457142857 Hz. But I still see no data.
Regarding polartiy:
With lane[0] = ABC and lane[1] = BCA I only get type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x00000080 no matter polarity setting on MAX96712.
With lane[0] = ABC and lane[1]= ABC I can get the CPHY calibration done flag by also adjusting lane polarity on MAX96712.
Btw, we again cross-checked the sensor yesterday with D-PHY. D-PHY reception on Orin from MAX96712 is working fine with 2.5 GBit/s @ 4 lanes (so just to confirm that sensor is working and video pipe configuration of MAX96712 is fine).
