manuti

No need to depend on board maker support, because official Rockchip version should work pretty well and basically all drivers are mainlined anyway.
 
Yes, it is possible, but I'm not sure how easy or interesting it is. If it is based on reference design, then yes, it is matter of hours for some who knows DT stuff. Another issue is how hard to find or extract is manufacturer dtb file. I doubt that they provide schematic. It is also the question if it is worth the effort.
 
I guess it should be similar enough to some existing board which has support already manilined. The biggest difference between the boards I saw is which power management chip is used.

Nope, not interested in RK3288
 
Your small chip is one of the reasons (since it's an Terminus USB2 hub, so 'shared bandwidth' which is kinda boring):

 
Regarding GbE I doubt further tests are needed (since the GbE MAC is inside the SoC and combined everywhere with an external RTL8211E PHY). If you destroy settings or at least don't care about those then you end up with something like this while everyone else reports 930-940 Mbits/sec (most probably that's iperf in 'duplex mode' vs. unidirectional -- that's always the mess with numbers flying around on the internet, without the exact test setup also mentioned they're always just 'numbers without meaning'  ).
 
Edit: As usual with Gigabit Ethernet... settings matter: http://freaktab.com/forum/tv-player-support/rk3288-devices/21530-poor-wired-network-rate-with-rk3288-board?p=395824#post395824

Yes. My computer works in Dutch.In Dutch" Dank je wel,manuti !"

H2+/H3/H5 boards overview (2017/03 update)
 
Since it has been a while since this topic has been updated and a lot of new boards have been released in the meantime it's time for a new overview.
 
