Arducam B0165 not working on Balena Fin v1.1 (The Raspberry Pi Camera Module v1 does)

I have a Balena Fin v1.1 and I cannot get the Arducam B0165 MIPI camera to work with it.

Arducam product used:

I have prepared a balena-os based app as requested to show the failure. I have followed the same steps from this repository (Dockerfile & start.sh) on a raspberry pi 3b and they worked, i.e. produced an image via capture binary (I did it on xenial with an updated firmware, i.e. start_x.elf & fixup_x.dat & the user space linux hardfloat libraries in /opt/vc/lib).

Prepared app:
https://bitbucket.org/bladeranger/arducam-balenaos-docker/

output when running with ov5647 camera (v1 Raspberry Pi Camera Module):

  • if you connect an hdmi cable you will see for 2 seconds the image (courtesy of raspivid -d).
  • both on RPi3b and on fincm3 (Balena Fin v1.1)

output when running with ov9281:

  • on RPi3B: images saved. End of logs shows raw files.
  • on Fin: no images saved. Timeout message “camera timeout” apparent in logs.

Docker logs (stdout output as recorded by docker, i.e. balena logs ):
On RPi 3B:- Note: ov5647 works also with default firmware, but I’m upgrading firmware first to minimize changes as compared to the balena fin (where firmware upgrade is required for ov5647 as well).

On Balena-Fin v1.1:

Additional important notes: - you must upgrade the firmware on the fincm3 to work with ov5647. - there is no mechanism to do it via balena-os dashboard, so I used the following steps:
Upgrding firmware (required):

  1. login as superuser (I used serial console (root, no password) on the fine, host via dashboard for the pi 3)
  2. Execute: (can copy paste)
# Before update on RPi3:
# dmesg | grep "raspberrypi-firmware soc"
# [    0.090274] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-08-28 15:10, variant start_x
# [    0.100123] raspberrypi-firmware soc:firmware: Firmware hash is 31098ceed842ca10c8ffd02ffe3640bf6c0190b4
cd /mnt/boot/ && mv start_x.elf start_x.elf.bak && mv fixup_x.dat fixup_x.dat.bak && wget https://github.com/raspberrypi/firmware/raw/01ecfd2ba2b7cf3a2f4aa75ada895ee4a3e729f5/boot/start_x.elf && wget https://github.com/raspberrypi/firmware/raw/01ecfd2ba2b7cf3a2f4aa75ada895ee4a3e729f5/boot/fixup_x.dat && sync && reboot
Important: To get the ov5467 camera (The standard camera) to work the firmware files /mnt/boot/ start_x.elf and fixup_x.dat need to be changed. I used the latest (16 of january 2020).

I can also say that "https://github.com/balena-io-playground/balena-rpi-python-picamera" would not work for me using the current development fincm3 image (I expect the updated firmware would have fixed it).

Additional information:
 - relevant post on arducam forum: https://www.arducam.com/forums/topic/ov9281-uc-599-not-being-detected-need-help/#post-20253 (see the last comments, the initial ones relate to the RPi 3B board and are not relevant to this post).

Hi

I am still looking into it, but I noticed that before you enabled the 44 pin, both the pi and the fin did not detect the camera using i2c detect. After you enabled 44, only the fin detected something at the address 60, and 70. I wonder why that happened, and if it has anything to do with the camera inits that happen later.
Is there any reason why you enabled pin 44 before the init?

The two boards are different, and the two cameras are different

For the fin, see the schematic:

  • On the Fin pin 44 is connected to the power gpio of the CSI (both)
  • GPIO44 <<>>CAM1_IO0
  • CAM1_IO0 <<>> pin 11 of J10, the CAM connector

And per the B0165 datasheet that connects to the power enable pin.
It needs to be up to give power to the ov9281.
When the ov9281 is up it shows itself on the I2C bus (that is also connected to the CAM connector, part of the CSI with the MIPI) as addresses 0x60 and 0x70.

