Problem enabling D3 camera on db410c

ljking · January 9, 2019, 6:42pm

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/enable-d3-mezzanine.sh and change
if [ ! -f ${BOOTIMG} ]; then
to
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.

-Lawrence-

ljking · January 9, 2019, 8:27pm

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 1d00000.video-codec: Linked as a consumer to 1ef0000.iommu
[ 4.004461] iommu: Adding device 1d00000.video-codec 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?

Loic · January 9, 2019, 9:30pm

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: loic.poulain/linux.git - [no description]

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: Build & Update Linux kernel for Debian/OpenEmbedded - 96Boards.

Abrahamon · January 9, 2019, 10:52pm

Hello
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.
Thanks.

ljking · January 10, 2019, 5:56am

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.

Loic · January 10, 2019, 9:29am

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 https://git.linaro.org/people/loic.poulain/linux.git/patch/?id=1acdd6f13925304bfe42c5df8b635750d679565a | git am
curl https://git.linaro.org/people/loic.poulain/linux.git/patch/?id=24a2474c45b1ad054db9a00fc6b326d6acdfa2cb | git am
curl https://git.linaro.org/people/loic.poulain/linux.git/patch/?id=72b81a3f899a420f6818b6f7f6f1159e20a921f2 | 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: https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/18.01/
Note that you don’t need to rebuild gstreamer1.0-plugins-good anymore.

Mani · January 10, 2019, 10:24am

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

Abrahamon · January 10, 2019, 1:18pm

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.

ljking · January 10, 2019, 3:32pm

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.

ljking · January 10, 2019, 3:34pm

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.

Abrahamon · January 11, 2019, 3:11pm

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

Loic · January 16, 2019, 8:15am

Release 18.01 is supposed to work.

ljking · January 18, 2019, 5:33pm

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

Abrahamon · February 2, 2019, 11:25pm

Hi

I have tried the releases 17.06, 18.01, 19.01. I have compiled the kernel with the change from this commit and used this dt-update tool.
Just by removing the disabled status from those 4 lines in the .dtsi file is it supposed to work?

But still have the error I mentioned before. My kernel has more errors than the kernel from @ljking :

[ 9.550623] media: Linux media interface: v0.10
[ 9.566673] Linux video capture interface: v2.00
[ 9.615740] qcom-venus 1d00000.video-codec: Linked as a consumer to 1ef0000.iommu
[ 9.615835] iommu: Adding device 1d00000.video-codec to group 0

[ 9.641882] i2c-qcom-cci 1b0c000.cci: Master 0 error 0x08000000
[ 9.645956] i2c-qcom-cci 1b0c000.cci: master 0 queue 0 error -5
[ 9.648406] qcom,pm8916-wcd-spmi-codec 200f000.spmi:pm8916@1:codec@f000: DT property missing, MBHC btn detection disabled
[ 9.653101] i2c-qcom-cci 1b0c000.cci: cci i2c xfer error -5
[ 9.653110] ov5645 4-003b: ov5645_write_reg_to: write reg error -5 on addr 0x3a: reg=0x3100, val=0x76
[ 9.669386] ov5645 4-003b: could not change i2c address
[ 9.681644] ov5645 4-003b: could not power up OV5645
[ 9.685988] ov5645: probe of 4-003b failed with error -5

[ 9.828917] qcom-camss 1b0ac00.camss: Linked as a consumer to 1ef0000.iommu
[ 9.829007] iommu: Adding device 1b0ac00.camss to group 1
…

More information about the current state of the system:
A loaded kernel module called: ov5645
/dev/i2c-0, /dev/i2c-1, /dev/i2c-3, /dev/i2c-4

ls /proc/iomem:

01b00020-01b0002f : csi_clk_mux
01b00030-01b00033 : csiphy0_clk_mux
01b00038-01b0003b : csiphy1_clk_mux
01b08000-01b080ff : csid0
01b08400-01b084ff : csid1
01b0a000-01b0a4ff : ispif
01b0ac00-01b0adff : csiphy0
01b0b000-01b0b1ff : csiphy1
01b0c000-01b0cfff : /soc/cci@1b0c000
01b10000-01b10fff : vfe0

Does the MIPI Aistarvision V2.1 has been tested by someone else?
Could this be related to ADV HDMI? As mentioned here.

