Review Banana Pi M2 Berry

[tkaiser]

 

The above is a so called 'Banana Pi M2 Berry' I bought yesterday and will return today to get my money back (due to 'Irreführende Werbung' / false advertising) showing most probably the use case this device will be bought by clueless people: To connect a SATA 2.5" disk to it since 'native SATA'. Of course this doesn't work as expected since the board's power design is an absolute fail.

 

The manufacturer already knows what a shit show using Micro USB for DC-IN is. I simply used the same average USB cable I used to demonstrate the problem a few years ago with the original Banana Pi. With an average USB cable the disk does not even spin up but only produces ugly noise (clicks and motor spinning on/off constantly). Check dmesg output at the bottom of http://sprunge.us/FaFL to see how under-voltage shows up in the logs. When the poor disk made ugly noise I measured on pin 2 and 6 (5V/GND) and saw voltage dropping as low as 4.4V which is definitely way too low for a variety of disks. Check with Hardkernel's findings wrt exactly the same issue: 'We found that Seagate 2TB and HGST/Hitachi 1TB HDDs are quite sensitive to the input voltage level while WD 1TB/500GB, Samsung Momentum and Toshiba HDDs are working well even with 4.4Volt input.'

 

Please note that in the above setup I did not use Gigabit Ethernet. GbE significantly increases consumption and then voltage drops even more. In other words: Depending on the USB cable users choose, the PSU/charger, the type of connected disk and additional load on the board the stuff people buy this board for (NAS use cases) will either work or not. Since all the advertisements for this board are misleading the average buyer of this board must be also clueless -- since if he does some research before he wouldn't buy the board. If Armbian starts to support this board we deal with a user base blaming us for the shitty power design of this board (since not understanding stuff like Ohm's law and talking about instable software where it's just under-voltage/hardware) and also why Armbian is incompatible to Raspberries (omxplayer won't work here, raspivid/raspistill don't work, every graphics stuff for Raspberries doesn't work and the users expect 'spoon feed' mode as known from Raspberry Pi forums).

 

Since I had the board already on my desk and the vendor itself is as usual too lazy or too stupid to provide any performance numbers I checked quickly for myself:

 

• The USB design of this board is as shitty as DC-IN: all 4 USB receptacles are behind the same USB hub so all have to share bandwidth (the SoC's 2nd real USB2 host port is not used. Responsible board makers in such situations connect only 3 USB receptacles to the hub and the other real USB host port to the fourth USB receptacle so this port doesn't need to share bandwidth and can be used with another disk for example). Here 'lsusb -t' output from me connecting my test USB disk to each of the 4 receptacles.
• Some CPU/memory performance numbers: https://pastebin.com/gANnaQJ5 (please keep in mind that you need to understand the influence of compiler/OS version to interpret sysbench numbers)
• Some storage performance made with a good 20AWG rated USB cable between board and my 5V/2A PSU (USB performance shitty since only USB2 and no UAS available with SinoVoip OS images, SATA performance shitty due to Allwinner's SATA implementation being slow): https://pastebin.com/24tTn05L
• Gigabit Ethernet performance: 654 Mbits/sec in TX direction and 866 Mbits/sec in RX direction (I did not try to tune settings but simply used the stupid SinoVoip defaults). Same shit show as with A20 on the older Bananas: networking is faster in RX direction while with SATA it's the opposite. So in NAS use cases when you need both Ethernet and storage bandwidth at the same time you're always bottlenecked by one of the two): https://pastebin.com/UTT9v9wN
• Wi-Fi performance not overwhelming (TX 26.6 Mbits/sec, RX 33.5 Mbits/sec, board 1m away from AP), the onboard antenna they use doesn't perform as good as the one on RPi Zero W or RPi 3 (you can't attach an external antenna since SinoVoip's technical documentation consists more or less only of lies like this): https://pastebin.com/AzMtYbFQ

 

