Jump to content

OV5640 camera with Orange Pi


mattday

Recommended Posts


[ 216.288532] [VFE]cci probe start cci_sel = 0!

[ 216.288675] [VFE]cci probe end cci_sel = 0!

[ 216.288987] [VFE]cci_init end

[ 305.485024] [VFE]Welcome to Video Front End driver

[ 305.485366] [VFE]pdev->id = 0

[ 305.485375] [VFE]dev->mipi_sel = 0

[ 305.485383] [VFE]dev->vip_sel = 0

[ 305.485391] [VFE]dev->isp_sel = 0

[ 305.491515] [VFE_WARN]vfe vpu clock is null

[ 305.499107] [VFE]..........................vfe clk open!.......................

[ 305.499141] [ISP] isp platform_id = 5!

[ 305.499292] [VFE]vfe_init end

[ 305.500111] [VFE]probe_work_handle start!

[ 305.500137] [VFE]v4l2 subdev register input_num = 0

[ 305.500154] [VFE]vfe sensor detect start! input_num = 0

[ 305.500167] [VFE_WARN]Camer detect "YUV" fmt is different from sys_config!

[ 305.500179] [VFE_WARN]Apply detect fmt = 0 replace sys_config fmt = 1!

[ 305.500191] [VFE]Find sensor name is "ov5640", i2c address is 78, type is "YUV" !

[ 305.500204] [VFE]Sub device register "ov5640" i2c_addr = 0x78 start!

[ 305.500221] [VFE]v4l2_device_register_subdev return 0

[ 305.500232] [VFE]registered sensor subdev is OK!

[ 305.500240] [VFE]Check sensor!

[ 305.513563] [VFE]mclk on

[ 305.580334] [VFE CCI_0 ERR] Status error at addr_8bit = 78, wr_flag = 1, val = 1000a30

[ 305.580595] [VFE CCI_0 ERR] Status error at addr_8bit = 78, wr_flag = 1, val = 1000a30

[ 305.580852] [VFE CCI_0 ERR] Status error at addr_8bit = 78, wr_flag = 1, val = 1000a30

[ 305.580869] [OV5640]error at sensor_detect

[ 305.580878] [OV5640]chip found is not an target chip.

[ 305.580888] [VFE]mclk off

[ 305.617004] [VFE]vfe sensor subdev unregister!

[ 305.617019] [VFE]Sub device register "ov5640" failed!

[ 305.617029] [VFE_ERR]vfe sensor register check error at input_num = 0

[ 305.621776] [VFE]V4L2 device registered as video0

[ 305.621811] [VFE]..........................vfe clk close!.......................

[ 305.621833] [VFE]probe_work_handle end!

[ 305.626876] [VFE]vfe_open

[ 305.626896] [VFE]..........................vfe clk open!.......................

[ 305.626935] [VFE]vfe_open ok

[ 305.627137] [VFE]vfe_close

[ 305.627150] [VFE]vfe select input flag = 0, s_input have not be used .

[ 305.627167] [VFE]..........................vfe clk close!.......................

[ 305.627196] [VFE]vfe_close end

Link to comment
Share on other sites

@lvmc,

 

I believe this message would be the same as not having the sensor attached to the board. You can check this booting without the camera.

I think you were in the right path in your previous setup.

Did you try that Sinovoip img you pointed? Unfortunately i don't have M2+.

Link to comment
Share on other sites

I edited /boot/script.fex from vip_dev0_fmt = 0 to vip_dev0_fmt = 1 and camera (OV5640 from SinoVoip) is now being correctly recognized on Linux.

