Hardware Issue on Camera Board

Hi, I’ve discovered an interesting problem on the CSI camera board. Once I desoldered the EEPROM onboard, the camera demo doesn’t seem to work. But when soldering back, everything works well. During the time when not working, there are quite a few error on the gstreamer, indicating the camera is not found.

Could you please explain why this happens? Is there any driver related element placed inside the EEPROM?

camera googlenet
  args (2):  0 [./imagenet-camera]  1 [googlenet]  

[gstreamer] initialized gstreamer, version
[gstreamer] gstreamer decoder pipeline string:
nvcamerasrc fpsRange="30.0 30.0" ! video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, format=(string)NV12 ! nvvidconv flip-method=2 ! video/x-raw ! appsink name=mysink

imagenet-camera:  successfully initialized video device
    width:  1280
   height:  720
    depth:  12 (bpp)

imageNet -- loading classification network model from:
         -- prototxt     networks/googlenet.prototxt
         -- model        networks/bvlc_googlenet.caffemodel
         -- class_labels networks/ilsvrc12_synset_words.txt
         -- input_blob   'data'
         -- output_blob  'prob'
         -- batch_size   2

[GIE]  attempting to open cache file networks/bvlc_googlenet.caffemodel.2.tensorcache
[GIE]  loading network profile from cache... networks/bvlc_googlenet.caffemodel.2.tensorcache
[GIE]  platform has FP16 support.
[GIE]  networks/bvlc_googlenet.caffemodel loaded
[GIE]  CUDA engine context initialized with 2 bindings
[GIE]  networks/bvlc_googlenet.caffemodel input  binding index:  0
[GIE]  networks/bvlc_googlenet.caffemodel input  dims (b=2 c=3 h=224 w=224) size=1204224
[cuda]  cudaAllocMapped 1204224 bytes, CPU 0x102a00000 GPU 0x102a00000
[GIE]  networks/bvlc_googlenet.caffemodel output 0 prob  binding index:  1
[GIE]  networks/bvlc_googlenet.caffemodel output 0 prob  dims (b=2 c=1000 h=1 w=1) size=8000
[cuda]  cudaAllocMapped 8000 bytes, CPU 0x102c00000 GPU 0x102c00000
networks/bvlc_googlenet.caffemodel initialized.
[GIE]  networks/bvlc_googlenet.caffemodel loaded
imageNet -- loaded 1000 class info entries
networks/bvlc_googlenet.caffemodel initialized.
default X screen 0:   1920 x 1080
[OpenGL]  glDisplay display window initialized
[OpenGL]   creating 1280x720 texture
loaded image  fontmapA.png  (256 x 512)  2097152 bytes
[cuda]  cudaAllocMapped 2097152 bytes, CPU 0x102e00000 GPU 0x102e00000
[cuda]  cudaAllocMapped 8192 bytes, CPU 0x102c02000 GPU 0x102c02000
[gstreamer] gstreamer transitioning pipeline to GST_STATE_PLAYING
Socket read error. Camera Daemon stopped functioning.....
gst_nvcamera_open() failed ret=0
[gstreamer] gstreamer failed to set pipeline state to PLAYING (error 0)

imagenet-camera:  failed to open camera for streaming

Hi KitKatY,

Device tree plugin manager requires the info in EEPROM to know what camera driver tegra should use.If you disable EEPROM, this could cause problem.

Is there anyway to simulate it or just to ignore it from the driver side?

HI KitKatY,

Please look into the l4t document for how to use camera module without EEPROM.

Camera Development-> Sensor Driver Programming guide → Using Plugin Manager

We’ve gone through the document above and we want to confirm with you some details before diving into the document.

To be more specific, We have built a customized board without EEPROM. The CSI camera we had used is the exact same module (The camera has been tested on the Nvidia Carrier board) on the NVidia carrier board.

We don’t have the driver code for that camera since it’s originated from the reference design. Is there any possibility that we could just modify the device tree without touching any driver source code to bypass the EEPROM?

Hi KitKatY,

Yes, it is possible to directly use the device tree.

The section “Using Main Platform Device Tree File” in the doc I pointed out already tells how to remove plugin-manager. After the removal, you need to add your own camera module’s device tree.

So if we remove the plugin-manager, where should the device tree be modified? Is there a dts/dtsi file to do it? We are not so familiar with Linux device tree.

And is it a similiar operation with these 2 threads?

Hi KitKatY,

What camera sensor are you using? If ov5693, its device tree should already there. Plugin-manager just modifies corresponding field according to the result from EEPROM.

As you can see in the file “tegra186-quill-camera-plugin-manager.dtsi”, it modifies different field according to their camera module.

