@lex

This is my first impression with the ov8865, a 8MP sensor running on kernel 3.4.39 (linux-sunxi).
I am running Banana Pi - M3 with the dual camera extension on Ubuntu Xenial rootfs and with the stock driver. The driver have not been touched because information is scarce and i asked @lvmc for some datasheet.
This sensor is a 4 lane CSI2 (MIPI) that has a good performance at high resolution. I am able to get 30 FPS on all available win sizes.
 
I have ran a small v4l2 application to have some benchmarks but  guvcview with some minor update is able to display video from the sensor just as we have for the ov5640:
TEST 0 ( 3264 x 2448 ) ---- cap parameters ----- width: 3264 height: 2448 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 3264x2448 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 11993088 Bytesused: 11993088 Address: 0xc37f8 FPS[0]: 13.38 Length: 11993088 Bytesused: 11993088 Address: 0xc3800 FPS[1]: 30.12 Length: 11993088 Bytesused: 11993088 Address: 0xc3808 FPS[2]: 29.47 Length: 11993088 Bytesused: 11993088 Address: 0xc3810 FPS[3]: 30.10 Length: 11993088 Bytesused: 11993088 Address: 0xc3818 FPS[4]: 28.36 Length: 11993088 Bytesused: 11993088 Address: 0xc3820 FPS[5]: 28.52 Length: 11993088 Bytesused: 11993088 Address: 0xc3828 FPS[6]: 34.09 Length: 11993088 Bytesused: 11993088 Address: 0xc3830 FPS[7]: 30.11 Length: 11993088 Bytesused: 11993088 Address: 0xc37f8 FPS[8]: 30.02 Length: 11993088 Bytesused: 11993088 Address: 0xc3800 FPS[9]: 1.08 ------- Avg FPS: 30.10 -------- TEST 1 ( 3264 x 1836 ) ---- cap parameters ----- width: 3264 height: 1836 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 3264x1836 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 8994816 Bytesused: 8994816 Address: 0x1543c00 FPS[0]: 12.07 Length: 8994816 Bytesused: 8994816 Address: 0x1543c08 FPS[1]: 30.11 Length: 8994816 Bytesused: 8994816 Address: 0x1543c10 FPS[2]: 29.51 Length: 8994816 Bytesused: 8994816 Address: 0x1543c18 FPS[3]: 28.47 Length: 8994816 Bytesused: 8994816 Address: 0x1543c20 FPS[4]: 30.99 Length: 8994816 Bytesused: 8994816 Address: 0x1543c28 FPS[5]: 31.19 Length: 8994816 Bytesused: 8994816 Address: 0x1543c30 FPS[6]: 30.12 Length: 8994816 Bytesused: 8994816 Address: 0x1543c38 FPS[7]: 30.05 Length: 8994816 Bytesused: 8994816 Address: 0x1543c00 FPS[8]: 30.02 Length: 8994816 Bytesused: 8994816 Address: 0x1543c08 FPS[9]: 1.28 ------- Avg FPS: 30.06 -------- TEST 2 ( 1920 x 1080 ) ---- cap parameters ----- width: 1920 height: 1080 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 1920x1080 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6e0 FPS[0]: 14.37 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6e8 FPS[1]: 30.12 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6f0 FPS[2]: 29.51 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6f8 FPS[3]: 28.00 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b700 FPS[4]: 31.51 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b708 FPS[5]: 31.29 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b710 FPS[6]: 30.03 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b718 FPS[7]: 30.06 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6e0 FPS[8]: 30.04 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6e8 FPS[9]: 3.44 ------- Avg FPS: 30.07 -------- TEST 3 ( 1600 x 1200 ) ---- cap parameters ----- width: 1600 height: 1200 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 1600x1200 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 2887680 Bytesused: 2887680 Address: 0x1fc92a8 FPS[0]: 10.73 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92b0 FPS[1]: 30.09 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92b8 FPS[2]: 29.56 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92c0 FPS[3]: 28.96 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92c8 FPS[4]: 25.95 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92d0 FPS[5]: 37.94 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92d8 FPS[6]: 30.03 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92e0 FPS[7]: 30.02 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92a8 FPS[8]: 30.07 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92b0 FPS[9]: 3.10 ------- Avg FPS: 30.33 -------- TEST 4 ( 1280 x 960 ) ---- cap parameters ----- width: 1280 height: 960 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size adjusted to: 800x600 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 724992 Bytesused: 724992 Address: 0x52f340 FPS[0]: 14.13 Length: 724992 Bytesused: 724992 Address: 0x52f348 FPS[1]: 33.46 Length: 724992 Bytesused: 724992 Address: 0x52f350 FPS[2]: 32.33 Length: 724992 Bytesused: 724992 Address: 0x52f358 FPS[3]: 27.94 Length: 724992 Bytesused: 724992 Address: 0x52f360 FPS[4]: 42.99 Length: 724992 Bytesused: 724992 Address: 0x52f368 FPS[5]: 33.27 Length: 724992 Bytesused: 724992 Address: 0x52f370 FPS[6]: 33.30 Length: 724992 Bytesused: 724992 Address: 0x52f378 FPS[7]: 33.30 Length: 724992 Bytesused: 724992 Address: 0x52f340 FPS[8]: 33.29 Length: 724992 Bytesused: 724992 Address: 0x52f348 FPS[9]: 8.38 ------- Avg FPS: 33.73 -------- TEST 5 ( 800 x 600 ) ---- cap parameters ----- width: 800 height: 600 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 800x600 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 724992 Bytesused: 724992 Address: 0x260368 FPS[0]: 19.52 Length: 724992 Bytesused: 724992 Address: 0x260370 FPS[1]: 33.59 Length: 724992 Bytesused: 724992 Address: 0x260378 FPS[2]: 32.32 Length: 724992 Bytesused: 724992 Address: 0x260380 FPS[3]: 31.84 Length: 724992 Bytesused: 724992 Address: 0x260388 FPS[4]: 33.39 Length: 724992 Bytesused: 724992 Address: 0x260390 FPS[5]: 35.97 Length: 724992 Bytesused: 724992 Address: 0x260398 FPS[6]: 33.34 Length: 724992 Bytesused: 724992 Address: 0x2603a0 FPS[7]: 33.30 Length: 724992 Bytesused: 724992 Address: 0x260368 FPS[8]: 33.30 Length: 724992 Bytesused: 724992 Address: 0x260370 FPS[9]: 6.94 ------- Avg FPS: 33.38 -------- TEST 6 ( 640 x 480 ) ---- cap parameters ----- width: 640 height: 480 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 640x480 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 466944 Bytesused: 466944 Address: 0xde03f8 FPS[0]: 12.74 Length: 466944 Bytesused: 466944 Address: 0xde0400 FPS[1]: 30.24 Length: 466944 Bytesused: 466944 Address: 0xde0408 FPS[2]: 29.19 Length: 466944 Bytesused: 466944 Address: 0xde0410 FPS[3]: 25.70 Length: 466944 Bytesused: 466944 Address: 0xde0418 FPS[4]: 31.95 Length: 466944 Bytesused: 466944 Address: 0xde0420 FPS[5]: 35.26 Length: 466944 Bytesused: 466944 Address: 0xde0428 FPS[6]: 30.04 Length: 466944 Bytesused: 466944 Address: 0xde0430 FPS[7]: 30.04 Length: 466944 Bytesused: 466944 Address: 0xde03f8 FPS[8]: 30.06 Length: 466944 Bytesused: 466944 Address: 0xde0400 FPS[9]: 6.26 ------- Avg FPS: 30.31 -------- Some output:

 

 

*Update:
 
I commented out 30fps and enabled 90fps and the driver is now capable of 90~100 fps on 640x480. If we can fix the color/exposure this sensor looks very promising.

