Csi2 not work on the custom carrier

Hello,We have designed a carrier board based on the Xavier NX carrier Board(P3509-A01)schematic, all multiplexing pins remain consistent with the development board.
We have flashed jetPack 5.1.1 through SDK manager.Our carrier board have 2 csi,but only find /dev/video0 and no /dev/video1.CAM_MUX_SEL use the same pin GPIO06 as P3509 .


When shorted these pins: CAM0_I2C_SCL to CAM1_I2C_SCL, CAM0_I2C_SDA to CAM1_I2C_SDA, We have obtained /dev/video0, regardless of whether two cameras are plugged in. Using an oscilloscope to monitor CAM-MUX-SEL, it shows a high level after power on and no low level appears.
So no /dev/video1 should be caused by CAM-MUX-SEL not working properly.
According from Pinmux Table, GPIO06 is GPIO3_PCC.03, that GPIO number for PCC.03 is 267. We manually controlled gpio267, but it failed. Upon checking the system for the definition of CAM-I2C-MUX, it was found that there is no CAM-I2C-MUX in the system.
The command : sudo cat /sys/kernel/debug/gpio query results are in the following file:
imx219.log (8.3 KB)
Could you please give us some suggestions:

  1. What error occurred when we flashed the system and how do we need to adjust it?

  2. On the basis of this system, CSI problems can be solved by modifying the configuration. So how to make the modifications?

  3. Reburning another version that can correctly use both CSIs, and what is the version number?
    Thanks for you attention.

Attached the dts file useing the cmd exchanged:
sudo dtc -I fs -O dts -o xavier-nx.dts /proc/device-tree

[Uploading: xavier_nx.txt…]()

xavier_nx.txt (387.8 KB)

The log tell unable to communicate with imx219 by i2c command.
Please make sure the power/reset pins in correct state.

Thanks

ShaneCCC,
Thanks for your attention and reply.
CSI0 is worked good. So we think the power/reset pins should be in correct state.
We want to control CPIO06 that for CAM_I2C_MUX by /sys/class/gpio, but failed. Will you please give me some advice on it.
Thanks

Hi @rose_duan
I have a similar problem as like yours. What does it mean of power/reset pin?

@rose_duan
The CPIO06 use to be the mux that you can’t control by GPIO sysfs.

gpio-320 (PCC.03              |mux                 ) out hi 

Hi @ShaneCCC,
I have similar problem about this pin with orin nano
when i check the pin status it looks different.
gpio-331 (PCC.03 |mux ) out lo
How is this pin looking out lo?

According to Understanding SYSFS GPIO number for Xavier NX - Jetson & Embedded Systems / Jetson Xavier NX - NVIDIA Developer Forums, the gpio number with xaiver nx for CAM_I2C_MUX is 267. Why it’s 320 now?

My device is Orin NX should be different with XNX.
BTW you can check the GPIO # by below command.

cat /sys/kernel/debug/gpio

We got the gpio numbers with above command have post at imx219.log,and there is no number 267.

Hi ShaneCCC,
I post the result from command: cat /sys/kernel/debug/gpio ,and it’s not same as what I think. According to the other topic wirtten, the gpio number should be 267 with xaiver nx,but the reslut information has no 267. Is my dtb wrong,and what wrong with it?
imx219.log (8.3 KB)

Hi ShaneCCC,
imx219 need mclk to working.And I can’t find the configruation for the mclk. The mclk result that imx219 can’t work on csi2. So how can i configure mclk to extperiph?
Best regards

It’s different with devkit design?

Suppose need to add clock-namesand mclk = “extperiph1” to control it. For example.

                ov5693_a@36 {
                    clocks = <&bpmp_clks TEGRA194_CLK_EXTPERIPH1>,
                         <&bpmp_clks TEGRA194_CLK_PLLP_OUT0>;
                    clock-names = "extperiph1", "pllp_grtba";
                    mclk = "extperiph1";
                    clock-frequency = <24000000>;
                    reset-gpios = <&tegra_main_gpio CAM0_RST_L GPIO_ACTIVE_HIGH>;
                    pwdn-gpios = <&tegra_main_gpio CAM0_PWDN GPIO_ACTIVE_HIGH>;
                    vana-supply = <&e3900_avdd_cam_2v8_cvb>;
                    vif-supply = <&e3900_sys_1v8_cvb>;
                };

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.