Beforehand, thanks for nay help.

Rob_Gries · March 20, 2019, 6:03pm

Hey Loic,

I’ve tried this with the 19.01 tag and I’m getting VFE0 pix0 overflow messages. I believe that this might be due to an improper pixel rate calculated in on line 1650 in ov5640.c in the ov5640_set_mode function. When checking yavta for the calculated pixel rate, it returns 42002400 which I believe is out of range for this particular camera 42 MHz pixel rate is compatible with the camera – the issue must be somewhere else, CAMSS perhaps?
Some particulars about my setup of the camera – 1280x720 @ 15FPS in NV12 is fed into a Gstreamer pipeline to gain H.264 encoded video.

These are a small sample of what I am seeing in the dmesg logs:
[ 2074.094064] ispif_isr_8x16: 140 callbacks suppressed
[ 2074.094073] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.127647] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.161157] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.194662] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.228174] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.261674] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.295091] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.328581] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.362082] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.395584] qcom-camss 1b0ac00.camss: VFE0 pix0 overflow
[ 2074.488818] qcom-camss 1b0ac00.camss: VFE sof timeout
[ 2075.000809] qcom-camss 1b0ac00.camss: VFE reg update timeout
[ 2076.001879] qcom-camss 1b0ac00.camss: vfe_camif_wait_for_stop: camif stop timeout

This is what I’m seeing in yavta:
— Image Processing Controls (class 0x009f0001) —
control 0x009f0902 `Pixel Rate’ min 0 max 0 step 0 default 0 current 42002400.

~~I’m going to try to see what I can do to get that pixel rate into a more “sane” range and see if there’s any noticeable differences in performance.~~

Rob_Gries · March 11, 2019, 12:42pm

I attempted to hard set the pixel rate to 96000000 and it appeared to allow the camera to work, but when attempting to engage the video codec I get the following error:

qcom-venus 1d00000.video-codec: HW is overloaded, needed: 432000 max: 352800

When the above error is seen it stops the encoder and shuts down my h.264 gstreamer encode pipeline. I’m a little stumped at this point. I haven’t seen that error before in the previous 18.01 kernel.

Loic · March 11, 2019, 3:04pm

Hi Rob, I’m going to try finding time to test this this week, did you try to revert the full ov5640 driver to 18.01 state (with ov5640 patch on top)? to check if problem is related to the ov5640 driver or the venus encoder.

Rob_Gries · March 11, 2019, 4:32pm

I haven’t tried that yet. But when I get a chance later tonight I’ll give it a shot and will post back to the forum.

Rob_Gries · March 12, 2019, 1:39pm

Hey Loic, I was able to successfully bring up the OV5640 camera by doing the following:

Revert 19.01 driver back to 18.01 baselines – Revert to: "media: ov5640: Remove unneeded gpiod NULL check " in ov5640.c
Add in Mani’s patch to publish hardset pixel rate to CAMSS via V4L2 API - https://github.com/RobGries/testing-linaro-19.01/commit/690928debb9ef02b0075b77e2b3b518693453c5f#diff-22c3c9331e9d564945443891f27bf1bf
In the encoder make every frame IDR (Might just be a dependency on my pipeline for h.264 RTP video) - https://github.com/RobGries/testing-linaro-19.01/commit/4f4d2caeb7554080cefe3b18e422fa0a6f88fe9a

Some observations –

qcom-venus 1d00000.video-codec: HW is overloaded, needed: 432000 max: 352800 error is no longer seen with the downstream driver + Mani’s pixel rate hack.
Framerate from the camera is not fixed - The camera should be running at 15 FPS but ranges between 10 - 24 FPS. Is this due to the pixel rate hack?
Encoder framerate when probed through h264parse in gstreamer returns an insane number (returns 120/1 framerate), when explicitly setting caps it locks into a more reasonable number (I explicitly set 15 FPS).
With all that said, it appears that the camera and codec are functional, but still have some strange issues surrounding frame rate stability.

My progress is tracked here if you’re interested: https://github.com/RobGries/testing-linaro-19.01/tree/18.01_ov5640_baseline

Loic · March 20, 2019, 9:09am

Did you try the ov5640 driver availale in this branch: loic.poulain/linux.git - [no description]