This is my first impression with the ov8865, a 8MP sensor running on kernel 3.4.39 (linux-sunxi).
I am running Banana Pi - M3 with the dual camera extension on Ubuntu Xenial rootfs and with the stock driver. The driver have not been touched because information is scarce and i asked @lvmc for some datasheet.
This sensor is a 4 lane CSI2 (MIPI) that has a good performance at high resolution. I am able to get 30 FPS on all available win sizes.
 
I have ran a small v4l2 application to have some benchmarks but  guvcview with some minor update is able to display video from the sensor just as we have for the ov5640:
TEST 0 ( 3264 x 2448 ) ---- cap parameters ----- width: 3264 height: 2448 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 3264x2448 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 11993088 Bytesused: 11993088 Address: 0xc37f8 FPS[0]: 13.38 Length: 11993088 Bytesused: 11993088 Address: 0xc3800 FPS[1]: 30.12 Length: 11993088 Bytesused: 11993088 Address: 0xc3808 FPS[2]: 29.47 Length: 11993088 Bytesused: 11993088 Address: 0xc3810 FPS[3]: 30.10 Length: 11993088 Bytesused: 11993088 Address: 0xc3818 FPS[4]: 28.36 Length: 11993088 Bytesused: 11993088 Address: 0xc3820 FPS[5]: 28.52 Length: 11993088 Bytesused: 11993088 Address: 0xc3828 FPS[6]: 34.09 Length: 11993088 Bytesused: 11993088 Address: 0xc3830 FPS[7]: 30.11 Length: 11993088 Bytesused: 11993088 Address: 0xc37f8 FPS[8]: 30.02 Length: 11993088 Bytesused: 11993088 Address: 0xc3800 FPS[9]: 1.08 ------- Avg FPS: 30.10 -------- TEST 1 ( 3264 x 1836 ) ---- cap parameters ----- width: 3264 height: 1836 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 3264x1836 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 8994816 Bytesused: 8994816 Address: 0x1543c00 FPS[0]: 12.07 Length: 8994816 Bytesused: 8994816 Address: 0x1543c08 FPS[1]: 30.11 Length: 8994816 Bytesused: 8994816 Address: 0x1543c10 FPS[2]: 29.51 Length: 8994816 Bytesused: 8994816 Address: 0x1543c18 FPS[3]: 28.47 Length: 8994816 Bytesused: 8994816 Address: 0x1543c20 FPS[4]: 30.99 Length: 8994816 Bytesused: 8994816 Address: 0x1543c28 FPS[5]: 31.19 Length: 8994816 Bytesused: 8994816 Address: 0x1543c30 FPS[6]: 30.12 Length: 8994816 Bytesused: 8994816 Address: 0x1543c38 FPS[7]: 30.05 Length: 8994816 Bytesused: 8994816 Address: 0x1543c00 FPS[8]: 30.02 Length: 8994816 Bytesused: 8994816 Address: 0x1543c08 FPS[9]: 1.28 ------- Avg FPS: 30.06 -------- TEST 2 ( 1920 x 1080 ) ---- cap parameters ----- width: 1920 height: 1080 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 1920x1080 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6e0 FPS[0]: 14.37 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6e8 FPS[1]: 30.12 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6f0 FPS[2]: 29.51 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6f8 FPS[3]: 28.00 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b700 FPS[4]: 31.51 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b708 FPS[5]: 31.29 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b710 FPS[6]: 30.03 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b718 FPS[7]: 30.06 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6e0 FPS[8]: 30.04 Length: 3117056 Bytesused: 3117056 Address: 0x1f0b6e8 FPS[9]: 3.44 ------- Avg FPS: 30.07 -------- TEST 3 ( 1600 x 1200 ) ---- cap parameters ----- width: 1600 height: 1200 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 1600x1200 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 2887680 Bytesused: 2887680 Address: 0x1fc92a8 FPS[0]: 10.73 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92b0 FPS[1]: 30.09 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92b8 FPS[2]: 29.56 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92c0 FPS[3]: 28.96 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92c8 FPS[4]: 25.95 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92d0 FPS[5]: 37.94 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92d8 FPS[6]: 30.03 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92e0 FPS[7]: 30.02 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92a8 FPS[8]: 30.07 Length: 2887680 Bytesused: 2887680 Address: 0x1fc92b0 FPS[9]: 3.10 ------- Avg FPS: 30.33 -------- TEST 4 ( 1280 x 960 ) ---- cap parameters ----- width: 1280 height: 960 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size adjusted to: 800x600 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 724992 Bytesused: 724992 Address: 0x52f340 FPS[0]: 14.13 Length: 724992 Bytesused: 724992 Address: 0x52f348 FPS[1]: 33.46 Length: 724992 Bytesused: 724992 Address: 0x52f350 FPS[2]: 32.33 Length: 724992 Bytesused: 724992 Address: 0x52f358 FPS[3]: 27.94 Length: 724992 Bytesused: 724992 Address: 0x52f360 FPS[4]: 42.99 Length: 724992 Bytesused: 724992 Address: 0x52f368 FPS[5]: 33.27 Length: 724992 Bytesused: 724992 Address: 0x52f370 FPS[6]: 33.30 Length: 724992 Bytesused: 724992 Address: 0x52f378 FPS[7]: 33.30 Length: 724992 Bytesused: 724992 Address: 0x52f340 FPS[8]: 33.29 Length: 724992 Bytesused: 724992 Address: 0x52f348 FPS[9]: 8.38 ------- Avg FPS: 33.73 -------- TEST 5 ( 800 x 600 ) ---- cap parameters ----- width: 800 height: 600 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 800x600 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 724992 Bytesused: 724992 Address: 0x260368 FPS[0]: 19.52 Length: 724992 Bytesused: 724992 Address: 0x260370 FPS[1]: 33.59 Length: 724992 Bytesused: 724992 Address: 0x260378 FPS[2]: 32.32 Length: 724992 Bytesused: 724992 Address: 0x260380 FPS[3]: 31.84 Length: 724992 Bytesused: 724992 Address: 0x260388 FPS[4]: 33.39 Length: 724992 Bytesused: 724992 Address: 0x260390 FPS[5]: 35.97 Length: 724992 Bytesused: 724992 Address: 0x260398 FPS[6]: 33.34 Length: 724992 Bytesused: 724992 Address: 0x2603a0 FPS[7]: 33.30 Length: 724992 Bytesused: 724992 Address: 0x260368 FPS[8]: 33.30 Length: 724992 Bytesused: 724992 Address: 0x260370 FPS[9]: 6.94 ------- Avg FPS: 33.38 -------- TEST 6 ( 640 x 480 ) ---- cap parameters ----- width: 640 height: 480 v4l2 buffers: 8 exposure: -999 hflip: -1 vflip: -1 Mode: V4L2_MODE_VIDEO Driver: "sunxi-vfe" Card: "sunxi-vfe" Bus: "sunxi_vfe sunxi_vfe.0" Version: 1.0 Capabilities: 05000001 Input: 0 V4L2 pixel formats: 0: [0x50323234] '422P' (planar YUV 422) 1: [0x32315559] 'YU12' (planar YUV 420) 2: [0x32315659] 'YV12' (planar YVU 420) 3: [0x3631564E] 'NV16' (planar YUV 422 UV combined) 4: [0x3231564E] 'NV12' (planar YUV 420 UV combined) 5: [0x3136564E] 'NV61' (planar YUV 422 VU combined) 6: [0x3132564E] 'NV21' (planar YUV 420 VU combined) 7: [0x32314D48] 'HM12' (MB YUV420) 8: [0x56595559] 'YUYV' (YUV422 YUYV) 9: [0x55595659] 'YVYU' (YUV422 YVYU) 10: [0x59565955] 'UYVY' (YUV422 UYVY) 11: [0x59555956] 'VYUY' (YUV422 VYUY) 12: [0x31384142] 'BA81' (RAW Bayer BGGR 8bit) 13: [0x47524247] 'GBRG' (RAW Bayer GBRG 8bit) 14: [0x47425247] 'GRBG' (RAW Bayer GRBG 8bit) 15: [0x47425247] 'GRBG' (RAW Bayer RGGB 8bit) 16: [0x30314742] 'BG10' (RAW Bayer BGGR 10bit) 17: [0x30314247] 'GB10' (RAW Bayer GBRG 10bit) 18: [0x30314142] 'BA10' (RAW Bayer GRBG 10bit) 19: [0x30314142] 'BA10' (RAW Bayer RGGB 10bit) 20: [0x32314742] 'BG12' (RAW Bayer BGGR 12bit) 21: [0x32314247] 'GB12' (RAW Bayer GBRG 12bit) 22: [0x32314142] 'BA12' (RAW Bayer GRBG 12bit) 23: [0x32314142] 'BA12' (RAW Bayer RGGB 12bit) V4L2 pixel sizes: ( 3264 x 2448 ) Pixels ( 3264 x 1836 ) Pixels ( 1920 x 1080 ) Pixels ( 1280 x 720 ) Pixels ( 1600 x 1200 ) Pixels ( 800 x 600 ) Pixels ( 640 x 480 ) Pixels Sensor size: 640x480 pixels Pixel Format: V4L2_PIX_FMT_YUV420 [0x32315559] Frame #10 will be saved! Length: 466944 Bytesused: 466944 Address: 0xde03f8 FPS[0]: 12.74 Length: 466944 Bytesused: 466944 Address: 0xde0400 FPS[1]: 30.24 Length: 466944 Bytesused: 466944 Address: 0xde0408 FPS[2]: 29.19 Length: 466944 Bytesused: 466944 Address: 0xde0410 FPS[3]: 25.70 Length: 466944 Bytesused: 466944 Address: 0xde0418 FPS[4]: 31.95 Length: 466944 Bytesused: 466944 Address: 0xde0420 FPS[5]: 35.26 Length: 466944 Bytesused: 466944 Address: 0xde0428 FPS[6]: 30.04 Length: 466944 Bytesused: 466944 Address: 0xde0430 FPS[7]: 30.04 Length: 466944 Bytesused: 466944 Address: 0xde03f8 FPS[8]: 30.06 Length: 466944 Bytesused: 466944 Address: 0xde0400 FPS[9]: 6.26 ------- Avg FPS: 30.31 -------- Some output:

 

 