I'll add also H2+ and H5 based boards since in the meantime we learned that those SoCs are pin-to-pin compatible and recently vendors started to simply exchange H3 with H5 on some PCB (and vice versa in at least one occurence). From a software point of view H5 is quite different (using 64-bit Cortex-A53 CPU cores and ARMv8 instruction set, some early boot stages are also totally different compared to Cortex-A7/ARMv7 used in H3 and H2+) and it should also be noted that Armbian currently only provides OS images based on mainline kernel for H5 boards (so please forget about HW accelerated video decoding or 3D for now or maybe ever since none of the developers is in the mood to deal with Allwinner's BSP/legacy kernel for H5 (regarding 'BSP' just look above in post #2).
 
While software support for H5 is currently somewhat different hardware features are pretty much the same as with H3 (still 3 to 4 real USB2 host ports and one USB2 OTG port: a simple register setting can switch the Micro USB port's PHY between the so called 'musb' controller used for OTG and a real EHCI/OHCI controller pair: with mainline kernel it will soon be possible to switch OTG to a real 4th USB2 host port with full feature set that still has not to share bandwidth with any of the other USB ports).
 
CPU performance with H5 compared to H3 is slightly higher at the same clockspeed but some workloads that benefit from either 64-bit or ARMv8 instruction set are significantly faster (eg. software making use of NEON instructions might perform almost twice as fast and the best example is the stupid 'sysbench' CPU pseudo benchmark which shows over 10 times better scores on the same hardware when compiled with ARMv8 settings).
 
In the following list I will also introduce some subjective 'categories' to deal better with the huge amount of boards we can use in the meantime:
NAS category: these are the H3/H5 boards with Gigabit Ethernet IoT category: these are the small and cheap boards best suited for low consumption 'General purpose' category: all the other H3 devices, these are also those you should look for if you want a cheap device to run with X11, OpenELEC, RetrOrangePi or Lakka since they all feature HDMI and full legacy kernel support As already said the differentiation is subjective and partially misleading since new boards like NanoPi NEO 2 featuring Gigabit Ethernet are also that inexpensive, small and energy efficient that they could serve both as NAS and IoT nodes (actually you can somewhat control behaviour since GbE vs. Fast Ethernet makes a pretty huge difference in consumption so it's up to you). Boards that might fit in multiple categories are listed more than once to make comparisons more simple if you're only interested in a specific device category:
 
NAS category (only due to Gigabit Ethernet available):
Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi PC Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB fast eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi IoT category (cheap, small, energy efficient, most of them headless):
NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Some important notes:
The following boards are listed in more than 1 category due to advanced feature mix: NanoPi NEO 2, NanoPi NEO Plus 2 and OrangePi Zero Plus 2 H3/H5 CE/FCC certifications: Please check individually and don't trust in logos silkscreened on the PCB, even if it looks like 'CE' it might mean 'China Export' instead IO bandwidth: H2+/H3/H5 SoC features 3+1 USB2 ports but on a few boards an internal USB hub is used so while these expose more USB receptacles some ports have to share bandwidth. Also on these boards a buggy/slow GL830 USB-to-SATA bridge is used. Search for 'hub' above to identify them. eMMC: shows most of the times higher random IO performance compared to 'the average SD card', but some vendors use pretty slow eMMC on their boards (Xunlong being the exception with OPi PC Plus, Plus, Plus 2, Plus 2E and Zero Plus 2). Please do not overestimate eMMC -- there's no need to choose crappy/slow SD cards and if you follow the usual recommendations difference in performance varies not that much (for example eMMC on most boards shows pretty low sequential write speeds that will be easily outperformed by any good SD card and differences in random IO don't have to be that huge, simply watch out for SD cards showing A1 or even A2 logo) USB ports: Some of the IoT devices have two of the SoC's USB host ports available on a pin header to be used with soldering or combined with various Docks, HATs or 'Expansion boards' (search for '1+1+2' above). On OPi One/Lite the unexposed USB host ports are available at pretty tiny solder pads so only usable with a lot of soldering experience Wi-Fi/BT: all boards providing both Wi-Fi and BT rely on Ampak's AP6212 so performance is identical, the Wi-Fi only boards either rely on RTL8189ETV/8189FTV (slightly better Wi-Fi performance than AP6212) or Allwinner's XR819 (so expect low Wi-Fi performance with OPi Zero or NEO Plus 2 since implementation is low-end and currently driver sucks) Yeah, each vendor's naming scheme totally sucks. Partially there are rules involved (the 'Plus' then means eMMC with Xunlong or GBit Ethernet with FriendlyELEC... mostly) but please don't trust in and check always individually!  
And now another few words on a different technical detail affecting both performance and thermal behaviour of the various boards: Voltage regulation / DVFS. TL;DR: the SoC can be fed with a variable voltage (VDD_CPUX), the lower the voltage the lower the temperature (less problems with heat/overheating), the higher the voltage the higher the maximum CPU clockspeed. So the best idea is to adjust this dynamically (low voltage/clockspeed when idle and only increasing both when needed). There are 3 variants to implement this: not at all, primitive or advanced (using a voltage regulator that's able to adjust VDD_CPUX in 20mV steps)
Only 3 devices implement no voltage regulation at all: Banana Pi M2+/EDU (frying the SoC constantly at 1.3V therefore prone to overheating), Beelink X2 (no idea) and NEO 2 (only 1.1V therefore limited to 1008MHz cpufreq max since above instabilities might occur).  Some boards use SY8106A I2C accessible voltage regulator where we can use fine grained voltage settings (Armbian fine-tuned these for every board so far to achieve max performance). This applies only to the following Xunlong boards: OPi PC, PC Plus, PC 2, PC 3, Plus, Plus 2 and Plus 2E. All other boards implement a simple two voltage scheme and are able to switch between 1.1V (up to 912MHz possible with H2+/H3 or 1008MHz with H5) or 1.3V (1.2GHz max with H2+/H3 and 1.25GHz with H5) And finally to add some stupid rankings: the cheapest board is from Xunlong (Orange Pi Zero: $7), the fastest is from Xunlong (Orange Pi PC 2 for $20) and the one with best feature set and onboard peripherals is also from Xunlong (Orange Pi Plus 2E: $35). And that's only due to OrangePi PC 3 Prime still not being released at the time of this writing (since otherwise regarding both performance and features this specific Xunlong board... )
 
Hope that helps
 
Edit: OPi 3 is now known as OPi Prime and (almost) nothing has changed compared to the leaked pictures back from last August.
 

Hi hojnikb,
I just did what you say, and it works perfect.
Thank you very much

If your card supports ERASE command (samsung cards to i believe) it's also a good idea to enable ERASE option in sdformatter. This will make the card factory fresh (all cells set to 1).

If you're inexperienced maybe the best idea is to simply follow the 'Getting started' guide step by step: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card
 
(so prior to flashing with Etcher always testing the SD card first with F3 or H2testw and in case this is an SD card that was already in use you might want to reset it to 'factory performance' with 'SD Formatter' in the next step still prior to flashing with Etcher -- everything explained in the link above)

Found a solution.
Because I installed it with this command sudo armbianmonitor -r i couldn't remove it with sudo apt autoremove rpimonitor.
However this is what I did :
 
1. sudo apt autoremove rpimonitor (uninstall some portion of the unofficial package)
2. sudo apt-get install rpimonitor (install the official package)
3. sudo apt autoremove rpimonitor (uninstall official package completely)
 
Cheers!

Hello! 
 
I'm new here and i would like to ask a question.
I have installed rpimonitor on an Orange PI zero but doesn't work so good (graphs doesn't show) so i decided to uninstall.
However I cannot! It removes "some" of it but I still get the rpi monitor screen at 8888 port...
I tried 
sudo apt autoremove rpimonitor
sudo apt-get purge rpimonitor
Can somebody help me remove it completely?  
I installed it with this command sudo armbianmonitor -r
 
Thanks!!!

Funnily with Zero Plus 2 a silent downgrade to H3 happened (I would assume that's related to Xunlong's software guy Buddy not being able to resolve voltage regulation issues with Allwinner's BSP and H5): http://www.cnx-software.com/2017/03/17/18-9-orange-pi-zero-plus-2-board-allwinner-h3-wifi-bluetooth-le-hdmi-and-8gb-emmc-flash/

Hello guys , I try to install Gl4ES  (https://github.com/ptitSeb/gl4es)  with success , in armbian Ubuntu Xenial Desktop .  For GL4ES you need to "put libGL.so.1 in your LD_LIBRARY_PATH". LD_LIBRARY_PATH is  "/usr/lib/arm-linux-gnueabihf" in the same path you need find "mesa" folder and rename it to ".mesa", maybe is the same for glshim.
You can run games like foobillard++ , openarena,quake ,etc .
Gl4ES is a wrapper for OpenGL 1.5, but the Hardware accelerated for chromium or firefox doesnt work.

Worked for me.
Orange Pi one
 
Thanks.
 
root@orangepione:~# h3consumption -p
Active settings:

cpu       1200 mhz allowed, 1200 mhz possible, 4 cores active

dram      624 mhz

hdmi/gpu  active

usb ports active

eth0      100Mb/s/Full, Link: yes
 

Hi,
 
1st OPi Zero (512 MB, heatsink, no case, capped to 768 MHz, room temp 15°C, 2A power supply via USB, ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i):
20:06:21:  240MHz  0.06   1%   0%   0%   0%   0%   0%   64°C
20:06:26:  240MHz  0.06   1%   0%   0%   0%   0%   0%   63°C
20:06:31:  240MHz  0.05   2%   1%   0%   0%   0%   0%   64°C
 
2nd OPi Zero (256 MB, no heatsink, no case, capped to 768 MHz, room temp 10°C, 1.5A power supply via pin1+2, ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i):
20:05:35:  240MHz  0.17   2%   1%   0%   0%   0%   0%   60°C
20:05:40:  240MHz  0.16   1%   1%   0%   0%   0%   0%   60°C
20:05:45:  240MHz  0.14   1%   1%   0%   0%   0%   0%   61°C
 
So there seems to be no effect of power supply.
However, it runs 50°C over room temp on idle... I wonder what will happen in the summer
 
To compare: OPi One, heatsink, case, room temp 15 °C, ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i:
20:11:09: 1008MHz  0.34   3%   0%   3%   0%   0%   0%   34°C
20:11:15: 1008MHz  0.40   4%   0%   3%   0%   0%   0%   35°C
20:11:20:  240MHz  0.37   4%   0%   3%   0%   0%   0%   35°C
 

- Allwinner H5
- Gigabit Ethernet
- 512MB (test subject)
- made few tests with our testing H5 (4.10) kernel
- nightly builds
 

Unfortunately there is no HW acceleration within any browser.

Well, I have to admit that I don't understand why you're talking about Raid0/Raid5 spanning accross different servers. IMO the whole idea is questionable especially using 5 overpriced SBC (BPi M2+ is IMO the least interesting H3 device around, if you need same feature set then look at NanoPi M1 Plus that doesn't overheat that much due to better voltage regulation or even Orange Pi Plus 2E where you get way faster eMMC twice the size and also 2GB DRAM and slightly higher clocked CPU).
 
Anyway: if I would have a use case where SBC with Gigabit Ethernet and as much USB2 ports as possible are required I would clearly go for Orange Pi PC 2 instead. And if I would like to implement RAID I clearly wouldn't use 5 SBC with USB disks but one board combined with SATA disks for the same price: Clearfog Pro combined with 2 x ASM1062 in the mPCIe slots for example.

Thanks tkaiser  RPi-Monitor is amazing also props to manuti for the post about the tkaiser approved heatsinks - Will order these
Just moved to Armbian and am so impressed.

In the meantime my Zero W arrived and it took me only 1 hour to set up Raspbian headlessly on the device: 
 
 
Quick Wi-Fi test made in 'location 1' using the well known script from above (still not showing differences regarding powermanagement since this also has no effect on the Zero W -- it's still just result variation):
 
RPi 3 (kernel 4.9.13-v7+):
powermanagement on:  23.36 Mbits/sec powermanagement off: 22.54 Mbits/sec  
RPi Zero W (kernel 4.4.50+):
powermanagement on:  28.54 Mbits/sec powermanagement off: 27.68 Mbits/sec  
RPi Zero W (after kernel upgrade to 4.9.13-v7+):
powermanagement on: 24.58 Mbits/sec powermanagement off: 25.49 Mbits/sec  
So throughput is the same or at least not lower (tests done all at different hours so not comparable since uncontrolled environment) and that's also a good reason to not further waste time with RPi tests. To my surprise onboard aerials of both WiFi equipped RPi work quite well but can't overcome 2.4GHz single antenna limitations of course. For some numbers with more antennas, 5GHz too and also 802.11ac see here for example: https://netbeez.net/2016/06/01/iperf-wifi-comparison-on-raspberry-pi-raspberry-pi-3-vs-asus-vs-hawking-vs-linksys-vs-tp-link/

Not enabling SSH any more by default is now called a 'security update' since even RPi foundation got it that pre-defined users/passwords are a really bad thing: https://www.raspberrypi.org/blog/a-security-update-for-raspbian-pixel/
 
But instead of doing it correctly (forcing the user to change the password on 1st login or even create an own sudo enabled user) they chose to make it harder to set a new RPi up (I'm glad I did the first step with my RPi 3 since without knowing the /boot/ssh hack I would've been lost with Zero W since I have no HDMI adapter for this board).
 
Regarding wpa_supplicant: Really no need to use this anachronistic stuff even on Raspbian. All I did was
apt-get --no-install-recommends install network-manager iw reg set DE nmcli device wifi connect 'Snort-Honeynet' password 'secret' ifname wlan0 (nmtui didn't work for whatever reasons, maybe network-manager is too outdated in Raspbian? And I also had to add 'iw reg set DE' to /etc/rc.local to be able to use Wi-Fi channel 13 which is the one my AP always chooses in 2.4 GHz band since least polluted)
 
Will start testing on the weekend with Zero W since buyzero.de managed to process my order from 1st March yesterday and DHL tracking confirmed delivery today. Not the best performance compared to Pimoroni in last summer (they processed my first Zero order within 24 hours, sent from the UK for less costs in shorter total time) but it doesn't really matter since I don't think I'll ever buy 'non products' from this mythical Foundation again. If the 'Zero W' will ever turn from a marketing stunt into a product (can be bought in quantities and is available at normal resellers) then it doesn't matter how bad 'authorized resellers' perform or not

Next round of tests in 'location 3' (still 5m away from AP with 2 walls in between, 1 m next to 'location 2' but with less troublesome stuff between devices and AP). I use the script from above to see whether enabling/disabling Wi-Fi powermanagement does change anything (or is possible at all). Obviously enabling/disabling on RPi 3 has no effect (brcmfmac driver), with RTL8189FTV and RTL8192CU is was not possible (same error message from iwconfig: 'Error for wireless request "Set Power Management" (8B2C) : SET failed on device wlan0 ; Operation not permitted.'), only with AP6212 (using legacy kernel dhd module) there were huge differences in performance.
 
I chose two rounds of tests at different times of the day. The first ran was shortly after midnight and the 2nd run started at 10:00 in the morning. This time I tried to find optimal antenna position but obviously that did not work that great with the TL-WN823N dongle (I have to admit that I slightly changed antenna positions between 1st and 2nd run, also not the best idea).
 
Software settings remained the same to before (so you can check dmesg output and so on above) and boards were tested one at a time (test execution lasts ~20 minutes which is also bad since environmental conditions between different test runs can change in between since for example the neighbour next to me transfers 15 min large amounts of data in his Wi-Fi interfering with mine and ruining performance in my network)
 
Results as follows, on the left nightly results as averaged iperf3 throughput numbers followed by those from now. 
 
NanoPi Air, AP6212 module, external small vertical aerial:
powermanagement on:  5.53 / 5.16 Mbits/sec powermanagement off: 30.14 / 14.66 Mbits/sec  
Orange Pi Lite, RTL8189FTV module, external small vertical aerial:
powermanagement on:  30.47 / 32.41 Mbits/sec powermanagement off: 30.57 / 32.56 Mbits/sec  
ODROID-C2 with TP-Link MIMO TL-WN823N dongle, RTL8192CU module, upright position:
powermanagement on:  34.90 / 48.51 Mbits/sec powermanagement off: 35.34 / 49.27 Mbits/sec  
RPi 3, BCM43438 module, onboard antenna oriented obviously properly:
powermanagement on:  35.42 / 25.59 Mbits/sec powermanagement off: 34.56 / 25.13 Mbits/sec How to interpret the results?
Powermanagement on/off matters at least with AP6212. With the other implementations there was no difference and numbers for on/off are just result variation. Further investigation needed whether it's just not possible adjusting PM settings with iwconfig or if it's not possible at all Environmental conditions matter at lot. Between the two test runs nothing regarding software/settings has changed, it was just different time of the day and slightly moving around antennas/boards. IMO it's already pretty obvious that this sort of 'performance' testing in real-world environments is too stupid to be continued since numbers depend highly on stuff you can't control. When RPi Zero W arrives I will add it to the test setup and move the whole setup to 'location 4' (will have to ask my neighbour to host the cardboard box with the 5 SBC inside). And then I might rewrite the testing script so that I can test through each board every 60 seconds to minimize external temporary influences.
 
Also interesting whether performance of TL-WN823N dongle improves when operated horizontally and not upright (Edit: nope). Same with Raspberries and their onboard antenna but here it seems upright position is better (at least when comparing the average 30 Mbits/sec from this test with the results from yesterday with RPi 3 just lying randomly around: 6 and 12 Mbits/sec)

Is the "like this" footer can be removed ?

after some week of uninterrupted working i can say that 3 opizero are working perfectly! And for now is my favorite board  I'm just start to use it instead of the orangepiPC and raspberry  

It took me a while to get this ILI9340 based LCD monitor working with the Orange Pi Zero until I found a post on this forum that explains how the H2+ ports are mapped to the GPIO numbers in the Linux kernel. So I built an online tool that does the math for you:
 

 
Here is a map of all the Orange Pi Zero GPIO pins:
 

All the additional details are described in this blog post.

Can't believe it myself
 
Well, I'm thinking about the data logger / sensor use case and compare here with el cheapo H2+/H3 boards. Given the used Ampak chip combined with a reasonable aerial provides long range connectivity (most probably then using 802.11b, right?) and battery situation and price are ok it might be worth a look (ok, differs a bit from 'interesting' as before).
 
We'll see. At least this hardware category starts to emerge (cheap Allwinner IoT stuff with battery support). BTW: It's 2 USB ports, 1 x host and 1 OTG

Just FYI: the first interesting Banana board since ages: BPi R16 based on Allwinner's A33 SoC (R16 is just a relabeled A33 with a different Allwinner business unit being responsible for).
 

 
For R16 exists a horribly outdated 'SDK' made by Allwinner's BU5: https://github.com/tinalinux/linux-3.4 (relies on unpatched kernel 3.4.39 which might contain more security flaws than features in the meantime. Their tinalinux approach combines this with an outdated Android 4.4 and somehow also a smelly OpenWRT version for reasons unknown to me. Surprisingly they also rely on their own proprietary LiveSuit image format no one on this planet outside of Allwinner wants to use).
 
But the good news is: There are some mainline kernel branches with patches for A33 around that are in a pretty good shape eg. https://github.com/Icenowy/linux/tree/a33-cedrus-pr (seems Icenowy also managed to get Allwinner video engine working with mainline kernel already). So most probably no need to fiddle around with Allwinner's tinalinux stuff or SinoVoip OS images at all
 
For me personally such an R16 IoT board has one big advantage over el cheapo H2+/H3 boards: PMIC support and therefore the ability to use/charge a connected battery (and also control voltage/useage and act on accordingly).
 
Let's see whether SinoVoip manages to introduce the usual design flaws (eg. not being able to use an external aerial unless you desolder components on the board), when they release (hopefully accurate) schematics, how the battery connector looks like and whether this device will be priced competitively.
 
Edit: According to the above pictures the same DRAM as on NanoPi Air is used (512MiB K4B4G1646Q-BCK0 DDR3) and at least not the ultra-slow eMMC they used on every other board since BPi M2+ (there they use KLM8G1WEMB-B031 -- can't read the exact writing on the picture above)
 
Edit 2: According to linux-sunxi IRC Ampak AP6212 is used on the board (WiFi/BT combo like on nearly all other Banana boards and also NanoPi Air or the upcoming OPi Zero 2 -- so we then have 3 flat and lightweight boards with eMMC, camera connector and the same Wi-Fi/BT combination but from 3 different companies using 3 different Allwinner SoCs. Funny)