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
imagenet-camera
args (2): 0 [./imagenet-camera] 1 [googlenet]
[gstreamer] initialized gstreamer, version 1.8.3.0
[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
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?
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?
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?
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/
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”?
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”.
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/
Have downloaded the kernel source and then tried to build the kernel but without success, there are several errors:
several files are missing during make zImage (bound.c got syntax problem, then kemem.c gf20a.h not found), which cause failure.
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?
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:
How exactly does plugin-manager work? Will plugin-manager affect the status of i2c@3180000 / host1x / CSI (from disable to okay)?
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
How can we correctly check the status of i2c/csi lane?
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 {
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).
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.
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?
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]