MIPI CSI lane grouping


I’m exploring the Jetson Nano module and its MIPI CSI interface. In my case there will be 3 cameras with 4 lanes each.

Question: are there limitations on which lanes I can assign to which camera? Ideally I’d like to map them out so that the PCB routing becomes as easy as possible.


If I am not mistaken, you can only combine subsequent lanes. Ie. CSI 0/1 for camera 1, CSI 2/3 for camera 2 and CSI 4/5 for camera 3.

Hi borgeqm27i,

Please refer to CSI chapter in design guide: https://developer.nvidia.com/embedded/dlc/jetson-nano-product-design-guide

Thanks a lot everybody! That explains matters.



I am new to Jetson Nano so please excuse me if my question is very basic.

For connecting the three cameras on Nano developer kit (which support only one), i have to take out the CSI connections from the J2 connector. right ?

I see in the schematics that the other camera pins are put on test points on bottom of PCB. Are these test points available, so that i can take out the Nano module pins directly via soldering few test points on the developer kit PCB ?

I would be very grateful for any help provided in this regard.


Hi Sany,

I’ve considered makign a breakout board which both plugs into the Nano development board and can carry the Nano module. All pins routed straight through except the MIPI-CSI and I2C for camera control.

Is there an interest in something like that?


Hello Børge

Thanks for such a quick response.

I was actually considering the Nano development kit because of cost. I was not able to figure out why the module cost is higher than the development kit.

But in the development kit I can connect only one camera over MIPI. i was thinking if its possible to take out the pin signals from J2 connector or the test points directly.

I need USB3, ethernet and wifi as well. so inclusing these when i considered the cost, i felt developer kit is more suitable.

Please feel free to correct me if my understanding is not correct.

Thanks once again for quickly responding.


Hi Borge,

Does this mean that your breakout board has all the CSI pins from the nano module which are not available in the developer kit ? will that help me to connect 3 cameras to these extra CSI pins from your breakout board ?

The CSI lines are high-speed connections, and there are several of them. So patching them out from test points is not exactly trivial.

In addition, the cameras have I2C control. On the Nano dev board the pin CAM_MUX_SEL / GPIO06 controls how the shared I2C bus CAM_I2C_* is multiplexed onto the used J13 connector and an unconnected camera slot. I haven’t yet checked the code to see if CAM_MUX_SEL is actually used, or if the multiplexer has static configuration.

In order to use three or more cameras, the control of CAM_MUX_SEL must be done by additional GPIO pins, or more I2C buses must be assigned to the cameras.

Designing a breakout board for I2C mux and camera connectors is doable, but still requires quite the effort. With the hardware in place, the software stack must be set up to work with multiple cameras as well.


I understand your point regarding the issue in patching out all the camera related pins.

I also understand that making these changes are quite an effort, but my doubt is, whether its feasible ? I mean taking out all the camera CSI lines and their corresponding I2C/CLK lines out of the module directly and then modifying the kernel to enable these CSI lines.

Should be possible right ? What do you say ?

(Sorry to ask so many small questions, just trying to be careful before putting effort effort :) )

It may be possible, but my own preference would be to make a dedicated go-between PCB. (I’ve worked with PCB design for many years, that’s where I have my instincts.)

Doesn’t mean it won’t work. Please keep us posted if you decide to patch in the CSI lines.

For patching it may be that the multiple-I2C approach is better than MUX-I2C, simply because patching in a multiplexer is harder than patching in any available excess I2C bus.


Hi Borge,

Thanks a lot for responding.

I am also planning to patch out the individual I2C lines, instead of muxing. But it all depends on further analysis.

As of now i am doing a feasibility study to carry this out. I will come back to this post with updates and if making changes in PCB is more feasible, then i may again need your help :)

thanks a lot for making my day.