[  140.099421] [VFE]Welcome to Video Front End driver
[  140.099764] [VFE]pdev->id = 0
[  140.099775] [VFE]dev->mipi_sel = 0
[  140.099782] [VFE]dev->vip_sel = 0
[  140.099789] [VFE]dev->isp_sel = 0
[  140.105923] [VFE_WARN]vfe vpu clock is null
[  140.113251] [VFE]..........................vfe clk open!.......................
[  140.113285] [ISP] isp platform_id = 5!
[  140.113463] [VFE]vfe_init end
[  140.120116] [VFE]probe_work_handle start!
[  140.120142] [VFE]v4l2 subdev register input_num = 0
[  140.120154] [VFE]vfe sensor detect start! input_num = 0
[  140.120168] [VFE]Find sensor name is "ov5640", i2c address is 78, type is "YUV" !
[  140.120180] [VFE]Sub device register "ov5640" i2c_addr = 0x78 start!
[  140.120195] [VFE]v4l2_device_register_subdev return 0
[  140.120205] [VFE]registered sensor subdev is OK!
[  140.120213] [VFE]Check sensor!
[  140.133563] [VFE]mclk on
[  140.278276] [OV5640]sensor_s_release_af
[  140.290607] [OV5640]disalbe oe!
[  140.290930] [VFE]mclk off
[  140.302989] [VFE]Sub device register "ov5640" is OK!
[  140.303299] [VFE]V4L2 device registered as video0
[  140.303330] [VFE]..........................vfe clk close!.......................
[  140.303351] [VFE]probe_work_handle end!
[  140.310638] [VFE]vfe_open
[  140.310659] [VFE]..........................vfe clk open!.......................
[  140.310695] [VFE]vfe_open ok
[  140.311109] [VFE]vfe_close
[  140.311121] [VFE]vfe select input flag = 0, s_input have not be used .
[  140.311139] [VFE]..........................vfe clk close!.......................
[  140.311168] [VFE]vfe_close end

BUT we have something else to solve. There is a function from H3 SDK (sun8iw7p1_isp_set_table_addr) that is not supported.

[   58.476803] [VFE]vfe_open
[   58.476823] [VFE]..........................vfe clk open!.......................
[   58.476863] [VFE]vfe_open ok
[   58.486403] [VFE]Set vfe core clk = 216000000, after Set vfe core clk = 200000000
[   58.486421] NOT_SUPPORT_THIS_FUNCTION:sun8iw7p1_isp_set_table_addr, line: 372
[   58.499735] [VFE]mclk on
[   58.645021] [VFE_WARN]v4l2 sub device queryctrl (null) unsuccess!
[   58.645108] [VFE_ERR]try bayer bus error when pix fmt is bayer rgb at try_fmt_internal!
[   58.649879] [VFE_ERR]pixel format (0x4745504a) width 384 height 288 invalid at vidioc_try_fmt_vid_cap.
[   58.654862] [VFE_ERR]try bayer bus error when pix fmt is bayer rgb at try_fmt_internal!
[   58.659861] [VFE_ERR]pixel format (0x47504a4d) width 384 height 288 invalid at vidioc_try_fmt_vid_cap.
[   58.665093] [VFE_ERR]try bayer bus error when pix fmt is bayer rgb at try_fmt_internal!
[   58.670398] [VFE_ERR]pixel format (0x31363553) width 384 height 288 invalid at vidioc_try_fmt_vid_cap.
[   58.675869] [VFE_ERR]try rgb888 bus error when pix fmt is rgb888/prgb888 at try_fmt_internal!
[   58.681532] [VFE_ERR]pixel format (0x33424752) width 384 height 288 invalid at vidioc_try_fmt_vid_cap.
[   58.687316] [VFE_ERR]try bayer bus error when pix fmt is bayer rgb at try_fmt_internal!
[   58.693114] [VFE_ERR]pixel format (0x33524742) width 384 height 288 invalid at vidioc_try_fmt_vid_cap.
[   58.698969] [VFE_ERR]try rgb888 bus error when pix fmt is rgb888/prgb888 at try_fmt_internal!
[   58.704954] [VFE_ERR]pixel format (0x34424752) width 384 height 288 invalid at vidioc_try_fmt_vid_cap.
[   58.711090] [VFE_ERR]try bayer bus error when pix fmt is bayer rgb at try_fmt_internal!
[   58.717265] [VFE_ERR]pixel format (0x34524742) width 384 height 288 invalid at vidioc_try_fmt_vid_cap.
[   58.915179] [OV5640]s_fmt set width = 640, height = 480
[   58.915663] [VFE_ERR]bsp_csi_set_fmt error at vidioc_s_fmt_vid_cap!
[   58.993859] [VFE]vfe_close
[   58.993874] [VFE]mclk off
[   59.030031] [VFE]..........................vfe clk close!.......................
[   59.030060] [VFE]vfe_close end