On the other hand on the RPi 3B pin 44 is irrelevant. And for the ov5647 it does not need to be enabled afaict,

Hi

Thanks for your reply.
I understand that the 2 cameras are different, but right now I am focused on the one that is not working.

I understand that the camera needs to be powered before i2c can detect it.
What I meant was, on the pi it looks like one doesn’t have to specifically power it up before communicating with it. I see in your patch that you have changed the pin 31 with 44 for the shutdown_pins. Is the Arducam library dealing with the power turning on? And is your script getting in the way of it?

Also worth noting is that the ov5647 has support in the kernel drivers, unlike the 9281. So I am almost certain that you got that working because it didn’t depend on the library given by the folks at Arducam.
If the above is true, then what we need to figure is what all would need to change in the userspace library to get this working for the fin, so that we can make those additional changes in the patch that you have created.

I think you should start from using the script as you believe it should be used - if my script is wrong then that is an artifact of my attempt and not interesting.

In other words: show me how it works in any way and I will be satisfied.

To answer your question: The MIPI_Camera/RPI/utils/c2i_camera script does exactly the same, only it also check which board you have first (it has not support for the Fin board) and then sets the gpio accordingly.

Also see Lee from Arducam’s reply to my thread on their forum asking about this specifically telling me the pin needs to be powered on:
https://www.arducam.com/forums/topic/ov9281-uc-599-not-being-detected-need-help/#post-20243

Replying to your second thread, you are correct: the ov9281 bring up (via the i2c I guess, maybe some mipi specific stuff too? no way to know, it is closed) is done by arducam’s library, no question there. I am left to wait for arducam’s support to help me. I believe you are in a better position to ask them for help since you know your board better than I do.

The patch I created moves from “cannot find sensor” to “can find sensor, but timeout on taking an image”. This is where I am stuck.

There are btw two kernel drivers just not in upstream, and I’ve started using it in raspiraw [1] (which also does not use any kernel support) but did not manage to complete it

  1. https://github.com/BPI-SINOVOIP/BPI-F2S-bsp/blob/master/linux-sp/drivers/media/video/ov9281.c
  2. https://gitlab.incom.co/CM-Shield/android_kernel_nvidia_quill/blob/lineage-15.1/kernel/linux-4.4/drivers/media/i2c/ov9281.c
    (both have header files in the same subdirectory as well)

[1] https://github.com/6by9/raspiraw/

Hi

Thanks for the links. We are procuring one of these cameras to test with the fin - so will have something to share soon.

Accidentally pressed the delete button and approved that sorta automatically. Redoing it:

About this, I’m not sure. Take a look at the raspiraw code I mentioned - it does all the mode setting and initialization plus switching to stream mode for a number of sensors, and does not seem to rely in any way on the linux’s kernel support. It does use the videocore libraries (mmal etc) for accessing the MIPI stream - but that is for the MIPI channel portion of the CSI, not for the I2C portion . I still do not understand how the arducam library sends presumably the same commands to the ov9281 with two results - mipi working for rpi3b and not working for fin. The only thing I can deduce is that there is some difference between the two chipsets (ov5647 and ov9281) in how they use the mipi interface, and the fin is different from the rpi3b just for the 9281. The other more obvious option is that the changed pins (i.e. using arducam_init_camera2 as opposed to the simpler arducam_init_camera, i.e. without the “2” suffix) is badly implemented and not supported for the specific pins I’ve used - but arducam specifically says this works with the raspberry pi foundation cm3 breakout board.

Hey Anujdeshpande,

Any updates?

Alon

We’re still working on it. We’ll get back to you as soon as we have news.

Hi Alon, let us give a quick update. We ordered the hardware and waiting for it to be shipped. That’s why we are blocked from investigating this issue further.

We will post an update once we have procured the camera and start working on this.

Cheers…

That ia good to hear. Meanwhile I have a short term workaround using a USB2 camera with othereise the same spec (chipset, lens).

Good to hear that you are not blocked with this.