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? [code]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[/code]
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

#1
Posted 12/24/2017 03:33 AM   
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.
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.

#2
Posted 12/25/2017 05:52 AM   
[quote="WayneWWW"]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.[/quote] Is there anyway to simulate it or just to ignore it from the driver side?
WayneWWW said: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?

#3
Posted 12/26/2017 08:12 AM   
HI KitKatY, Please look into the l4t document for how to use camera module without EEPROM. https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-2 Camera Development-> Sensor Driver Programming guide -> Using Plugin Manager
HI KitKatY,

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

https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-2


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

#4
Posted 12/26/2017 08:30 AM   
[quote="WayneWWW"]HI KitKatY, Please look into the l4t document for how to use camera module without EEPROM. https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-2 Camera Development-> Sensor Driver Programming guide -> Using Plugin Manager[/quote] 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?
WayneWWW said:HI KitKatY,

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

https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-2


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?

#5
Posted 12/27/2017 05:17 AM   
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.
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.

#6
Posted 12/27/2017 05:41 AM   
[quote="WayneWWW"]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.[/quote] 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? https://devtalk.nvidia.com/default/topic/947552/enabling-ov5693-v4l2-driver-in-l4t-24-1/ https://devtalk.nvidia.com/default/topic/963114/tegra_camera-module-can-not-load/
WayneWWW said: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?

https://devtalk.nvidia.com/default/topic/947552/enabling-ov5693-v4l2-driver-in-l4t-24-1/

https://devtalk.nvidia.com/default/topic/963114/tegra_camera-module-can-not-load/

#7
Posted 12/27/2017 09:04 AM   
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.
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.

#8
Posted 12/27/2017 09:39 AM   
[quote="WayneWWW"]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.[/quote] 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?
WayneWWW said: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?

#9
Posted 12/28/2017 05:24 AM   
[quote=""][quote="WayneWWW"]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.[/quote] Thank you. We are using ov5693 same as the camera board. we have three questions. [b]Question 1:[/b] 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? [b]Question 2:[/b] And according to the L4T Sensor Driver Programming Guide r28.1, there should be tegra186-quill-p3310-1000-a00-00-base.dtsi, but that file is missing, only tegra186-quill-p3310-1000-a00-00-base.dts. Is it normal? [b]Question 3:[/b] Is there any tutorial or detailed instruction to compile and deploy the kernel for TX1/TX2? [/quote]
said:
WayneWWW said: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.


Thank you.

We are using ov5693 same as the camera board.

we have three questions.
Question 1:
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?

Question 2:

And according to the L4T Sensor Driver Programming Guide r28.1, there should be tegra186-quill-p3310-1000-a00-00-base.dtsi, but that file is missing, only tegra186-quill-p3310-1000-a00-00-base.dts. Is it normal?

Question 3:
Is there any tutorial or detailed instruction to compile and deploy the kernel for TX1/TX2?

#10
Posted 12/28/2017 06:28 AM   
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/
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/

#11
Posted 12/28/2017 07:02 AM   
[quote="WayneWWW"]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/ [/quote] 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"?
WayneWWW said: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"?

#12
Posted 12/28/2017 07:30 AM   
Step 2 looks not exact to me. You should download our kernel source in following link https://developer.nvidia.com/embedded/dlc/l4t-sources-28-1 and following steps in document for building kernel. https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-1 put the dtb from your build path to /out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/kernel/dtb/
Step 2 looks not exact to me.

You should download our kernel source in following link

https://developer.nvidia.com/embedded/dlc/l4t-sources-28-1


and following steps in document for building kernel.


https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-1


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

#13
Posted 12/28/2017 08:12 AM   
[quote="WayneWWW"]Step 2 looks not exact to me. You should download our kernel source in following link https://developer.nvidia.com/embedded/dlc/l4t-sources-28-1 and following steps in document for building kernel. https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-1 put the dtb from your build path to /out/l4t-t186ref-release-aarch64/full_linux_for_tegra/Linux_for_Tegra/kernel/dtb/ [/quote] 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?
WayneWWW said:Step 2 looks not exact to me.

You should download our kernel source in following link
https://developer.nvidia.com/embedded/dlc/l4t-sources-28-1

and following steps in document for building kernel.

https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-1


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?

#14
Posted 12/28/2017 08:53 AM   
KitKatY, 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/ [code] sudo ./flash jetson-tx2 mmcblk0p1 [/code] 3. If want to do cross-compilation, we also provide tool chain to build kernel on PC. https://developer.nvidia.com/embedded/dlc/l4t-gcc-toolchain-64-bit-28-1
KitKatY,

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


3. If want to do cross-compilation, we also provide tool chain to build kernel on PC.

https://developer.nvidia.com/embedded/dlc/l4t-gcc-toolchain-64-bit-28-1

#15
Posted 12/28/2017 09:07 AM   
Scroll To Top

Add Reply