Search the Community
Showing results for tags 'quick review'.
Found 3 results
Overview: 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.org/Sinovoip_Banana_Pi_M2%2B Compatibility: 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://openbenchmarking.org/result/1604082-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 4.6.0-rc1: 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 Open questions: 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) Conclusion: 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!)
Overview (Disclaimer: The following is for techies only that like to dig a bit deeper. And if you're not interested in energy-efficient servers then probably this is just a waste of time ) EDIT: Half a year after this poorly designed SBC has been released just one of the many design flaws has been fixed: Micro USB for DC-IN has been replaced by the barrel jack that was present on the pre-production batches. If you were unfortunate to get a Micro USB equipped M3 please have a look here how to fix this. Apart from that check the Banana forums what to expect regarding software/support first since this is your only source) SinoVoip sent me a review sample of the recently shipped so called "Banana Pi M3" yesterday. It's a SBC sharing name and form factor of older "Banana Pi" models but is of course completely incompatible to them due to a different SoC, an A83T (octa-core Cortex-A7 combined with a PowerVR SGX544 GPU). For detailed and up-to-date informations please always refer to the linux-sunxi wiki. This new model distinguishes itself from the Banana Pi M2 with twice as much CPU cores and DRAM (LPDDR3), 8 GB eMMC onboard and BT4.0. And compared to the "M1" (the original Banana Pi) it features also 802.11 b/g/n Wi-Fi. Unlike the M2 the M3 is advertised as being SATA capable. But that's not true, it's just an onboard GL830 USB-to-SATA bridge responsible for horribly slow disk access. Unfortunately the GL830 and both externally available USB ports are behind an internal USB hub therefore all ports have to share bandwidth this way and use just one single USB connection to the SoC. Since my use cases for ARM boards are rather limited you won't find a single word about GPIO stuff (should work if pin mappings are defined correctly), GPU performance, BT, Wi-Fi or Android. Simply because I don't care Getting Started: The board arrived without additional peripherals (no PSU) therefore you need an USB cable using a Micro-USB connector to power the board. Both DC-IN and USB-OTG feature an Micro-USB connector which is bad news since pre-production samples had a real DC-In connector (4.0mm/1.7mm barrel plug, centre positive like the M2). I suffered from several sudden shutdowns under slight load until I realized that I used a crappy cable. Many (most?) USB cables lead to voltage drops and when the board demands more power it gets in an undervoltage situation and the PMU shuts off. Same will happen to you unless you can verify that you've a good cable. I did not succeed querying the M3's powermanagement unit (PMU) regarding available voltage (/sys/devices/platform/axp81x_board/axp81x-supplyer.47/power_supply/ac/voltage_now shows always 0). This was a lot easier with the older Banana Pi M1: Here you can watch my cable being responsible for voltage drops under high load (I accidentally used this again with the M3). To avoid the crappy Micro-USB connector (limited to 1.8A maximum by specs and tiny contacts) you can desolder it and solder a cable or a barrel plug -- the PCB is already prepared for the latter. Or ask SinoVoip if they can fix this mistake with the next batch of PCBs. On the bottom side of the PCB there are also solder pads for a Li-Ion battery. It has to be confirmed whether the AXP813 PMU can also be fed with 5V through the Li-Ion connector since this is the preferred way to fix the faulty power design other SinoVoip products show. One final word regarding power: It seems currently something's wrong with power initialisation in the early boot stages (u-boot). With a connected bus-powered USB disk the board won't start or immediately shut down when the disk is connected within the first 10 seconds. I didn't verify when exactly because if you've a look at SinoVoip's commit log it seems they began to fix many obvious bugs just right now after they already started shipping the board (we've seen that with the M2 also). First Showstoppers: Since the board came with an unpopulated eMMC (why the heck?) I had to try out the available OS images from the banana-pi.org download site. Unlike everyone else on this planet they don't provide MD5/SHA1 checksums to be able to check integrity of downloads and even if you tell them that they've uploaded corrupted images they don't care. From 4 OS images 3 are corrupted (according to unzip) and all failed soon after boot with kernel panics. I tried the Android image to verify FEL mode works. But since Android is of zero use for me, I decided to build an own OS image from an Ubuntu distro running on the Orange Pi where I had the SD-card inserted. Since details are boring just as a reference. From then on I used this Ubuntu image and exchanged only the freshly built stuff from SinoVoip's BSP Github repo (3.4.39 kernel, modules, bootloader and also simple things like hardware initialisation since kernel/u-boot they prefer does NOT support script.bin) First Impressions: Heat (dissipation): The A83T needs a heatsink otherwise you won't be able to benefit from its performance. Allwinner's 3.4.39 kernel provides 'budget cooling' using 2 techniques: thermal throttling and shutting down CPU cores. You can define this 'thermal configuration' in sysconfig.fex and have to take care that you understand what you're doing since if throttling doesn't help your CPU cores will be deactivated and you have to can't bring them back online manually the usual way since Allwinner's kernel doesn't allow so: echo 1 >/sys/devices/system/cpu/cpuX/online Therefore it's better to stay with the thermal defaults to allow throttling and improve heat dissipation instead. I used a $0.5 heatsink that performs ok. Without heatsink when running CPU intensive jobs throttling limited clockspeed to 1.2 GHz but with the heatsink I was able to run most of the times at ~1.6Ghz under full load. With heatsink and an annoying fan I managed to let the SoC run constantly at 1.8GHz and achieved a 7-zip score close to 6000 and finished "sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=8" in less than 53 seconds. This is an example for wrong throttling values (too high) so that the kernel driver does not limit clockspeeds but starts to drop CPU cores instead: CPU performance: Since the H3 (used on the more recent Orange Pis) and the A83T seem to use much of the same kernel sources (especially the 'thermal stuff') I did a few short tests. When running with identical clockspeed and the same amount of cores they perform identical (that means they're slower than older Cortex-A7 SoCs like eg. the A20 when running at identical clockspeed -- a bit strange). Obviously the difference between H3 and A83T is the process. Both already made in 28nm but the A83T as 'tablet SoC' in the more energy efficient HPC process allowing less voltage and higher clockspeeds. According to sysconfig.fex the SoC should be able to clock above 2.1 GHz but since exceeding 1.6 Ghz already needs a fan this is pretty useless on a SBC (might be different inside a tablet where the back cover could be used as a large heatsink). Network throughput: I used my usual set of iperf testings and tried GBit Ethernet performance (with and without network tunables it remains the same -- reason below): BPi-M3 --> Client: [ 4] 0.0-10.0 sec 671 MBytes 563 Mbits/sec [ 4] 0.0-10.0 sec 673 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 870 MBytes 729 Mbits/sec [ 4] 0.0-10.0 sec 672 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 675 MBytes 566 Mbits/sec Client --> BPi-M3: [ 4] 0.0-10.0 sec 714 MBytes 599 Mbits/sec [ 5] 0.0-10.0 sec 876 MBytes 734 Mbits/sec [ 4] 0.0-10.0 sec 598 MBytes 501 Mbits/sec [ 5] 0.0-10.0 sec 690 MBytes 578 Mbits/sec [ 4] 0.0-10.0 sec 604 MBytes 506 Mbits/sec When I used longer test periods (-t 120) then the "Client --> BPi-M3" performance increased up to the theoretical limit: 940 Mbits/s. Then a second iperf thread jumped in, both utilising a single CPU core fully. And that's the problem: Networking is CPU bound, a single client-server connection will not exceed 500-600 Mbits/sec as it was the case when I started with A20 based boards 2 years ago. Since all we have now with the A83T is an outdated 3.4.39 kernel and since I/O bandwidth on the M3 is so low, I stopped here since it's way too boring to try to improve network throughput and also useless (disk access is so slow that it simply doesn't matter when Ethernet is limited to half of the theoretical GBit Ethernet speed... at least for me ) Accessing disks: Since there's a SATA connector on the board I gave it a try. Important: the SATA-power connector uses the same polarity as older Banana Pis and Orange Pis (keep that in mind since combined SATA data/power cables from LinkSprite and Cubietech that share exactly the same connector use inverted polarity!). I started with the Samsung EVO I always use for tests (but due to the old 3.4 kernel using ext4 instead of btrfs) and was shocked: 13.5/23 MB/s is the worst result I ever measured. I then realised that I limited maximum cpufreq to 480 MHz and tried with 1800 MHz again. A bit better but far away from acceptable: GL830 USB-to-SATA performance: 480 MHz: kB reclen write rewrite read reread 4096000 4 13529 13466 22393 22516 4096000 1024 13588 13411 22717 26115 1.8 GHz: 4096000 4 15090 15082 30968 30316 4096000 1024 15174 15131 30858 29441 I disconnected the SSD from the 'SATA port' and put it in an enclosure with a JMicron JMS567 USB-to-SATA bridge and measured again: Now sequential transfer speeds @ 1800 MHz exceeded 35/34 MB/s. The GL830 is responsible for low throughput -- especially writes are slow as hell. I made then a RAID-1 through mdadm consisting of an external 3TB HDD (good news: the GL830 can deal with partitions larger than 2 TB) and the SSD. First test with the HDD connected to the M3's GL830 bridge (GL) and the SSD connected to the JMS567 (JM). Then I disconnected the HDD from the GL830 and put it in another external enclosure with an ASMedia 1053 (ASM). Obviously SinoVoip's decision to use an internal USB hub and only one host port of the SoC leads in both situations to limited (shared) bandwidth. But in case the internal USB-to-SATA bridge is involved performance is even worse: GL/JM: kB reclen write rewrite read reread 4096000 4 17800 17140 14382 16807 4096000 1024 17741 17258 14493 14368 JM/ASM: 4096000 4 19307 18458 22855 26241 4096000 1024 19231 18518 21995 22362 If SinoVoip would've saved the GL830 USB-to-SATA bridge and wired both SoC's host ports to the 2 type-A USB ports directly without the internal hub in between overall performance would be twice as good. And obviously the M3's 'SATA port' is the worst choice to connect a disk to. Any dirt-cheap external USB enclosure will perform better. SD-card and eMMC: Just a quick check with the usual iozone settings running @ 1.8 GHz: kB reclen write rewrite read reread eMMC: 4096000 4 26572 27014 59187 59239 4096000 1024 25875 26614 56587 56667 SD-card: 4096000 4 20483 20855 22473 22892 4096000 1024 20526 19948 22285 22660 LOL, eMMC twice as fast as 'SATA'. The performance numbers of the SD-card (SanDisk "Extreme Pro") are irrelevant since I can not provide performance numbers from a known fast reference implementation. But since I might be able to provide this the next few days, I decided to give it a try. On older Allwinner SoCs there's a hard limitation regarding SDIO/SD-card speed. Maybe this applies here too. EDIT: Yes, it's a board/SoC limitation. When reading/writing the SD-card on a MacBook Pro I achieve ~80 MB/s. It seems SDIO on A83T is limited to ~20MB/s Other issues: If you want to try out the M3 you'll have to stay on the bleeding edge. Don't expect that any of the available OS images are close to useable. They just recently started to fix a lot of essential bugs in code and hardware initialisation. If you want to test the M3 be prepared to compile the BSP daily and exchange the bootloader/kernel/initialisation stuff on your SD-card/eMMC Currently average load is always 1 or above. When we started over 2 years ago with Cubieboards (and an outdated kernel 3.4.x) there was a similar issue. Maybe it's related. I just opened a Github issue Mainline kernel support in very early stage. Don't count on this that soon (situation with Banana Pi M2 was a bit different. All the OS images from SinoVoip based on kernel 3.3 weren't useable but the community provided working distros backed by the work of the linux-sunxi community and existing mainline kernel support for the M2's A31s) Always keep in mind that hardware without appropriate software is somewhat useless. SinoVoip has a long history of providing essential parts of software way too late or not at all (still applies to the M2 -- before you buy any SinoVoip product better have a look into their forums to get the idea which level of support you can expect: zero). Even worse: For the M2 and its A31s SoC there exists mainline kernel support (everything developed by the community while the vendor held back necessary informations). This does not apply to the A83T used on the M3. At the moment you're somewhat lost since you've to rely on the manufacturer's OS images (all of them currently being broken) Conclusion: Still no idea what to do with such a device. Integer performance is great when you use a heatsink and even greater with an annoying fan. But where's the use case? If I would use the M3 with Android then everything that's relevant for performance does not depend on CPU (but instead CedarX for HW accelerated video decoding and GPU for 2D/3D acceleration -- BTW: the A83T is said to contain only a single core SGX544MP1 but the fex file's contents let me believe it's a faster MP2 instead). Due to limited I/O and network bandwidth the integer performance is also irrelevant for nearly all kinds of server tasks. If it's just about 'SBC stuff' why wasting so much money? Triggering GPIO pins works also with cheap H3 based boards like Orange Pi PC or Orange Pi One that also have 4 times more I/O bandwidth compared to the M3 (due to 4 available USB ports instead of one). And if I would really need a performant ARM SoC then I would buy such a thing and not an outdated Cortex-A7 design. I still have no idea what the M3 is made for. Except of selling something under the "Banana" brand to clueless people. Don't know. For my use cases the Banana Pi M1 outperforms the M3 easily -- both regarding price and performance (sufficient CPU power, 3 x USB and real SATA not 'worst USB-to-SATA implementation ever'). As usual: YMMV Maybe the worst design decision (next to choosing the crappy Micro-USB connector for DC-IN) on the M3 is the 'SATA port'. If they would've saved both internal USB hub and GL830 and instead use the two available USB host ports then achievable I/O bandwidth would be way higher. Now both USB ports and the 'SATA port' have to share the bandwidth of a single USB 2.0 connection. Almost as bad as with the Raspberry Pis. But most importantly: Check software und support situation first and don't rely on 'hardware features'. Remember: SinoVoip shipped the M2 with OS images where not a single GPIO pin was defined and Ethernet worked only with 100Mb/s since they 'forgot' to define GMAC pins. They fixed that months later but still not for every OS image (the Android image they provide is corrupted since months but they don't care even if users complain several times). Visit their forums first to get an idea what to expect. It's important! Armbian support: Not to be expected soon. It's worthless when having to rely on Allwinner's old 3.4.39 kernel. I combined loboris' H3 Debian image with kernel/bootloader stuff for the A83T and it worked as expected (even my RPi-Monitor setup matched almost perfectly). Unless the linux-sunxi community improves mainline support for the A83T this situation won't change. But maybe someone interested in M3 (definitely not me) teaches SinoVoip how to escape from u-boot/kernel without support for script.bin in the meantime. Would be a first step.