The board's advertising consists mostly of lies ('fully compatible to Raspberries and all Raspberry Pi accessories'), same can be said about the 'technical documentation', the hardware vendor doesn't support his own boards (just check the forum: http://forum.banana-pi.org/latest), while the board is already sold they still don't provide schematics (and if they'll provide schematics anytime most probably they cripple them as they did with their R2 board) and the manufacturer also still refuses to merge these pull requests providing tons of security fixes for BPi M2 Ultra and this Berry here.

 

In other words: customers of this hardware must be absolutely clueless to buy it (trusting in false advertising and not doing any research before) while open source developers must even be stupid starting to work on this hardware given the above problems.

 

Final remarks: V40 SoC without heatsink idles at +55°C which seems reasonable verifying with 'thumb test', running heavy loads like cpuminer temperature exceeded 80°C but throttling with SinoVoip's OS image is configured to jump in later. DRAM frequency is not 733 MHz as claimed but 576 MHz max (will be lowered by legacy kernel throttling code at high temperatures and can be read out using /sys/devices/1c62000.dramfreq/devfreq/dramfreq/cur_freq), average load of SinoVoip's OS image never goes below 1 as usual (they really repeat every single mistake with every new board again and again) and if you're unfortunate enough to have bought this poor design you should be aware that on their OS image the first 60 seconds the below process is occupying a single CPU core fully:

root@bpi-iot-ros-ai:~# ps auxwww | grep brcm_patchram_plus
root      3812  0.0  0.0   3744   548 ?        S    15:48   0:00 /usr/bin/timeout 60s /usr/local/bin/brcm_patchram_plus -d --patchram /lib/firmware/ap6212/bcm43438a0.hcd --enable_hci --no2bytes --tosleep 1000 --bd_addr 43:29:B1:55:01:01 /dev/ttyS1
root      3813  100  0.0   1444   252 ?        R    15:48   0:49 /usr/local/bin/brcm_patchram_plus -d --patchram /lib/firmware/ap6212 bcm43438a0.hcd --enable_hci --no2bytes --tosleep 1000 --bd_addr 43:29:B1:55:01:01 /dev/ttyS1

The PMIC theoretically exposes under-voltage readouts but for whatever reason 0 is the reported value (so 3rd parties trying to support this board and its users can't identify under-voltage situations. This device is a support nightmare with a 2.5" disk connected):

root@bpi-iot-ros-ai:~# find /sys -name "*_now" | while read ; do
> echo -e "${REPLY}: $(cat "${REPLY}")"
> done
/sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/ac/current_now: 0
/sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/ac/voltage_now: 0
/sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/usb/current_now: 0
/sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/usb/voltage_now: 0

Will now take the board back to the seller asking to refund me since the claim 'fully compatible to Raspberry Pi' is just a bold lie. Will take a RPi camera with me to show the staff that it's impossible to use RPi accessories like cameras due to different physical FPC connector.

 

[op1tjaap]

Really shocking that nobody at these companies seems to bother to read this forum and learn from mistakes from the past.

If your board is still equipped with USB power this is really unbelievable after all we now know about the problems it will cause. 

 

I sometimes think that we should make a design for a board outselved and let it be build instead of waiting until somebody wakes up and out of the blue will do the "good thing". 

[zador.blood.stained]

5 minutes ago, op1tjaap said:

I sometimes think that we should make a design for a board outselved and let it be build instead of waiting until somebody wakes up and out of the blue will do the "good thing". 

Well, designing a board (beyond "I want a board with Allwinner H5, lots of USB ports and a good power connector") is not that simple since it requires specific knowledge. And designing a commercially successful board is a whole another story.

 

Looking at the Armbian download statistics it's clear that cheap devices are the most popular ones. And looking at the vendor discussed in this thread it's clear that larger profit per one board + distribution through recellers + false advertising targeting Raspberry Pi audience works too (unfortunately).

[tkaiser]

Final benchmark (after fighting against this lousy OS image called '2017-07-10-ubuntu-16.04-mate-desktop-beta-bpi-m2u-sd-emmc.img'). After moving an orphaned /etc/samba/smb.conf out of my way I used our 'armbian-config' tool to conveniently install Samba. I added the usual OMV/Armbian performance options and then did a benchmark using Gigabit Ethernet and the usual Samsung EVO840 SSD I always use for such tests (so you can compare results here):

 

 

 

As already said: I did not optimize settings like IRQ affinity further but simply used the stupid SinoVoip defaults (not giving a sh*t about what's important on these small ARM boards to get somewhat decent performance).

 

Please check also dmesg output: http://sprunge.us/KfTO -- while benchmarking this pretty power efficient SSD numerous occurences of 'ata1: hard resetting link' happened. It seems the power design of this board is not even capable of providing enough power to SSDs. Tests were done  with a short 20AWG rated Micro USB cable and with my 'standard' PSU known to provide stable 5.0V even at 1.8A load. Well, if your 'business model' is simply trying to cash in on Raspberry Pi popularity and involves lying to your potential customers and claiming your device would be 'fully compatible' to every RPi accessory then of course you have to also use shitty Micro USB for DC-IN to create the impression of 'compatibility'.

 

But on Raspberries starting with 2nd generation RPi Foundation implemented under-voltage detection circuitry that triggers actions when input voltage drops below 4.65V. The firmware then starts to throttle down CPU, memory, GPU and VPU. Nothing of this is implemented on this M2 Berry thingie. It simply fails with providing enough voltage to a connected SATA disk.

 

Since the hardware vendor doesn't provide schematics we can't have a look into details and whether it's possible to fix the issue here or there. Most simple solution: stay away from such irresponsible vendors. They'll make their profit anyway as @zador.blood.stained already explained.

 

 

[Tido]

5 hours ago, zador.blood.stained said:

And designing a commercially successful board is a whole another story.

Do not forget, @jernej who does TV stuff has a totally different preferation than @tkaiser for example.

What I want to say, you might reach a good compromise, but it will be IMPOSSIBLE to create a "cash cow" like RPi where most of the user accept the design flaw because it just works. Huge community and most of them catch just dust like some of mine do.

 

IIRC, Orange Pi+ 2e does ful fill many wishes, but according to the forum and support of HW it is not the favorite of everyone.

 

[tkaiser]

On 5.8.2017 at 12:28 PM, op1tjaap said:

Really shocking that nobody at these companies seems to bother to read this forum and learn from mistakes from the past.

If your board is still equipped with USB power this is really unbelievable after all we now know about the problems it will cause. 

 

This specific company responsible for BPi-M2 Berry's power design knows exactly what they do. Here their CEO (Lion Wang) explained that you need a PSU with 5.5V to compensate for voltage drops with a connected HDD when powering the crappy way (Micro USB): '5V power for some hardisk is not good to work , but we test . if you use 5.5V , 2.A will work fine . so we do 5.5V , 2.1A power for R1'

 

Different Banana, same (long known) problem. But since they want to advertise this BPi-M2 Berry as being 'fully compatible' with Raspberries they chose this absolute unreliable powering scheme again. And when then more and more unsatisfied customers start to fill their forum with complaints they simply shut it down -- that's why the above is only available through web.archive.org any more.

 

Edit: Under-voltage reports:

• Das Image "2017-05-25-raspbian-jessie-preview3-bpi-m2u-sd-emmc.img" läßt sich nicht starten. Der Banana Pi hängt sich beim booten in einer Endlosschleife auf
• http://forum.banana-pi.org/t/external-usb-does-not-work-on-bpi-m2-berry/4094

[Lion Wang]

BPI-M2 Berry schematic diagram public

 

https://bananapi.gitbooks.io/bpi-m2-ultra-open-source-single-board-computer/content/bpi-m2-berry-hardware/bpi-m2-berry-schematic-diagram.html

[domoticity]

@tkaiser Hy,

Can you tell me which OS do you used in this M2 berry? Ubuntu or raspbian? Thanks

Edited October 21, 2017 by Tido
removed unnecessary, very big quote. replaced with @

[Igor]

11 hours ago, domoticity said:

Can you tell me which OS do you used in this M2 berry? Ubuntu or raspbian? Thanks

Irrelevant. Those problems are OS independent.

[domoticity]

On 21/10/2017 at 8:11 AM, Igor said:

Irrelevant. Those problems are OS independent.

not for problem. In this Topics,it's said 

Quote

654 Mbits/sec in TX direction and 866 Mbits/sec in RX direction 

But with mine, id don't go beyond 300mbits in download. I am have normally 750mbits

[Юрий Долгорукий]

will this board have firmware from armbian?

[Igor]

2 minutes ago, Юрий Долгорукий said:

will this board have firmware from armbian?

It exists as .csc target in the build system, while official support ... we haven't discussed. I tried it 1-2 weeks ago (kernel 4.17.RC something) just for fun: there is no HDMI, no DVFS, ... but boots, all four cores are up, USB works, wifi works ... and can be used for some simple tasks testings.

[guidol]

So only WiFi is up? Because I did build the M2 Ultra .csc and had no HDMI output and no DHCP request at the ethernetport

Therefore I did think the image doesnt boot, because I had no serial-port dongle attached.

Is the eth at this time also unsupported?

[Igor]

12 minutes ago, guidol said:

Is the eth at this time also unsupported?

Yes. It looked that way.

[guidol]

I did try the new created images (via the Bionic 18.04 build system) for xenial and stretch.

 

OK - we did know that the ethernet isnt working, but WiFi is working very badly for me.

Sometimes wlan0 could find my wlan and sometimes it could even scan the network - then dmesg shows scan-timeouts

Spoiler

[   15.689541] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   18.249525] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   20.819447] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   20.819459] brcmfmac: brcmf_p2p_set_firmware: failed to update device address ret -110
[   23.369447] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   23.369459] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
[   23.369471] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 type 10 failed: err=-110
[   25.929442] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   25.929453] brcmfmac: brcmf_do_escan: error (-110)
[   25.929459] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[   29.529447] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   29.529460] brcmfmac: brcmf_do_escan: error (-110)
[   29.529466] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[   52.569451] brcmfmac: brcmf_do_escan: error (-110)
[   52.569462] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[   66.189494] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
 