We are using ov5693 same as the camera board.
Is it correct process as following,

Step 1: Download source code of l4t and modify the file “tegra186-quill-camera-plugin-manager.dtsi”
Step 2: Rebuild the kernel
Step 3: Re-deploy the modified kernel to TX1/TX2.

Could you help us to confirm the about step is correct?

Hi KitKatY,

Sorry that document may have a typo… It should be normal.

After rebuild the device tree, a new dtb file would be generated. Please replace it under /out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/kernel/dtb/

So is it correct that:

  1. Recompiling the kernel is not necessary;

  2. Replace the dtb file in /boot/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb with the newly gererated one under /out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/kernel/dtb/ using “make dtbs”?

Step 2 looks not exact to me.

You should download our kernel source in following link

and following steps in document for building kernel.


put the dtb from your build path to /out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/kernel/dtb/

Thanks for you kindness.

And there are still some issues to be clarified:

  1. Currently, the path you provided is missing, is it a generated path once built the kernel?

  2. After the kernel is built, how can it be renewed?

  3. I’ve tried to download the kernel and follow the instruction to build the kernel on my PC but seems no luck, is that kernel must be built on the TX2?


  1. The path is inside jetpack, this is where you flash the image. If you worked this on jetpack, you should notice there is a new directory “64_TX2”.

  2. Not pretty sure what “renew” means, I guess you meant reflash. Use following command in /out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/

sudo ./flash jetson-tx2 mmcblk0p1
  1. If want to do cross-compilation, we also provide tool chain to build kernel on PC.

Thanks for your reply.

Have downloaded the kernel source and then tried to build the kernel but without success, there are several errors:

  1. several files are missing during make zImage (bound.c got syntax problem, then kemem.c gf20a.h not found), which cause failure.

  2. installed device-tree-compiler (Initially want to bypass building the whole kernel since only thing needed to be done is the dtb file), but it cannot recognize the include file, which caused the parse error.

Could you advise how to fix the errors and build the dtb successfully?

Hi Wayne,

We’ve rebuilt the kernel without problem and flash the device tree to /dev/mmcblk0p15 using dd command on the device. but it seems the camera is still offline (not on /dev/video0).

And after some research, inside tegra186-quill-camera-modules.dtsi (/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms), all i2c/csi/host1x ports are with status=“disabled”.

We’ve also tried using i2cdetect -r -y 5 to probe the camera on 0x6C/0x6D (i2c 0-5). But nothing shows up on these i2c buses.

Here are some questions:

  1. How exactly does plugin-manager work? Will plugin-manager affect the status of i2c@3180000 / host1x / CSI (from disable to okay)?

  2. If plugin-manager has been disabled following the camera development section of the manual, is it correct that nothing else needs to be touched? Or the tegra186-quill-camera-modules.dtsi need to change some nodes from disabled to okay

  3. How can we correctly check the status of i2c/csi lane?


  1. How exactly does plugin-manager work? Will plugin-manager affect the status of i2c@3180000 / host1x / CSI (from disable to okay)?

Yes, of course it affects. Please take a look at plugin-manager: tegra186-quill-camera-plugin-manager.dtsi.

For example, following section is for E3326 camera board and it would override some status from “disable” to “okay” and thus that camera board is on.

/* E3326 camera board */
fragment-e3326@0 {
  1. If plugin-manager has been disabled following the camera development section of the manual, is it correct that nothing else needs to be touched? Or the tegra186-quill-camera-modules.dtsi need to change some nodes from disabled to okay

You need to find which camera you are using and then modify all needed field. You can refer to plugin-manager to know what fields are needed. (E3326 is the default board of OV5693 sensor).

  1. How can we correctly check the status of i2c/csi lane?

You can check current device tree through /proc/device-tree.

Note that device-tree is just a blob file which contains bunch of info read by camera driver. Thus, in fact you don’t need to replace whole kernel image but only the dtb file.

Hi Wayne,

I’ll give it a shot first, since I can see nothing using dmesg | grep nvcsi (grep 1570000 neither)

Thanks for your instant reply.


Good morning Wayne,

There are a few things unclear on the dtsi(s):

  1. Several nodes in tegra186-quill-camera-modules.dtsi is missing (i.e. target = <&e3326_vi_in0>, target) = <&e3326_csi_in0>…), however these parameters(labels) can be found in tegra186-quill-e3326-a00.dtsi. Is there any other dts file contains the missing info? Is it safe to modify those parameters in tegra186-quill-e3326-a00.dtsi?

  2. Some of the parameters cannot be found in nodes (i.e. num-channels = <1> @csi_base of tegra186-quill-camera-modules.dtsi…). Is it safe to add? Overlay function in dts is to add or change the content?[/s]