@lex

It is fine.
 
For the torture test, better use a good heatsink.
I just would like to comment that if you have an image without HDMI (no fb) and a good heatsink you get slightly better values.
Now is time to move on and learn new platforms... 

OrangePi One Plus BSP 4.9, kernel 4.9.56 stock for analisys. 
Here is DRAM initialization in use (hope is what you meant):
[271]PMU: AXP806 [275]set pll start [278]set pll end [279]rtc[0] value = 0x00000000 [282]rtc[1] value = 0x00000000 [285]rtc[2] value = 0x00000000 [288]rtc[3] value = 0x00000000 [292]rtc[4] value = 0x00000000 [295]rtc[5] value = 0x00000000 [298]DRAM VERSION IS V2_5 [300]PMU:Set DDR Vol 1200mV OK. [304]PMU:Set DDR Vol 1200mV OK. [314]BYTE0 GATE ERRO IS = 00000002 [318]BYTE1 GATE ERRO IS = 00000002 [321]BYTE2 GATE ERRO IS = 00000002 [324]BYTE3 GATE ERRO IS = 00000002 [336]DRAM CLK =744 MHZ [338]DRAM Type =7 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3) [343]DRAM zq value: 003b3bfb [350]IPRD=006f006e--PGCR0=00000f5d--PLL=b0003d00 [354]DRAM SIZE =1024 M,para1 = 000030fa,para2 = 04000000 [366]DRAM simple test OK. [369]dram size =1024 tinymembench, running first time with interactive governor:

CPU:
Running subsequent tinymembench with performance governor:
 
CPU:
 
 
Things you should consider in your analysis that could favor some results or not.
 
* axp806 not detected by kernel
[    0.431724] [axp806] chip id not detect 0xff ! [    1.496996] input: axp80x-powerkey as /devices/platform/soc/pmu0/axp80x-powerkey/input/input0 [    4.925539] axp80x_aldo1: unsupportable voltage range: 858992688-3300000uV * eth not functional
[    0.816207] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:csi0 [    0.824909] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:mdc0 [    0.833599] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:mdio0 [    0.843450] gmac-power2: NULL [   11.600421] libphy: gmac0: probed And the usual:
 
 
I am pretty sure it runs at 1.8 GHz:
CPU1 freq      : 1800 MHz  CPU2 freq      : 1800 MHz  CPU3 freq      : 1800 MHz  CPU4 freq      : 1800 MHz  CPU count      : 4   Governor       : performance   SOC Temp       : 55 C  Next time i get results from 3.10...

I am running @Icenowy kernel, 1.5 GHz, 3.10.65 with some minor modification and 4.4.y 4.9.y without ethernet and axp805/6 not recognized .
I will run  tinymembench possibly tomoorow (lack of time)...

