lvmc Posted June 5, 2016 Posted June 5, 2016 [ 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
@lex Posted June 5, 2016 Posted June 5, 2016 @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+.
lvmc Posted June 6, 2016 Posted June 6, 2016 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
tkaiser Posted June 6, 2016 Posted June 6, 2016 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)
@lex Posted June 6, 2016 Posted June 6, 2016 I hit this nasty blob long ago on a previous post. Some nice article why is closed source: http://www.anandtech.com/show/6777/understanding-camera-optics-smartphone-camera-trends/4 1
@lex Posted June 6, 2016 Posted June 6, 2016 vip_dev(x)_fmt: 0:yuv 1:bayer raw rgb So if set to 1 the error makes sense.
lvmc Posted June 7, 2016 Posted June 7, 2016 @tkaiser do you know anything about libisp or how do update Armbian version to the newest one? Me and @lex did a very deep debug and found it is outdated.
tkaiser Posted June 7, 2016 Posted June 7, 2016 @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.
lvmc Posted June 8, 2016 Posted June 8, 2016 Got new libisp blobs from SinoVoip: https://www.dropbox.com/s/ghdcxy16ktim3n0/libisp.zip?dl=0
tkaiser Posted June 8, 2016 Posted June 8, 2016 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.
lvmc Posted June 9, 2016 Posted June 9, 2016 @tkaiser and m2+ owners, could you please check if on your boards there are 2 resistors that seems to be soldered by hand on pins 3 and 4 of camera connector?
jernej Posted June 9, 2016 Posted June 9, 2016 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
lvmc Posted June 10, 2016 Posted June 10, 2016 @tkaiser What is your board revision? My board is v1.0, while @jernej board revision is v1.1 @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!
tkaiser Posted June 10, 2016 Posted June 10, 2016 @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. 2
jernej Posted June 10, 2016 Posted June 10, 2016 Unfortuantelly I don't have any camera to connect on the board. It was interesting to me to spot the difference.
mattday Posted June 10, 2016 Author Posted June 10, 2016 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.
@lex Posted June 10, 2016 Posted June 10, 2016 @mattday, Good job, we know it is working. Can you please check the board revision? @lex
@lex Posted June 10, 2016 Posted June 10, 2016 Are you using the camera extension with a vvision sensor rotated 180? can you share a picture?
mattday Posted June 11, 2016 Author Posted June 11, 2016 Orange Pi One Orange Pi camera expansion board and flat flex cable from official camera (2Mp GC2035). 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.
tkaiser Posted June 12, 2016 Posted June 12, 2016 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?
lvmc Posted June 13, 2016 Posted June 13, 2016 @tksaiser I'm doing several tests and pinouts comparisons... hope to have the final answer this week.
tkaiser Posted June 13, 2016 Posted June 13, 2016 I'm doing several tests and pinouts comparisons... hope to have the final answer this week. But do you have any proof that the combination you're playing with works at all?
mattday Posted June 13, 2016 Author Posted June 13, 2016 @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?
@lex Posted June 13, 2016 Posted June 13, 2016 @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: Here is another AF ov5640 schematic:
lvmc Posted June 14, 2016 Posted June 14, 2016 @lex, accordingly to VVision engineer it doesn't matter AF_VCC and AF_GND on AF modules are inverted... waiting my new v1.1 M2+ board to test...
mattday Posted June 14, 2016 Author Posted June 14, 2016 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.
Recommended Posts