Maybe we are missing some .bin files from sun8iw7p1... I have no idea how and where to add this files. Please check from oficial SinoVoip GitHub/repository: 

 

https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/tree/master/sunxi-pack/chips/sun8iw7p1/bin

Link to comment
Share on other sites

Maybe we are missing some .bin files from sun8iw7p1... I have no idea how and where to add this files. Please check from oficial SinoVoip GitHub/repository: 

 

https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/tree/master/sunxi-pack/chips/sun8iw7p1/bin

 

I checked the sources we use now with those we used before and unfortunately also this video stuff relies on BLOBs (so no sources). Same with SinoVoip's BSP (but they simply used loboris' kernel for Oranges from back then)

Link to comment
Share on other sites

@tkaiser do you know anything about libisp or how do update Armbian version to the newest one?

 

Nope, as already listed above that's all we have. Allwinner released their older BSP kernel sources here. That or a tarball was loboris' basis and now used by 'Team BPi' for their BSP variant. Armbian startet not with this but with an enhanced fork of ssvb's lima-memtester kernel. Then jernej spotted a new BSP variant made available by FriendlyARM that Igor cleaned up a bit and that we use now as the legacy kernel source.

 

No information regarding the BSP source contents available and libisp is not the only BLOB contained.

Link to comment
Share on other sites

Got new libisp blobs from SinoVoip:

 

That's the 'new' stuff you got from SinoVoip:

MD5 (bsp_isp.h) = 2c9260c460381fc19358d54d4adf47c2
MD5 (bsp_isp_algo.h) = da1db35fa0e937a17b320e5002749d46
MD5 (bsp_isp_comm.h) = a03d7b2f93115d0254d8d90688301b75
MD5 (isp_module_cfg.h) = 0670e4cf4a676357c638e2c353533776
MD5 (lib_mipicsi2_v1) = bb3638782dfeb75d798e97d5219adb05
MD5 (lib_mipicsi2_v2) = 8419aae221d27670459df63605f82844
MD5 (libisp) = 7adcefa7edbf8fe86b1c01c84e67da52

That's what Allwinner put on their Github repo ages ago and what's present in all BSP kernel variations flying around:

da1db35fa0e937a17b320e5002749d46  bsp_isp_algo.h
a03d7b2f93115d0254d8d90688301b75  bsp_isp_comm.h
2c9260c460381fc19358d54d4adf47c2  bsp_isp.h
0670e4cf4a676357c638e2c353533776  isp_module_cfg.h
7adcefa7edbf8fe86b1c01c84e67da52  libisp
bb3638782dfeb75d798e97d5219adb05  lib_mipicsi2_v1
8419aae221d27670459df63605f82844  lib_mipicsi2_v2

And that's what I would call 'the SinoVoip experience'. Talking to them is like talking to a wall.

Link to comment
Share on other sites

For some reason I can't post images, so here you have:

http://shrani.si/f/1N/ee/1lHT0KQY/port.jpg

 

EDIT: It seems that I have newer revision of the board. I have those additional resistors soldered on PCB. It has a bit different placement of some components:

http://shrani.si/f/1/pj/WWy1wPw/20160610013321.jpg

