Problem enabling D3 camera on db410c


Hi @loic and @ndec

I am trying to enable the D3 camera on the 410c with snapshot 491. I have followed Loic’s instructions from this thread 96Boards MIPI adapter but I consistently get the error:
Invalid bootimg: /dev/disk/by-partlabel/boot
I had to go into the script dt-update/scripts/db410c/ and change
if [ ! -f ${BOOTIMG} ]; then
if [ ! -e ${BOOTIMG} ]; then
The -f test fails because the file is a symlink and not a regular file.

Once the -f is changed to -e the script works.



Further followup on trying to enable cameras: once I have the appropriate camera turned on I find the /dev/video* and /dev/v4l devices are present, but the /dev/media[0-1] device is not present so I can’t setup a pipeline to do anything useful with the cameras.

I have tried this with the D3 Engineering board with a single OV5640, and with a AiStarVision V2.0 board with dual OV5645 cameras (I restored the kernel to original state between tests). I can see the dmesg that says the dual OV5645 camera were found, but still no /dev/media[0-1].

Here is a small portion of the dmesg log:

[ 3.967895] media: Linux media interface: v0.10
[ 3.977099] Linux video capture interface: v2.00
[ 4.004364] qcom-venus Linked as a consumer to 1ef0000.iommu
[ 4.004461] iommu: Adding device to group 0
[ 4.046496] rtc-pm8xxx 200f000.spmi:pm8916@0:rtc@6000: rtc core: registered pm8xxx_rtc as rtc0
[ 4.180539] qcom-camss 1b0ac00.camss: Linked as a consumer to 1ef0000.iommu
[ 4.185915] iommu: Adding device 1b0ac00.camss to group 1

Am I doing something silly? did I miss a step?


Hi @ljking

Yes, thanks, good fix to have, I think the others scripts use the correct test but not this one.

AFAIR, for ov5645, it’s fairly easy and supported by last qcomlt debian release (18.01) and snapshots. All you have to do is (normally) executing the dt-update ov5645 enable script.

For, ov5640/D3 mezzanine it’s a bit more complicated since the ov5640 is not functional and you need to rebuild the kernel/modules after patching the driver or using ‘my’ qcomlt-4.14-ov5640 branch:

Yes, you should have a /dev/media0 corresponding to the camera pipeline.

If you do not have any ov5640/ov5645 error could you please check with lsmod that the related driver (ov5640.ko/ov5645.ko) is correctly loaded, try to load it manually with insmod/modprobe (modprobe ov5640). Please also make sure that you copy the new kernel modules when you rebuild your kernel as described in the build steps:


I’m facing a similar problem. After editing the device tree (just edited the apq8016-sbc.dtsi file and set status = “ok” in four places, just like in this commit) and compile the kernel with the given instructions. I can find ov5645 loaded, if I check with lsmod. However with dmesg | grep ov5645 I get the following:

[ 4.286594] ov5645 4-003b: ov5645_write_reg_to: write reg error -5 on addr 0x3c: reg=0x3100, val=0x76
[ 4.286597] ov5645 4-003b: could not change i2c address
[ 4.286613] ov5645 4-003b: could not power up OV5645
[ 4.286877] ov5645: probe of 4-003b failed with error -5
[ 4.338468] ov5645 4-003a: ov5645_write_reg_to: write reg error -5 on addr 0x3c: reg=0x3100, val=0x74
[ 4.338471] ov5645 4-003a: could not change i2c address
[ 4.338486] ov5645 4-003a: could not power up OV5645
[ 4.338736] ov5645: probe of 4-003a failed with error -5

I believe this does not allow to create the /dev/media*. Reading the ov5645.c driver I find out that everything starts to fail with the instruction:
ret = i2c_transfer(ov5645->i2c_client->adapter, &msgs, 1);

By now I have checked several times hardware connections, but still don’t know what is causing this error.


I have made some progress. I removed one of the cameras from the AiStarVision OV5645 adapter, changed the jumpers to the single camera configuration and then /dev/media0 shows up as expected. My setup scripts for enabling the video pipeline are from almost a year ago and need to be fixed slightly to work with the latest, but I think I can handle that.

Since OV5645 works, I have set aside the OV5640 challenge for a day or two.

I am familiar with building and installing the modules, however, is there a quick easy way to use git to add your patches for OV5640 or do I need to download the tar files and expand them in my kernel build directory?

@Abrahamon, did you check the jumpers settings on your OV5645 board? They affect the I2C connections to the cameras. If I2C is not correctly connected, then the transfers will fail when the camera misses sending the ack for the transfer.


If you’re on a qcomlt 4.14 kernel you can add my repository as remote and cherry-pick or you can also simply pick patches from the web (3 patches):

curl | git am
curl | git am
curl | git am

Nice, you then need to setup the media pipeline (/dev/media0) before capturing to link the different camera elements together and configure the format (with media-ctl). You can look at 18.01 release note for example:
Note that you don’t need to rebuild gstreamer1.0-plugins-good anymore.

Issue with 410c D3 Camera Mezzanine set-up @ the make defconfig distro.config step

/dev/media0 link will only get created if all the cameras defined in DT probed successfully.


Thanks about this suggestion, I am following this configuration for the jumpers:
J13: 19-20 for CSI0 CCI SCL
J13: 21-22 for CSI0 CCI SDA
J14: 5-6 for 24MHz OSC clock for camera module of CSI0
CSI1/CAM1 Jumpers:
J13: 15-16 for CSI1 CCI SCL
J13: 17-18 for CSI1 CCI SDA
J14: 3-4 for 24MHz OSC clock for camera module of CSI1
With the AistarVision MIPI Adapter V2.1 but the same error.


Hi @Abrahamon

My AiStarVision board is V2.0, but it looks like we have the same jumpers. When I had dual cameras on the board and all of the jumpers installed it failed, when I removed the CSI1 camera and the CSI1 jumpers it works for a single camera.


Hi @Mani

The script that @loic provided doesn’t seem to have options for 1 or 2 cameras. it works for a single camera, but not dual cameras.


Hi @ljking
Which version of the Linaro Releases are you using?
I am using with the lastest Linaro Debian alip.


Release 18.01 is supposed to work.


Hi @Abrahamon, I am not using a “release”, I am using the bleeding edge snapshot #491.