If anyone interested I wired CR2032 on NanoPi M3 so i can have RTC backup and don't need to be connected to internet. The date and Time is saved in the rtc chip and restored with the correct time when you turn on.
 
here is how to do:
 
a) Use a cheap coincell battery  holder like this:
 

Wire like this:

 
c) Careful not to invert the polarity, the silkscreen has a square rect on the  (+) - red wire on the image above.
refer to this: http://wiki.friendlyarm.com/wiki/index.php/File:NanoPi-M2-1602-if.png
 
d) Atfter you update your current time / localization on your distro, you just type: sudo hwclock -w to save it.
 
If you want to set the time/date in RTC chip manually: sudo hwclock --set --date "dd mmm yyyy HH:MM"
or check the current date/time with: sudo hwclock
 
 
 
 
 

*Update:
 
I commented out 30fps and enabled 90fps and the driver is now capable of 90~100 fps on 640x480. If we can fix the color/exposure this sensor looks very promising.

I have made some simple tests with OV5640 on another board (guitar), still waiting for NanoPI M1 (OPI clone) with 5MP module.
 
I can confirm that OV5640 module (and the driver for this board) works pretty nice and you can get 5MP (2592x1944) at ~5 fps framerate  and quality is similar (a bit better i would say) to 1600x1200 (gc2035).
 
* 1280x720 can be rendered at ~17 fps and i can say by observation i has a sharp image (good quality), and the sharpest image i can get is 1600x1200 but at low framerate (~ 4 fps), i think this can be used for taking photos with high quality, while 480x640 and 1280x720 are good candidates for video streams.
 
* AF works with 640x480 only on my simple tests, need to check the Android source code to see which parameters are used to get AF working on HD (1280x720) since kernel is the same.
 
* Armbian will(is) support(ting) guitar (can i say this?),
 
If AW driver sucks we can try to improve it based on Actions code. AW OV5640 code has a lot of more window size to choose suggesting a lower quality image, i may be wrong!
I have read the 'Sitheek' post and hope we don't need to fix any code specially the sunxi-vfe code.
 
If the AW OV5640 driver code works as Actions driver code it will be really nice and NanoPi M1, SinoVoip M2+ (M3?) can benefit from this and we can push Steven to design a 5MP module.

While I was playing with NanoPi -M3 and following the tkaiser's advice to test Gbps I thought I could have some improvement by building the image with gcc 5.4 and I found that I could have the gcc 6.2 compilation tools in parallel without breaking anything . This is not new to kernel developers but it was to me because i keep using ubuntu 12.04 to compile for other platforms (have to use older gcc versions) and now using lubuntu 16.04.   I compiled iperf3 with gcc 6.2 to see the results: ~/iperf3/src$ ./iperf3 -c 192.168.254.3 Connecting to host 192.168.254.3, port 5201 [ 4] local 192.168.254.87 port 58987 connected to 192.168.254.3 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 108 MBytes 901 Mbits/sec 0 819 KBytes [ 4] 1.00-2.00 sec 113 MBytes 949 Mbits/sec 0 1.72 MBytes [ 4] 2.00-3.00 sec 111 MBytes 937 Mbits/sec 0 1.72 MBytes [ 4] 3.00-4.00 sec 112 MBytes 940 Mbits/sec 0 1.72 MBytes [ 4] 4.00-5.00 sec 110 MBytes 927 Mbits/sec 0 1.72 MBytes [ 4] 5.00-6.00 sec 111 MBytes 929 Mbits/sec 0 1.72 MBytes [ 4] 6.00-7.00 sec 106 MBytes 895 Mbits/sec 0 1.72 MBytes [ 4] 7.00-8.01 sec 106 MBytes 887 Mbits/sec 0 1.72 MBytes [ 4] 8.01-9.00 sec 110 MBytes 924 Mbits/sec 0 1.72 MBytes [ 4] 9.00-10.01 sec 112 MBytes 942 Mbits/sec 0 1.72 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.01 sec 1.08 GBytes 923 Mbits/sec 0 sender [ 4] 0.00-10.01 sec 1.07 GBytes 921 Mbits/sec receiver iperf Done. The tips to use latest gcc-6 on Lubuntu Xenial 16.04 (armhf)
 
I can have gcc linked to gcc-5 and arm-linux-gnueabihf-gcc linked to arm-linux-gnueabihf-gcc-6 just as this:
gcc --version
gcc (Ubuntu/Linaro 5.4.1-2ubuntu1~16.04) 5.4.1 20160904 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. and arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Ubuntu 6.2.0-3ubuntu11~16.04) 6.2.0 20160901 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. We need to tell Ubuntu a higher precedence to gcc-6 if i want to use it. In my case i used 100 that is higher than gcc-5 as an example.
 
