SinoVoip sent me a few days ago a review sample of their new Banana Pi M2+. It's based on Allwinner's H3 SoC and tries very hard to be a 99% clone of Orange Pi Plus/PC. SinoVoip chose to stay compatible to nearly all pin mappings therefore any OS image that works on Orange Pi Plus will also work on BPi M2+ but some things need adjustments.
BPi M2+ features GBit Ethernet, eMMC, 2 USB host ports and one USB OTG that do not have to share bandwidth (no internal USB hub used and H3's 3rd USB host port unused unfortunately), Ampak AP6212 to provide WiFI/BT, fortunately no crappy USB-to-SATA bridge, a CSI interface to be used together with an OV5460 5MP camera module and... no programmable voltage regulator for the SoC.
Since it's based on the H3 SoC it's incompatible to all other Banana Pi variants and almost everything you can expect is already known. As usual you find the most recent and comprehensive information for any board based on Allwinner SoCs in the linux-sunxi wiki: http://linux-sunxi.o...p_Banana_Pi_M2+
The SoC's pins are routed to the externals exactly like on Orange Pi Plus/PC so it was pretty easy to create a device tree file for mainline kernel by using everything from Orange Pi Plus and replacing USB definitions with the stuff from Orange Pi PC (deleting the usb3 node since not existent) and here we are: Banana Pi M2+ is supported by mainline kernel with working USB, eMMC, GBit Ethernet and WiFi/BT already and as soon as display support and so on are available for H3 BPi M2+ benefits automagically from it.
Situation with kernel 3.4 is the same: In Armbian we support the board already since it was just adoption of SinoVoip's settings (and correction where they're horribly wrong -- see below when it's about performance). Since it's 'just another H3 board' software support will progress nicely and maybe the best news: You are not forced to use OS images from SinoVoip since you can rely on the community's work instead (Armbian for example).
Documentation and support provided by vendor:
To sum it up: still the usual horrible 'SinoVoip experience' we already know. They still don't get why correct information might matter. 'Documentation' is not written by engineers but instead trainees playing 'copy&paste gone wrong'. According to their website the board is either '55mm square' or 65x65mm, features 'Power led, Status led' (in reality just one led), has a 'CAN bus' (wrong for all their last SBCs, this is still moronic copy&paste from the first Banana Pi whose A20 SoC is CAN capable) and so on... you never know whether the information provided there is information or just the usual copy&paste errors they're famous for.
It gets even worse when you look into the vendor's so called 'documentation': There the M2+ is most of the times called M3 ("BPI-M2+ USB interface: BPI-M3 have two USB 2.0 interface on board"), the onboard WiFi chip is sometimes AP6212 and sometimes AP6181, according to the 'BPI-M2+ Quick Start' guide you can power the board through USB OTG (not true) and a '3.5mm jack audio' is available (which is also not true) and so on. And they ask you to download OS images from http://www.banan-pi.org (domain does not exist). Any more questions? If you've to rely on their information or support you're already lost since the vendor simply doesn't give a shit about stuff like this.
Software provided by the vendor:
Since SinoVoip today released an OS image for M2+ -- they call it Raspbian Jessie(debian 8) BPI-M2P (20160408) -- I thought: let's give it a try. Armbian supports this board already but maybe we missed something. OMFG, what a horrible experience! I burned this Raspbian image to a 8GB SD card and booted. Whole boot log as follows:
And then I had an installation with zero free space. You can't do anything with it:
Filesystem Size Used Avail Use% Mounted on /dev/root 3.9G 3.7G 0 100% / devtmpfs 373M 0 373M 0% /dev tmpfs 501M 68K 501M 1% /dev/shm tmpfs 501M 6.9M 494M 2% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 501M 0 501M 0% /sys/fs/cgroup /dev/mmcblk0p1 256M 45M 211M 18% /boot tmpfs 101M 4.0K 101M 1% /run/user/1000 /dev/mmcblk1p1 7.2G 145M 6.7G 3% /media/pi/3684f9bd-1ea5-4cd0-a75b-b47af6147d77 tmpfs 101M 0 101M 0% /run/user/0
I quickly used Armbian's tools to resize the partition to the maximum and rebooted just to realise that they really use raspbian.org repositories for this OS image (how moronic is it to use ARMv6 code on a H3 board?!). I tried to get RPi-Monitor installed which didn't work out of the box, wasted almost an hour to fix this stuff and then gave up. Since I simply copied our armbianmonitor tool to the installation I gave up on RPi-Monitor and used armbianmonitor instead to monitor temperatures, CPU clockspeed and so on when running a few benchmarks:
The bad news:
BPi M2+ is a 99% clone of Orange Pi Plus/PC. Why didn't they do a 100% copy but instead chose to f*ck up the missing one percent? The Orange Pi variants all use a programmable voltage regulator to provide the SoC's VDD_CPUX voltage (lower clockspeeds --> lower voltage --> less heat --> more efficient throttling behaviour if SoC starts to overheat). On BPi M2+ the SoC is always fed with 1.3V which prevents best performance with heavy multithreaded workloads. Be prepared that due to this high voltage even throttling down to half of the maximum clockspeed doesn't help that much:
This is a not so demanding benchmark running with Armbian settings. Any Orange Pi variant would reduce voltages when reduding clockspeeds which is responsible for less heat emissions and therefore with the very same settings a H3 used on an Orange Pi would still run with 816, 912 or even 960 MHz due to reduced VDD_CPUX voltage where BPi M2+ remains at 648 MHz.
SinoVoip not only tried to copy the hardware very closely, they also use loboris' kernel 3.4 sources developed for Orange Pis (Armbian uses a different code base) and they chose to copy the most important mistake Xunlong made so far (the Orange Pi vendor, that developed also the 1st Banana Pi that has been manufactured by SinoVoip from then on).
Their throttling settings prefer killing CPU cores instead of throttling if the SoC starts to overheat. This is the main reason why Orange Pi boards get that bad scores on openbenchmarking.org: Since the multithreaded benchmarks increase temperatures that much that CPU cores are killed and never come back.
This is exactly what happens with SinoVoip's software settings: I started an usual run of Phoronix Test Suite, the 1st benchmark already killed cpu3, the next one cpu2 and due to their moronic THS settings the maximum clockspeed is 1008 MHz anyway. So a SBC advertised as 'quad core @ 1.2GHz' is already just a 'dual core @ 1.0GHz' when running a few boring benchmarks:
[ 2749.050080] CPU Budget:Try to down cpu 3, cluster0 online 4, limit 3 [ 2749.051406] [hotplug]: cpu(0) try to kill cpu(3) [ 2749.052482] [hotplug]: cpu3 is killed! . [ 4575.080090] CPU Budget:Try to down cpu 2, cluster0 online 3, limit 2 [ 4575.081791] [hotplug]: cpu(0) try to kill cpu(2) [ 4575.081853] [hotplug]: cpu2 is killed! .
And benchmark results look as expected: The worst combination is SinoVoip hardware combined with SinoVoip software: http://openbenchmark...-GA-1604074GA00
We implemented a special corekeeper service especially for M2+ in Armbian two days ago to help recover from killed CPU cores (since we can't prevent this as long as we've to rely on kernel 3.4 and the M2+'s fixed voltage is a real problem). Be prepared that if you run really demanding workloads on the BPi M2+ with their OS images that you end up with a single core board pretty soon.
The good news:
Since it's 'just another H3 board' trying very hard to be as compatible as possible to the Oranges you benefit automagically from every software effort made by the community. You don't need to use software from SinoVoip, you don't need to rely on their (non existing) support, you simply can use any of the community's stuff. Mainlining efforts are progressing nicely and by simply mixing device tree stuff from Orange Pi Plus and PC I've been able to get the BPi M2+ with working GBit Ethernet and maximum USB throughput running with kernel 4.6.
As a reference iozone measurements of a USB connected HDD (UASP capable enclosure which is responsible for better performance with mainline kernel) and the onboard eMMC:
'SinoVoip' 3.4.39-lobo kernel:
USB disk: random random KB reclen write rewrite read reread read write 102400 4 6347 8163 8494 8473 506 1603 102400 16 15420 18110 16543 16674 1885 5445 102400 512 23024 33610 32381 32779 23049 23276 102400 1024 17930 30673 23079 24077 23051 24331 102400 16384 22468 35098 34304 34148 34189 35090 eMMC: random random KB reclen write rewrite read reread read write 102400 4 5323 5683 14130 14135 12028 5573 102400 16 17531 18513 34499 34598 31193 17278 102400 512 24868 24626 61687 61697 61581 23991 102400 1024 25134 24949 66979 67180 67140 24553 102400 16384 26165 25950 76265 76649 76701 25931
USB disk: random random KB reclen write rewrite read reread read write 102400 4 7760 7917 7845 7868 505 1445 102400 16 17647 20568 20593 20945 1945 4729 102400 512 27334 35579 38033 38553 24980 35320 102400 1024 27419 36866 38764 39026 30661 36766 102400 16384 28267 37358 38540 38558 38988 37542 eMMC: random random KB reclen write rewrite read reread read write 102400 4 5233 5708 14953 14951 12650 5916 102400 16 19776 20609 37958 38023 34206 19403 102400 512 26981 27200 78648 78752 77930 26121 102400 1024 27188 27173 78793 78764 78431 26651 102400 16384 27276 27135 79341 79440 79406 27334
The board is designed to be used with an OmniVision OV5460 camera module (Xunlong sells a cheap GalaxyCore gc2035 camera module instead). The very same camera module has already been sold for Banana Pi. And the state of the driver prevented any resolutions above 640x480 (video). So unless someone is able to check the state of the drivers the use of this 'superiour' 5MP module is questionable (at least when you try to run the board with Linux -- Android might be a different story)
If the price will be competitive this board is worth a look unlike other SinoVoip boards (M2/M3). It's already fully supported by Armbian so there's no need to use any of the crappy OS images the vendor provides (it's easy to use our Armbian build system to create OS images for non Debian based distros, just read the docs!)