FYI, Orange Pi One Plus ethernet Gbit is already working on mainline kernel.
Thanks to Jagan Teki and Icenowy for their work!
 ./iperf3 -c 192.168.254.100 Connecting to host 192.168.254.100, port 5201 [  4] local 192.168.254.253 port 32808 connected to 192.168.254.100 port 5201 [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd [  4]   0.00-1.00   sec   112 MBytes   942 Mbits/sec    0    112 KBytes        [  4]   1.00-2.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   2.00-3.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   4.00-5.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   5.00-6.00   sec   112 MBytes   941 Mbits/sec    0    119 KBytes        [  4]   6.00-7.00   sec   112 MBytes   942 Mbits/sec    0    202 KBytes        [  4]   7.00-8.00   sec   112 MBytes   942 Mbits/sec    0    202 KBytes        [  4]   8.00-9.00   sec   112 MBytes   941 Mbits/sec    0    202 KBytes        [  4]   9.00-10.00  sec   112 MBytes   942 Mbits/sec    0    202 KBytes        - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval           Transfer     Bandwidth       Retr [  4]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec    0             sender [  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver iperf Done. ./iperf3 -R -c 192.168.254.100 Connecting to host 192.168.254.100, port 5201 Reverse mode, remote host 192.168.254.100 is sending [  4] local 192.168.254.253 port 32816 connected to 192.168.254.100 port 5201 [ ID] Interval           Transfer     Bandwidth [  4]   0.00-1.00   sec   107 MBytes   895 Mbits/sec                   [  4]   1.00-2.00   sec   107 MBytes   896 Mbits/sec                   [  4]   2.00-3.00   sec   106 MBytes   892 Mbits/sec                   [  4]   3.00-4.00   sec   106 MBytes   890 Mbits/sec                   [  4]   4.00-5.00   sec   106 MBytes   893 Mbits/sec                   [  4]   5.00-6.00   sec   107 MBytes   894 Mbits/sec                   [  4]   6.00-7.00   sec   106 MBytes   889 Mbits/sec                   [  4]   7.00-8.00   sec   107 MBytes   894 Mbits/sec                   [  4]   8.00-9.00   sec   106 MBytes   891 Mbits/sec                   [  4]   9.00-10.00  sec   106 MBytes   892 Mbits/sec                   - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval           Transfer     Bandwidth       Retr [  4]   0.00-10.00  sec  1.04 GBytes   893 Mbits/sec  4257             sender [  4]   0.00-10.00  sec  1.04 GBytes   893 Mbits/sec                  receiver iperf Done.  

Today I had a chance to test OV5640 on mainline kernel 4.17.2 and see the status of OV5640 and CSI drivers, thanks to FE work and the author of the driver (help name here...). I tested on NanoPi K1 Plus (H5) to verify the images in very low light conditions, so don't expect good quality.
I could take some images using fswebcam and you should expect basic v4l2 functionality already works if not all. I think motion (did not test  / had time to test it) can work with current OV5640 on mainline kernel.
Grabbing Image is very fast, currently, Image size I can get are 320x240 and 640x480 pixels, above this i get a dark image. I have not looked at the driver source code to see if it is implemented or not.  
 
Basically, you need to add the sun6i_csi and ov5640 drivers to the kernel and adjust DT to have the endpoint. FE has already done it and left H5 for homework, but is the same as H3.
 
To check the functionality, install v4l2-utils and when the driver sun6i_cs loads, it creates the device node /dev/video0 and you can check that:
 
sudo v4l2-ctl -d /dev/video0 -D Driver Info (not using libv4l2):     Driver name   : sun6i-video     Card type     : sun6i-csi     Bus info      : platform:camera     Driver version: 4.17.2     Capabilities  : 0x84200001         Video Capture         Streaming         Extended Pix Format         Device Capabilities     Device Caps   : 0x04200001         Video Capture         Streaming         Extended Pix Format You should see the modules loaded like this:
lsmod Module                  Size  Used by sun6i_csi              24576  0 videobuf2_dma_contig    20480  1 sun6i_csi videobuf2_memops       16384  1 videobuf2_dma_contig ov5640                 36864  1 videobuf2_v4l2         24576  1 sun6i_csi videobuf2_common       40960  2 videobuf2_v4l2,sun6i_csi v4l2_fwnode            20480  2 ov5640,sun6i_csi v4l2_common            16384  1 ov5640 videodev              196608  6 v4l2_fwnode,v4l2_common,ov5640,videobuf2_v4l2,sun6i_csi,videobuf2_common sunxi_cir              16384  0 media                  36864  3 videodev,ov5640,sun6i_csi rc_core                40960  2 sunxi_cir sch_fq_codel           20480  6 8189es               1118208  0 So time to revisit the camera drivers on mainline.
Here are some images (remember, low light condition!):
 
*update: All possible window sizes are working for streaming!
 
 
 

That's interesting.
And then the fun begins, i gave it a try using r8p1 with kernel 4.4 on A64 and it works... a bit slow but works, though i don't know for how long. Framebuffer only.
 
The weird thing (it's  kind of frankenstein):
=======================================================
    glmark2 2012.12
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-400 MP
    GL_VERSION:    OpenGL ES 2.0 "mali450-r5p1-01rel0-lollipop-233-g52c929d"
=======================================================
[build] use-vbo=false: FPS: 60 FrameTime: 16.667 ms
[build] use-vbo=true: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=nearest: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=linear: FPS: 60 FrameTime: 16.667 ms
[texture] texture-filter=mipmap: FPS: 60 FrameTime: 16.667 ms
[shading] shading=gouraud: FPS: 60 FrameTime: 16.667 ms
 
Does Anyone one know a complete recipe for building KODI or similar (framebuffer) to check if this is really working?

Today I had a chance to test OV5640 on mainline kernel 4.17.2 and see the status of OV5640 and CSI drivers, thanks to FE work and the author of the driver (help name here...). I tested on NanoPi K1 Plus (H5) to verify the images in very low light conditions, so don't expect good quality.
I could take some images using fswebcam and you should expect basic v4l2 functionality already works if not all. I think motion (did not test  / had time to test it) can work with current OV5640 on mainline kernel.
Grabbing Image is very fast, currently, Image size I can get are 320x240 and 640x480 pixels, above this i get a dark image. I have not looked at the driver source code to see if it is implemented or not.  
 
Basically, you need to add the sun6i_csi and ov5640 drivers to the kernel and adjust DT to have the endpoint. FE has already done it and left H5 for homework, but is the same as H3.
 
To check the functionality, install v4l2-utils and when the driver sun6i_cs loads, it creates the device node /dev/video0 and you can check that:
 
sudo v4l2-ctl -d /dev/video0 -D Driver Info (not using libv4l2):     Driver name   : sun6i-video     Card type     : sun6i-csi     Bus info      : platform:camera     Driver version: 4.17.2     Capabilities  : 0x84200001         Video Capture         Streaming         Extended Pix Format         Device Capabilities     Device Caps   : 0x04200001         Video Capture         Streaming         Extended Pix Format You should see the modules loaded like this:
lsmod Module                  Size  Used by sun6i_csi              24576  0 videobuf2_dma_contig    20480  1 sun6i_csi videobuf2_memops       16384  1 videobuf2_dma_contig ov5640                 36864  1 videobuf2_v4l2         24576  1 sun6i_csi videobuf2_common       40960  2 videobuf2_v4l2,sun6i_csi v4l2_fwnode            20480  2 ov5640,sun6i_csi v4l2_common            16384  1 ov5640 videodev              196608  6 v4l2_fwnode,v4l2_common,ov5640,videobuf2_v4l2,sun6i_csi,videobuf2_common sunxi_cir              16384  0 media                  36864  3 videodev,ov5640,sun6i_csi rc_core                40960  2 sunxi_cir sch_fq_codel           20480  6 8189es               1118208  0 So time to revisit the camera drivers on mainline.
Here are some images (remember, low light condition!):
 
*update: All possible window sizes are working for streaming!
 
 
 

Today I had a chance to test OV5640 on mainline kernel 4.17.2 and see the status of OV5640 and CSI drivers, thanks to FE work and the author of the driver (help name here...). I tested on NanoPi K1 Plus (H5) to verify the images in very low light conditions, so don't expect good quality.
I could take some images using fswebcam and you should expect basic v4l2 functionality already works if not all. I think motion (did not test  / had time to test it) can work with current OV5640 on mainline kernel.
Grabbing Image is very fast, currently, Image size I can get are 320x240 and 640x480 pixels, above this i get a dark image. I have not looked at the driver source code to see if it is implemented or not.  
 
Basically, you need to add the sun6i_csi and ov5640 drivers to the kernel and adjust DT to have the endpoint. FE has already done it and left H5 for homework, but is the same as H3.
 
To check the functionality, install v4l2-utils and when the driver sun6i_cs loads, it creates the device node /dev/video0 and you can check that:
 
sudo v4l2-ctl -d /dev/video0 -D Driver Info (not using libv4l2):     Driver name   : sun6i-video     Card type     : sun6i-csi     Bus info      : platform:camera     Driver version: 4.17.2     Capabilities  : 0x84200001         Video Capture         Streaming         Extended Pix Format         Device Capabilities     Device Caps   : 0x04200001         Video Capture         Streaming         Extended Pix Format You should see the modules loaded like this:
lsmod Module                  Size  Used by sun6i_csi              24576  0 videobuf2_dma_contig    20480  1 sun6i_csi videobuf2_memops       16384  1 videobuf2_dma_contig ov5640                 36864  1 videobuf2_v4l2         24576  1 sun6i_csi videobuf2_common       40960  2 videobuf2_v4l2,sun6i_csi v4l2_fwnode            20480  2 ov5640,sun6i_csi v4l2_common            16384  1 ov5640 videodev              196608  6 v4l2_fwnode,v4l2_common,ov5640,videobuf2_v4l2,sun6i_csi,videobuf2_common sunxi_cir              16384  0 media                  36864  3 videodev,ov5640,sun6i_csi rc_core                40960  2 sunxi_cir sch_fq_codel           20480  6 8189es               1118208  0 So time to revisit the camera drivers on mainline.
Here are some images (remember, low light condition!):
 
*update: All possible window sizes are working for streaming!
 
 
 

last numbers:
openssl speed -elapsed -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 21097762 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 13885050 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 5712407 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1744124 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 232965 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 116966 aes-256-cbc's in 3.00s OpenSSL 1.1.0g 2 Nov 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 112521.40k 296214.40k 487458.73k 595327.66k 636149.76k cpufreq-info -c 1 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.54 ms. hardware limits: 480 MHz - 1.37 GHz available frequency steps: 480 MHz, 648 MHz, 720 MHz, 768 MHz, 912 MHz, 1.08 GHz, 1.20 GHz, 1.37 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.37 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1.37 GHz. cpufreq stats: 480 MHz:4.74%, 648 MHz:1.64%, 720 MHz:0.35%, 768 MHz:0.59%, 912 MHz:0.48%, 1.08 GHz:0.44%, 1.20 GHz:0.38%, 1.37 GHz:91.36% (3239) at least, 4.17 pretty stable...
 
I think there is room for improvement, board does not get Temp over 54 ºC so lets the experts handle this... 
 

I have spent a lot of time on this and latest package should fix that, hopefully:
 
https://patchwork.kernel.org/patch/10128825/
 

I'm not sure about the specs for the battery, I just used a 4400mAh lipo I found on ebay or aliexpress a while back. I didn't configure anything on the m2m for this specific battery, so it might blow up eventually...
 
I bought some 6 pin 1.25mm JST connectors that were mentioned here: http://forum.banana-pi.org/t/battery-cable-circuit/3737 (even though this is for a different board). 
 
This is from the m2magic schematic located here: https://bananapi.gitbooks.io/banana-pi-bpi-m2-magic-iot-development-board/content/chapter1/bpi-m2-magic-schematic-diagram.html

 
 
 
Here are the pins on the board:

 
The battery I'm using at the moment only has two wires (no temp sensor). I put pins 1-3 to bat +, pins 4 and 5 to bat - and a 10k resistor between pin 6 and gnd. It looks like that was wrong though, and pin 6 should go straight to gnd with no resistor?
 
Here is one of the 6 pin 1.25mm JST connectors:

 
Sorry for the bad pictures! 

Oh and here is a connector that should work: https://www.ebay.com/i/162705482126?chn=ps&dispItem=1
 

... better ask on another thread...

There is no CSI available for Kernel 4.x 4.1x  yet, it is a WiP.
 

Fixed. NanoPi DUO with kernel 4.14.0, fast, solid as rock.
That's it. Job accomplished.
 
 
ethernet:
 

Fixed. NanoPi DUO with kernel 4.14.0, fast, solid as rock.
That's it. Job accomplished.
 
 
ethernet:
 

BTW, banana pi zero and nano pi air makes a perfect board for using OV5640 sensor, so i would like to ask @Robert LabTeam if you are going to share your work on the OV5640 to be able to reach 60 fps or 90 fps, will you?
 
 

$ 15.00 ?
That's a good price for what the board offers, mini HDMI, CSI port, 512 MB and Wifi&Bluetooth. Personally i would add a 8 GB eMMC and try to keep the price below $ 20.00. Once you boot from eMMC you will never want to boot from SD card again.
BTW, Have you considered Banana Pi M2M? no HDMI but there is a MIPI DSI port to connect LCD panel, and i can say the 5" LCD is the best LCD i have tested so far, unfortunately i have damaged the LCD some how while porting it to M64. They are short on supply another sample but Nora Lee is kindly sending me another one when they are ready so i can finish all the tests, i have not tested it to the exhaustion nor did any extensive testing but there is no problem with heat and Wifi&BT works as expected and the board has been a nice surprise.
 
I have no idea about the price and availability.
 
 
 

@lvmc,
You probably know there is no CSI/VFE subsystem in kernel 4.xx , to have full control over DVP interface for OV5640 you should rely on legacy kernel or develop your own subsystem which is... well... overkill.
As a start, you could look into ./config/boards and change from a current H2 board config file and modify/add  information, since all H2 seems to be very similar with little changes. You just need to find  the correct gpio/port  pins for the ./config/fex (if legacy).
Nora Lee from Foxconn has always provided information when asked,  seems to be part of the business, need more information... just ask me. (you get the picture! ) 
 
Hope this helps.
 
 
 

It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
 
In case that somebody is interested, I recently bought couple those displays from here
 
Few basic informations:
 
1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
5. My electrical setup (keep in mind it's 3.3V)
 
OPIZ - LCD (ili9431)
PA13 - CS
PA14 - SCK
PA16 - SDO
PA15 - SDI
PA03 - DC
PA00 - RESET
PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
 
And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
 
OPIZ - LCD (tsc2046)
PA10 - T_CS
PA18 - T_IRQ
PA19 - T_CLK
PA11 - T_DIN
PA12 - T_DO
 
Configuration for the first spi bus:
 
Configuration for touchscreen driver:
 
Compile and add those DTS with "armbian-add-overlay" command.
Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
# mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
Loading modules at startup:
# cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
 
I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal

 
 

"Oh dear! Oh my! Oh trouble!!" 
I think you just found a use case for this: https://github.com/avafinger/H5-firmware
 
 

For anyone interested I have pushed the sources to github here: https://github.com/avafinger/ffmpeg-3.3.4_cedrus264
 
Feel free to try. It has been tested on A64, R40 and possibly will work on H5 too.  Cross compiling and re-writing the package in a compliant way would speedup things.
 

For anyone interested I have pushed the sources to github here: https://github.com/avafinger/ffmpeg-3.3.4_cedrus264
 
Feel free to try. It has been tested on A64, R40 and possibly will work on H5 too.  Cross compiling and re-writing the package in a compliant way would speedup things.
 

hmmm, ok.
 
[    5.938267] [CSI_ERR][GC2035]sensor_read err at sensor_detect!
 
Is still a i2c issue, may be i2c has been updated on 5.25?
Please, double check your fex, decompile fex from 5.23 and 5.25 and see if there are other changes.

You mean gc2035 sensor on Banana Pi R40? I think yes, just need to change DTB (aka config.sys today) although i haven't tried.
Kernel 3.10.107 is stable and it is now time to do some serious work, as time permits i will try to expose the DTB as in A64... I will post the progress if i am successful.