But when it do find my wlan it cant connect/activate the connection.

 

With the little help of a USB-Ethernet-adapter I could get connected to the internet.

In xenial this did work right after configureing nmtui - BUT in strech I had to edit the /etc/resolv.conf, because nmtui/the NetworkManager didnt changed the resolv.conf

 

If anyone want to to have a look: 

root@bpi-m2-berry:~# armbianmonitor -u
System diagnosis information will now be uploaded to http://ix.io/1ceN

 ____                                  ____  _   __  __ ____  _   _
| __ )  __ _ _ __   __ _ _ __   __ _  |  _ \(_) |  \/  |___ \| | | |
|  _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | | | |\/| | __) | | | |
| |_) | (_| | | | | (_| | | | | (_| | |  __/| | | |  | |/ __/| |_| |
|____/ \__,_|_| |_|\__,_|_| |_|\__,_| |_|   |_| |_|  |_|_____|\___/


Welcome to ARMBIAN 5.46 user-built Debian GNU/Linux 9 (stretch) 4.14.47-sunxi

Linux bpi-m2-berry 4.14.47-sunxi #2 SMP Sun Jun 3 22:02:09 +03 2018 armv7l GNU/Linux

 

[Roman B]

Did any one try this board with SSD instead of HDD which I beleive topic starter used in his tests?

SSD has less power consumption so probably it works ok with this board and usual PSU.

[tkaiser]

On 6/20/2018 at 7:27 AM, Roman B said:

Did any one try this board with SSD instead of HDD which I beleive topic starter used in his tests?

 

You believe the thread starter used only a HDD? What about reading the threads you're writing to?

 

On 8/5/2017 at 12:56 PM, tkaiser said:

while benchmarking this pretty power efficient SSD numerous occurences of 'ata1: hard resetting link' happened. It seems the power design of this board is not even capable of providing enough power to SSDs. Tests were done  with a short 20AWG rated Micro USB cable and with my 'standard' PSU known to provide stable 5.0V even at 1.8A load

 

On 6/3/2018 at 7:39 AM, Юрий Долгорукий said:

will this board have firmware from armbian?

 

Why should it? Why do people not read the threads they're writing too? It's explained in top post here why this device is problematic: powering is a problem, user expectations due to false advertising are a problem, software support situation is a huge problem since vendor offerings are crap and linux-sunxi community tries to get these R40/V40 boards mainlined for whatever reasons are way behind. It's also explained why this board will be a support nightmare since only bought by clueless users and blaming Armbian later for the hardware flaws like this crappy Micro USB connector to power it.