Install gcc-6 on Xenial 16:04 in (armhf) but this possibly will work in arm64 and x86:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt-get update sudo apt-get dist-upgrade sudo apt-get install gcc-6 g++-6 In my case, i want to use gcc-6 in all build using arm-linux-gnueabihf- and let gcc be linked to gcc-5:
sudo update-alternatives --install /usr/bin/arm-linux-gnueabihf-cpp arm-linux-gnueabihf-cpp /usr/bin/arm-linux-gnueabihf-cpp-6 100 sudo update-alternatives --install /usr/bin/arm-linux-gnueabihf-gcc arm-linux-gnueabihf-gcc /usr/bin/arm-linux-gnueabihf-gcc-6 100 sudo update-alternatives --install /usr/bin/arm-linux-gnueabihf-g++ arm-linux-gnueabihf-g++ /usr/bin/arm-linux-gnueabihf-g++-6 100 sudo update-alternatives --install /usr/bin/arm-linux-gnueabihf-gcov arm-linux-gnueabihf-gcov /usr/bin/arm-linux-gnueabihf-gcov-6 100 sudo update-alternatives --install /usr/bin/arm-linux-gnueabihf-gcc-ar arm-linux-gnueabihf-gcc-ar /usr/bin/arm-linux-gnueabihf-gcc-ar-6 100 sudo update-alternatives --install /usr/bin/arm-linux-gnueabihf-gcc-nm arm-linux-gnueabihf-gcc-nm /usr/bin/arm-linux-gnueabihf-gcc-nm-6 100 sudo update-alternatives --install /usr/bin/arm-linux-gnueabihf-gcov-tool arm-linux-gnueabihf-gcov-tool /usr/bin/arm-linux-gnueabihf-gcov-tool-6 100 sudo update-alternatives --install /usr/bin/arm-linux-gnueabihf-ranlib arm-linux-gnueabihf-ranlib /usr/bin/arm-linux-gnueabihf-ranlib-6 100 sudo update-alternatives --install /usr/bin/arm-linux-gnueabihf-gcc-ranlib arm-linux-gnueabihf-gcc-ranlib /usr/bin/arm-linux-gnueabihf-gcc-ranlib-6 100 This worked nicely and i could build the new image with arm-linux-gnueabihf- version 6.2 (test)
 

Just occurred to me a crazy theory, they provide a 4GB image that changes the layout of the sd card, there may be some sd cards prone to have problems with the layout, or it is just the PSU causing all sort of problems.
    Here is my ingenious heat-sink:     

We have initial support for Pine64/Pine64+ for a long time in our repository but not released any official images yet. Since this will change soon a sneak preview what to expect.
 
Hardware related issues:
 
Please don't blame Armbian for the few design flaws Pine64 and Pine64+ show:
These boards use Micro USB for DC-IN which is the worst possible decision. Most USB cables have a resistance way too high and are responsible for severe voltage drops when consumption increases, then the tiny Micro USB contacts have also a pretty high contact resistance and also maximum amperage for this connector is limited to 1.8A by USB specs. So in case you want to do heavy stuff immediately look into linux-sunxi wiki page for Pine64 to get the idea how to use the pins on the so called Euler connector to power the board more reliably. If you think about buying a Pine now consider ordering their PSU  too since there cable resistance shouldn't be a problem (should also apply to the Micro USB cables they sell) The only led on this board is a power led that immediately lights when power is provided. Pre-production samples had a green led, on the normal batches this has been replaced with a red led. So there's no way for an OS image to provide user feedback (activate an led when u-boot or kernel boots) and the red light has often been interpreted as 'something is wrong' USB: you find 2 USB type A receptacles on the board but only one is a true USB host port, the other/upper is A64's USB OTG port exposed not as Mini/Micro USB (with ID pin to be able to switch roles) but as a normal type A port. Expect performance to be lower on this port. I've also never been able to do disk benchmarking on the upper port but that might have changed in the meantime (I only have a pre-production developer sample here). Please note also that the maximum amperage available on the USB port is 650mA so connecting bus-powered USB disks might already exceed this so be prepared to use a powered USB hub in between A64 is prone to overheating but unfortunately the Pine64 folks do not sell the board with an effective heatsink by default (compare with ODROID-C1+ or ODROID-C2 for example how it looks like if the vendor cares about heat dissipation). They promised to provide a good heatsink as option but at least I'm not able to find one in their online store. But a heatsink is mandatory if you plan to run this device constantly with high loads, otherwise throttling will occur (when we tested an unrealistic heavy workload without a heatsink -- cpuburn-a53 -- A64 had to throttle down to as less as 600 MHz (for some numbers see IRC log from a while ago) Not a real hardware issue but a problem anyway: the HDMI driver in Allwinner's BSP does not negotiate any display output with a lot of displays that are connected with a HDMI <--> DVI converter or use non-common resolutions. Better do not expect any display output if your display is neither connected directly using HDMI nor capable of 1080p (we can't do anything here since Allwinner's driver uses closed source blobs and no documentation or code with useable license exists) On a couple of Gbit equipped Pine64+ users report that they're not able to negotiate Gbit Ethernet reliably and have to force the connection to Fast Ethernet (since we know that the RTL8211E PHY used on the boards needs an additional ~350 mW when negotiating a Gbit Ethernet connection this might be related to power problems or maybe different PHY batches or something else). Confirmed in the meantime to be a hardware issue. Now combine Micro USB encouraging users to combine this SBC with crappy phone chargers, 'smart' hubs/chargers that do only provide 500mA since Pine64 isn't able to ask for more and crappy USB cables leading to voltage drops (all sorts of power related issues 'by design' due to crappy Micro USB connector) with a missing custom led able to be used to provide user feedback while booting and the inability to use a lot of displays then you might already get what a support nightmare this device is.
 
The only reliable DOA detection method without a serial console is to ensure you have a working SD card (test it before using either F3 or H2testw as outlined in our docs), then check download integrity of the Armbian image (again see the documentation), then ensure you burn the image correctly to SD card (see docs), insert SD card, power on the board and wait 20 seconds. If then the leds on the Ethernet jack start to flash randomly at least the kernel boots and after waiting an additional 2 minutes you'll be able to login with SSH or serial console (for the latter better choose the EXP header over the Euler connector -- reason here)
 
Anyway: In case you run in booting or stability problems with Armbian on Pine64/Pine64+ be assured that it's not an Armbian issue. You run into any of the problems above therefore please try to resolve them on your own and send your complaints to Pine64 forum and not ours: http://forum.pine64.org/forumdisplay.php?fid=21  (really, we don't do hardware and these issues are all related to hardware design decisions)
 

 
Expectations:
 
The Pine64 folks did a great job raising expectations to the maximum. They advertised this board as 'first $15 64-Bit Single Board Super Computer', promised an average consumption of just 2.5W, the SoC remaining at 32°C and a few other weird things while they already knew that reality differs a lot (the journey started here last Dec).
 
Pine64 is not a 'Super Computer' but most probably the slowest 64-bit ARM board around due to A64 being limited regarding maximum cpufreq and overheating issues (40nm process being responsible for) and lack of fast IO interconnections (only one real USB 2.0 host port present, no eMMC option possible, no SD card implementation using the faster modes). If you then combine the high expectations with a rather clueless kickstarter crowd (many of them not even getting that they did not buy products but backed a project) and the hardware flaws it's pretty obvious why their forums are full of complaints and why they receive so much boards as being DOA that work flawlessly in reality.
 
So why bringing Armbian to Pine64? Since for some (headless) use cases these boards are really nice and also cheap, A64 support is progressing nicely thanks to our awesome linux-sunxi community and also a few more A64 devices will be available soon.
 
What do you get with Armbian on Pine64?
 
User experience will not be much different compared to longsleep's minimal Ubuntu image. If you prefer Debian then at least you can be assured that our images do not contain bad settings and silly bugs like the one's from official Pine64 downloads section (since they fiddle around manually with their OS images for example all Pine boards running these have the same MAC address by default which will cause network troubles if you've more than one board in the same collision domain).
 
We use the same thermal/throttling settings like OS images based on longsleep's kernel (since we helped developing them back in March), we use the same BSP kernel (patched by Zador up to the most recent version back in May) and share a few more similarities since our modifications were sent back to longsleep so all OS images for Pine64 might be able to benefit from.
 
Differences: You don't need to execute longsleep's various platform scripts since kernel and u-boot updates are done using the usual apt-get upgrade mechanism in Armbian. You also don't need (and should not use) scripts like pine64_tune_network.sh since they decrease network performance with Armbian (stay with our defaults unless you're an expert). And a few more tweaks might result in better performance and at least by using Armbian you have the usual Armbian experience with some additional tools at the usual location, automatic fs resize on first boot and so on.
 