http://shrani.si/f/y/J1/3barSjGP/20160610013043.jpg

Link to comment
Share on other sites

@tkaiser

 

What is your board revision?

My board is v1.0, while @jernej board revision is v1.1

 

Untitled-5.png

 

@tkaiser and @jernej,

 

I'm investigating the OV5640 with @lex... to advance the investigation we need do some tests on more boards with OV5640 from both SinoVoip and VVision {with Auto Focus (AF) and Fixed Focus (FF)}

 

Has anyone found a M2+ and operating system (Linux or Android) combination that is working?

 

SinoVoip claims that OV5640 is working on:

 

BPI-M2_Plus_Android_V1.zip

BPI-M2_Plus_Android_V2.zip

2016-05-05-u1510_gpu_vpu_camera_bt_bpi-m2p_beta.img.zip

 

For further investigation I need remote access over SSH connection to M2+ with OV5640 because I got my M2+ from the first pre mass-production batch and it didn't came with Q.C PASSED seal and there are some hand soldered resistors.

 

Could any of you provide me SSH access?

 

We are really working hard to solve it for community benefit!

Link to comment
Share on other sites

@tkaiser

 

What is your board revision?

 

Rev 1.0 (resolution should be high enough to spot details): http://linux-sunxi.org/Banana_Pi_M2%2B#Pictures

 

And no, I won't spend any more time with Foxconn/SinoVoip products. They simply don't get it and we here at Armbian should also think about stopping to support all of their products except of the real Banana Pi [TM]. It's both an insanely waste of time and also a wrong signal to our users.

 

Just as a little example: 'Team BPi' produced for each and every BPi that came after the first A20 based fake videos showing features that didn't work (at that time), especially regarding 'GPU acceleration' and 'HW video acceleration'. When they came out with the H3 based M2+ where all this stuff already worked (since community did such a great job over at linux-sunxi and also in Orange Pi forums) they were still busy showing fake videos (nearly statical manga video stuff as proof that 'HW acceleration' would work) instead of using any of the advanced OS distros for H3 boards and demonstrating that it really works using appropriate software.

 

They simply don't get it, just look through their forums. But on the other hand they don't need to improve anything since they can sell all this incompatible crap under the Banana brand and therefore constantly new clueless people buy their products just to realize later that nothings works (as expected), then use these electronics as a paperweight and disappear from the forums since none of their questions got answered. Then the next bunch of fooled customers appears, complains, does not get their questions answered and the whole thing repeats again and again.  

Link to comment
Share on other sites

Just a small update from me as I've not had much time. My new parts arrived and after some messing around I was able to reverse the camera connector. 

 

