Jay Baghem

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.