We already provide a vanilla image currently based on kernel 4.7 but that's stuff for developers only, see below.
 
Performance with legacy Armbian image:
 
'Out of the box' CPU performance with A64 is not that great unless you are able to benefit from the new CPU features: A64 uses Cortex-A53 CPU cores that feature 64-bit capabilities (which are not that interesting since A64 devices are limited to 2 GB DRAM anyway at the moment) but more interestingly ARMv8 instruction set can be used which might increase performance a lot when software will be compiled for this platform. Best example: the commonly mis-used sysbench cpu test: When running an ARMv6 'optimized' sysbench binary on an ARMv8 CPU then performance will be 15 times slower than necessary (applies to the RPi 3 or the upcoming Banana Pi M64 when used with their OS images)
 
But as soon as ARMv8 optimized code is used A64 can really shine in some areas. I used the default sysbench contained in Ubuntu Xenial's arm64 version, tried it with 20000 settings and got less than 8 seconds execution time (an RPi 3 running Raspbian has the faster CPU cores but here it will take 120 seconds -- just due to different compiler switches!). Then I tried whether I can optimize performance building sysbench from source using
export AM_CFLAGS="-march=armv8-a -mtune=cortex-a53" and got 11 seconds execution time, so optimized code led to a huge performance loss? Not really, I checked out sysbench version 0.5 by accident and there for whatever reasons execution with ARMv8 optimization or in general takes longer (great! benchmark version influences execution time, so one more reason to never trust in sysbench numbers found on the net!). Using the '0.4' branch at version 0.4.12 I got an execution time of less than 7.5 seconds which is a 10 percent increase in performance for free just by using appropriate compiler flags:
 
 
 
 
Another great example how using CPU features or not (NEON in this case) influences performance and 'benchmarking gone wrong' numbers are Linpack's MFLOPS scores. By choosing the package your distro provides instead of using one that makes use of your CPU's features you loose at lot of performance, ruin every performance per watt ratios and behave somewhat strange
 
Someone sent me Linpack MFLOPS numbers generated with Debian Jessie which is known for horribly conserative compiler settings when building packages -- if you switch your distro from Jessie to Ubuntu Xenial for example you get a 30 percent improvement in sysbench numbers, yeah that's the 'benchmark' we already laughed at above.
 
With Jessie's/Raspbian's hpcc package, Pine64+ gets a score of 1625 MFLOPS and RPi 3 just 1035. So is Pine64 1.6 times faster than RPi 3? Nope, that's just 'benchmarking gone wrong' since these numbers are the result of a joke: Using tools for 'High performance computing' with standard settings (no one interested in HPC would ever do that). By using the correct Linpack version that makes use of NEON optimizations on both CPUs we end up with 3400 MFLOPS (Pine64 at 1.3 GHz) vs 3600 MFLOPS (RPi 3 at 1.2 GHz).
 
So if we're talking about this use case (HPC -- high performance computing) RPi 3 easily outperforms A64 (please keep in mind that the 3400 MFLOPS I got are the result of overclocking/overvolting at 1296 MHz, Pine64 is limited to 1152 MHz by default so we're talking about 3000 MFLOPS for A64 vs. 3600 MFLOPS for RPi 3's SoC. So it's not Pine64 being 1.6 times faster but RPi 3 being more suited for Linpack numbers and this type of benchmarks only shows how wrong it is to use distro packages that are built using conservative settings (which is a must if the distro wants to support a wide range of different SoCs!)
 
Anyway: I's obvious that in case you want to use Pine64 for number crunching or performance stuff in general evaluating whether compiling packages from source might improve performance is a great idea (at least it's obvious that from a performance point of view using an ARMv6 distro with ARMv8 SoCs is stupid -- reality with Raspbian running on RPi 3 and BPi M64). ARMv8 also provides crypto extensions that might be used with OpenSSL for example. Didn't look into it yet but maybe huge performance gains when using a Pine64 as HTTPS enabled web server or VPN endpoint are possible just like we've already seen with sysbench.
 