Running modprobe vfe_v4l2 is now successful (output same as post #34).

 

fswebcam is able to capture images from the sensor:

  • 1280x960 and 640x480 give decent images
  • 2592x1936 (full resolution) and 1024x768 give very over exposed images
  • 1920x1080 and 800x600 give green/pink noisy images
 

I get the following output when running fswebcam:

[ 2424.901977] [VFE]vfe_open
[ 2424.902034] [VFE]..........................vfe clk open!.......................
[ 2424.902095] [VFE]vfe_open ok
[ 2424.903081] [VFE]Set vfe core clk = 216000000, after Set vfe core clk = 200000000
[ 2424.903116] NOT_SUPPORT_THIS_FUNCTION:sun8iw7p1_isp_set_table_addr, line: 372
[ 2424.903147] [VFE]mclk on
[ 2424.939416] [OV5640]enable oe!
[ 2425.060972] [VFE_WARN]v4l2 sub device queryctrl (null) unsuccess!
[ 2425.250099] [OV5640]s_fmt set width = 1024, height = 768
[ 2425.250535] [VFE]buffer_setup, buffer count=4, size=1179648
[ 2425.486065] [VFE]capture video mode!
[ 2425.619313] [VFE]capture video first frame done!
[ 2425.722818] [VFE]vfe_close
[ 2425.722841] [OV5640]sensor_s_release_af
[ 2425.735208] [OV5640]disalbe oe!
[ 2425.735554] [VFE]mclk off
[ 2425.747635] [VFE]..........................vfe clk close!.......................
[ 2425.747670] [VFE]vfe_close end
@lmvc I think you must have also changed something else when your camera started working with vip_dev0_fmt = 1. If you haven't already, I suggest you try putting your camera back in YUV mode because raw bayer format image data is not so useful.
 

post-1273-0-71378100-1465556984_thumb.jpg

Link to comment
Share on other sites

  1. Orange Pi One
  2. Orange Pi camera expansion board and flat flex cable from official camera (2Mp GC2035).
  3. OV5640 (of unknown origin) with extra flat flex cable. These are soldered together to reverse connector pins. Ideally the cable would be shorter, but this was just to test. Note that camera is pointing downwards in photo, whereas it would be pointing upwards if plugged directly into expansion board.

Hope this is useful to clarify and hope the photo still has enough detail after the forum software has messed with it.

 

 

post-1273-0-68883200-1465642570_thumb.jpg

Link to comment
Share on other sites

My personal opinion (after a short conversation with @lex about state of camera support): We should ask Steven/Xunlong to provide an expansion board suitable for OV5640 (without the need to solder anything) or even a whole camera module.

 

I got the impression that a few of us currently really trying hard to get this camera stuff working (including HW accelerated video encoding) but that we're experiencing some sort of a chicken-and-egg problem: Only a 2MP camera available on the popular/cheap H3 boards and therefore driver development efforts being stuck somewhat.

 

Maybe I'm wrong but can anyone a bit familiar with the hardware side of things comment on what would be needed to get an OV5640 camera module compatible to the various Orange Pi boards?

Link to comment
Share on other sites

@tkaiser, I agree regarding Steven/Xunlong. Curiously, the current OPi camera expansion board has "200M&500M" printed on it. Anyhow, it should be straightforward to add an extra connector to the board. This seems to be all that is required. The second camera connector would point in the opposite direction to the first camera connector, allowing a OV5640 to plug straight in. I have attached a very rough illustration to show what I mean. In theory, this could also be used with the older OPi boards (the ones that don't require an expansion board to use a GC2035). In this case, it would function only as a means of reversing the pins. The extra cost is unlikely to amount to more than maybe 20 cents.

 

Does anyone have any suggestions on what I should try next with the OV5640? I was thinking of taking a look at what is going wrong at certain image sizes (e.g. 1920x1080). @lex did you experience this with the guitar board?

post-1273-0-93118700-1465839239_thumb.jpg

Link to comment
Share on other sites

@mattday

 

All window size work on guitar camera without any glitch. 

I should note the camera is AF as NanoPi M1 camera and seems to be the same sensor.

 

I would like you to comment about the Pin 23 and Pin 24, the AF camera schematic has pin 23 and pin 24 in reverse order.

I believe your camera is FF, is that correct?

 

Here is the cam500a schematic:

 

post-957-0-52227500-1465861632_thumb.jpg

 

 

Here is another AF ov5640 schematic:

 

post-957-0-13023800-1465861716_thumb.jpg

 

Link to comment
Share on other sites

Yes, I am using a fixed focus module. It looks as though different modules may use different pins for the AF supply. Obviously not wise to short the supply to ground. However, it is possible some modules internally route power from IO-VDD to AF-VDD and don't even connect pins 23 and 24 to the sensor chip. This is a pure guess, but could explain what lmvc says about it not mattering. 

 

Unfortunately there are no standards for the camera connector. Some of them seem to use the same layout, but it is entirely down to the company who package the sensor. Omnivision just sell an imaging chip with contact pads on the back. Someone else must mount this on a small circuit board with some passive components, route some of the pins out to a connector and integrate a lens assembly to focus light onto the front of the chip.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines