hello,
we have some tx2 modules bought from local agent, and these tx2 modules have no firewire inside,
- one tx2 module, we flash full system by flash.sh tool, the full system contains our own system.img which cloned and modified from official ubuntu system,
after that, we capture ov5693 image by gst-launch tool, the image looks wired and is different from official tx2 devkit.
the flash command is:
sudo ./flash.sh jetson-tx2 mmcblk0p1
- the other tx2 module, we flash full system by SDK manager, then reflash our cloned system same with step 1
after that, the image from ov5693 is similar with official tx2 devkit…
till now, we don’t know what issues cause the difference…
if we use sdk manager to flash our board (tx2 module + custom carrie board), does it have any difference (fireware, info, bin files, etc…) between custom board and official board?
the image looks wired and is different from official tx2 devkit.
hello ChinoLuo,
what does this means, do you have capture results for reference?
how the tx2 module and system recognize carrier board version, such as e3326?
I found some drivers didn’t initial if tx2 module running on our custom carrier board…
hello ChinoLuo,
please refer to Device Registration chapter, it’s by default have plugin-manager to register camera device.
On booting BL31 stage, eeprom attatched camera sensor will be detectd…
can it be disabled?
I2C: slave not found in slaves.
[0001.966] E> I2C: Could not write 0 bytes to slave: 0x00ae with repeat start true.
[0001.974] E> I2C_DEV: Failed to send register address 0x00000000.
[0001.980] E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xae at 0x00000000 via instance 7.
[0001.989] E> eeprom: Failed to read I2C slave device
hello ChinoLuo,
please unregister Plugin Manager support, you may revise the sources of device tree to register a camera device with main platform device tree file.
i comment eeprom-manager in tegra186-quill-p3310-1000-a00-plugin-manager.dtsi as followed：
but still have eeprom detection on BL31 stage…
hello ChinoLuo,
you should have a try to exclude pugin-manger.dtsi completely.
for example,
diff --git a/kernel-dts/tegra186-quill-p3310-1000-a00-00-base.dts b/kernel-dts/tegra186-quill-p3310-1000-a00-00-base.dts
index b8fad4c..01a84b1 100644
--- a/kernel-dts/tegra186-quill-p3310-1000-a00-00-base.dts
+++ b/kernel-dts/tegra186-quill-p3310-1000-a00-00-base.dts
@@ -24,7 +24,6 @@
#include <t18x-common-modules/tegra186-super-module-e2614-p2597-1000-a00.dtsi>
#include <t18x-common-plugin-manager/tegra186-quill-display-plugin-manager.dtsi>
#include <t18x-common-prod/tegra186-priv-quill-p3310-1000-a00-prod.dtsi>
-#include <t18x-common-plugin-manager/tegra186-quill-camera-plugin-manager.dtsi>
hello,
how the tx2 system recognize camera module, such as e3326? does module information memory in EEPROM?
hello ChinoLuo,
yes, it’s camera board with eeprom to contain the info, and plugin-manger to parse the string, such as… ids = "3326-*";
if my ov5693 camera module has no EEPROM, ids sets as ids = "*", and EEPROM initialization has been removed from ov5693 driver…
In this case, will it affect image quality captured from ov5693?
hello ChinoLuo,
no, eeprom it has nothing to do with image quality.
it’s ISP tuning file to affect image quality.
please also check the badge property in sensor device tree, camera stack check this unique string for loading tuning parameters.
OK,
I also have a question, except for camera module info, does tx2 system also recognize other modules info? for example carrier board info.
hello ChinoLuo,
may I know what’s the actual use-case?
there’re other configurations load by plugin-manager. you may check public_sources/kernel_src/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-plugin-manager/ for reference.
we use tx2 module + custom carrier board + ov5693 without EEPROM combined to process camera image…
currently we meet some image quality issues that seem related to EEPROM, we don’t know what issue it is, so now we are checking every parts, include software and hardware…
As you mentioned ISP turning file, does it store in filesystem?
hello ChinoLuo,
what’s the image quality issues you seen? had you try replace camera modules to have cross validation?
please check your file system, /var/nvidia/nvcam/settings/.
if there’s camera_overrides.isp file exist, camera stack prior to load file and use those settings apply to camera frames. there’re also *.bin file to cache the camera settings, you may delete those binary file if you have new IQ settings.
BTW, may I also know which Jetpack release you’re working with.
hello,
may I also know which Jetpack release you’re working with.
Jetpack 4.5.1
what’s the image quality issues you seen?
I will upload faulty image later…
had you try replace camera modules to have cross validation?
not yet, I will have a try later.
hello,
on official dev board, the image captured from ov5693 shows as followed:
on our carrier board, attatchs e3326 module, ubuntu system and dts was modified but badge is the same, the image shows as followed:
it looks very strange…
what is the most likely cause of this problem?
can it support to check IQ settings