Network performance: Pine64+ combines the SoC internal GbE MAC implementation (the same as in H3 and A83T SoCs from Allwinner) with an external RTL8211E PHY as used on most GbE capable SBC. Default iperf performance with Armbian/Xenial: +900 MBits/sec in both directions (920/940 MHz) so no need for further tuning (please read through this explanation here why blindly trusting in iperf numbers is always stupid and why it's neither necessary nor useful to further tune network settings to get better iperf numbers).
 
 
  Please keep in mind that for yet unknown reasons a couple of Pine64+ are reported to not reliably work at Gbit Ethernet speeds. Please also keep in mind how settings might matter. If you run a standard iperf test in 'passive benchmarking' mode you might get throughput numbers 200-250 Mbits/sec lower than ours maybe just due to a wrong cpufreq governor. Ethernet throughput scales linearly with CPU clockspeed with most cheap ARM SoCs (our only known exception from this is Solid-Run's Clearfog which uses a SoC optimized for IO and network throughput) so by using the ondemand governor with wrong/default settings for example you ensure that an idle SBC will only slowly increase clockspeed when you start your iperf test. This is Armbian switching from interactive to ondemand governor now being below 700 Mbits/sec just due to adjusting CPU clockspeed too slow:    
 
The other stuff normally 'benchmarked' is not worth mentioning/testing it so just as quick notes:
A64 is showing the same SDIO limitation as most other SoCs limiting sequential transer speeds to/from SD card to ~23MB/s (do the math yourself: SDIO with 4 bit @ 50 MHz minus some overhead is 23 MB/s) -- fortunately that's rather uninteresting since random IO matters on SBCs and there it's your choice to choose between crappy cards that horribly suck or follow our recommendations and choose a really fast card. But Pine64 can not use the faster eMMC interface so if you really need high IO bandwidth and high IOPS better choose a different device USB is USB 2.0 so expect ~35MB/s with BSP kernel and ~40MB/s with mainline kernel and UASP capable disk enclosures for individual USB connections (UASP + mainline kernel might show high random IO numbers if used together with an SSD!) HW accelerated video decoding is already possible (see here for the codec matrix) and situation with HW accelerated video encoding looks promising too: http://forum.armbian.com/index.php/topic/1855-ffmpeg-with-cedrus-h264-hw-encoder-a64-cmos-camera/ In case one is interested in performance testing on SBCs monitoring what's happening is mandatory. Currently our armbianmonitor tool does not install the necessary templates on A64 so still my script to install this stuff on A64 should be used: http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-a64.sh (read the script's header how to install)
 
Performance with vanilla Armbian image:
 
Not interesting at all at the time of this writing since while Pine64 happily boots mainline u-boot/kernel it's way too early to do tests in this area. Currently there's no access to the AXP803 PMIC from mainline kernel so not even VDD_CPUX voltage regulation works and as a result cpufreq scaling is also not working and the SoC is clocked pretty conservative. Since most performance relevant stuff running on cheap ARM SoCs depends on (switching as fast as possible to) high CPU clockspeeds benchmarking is absolutely useless now.
 
You should also keep in mind that many core features still not work with mainline kernel so this is really stuff for developers (who normally prefer their own way to boot their freshly compiled kernels). So please don't expect that much from vanilla images for A64 boards now, better choose the legacy variant.
 
The future?
 
A few more A64 boards are announced or already available as dev samples, for example the aforementioned BPi M64 (possible advantages over Pine64: sane DC-IN, real USB OTG, more USB host ports behind an internal USB hub, eMMC available and custom leds being able to provide user feedback, everything else is more or less the same as the 2 GB Pine64+) or Olimex working on both an SBC and an A64 based Laptop.
 
And then Xunlong announced 2 new SBC based on Allwinner's H5. H5 (product brief) seems to be A64's bigger sibling providing video/GPU enhancements, 3 true USB host ports in addition to one USB OTG (just like H3 where we can use all 4 USB ports that do not have to share bandwidth), integrating a Fast Ethernet PHY (just like H3) but lacks PMIC support (again just like H3, so no mobile useage, no battery support out of the box and it gets interesting how VDD_CPUX voltage regulation will work there -- maybe 'just like H3' again).
 
Since A64 shares many/most IP blocks with H3 and A83T from Allwinner I still hope that H5 will be just a mixture of A64 and H3 and we will get full support based on what we now have for these 2 other SoCs pretty fast. But that's 100 percent speculation at this moment
 
Update regarding longsleep's pine64_tune_network.sh script. Benchmark results don't get automatically worse when applying the tweaks from his script but the result variation gets huge (730 - 950 Mbits/sec, exceeding 940 Mbits/sec is already an indication that buffers are invoked):
 
 
 
So better enjoy defaults unless you really know what you do since network performance tuning works in different directions. Stuff that might increase throughput might negatively affect latency and vice versa. So if you start to tune, tune for your specific use case!

Since I like this board more and more another round of tests. NanoPi M3 is equipped with a GBit Ethernet interface obviously using the stmmac implementation combining an internal GbE MAC implementation in the SoC with RTL8211E external GBit PHY.
 
First turn FriendlyARM's Debian distro into a server OS: sudo systemctl disable lightdm (that's all, if you want to reclaim space on the SD card you might want to deinstall the GUI stuff but that's not important for performance behaviour)
  Let's use iperf first to do some passive benchmarking. M3 and Client (x86 host capable of maxing out its GBit interfaces connected to lab switch):   M3 --> Client: 730 Mbits/sec Client --> M3: 640 Mbits/sec  
  Now let's take a closer look what happened by using htop, limiting maximum cpufreq to the lower frequency so CPU cores remain at 400 MHz all the time and looking at /proc/interrupts and monitoring cpu clockspeeds: while true ; do cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq; sleep 1; done 5 minutes later: cpufreq matters, when running only at 400 MHz instead of 1400 MHz throughput is affected (so we must look at cpufreq scaling behaviour in the next step!) eth0 IRQs are spread accross all 8 CPU cores with this kernel (not that good, it's known that a fixed IRQ affinity helps on SMP systems with Ethernet loads) When testing client --> M3 performance iperf runs single threaded and maxes out 1 CPU core. This is obviously a limiting factor When testing M3 --> client performance iperf activity is spread accross all CPU cores. This leads to cpufreq remaining most of the times on the lowest CPU clockspeed (400 MHz) with interactive cpufreq governor which is obviously a limiting factor To address the last issue switching to performance governor would be a 'solution' or looking into interactive taking notice of this sort of activity and switching to maximum clockspeed. So let's try to improve Ethernet IRQ handling and also create an artificial bottleneck and see what happens. Only change made is this: echo 2 >/sys/class/net/eth0/queues/rx-0/rps_cpus Now iperf and iperf3 performance increases a lot. We're exceeding already 900 Mbits/sec in both directions:   
  Now the most important thing to notice: 900 Mbits/sec reported by iperf are enough if we start to think about how synthetic benchmarks correlate with reality.   Using iperf with default window sizes is a joke (way too small) so by further tuning this stuff also iperf performance numbers will improve. Are these better numbers important or even good? Not at all since real world applications behave differently (see here for an example how Windows' Explorer or OS X Finder tune their settings dynamically to get the idea how wrong it is to use iperf with default window sizes). Also iperf is limited by being bound to one CPU core when running as server task.   So what did we achieve with this single line added to /etc/rc.local: echo 2 > /sys/class/net/eth0/queues/rx-0/rps_cpus   We let all Ethernet RX IRQs be processed on a single CPU core (better performance) and also created a bottleneck which let the interactive governor behave 'better' and let cpufreq immediately jump from 400 MHz to 1400 Mhz which helps with benchmark numbers. What does this mean for real workloads running a web server or a NAS daemon? There the overall higher CPU activity would for sure lead to cpufreq scaling jumping to the maximum 1400 MHz and inventing a bottleneck as above might even negatively affect performance. This is something that has to be tested with real world workloads. Just better benchmark scores are not sufficient.   What do we learn from that? Passive benchmarking as it's done by most people does only create numbers without meaning and is crap. Always.   By looking at what's happening we are able to identify the bottlenecks that prevent synthetic benchmarks producing nice numbers. We now know how to improve numbers for this specific benchmark, we know that the tool in question sucks somehow (being maxed out by acting single threaded in a specific mode) and that the 'fix' for better benchmark scores might be counterproductive for real world workloads.   So now we know that Gbit Ethernet on this board performs very well, we know that by influencing CPU affinity of Ethernet RX IRQs we affect performance in 2 different ways (better IRQ processing and better cpufreq scaling of interactive governor) and most importantly we know where to look at when more serious network testing starts with real world workloads and not silly stuff like iperf/iperf3 with default settings.   BTW: Openend issue at FriendlyARM to let them know: https://github.com/friendlyarm/linux-3.4.y/issues/5   Update: I tested static delivery of web pages with nginx, this testfile with weighttp using this command line from my x86 box weighttp -n 100000 -c 20 -t 4 -k http://$target:80/testfile.js and with/without tweaking /sys/class/net/eth0/queues/rx-0/rps_cpus: No differences (result variation below 5 percent difference can be regarded identical). It's 4330 req/s on average (Pine64+ with BSP kernel, no network tuning at all and GbE connected to the same Gbit switch gets a +4800 req/s score, Pine64 testing my x86 host gets 4950 req/s but results are constant 496 req/s when one of the hosts is forced to use 100 MBits/sec network -- ethtool -s eth0 speed 100 duplex full -- so this test is bullshit anyway since it's not a webserver test but a throughput test similar to iperf)  

Hi @Gravelrash,
 
FYI, i received the board today, everything is OK and i hope to come up with something useful for the platform.
 
Thank You.

Yes, using HW accelerated h.264 encoding and about 15% cpu load on one core.
 
Tested with GC2035 on M2P (Armbian, Ubuntu 14.04.3), OV5640 still in China (Hello @lvmc?) 
It surely will work better with OV5640.
 
I am new to FFmpeg to push this AW encoder to its limits.
 
Here is the sample output:
[VDPAU SUNXI] VE version 0x1680 opened. Output #0, mp4, to 'test4.mp4':   Metadata:     encoder         : Lavf56.2.100     Stream #0:0: Video: h264 (cedrus264) ([33][0][0][0] / 0x0021), nv12, 640x480, q=2-31, 64 kb/s, 30 fps, 15360 tbn, 30 tbc     Metadata:       encoder         : Lavc56.0.101 cedrus264 Stream mapping:   Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (cedrus264)) Press [q] to stop, [?] for help frame=   16 fps=0.0 q=30.0 size=      50kB time=00:00:00.53 bitrate= 775.1kbits/ frame=   30 fps= 30 q=30.0 size=      94kB time=00:00:01.00 bitrate= 772.6kbits/ frame=   45 fps= 30 q=30.0 size=     141kB time=00:00:01.50 bitrate= 768.5kbits/ frame=   61 fps= 30 q=30.0 size=     190kB time=00:00:02.03 bitrate= 767.3kbits/ frame=   76 fps= 30 q=30.0 size=     237kB time=00:00:02.53 bitrate= 765.1kbits/ frame=   91 fps= 30 q=30.0 size=     282kB time=00:00:03.03 bitrate= 762.8kbits/ frame=  105 fps= 30 q=30.0 size=     325kB time=00:00:03.50 bitrate= 760.4kbits/ frame=  122 fps= 30 q=30.0 size=     376kB time=00:00:04.06 bitrate= 758.4kbits/ frame=  136 fps= 30 q=30.0 size=     419kB time=00:00:04.53 bitrate= 757.1kbits/ frame=  151 fps= 30 q=30.0 size=     470kB time=00:00:05.03 bitrate= 764.5kbits/ frame=  167 fps= 30 q=30.0 size=     532kB time=00:00:05.56 bitrate= 782.4kbits/ frame=  182 fps= 30 q=30.0 size=     597kB time=00:00:06.06 bitrate= 806.6kbits/ frame=  197 fps= 30 q=30.0 size=     667kB time=00:00:06.56 bitrate= 831.5kbits/ frame=  213 fps= 30 q=30.0 size=     735kB time=00:00:07.10 bitrate= 848.2kbits/ frame=  228 fps= 30 q=30.0 size=     817kB time=00:00:07.60 bitrate= 880.9kbits/ frame=  242 fps= 30 q=30.0 size=     868kB time=00:00:08.06 bitrate= 881.9kbits/ frame=  257 fps= 30 q=30.0 size=     915kB time=00:00:08.56 bitrate= 874.7kbits/ frame=  273 fps= 30 q=30.0 size=     964kB time=00:00:09.10 bitrate= 867.5kbits/ frame=  288 fps= 30 q=30.0 size=    1009kB time=00:00:09.60 bitrate= 861.1kbits/ frame=  303 fps= 30 q=30.0 size=    1055kB time=00:00:10.10 bitrate= 855.5kbits/ frame=  317 fps= 30 q=30.0 size=    1097kB time=00:00:10.56 bitrate= 850.6kbits/ frame=  330 fps= 30 q=30.0 Lsize=    1138kB time=00:00:11.00 bitrate= 847.8kbits/     video:2782kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.160191% Received signal 2: terminating.

My understanding is that CPU utilization is solved if you don't care about bitrate. I am still thinking Cedrus can encode better than MJPG but have not done any real world test.
I have seen ~16% CPU utilization in one core, but Cedrus has its own limitations, for example i could not encode 1920x1080 yet,  once i got 1280x720 encoded (failed when tried next) but have to experiment with the FFmpeg parameters and get the best -qp [2-47] value for that specific window size. I will learn from the StreamingGuide and put it in practice and it is a nice starting point.

Found -qp=47 [2-47] to compress better. * But quality sucks
Output #0, mp4, to 'test4.mp4': Metadata: encoder : Lavf56.2.100 Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), nv12, 640x480, q=-1--1, 64 kb/s, 30 fps, 15360 tbn, 30 tbc Metadata: encoder : Lavc56.0.101 libx264 Stream mapping: Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264)) Press [q] to stop, [?] for help frame= 49 fps=0.0 q=0.0 size= 0kB time=00:00:00.00 bitrate=N/A dup=22 dr frame= 72 fps= 44 q=43.0 size= 4kB time=00:00:00.66 bitrate= 45.9kbits/ frame[VDPAU SUNXI] VE version 0x1680 opened. Output #0, mp4, to 'test4.mp4': Metadata: encoder : Lavf56.2.100 Stream #0:0: Video: h264 (cedrus264) ([33][0][0][0] / 0x0021), nv12, 640x480, q=2-31, 200 kb/s, 30 fps, 15360 tbn, 30 tbc Metadata: encoder : Lavc56.0.101 cedrus264 Stream mapping: Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (cedrus264)) Press [q] to stop, [?] for help frame= 65 fps=0.0 q=47.0 size= 55kB time=00:00:02.16 bitrate= 207.8kbits/ frame= 80 fps= 79 q=47.0 size= 68kB time=00:00:02.66 bitrate= 207.6kbits/ frame= 94 fps= 62 q=47.0 size= 79kB time=00:00:03.13 bitrate= 207.2kbits/ frame= 109 fps= 54 q=47.0 size= 92kB time=00:00:03.63 bitrate= 206.8kbits/ frame= 125 fps= 50 q=47.0 size= 105kB time=00:00:04.16 bitrate= 206.4kbits/ frame= 140 fps= 46 q=47.0 size= 117kB time=00:00:04.66 bitrate= 206.2kbits/ frame= 155 fps= 44 q=47.0 size= 130kB time=00:00:05.16 bitrate= 206.1kbits/ frame= 171 fps= 42 q=47.0 size= 144kB time=00:00:05.70 bitrate= 206.3kbits/ frame= 186 fps= 41 q=47.0 size= 156kB time=00:00:06.20 bitrate= 206.4kbits/ frame= 200 fps= 40 q=47.0 size= 168kB time=00:00:06.66 bitrate= 206.5kbits/ frame= 215 fps= 39 q=47.0 size= 181kB time=00:00:07.16 bitrate= 206.7kbits/ frame= 231 fps= 38 q=47.0 size= 194kB time=00:00:07.70 bitrate= 206.8kbits/ frame= 246 fps= 37 q=47.0 size= 207kB time=00:00:08.20 bitrate= 206.6kbits/ frame= 261 fps= 37 q=47.0 size= 219kB time=00:00:08.70 bitrate= 206.6kbits/ frame= 277 fps= 37 q=47.0 size= 233kB time=00:00:09.23 bitrate= 206.6kbits/ frame= 279 fps= 36 q=47.0 Lsize= 236kB time=00:00:09.30 bitrate= 208.2kbits/s dup=126 drop=0 video:235kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.779432%

The Cedrus HW encoder  is working on A64 (POC).
 
FFmpeg 2.8.6 with cedrus264 can be found for testing here: https://github.com/avafinger/ffmpeg_cedrus264_A64
It was tested on Pine64+ (1GB) and OV5640.
 
Output:
VDPAU SUNXI] VE version 0x1689 opened. Output #0, h264, to 'test.h264':   Metadata:     encoder         : Lavf56.40.101     Stream #0:0: Video: h264 (cedrus264), nv12, 1024x768, q=2-31, 200 kb/s, 15 fps, 15 tbn, 15 tbc     Metadata:       encoder         : Lavc56.60.100 cedrus264 Stream mapping:   Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (cedrus264)) Press [q] to stop, [?] for help frame=   12 fps=0.0 q=-0.0 size=      89kB time=00:00:00.80 bitrate= 910.4kbits/ frame=   24 fps= 22 q=-0.0 size=     170kB time=00:00:01.60 bitrate= 868.2kbits/ frame=   36 fps= 22 q=-0.0 size=     233kB time=00:00:02.40 bitrate= 796.0kbits/ frame=   48 fps= 22 q=-0.0 size=     309kB time=00:00:03.20 bitrate= 791.3kbits/ frame=   60 fps= 22 q=-0.0 size=     406kB time=00:00:04.00 bitrate= 831.6kbits/ frame=   72 fps= 22 q=-0.0 size=     501kB time=00:00:04.80 bitrate= 855.6kbits/ frame=   84 fps= 22 q=-0.0 size=     583kB time=00:00:05.60 bitrate= 853.4kbits/ frame=   96 fps= 22 q=-0.0 size=     664kB time=00:00:06.40 bitrate= 850.1kbits/ frame=  106 fps= 22 q=-0.0 size=     741kB time=00:00:07.06 bitrate= 858.5kbits/ frame=  114 fps= 21 q=-0.0 size=     806kB time=00:00:07.60 bitrate= 869.3kbits/ frame=  122 fps= 20 q=-0.0 size=     856kB time=00:00:08.13 bitrate= 862.0kbits/ frame=  130 fps= 20 q=-0.0 size=     894kB time=00:00:08.66 bitrate= 845.0kbits/ frame=  138 fps= 20 q=-0.0 size=     931kB time=00:00:09.20 bitrate= 829.1kbits/ frame=  140 fps= 20 q=-0.0 Lsize=     940kB time=00:00:09.33 bitrate= 825.1kbits/s dup=69 drop=0     video:940kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%  

Yes, using HW accelerated h.264 encoding and about 15% cpu load on one core.
 
Tested with GC2035 on M2P (Armbian, Ubuntu 14.04.3), OV5640 still in China (Hello @lvmc?) 
It surely will work better with OV5640.
 
I am new to FFmpeg to push this AW encoder to its limits.
 
Here is the sample output:
[VDPAU SUNXI] VE version 0x1680 opened. Output #0, mp4, to 'test4.mp4':   Metadata:     encoder         : Lavf56.2.100     Stream #0:0: Video: h264 (cedrus264) ([33][0][0][0] / 0x0021), nv12, 640x480, q=2-31, 64 kb/s, 30 fps, 15360 tbn, 30 tbc     Metadata:       encoder         : Lavc56.0.101 cedrus264 Stream mapping:   Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (cedrus264)) Press [q] to stop, [?] for help frame=   16 fps=0.0 q=30.0 size=      50kB time=00:00:00.53 bitrate= 775.1kbits/ frame=   30 fps= 30 q=30.0 size=      94kB time=00:00:01.00 bitrate= 772.6kbits/ frame=   45 fps= 30 q=30.0 size=     141kB time=00:00:01.50 bitrate= 768.5kbits/ frame=   61 fps= 30 q=30.0 size=     190kB time=00:00:02.03 bitrate= 767.3kbits/ frame=   76 fps= 30 q=30.0 size=     237kB time=00:00:02.53 bitrate= 765.1kbits/ frame=   91 fps= 30 q=30.0 size=     282kB time=00:00:03.03 bitrate= 762.8kbits/ frame=  105 fps= 30 q=30.0 size=     325kB time=00:00:03.50 bitrate= 760.4kbits/ frame=  122 fps= 30 q=30.0 size=     376kB time=00:00:04.06 bitrate= 758.4kbits/ frame=  136 fps= 30 q=30.0 size=     419kB time=00:00:04.53 bitrate= 757.1kbits/ frame=  151 fps= 30 q=30.0 size=     470kB time=00:00:05.03 bitrate= 764.5kbits/ frame=  167 fps= 30 q=30.0 size=     532kB time=00:00:05.56 bitrate= 782.4kbits/ frame=  182 fps= 30 q=30.0 size=     597kB time=00:00:06.06 bitrate= 806.6kbits/ frame=  197 fps= 30 q=30.0 size=     667kB time=00:00:06.56 bitrate= 831.5kbits/ frame=  213 fps= 30 q=30.0 size=     735kB time=00:00:07.10 bitrate= 848.2kbits/ frame=  228 fps= 30 q=30.0 size=     817kB time=00:00:07.60 bitrate= 880.9kbits/ frame=  242 fps= 30 q=30.0 size=     868kB time=00:00:08.06 bitrate= 881.9kbits/ frame=  257 fps= 30 q=30.0 size=     915kB time=00:00:08.56 bitrate= 874.7kbits/ frame=  273 fps= 30 q=30.0 size=     964kB time=00:00:09.10 bitrate= 867.5kbits/ frame=  288 fps= 30 q=30.0 size=    1009kB time=00:00:09.60 bitrate= 861.1kbits/ frame=  303 fps= 30 q=30.0 size=    1055kB time=00:00:10.10 bitrate= 855.5kbits/ frame=  317 fps= 30 q=30.0 size=    1097kB time=00:00:10.56 bitrate= 850.6kbits/ frame=  330 fps= 30 q=30.0 Lsize=    1138kB time=00:00:11.00 bitrate= 847.8kbits/     video:2782kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.160191% Received signal 2: terminating.

I have managed to build FFmpeg with Cedrus on Armbian and it seems working.
It would be nice to see some benchs and how would be the best use for this AW Encoder.
I have not much experience with FFmpeg.
 
You can test it:
https://github.com/avafinger/ffmpeg_cedrus264_H3
 
 
To grab video stream from the CMOS camera:
sudo ./ffmpeg -f v4l2 -channel 0 -video_size 640x480 -i /dev/video0 -pix_fmt nv12 -r 30 -b:v 64k -c:v cedrus264 test.mp4
 
 
 
 

task : armbian-gc2035-fswebcam package script posted on GITHUB and merge request issued.
 
https://github.com/gravelrash/lib/blob/master/extras/fswebcam.sh
 
Pending acceptance / rejection / comments.

Leak from Xunlung lab:
 

 
Kernel 3.10.x
Some info about H5:
http://www.cnx-software.com/2015/04/15/allwinner-h-series-ott-soc-roadmap-adds-h5-and-h2-processors/

Pine64+ camera is not HIMAX HM5065 (**), it is Samsung S5K4EC . It may well be Himax IC but the buyout was not completed (that's what i read), so they may supply Samsung.
S5K4EC documentation is scarce and recently AW move seems not helping, but it is just an opinion. Some manufacturers are now willing to help and they are welcome.
 
To get this sensor working:
 
* Update DTB with this sensor activated ( https://github.com/avafinger/pine64_camera )
* Use kernel 3.10.102 or later (it may or not work with previous kernel, you have to find out)
* use a distro that has no broken dependencies, you will not be able to compile Guvcview and it is NOT Guvcview fault.
* Use the modified Guvcview ( https://github.com/avafinger/guvcview )
unisntall any Guvcview stock version.
apt-get purge guvcview
* install dependencies before builkding Guvcview: sudo apt-get install git build-essential autoconf libtool sudo apt-get install intltool autotools-dev libsdl1.2-dev libgtk-3-dev portaudio19-dev libpng12-dev libavcodec-dev libavutil-dev libudev-dev libusb-1.0-0-dev libpulse-dev libgsl0-dev libv4l-dev libsdl2-dev libv4l2rds0 * Load the modules in correct order or put it in /etc/modules   The stripes, pink and violet artifacts you will see is not Guvcview fault but S5K4EC driver.
 
And finally, this is a WIP in a hope it can be useful. 
 
Edited:
** If you have the very first sensor released, this instructions will not work if you activate S5K4EC instead of HM5065.

I just got the Guvcview working on the Pine64+ with a 5MP camera.
 
Have a look here: https://drive.google.com/open?id=0B7A7OPBC-aN7cFlBeEpnM3FIeE0
 
Some consideration:
 
640x480 -> 30 FPS
1280x720 -> 18 FPS
 
 
 

update on OV5640.
 
The driver has been improved to run with all available win size and more than decent quality.
320x240 (30 fps),640x480 (30 fps),800x600 (30 fps),1024x768 (7.5 fps),1280x720 (~20 fps),1280x960 (~10 fps),1600x1200(~7 fps),1920x1080(~4 fps),2048x1536( ~4 fps)
 
Now focus on v4l2 compatibility.
https://plus.google.com/u/0/photos/photo/113203245923875824895/6309842835642781394

Improved OV5640 on Pine64+:
https://plus.google.com/u/0/photos/photo/113203245923875824895/6309843639856225458

Here is 1920x1080P output so you can compare the quality: https://drive.google.com/open?id=0B7A7OPBC-aN7TG81aVlVS0lBclk
Driver still need some work.
So we have 2 MP (CG2035) camera and 5 MP (OV5640 and S5K4EC) camera to compare.

update on OV5640.
 
The driver has been improved to run with all available win size and more than decent quality.
320x240 (30 fps),640x480 (30 fps),800x600 (30 fps),1024x768 (7.5 fps),1280x720 (~20 fps),1280x960 (~10 fps),1600x1200(~7 fps),1920x1080(~4 fps),2048x1536( ~4 fps)
 
Now focus on v4l2 compatibility.
https://plus.google.com/u/0/photos/photo/113203245923875824895/6309842835642781394