Review Banana Pi M3

[tkaiser]

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.

[Guest Mark]

Thanks for the honest and detailed write-up - much appreciated!

[tkaiser]

Update 3 days later: SinoVoip's software/support is worse than ever before:

 

• They're still busy fixing essential things long after sales have started: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/commits/master
• They close Github issues without investigation: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/3
• They close Github issues without even reading/understanding them and answer pure nonsense to questions: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/4
• They provide a faked Armbian image: http://forum.banana-pi.org/t/bpi-m3-new-image-armbian-v4-70-30-11-2015-for-bpi-m3/
• Their own images don't boot: http://forum.banana-pi.org/t/bpi-m3-new-image-ubuntu-mate-15-10-for-bpi-m3-20151203/817
• Still no MD5/SHA1 checksums to verify download integrity. But it wouldn't help if there were any since even if they provide an MD5 hash, they upload corrupted images at the same time but don't care about. They simply don't give a sh*t about anything else than selling hardware.

 

If you buy any product from this vendor be prepared that software/support will be catastrophic.

[technik007_cz]

Good job mate. You saved my money ;-).

[tkaiser]

Another update regarding software / OS images. In the meantime they released a few more images: http://www.banana-pi.org/download.html

 

As usual without MD5/SHA1 checksums so you can not check whether your download is corrupted or not. But even if they would provide checksums it won't help since SinoVoip simply doesn't give a sh*t about anything other than selling hardware. Numerous downloads are corrupted (see here or here or here) and they simply don't react even if customers complain multiple times.

 

At the moment they are also clueless how to flash a Linux image onto eMMC using FEL mode (this only works with the Android images using PhoenixSuit/LiveSuit) so in case you want to start a Linux image from the internal eMMC storage you would have to first flash it to an SD card, then boot from this card, then transfer the image using dd to /dev/mmcblk1. I did it through the network as follows:

ssh tk@macbookpro-tk "dd if=/Users/tk/Downloads/ubuntu-mate-15.10-desktop-armhf-raspberry-pi-2-bpi-m3-sd-emmc-20151203.img bs=4m" | dd of=/dev/mmcblk1

Three times dd quit unexpectedly while writing to eMMC, then I simply lowered the maximum cpufrequency down to 1008 MHz and it worked. Seems there's a bug when writing to eMMC so be prepared to experience filesystem corruptions if you're booting from eMMC. At least you can use eMMC this way, the M3 boots from there when no SD card is present.

 

I tried then their Ubuntu 15.10 image and had a laugh: They ship with enabled irqbalanced! It's a well known fact that irqbalancing doesn't work on ARM based SBCs and has a memory leak on platforms that lack PCI/PCIe. So be prepared that irqbalanced will eat up all your RAM over time and then the whole system has to be rebooted. It's completely weird to release an OS image for an ARM SBC with an enabled irqbalanced. 

 

Now they ship also with a small script called bpi-bootsel (source here) which can be used to overwrite the 1st sectors of the boot media to change the display resolution (all their images based on Allwinner's 3.3/3.4 kernel for Banana Pi M2/M3 still lack support for script.bin!). In /usr/lib/u-boot/bananapi/ there exist 2 subdirs with a few handpicked archives to provide a few display configurations (details here). And while this is a small step in the right direction it also means they do it still wrong since they're continually fixing critical bugs for the M3 that should also be applied to the 1st sectors (there's where u-boot, hardware initialisation and a kernel image lives -- don't expect this stuff being easily accessible in /boot/).

 

In other words: The new OS images they provide now are already outdated and cut-off from important fixes they commit in the meantime to their BSP github repo.

 

Just a few words regarding the BSP: The initial Readme.md was just wrongly copy&paste from the Banana Pi M2 and of course misses the most important information: How to setup a build environment (details here).

 

Back to the OS images. I dropped Ubuntu 15.10 since I already have my own image upgraded (apt-get install update-manager-core && do-release-upgrade sometimes works as expected  ). 

 

Then I tried their so called "Armbian 4.7" image: It's the same outdated u-boot/kernel stuff missing the last fixes combined with a crippled Armbian rootfs. Of course nearly all Armbian features don't work and it's not worth the time to further explore this crap. They did not even adjust the thermal read-outs or prevent kernel messages from spamming to console as it will happen from time to time when thermal throttling occurs -- see their own image below.

 

 

It seems it's as with the M2 half a year ago and as a Banana Pi M3 user you'll have to wait until the community jumps in and provides OS images that aren't that crappy. Close to unbelievable but unfortunately true.

[tkaiser]

Small follow-up since now I'm really done with the device.

 

Today I soldered a barrel plug to the M3 since I had way too much sudden power-offs resulting in a corrupted SD card (only filesystem): http://forum.banana-pi.org/t/voltage-drops-on-dc-in/846  (note to myself: never ever buy any device that uses the crappy micro USB for DC-IN)

 

 

Using a sane DC-IN solution I was able to test a bit more and had to realize that it's not a bug but a feature that you're not able to clock the M3 constantly above 1.2 GHz since otherwise it would just power-off when using it in a 'normal way' (in my test scenario I had most of the times only Ethernet and a serial console connected): http://forum.banana-pi.org/t/bpi-m3-battery-charging-capability/848/12?u=tkaiser

 

Good news regarding kernel compatibility: Allwinner's 3.4.39 kernel for H3 (Orange Pi's) and A83T (the unfortunate next Banana) shares large portions of code (it seems everything that's not hardware related). So you're not totally lost (having to rely on SinoVoip) but can benefit from community's work. Today I 'stole' some of the enhancements H3 users made and applied them to the M3's BSP: http://pastebin.com/xvJ04Pi2 -- seems to work.

 

I added the stuff to the preliminary OS image I had to use last week to be able to test (all SinoVoip provided OS images broken more or less) where I also relied on the H3 community. Just have a look into the readme: http://kaiser-edv.de/tmp/2m8dxM/

[tkaiser]

Another small update regarding the M3:

 

In SinoVoip's current 'official' forum (time will tell how long it takes until they abandon this and start over with the next one like they did already before) the same question regarding the M3 will be asked again and again "How can i boot from SATA?!". Even via PM again and again. Only by people who aren't willing to accept the only possible answer "You can't. Banana Pi M3 has no SATA".

 

It's that simple: the M3 has no SATA port. Just one single USB port is used to connect all externally available USB ports and a very slow USB-to-SATA bridge through an internal USB hub. It's really that limited. So the question could've be "How can I boot from USB?" instead. And the only valid answer to that is: "Why would you? Are you insane?"

 

Every M3 comes with 8 GB eMMC that is at least twice as fast as the crappy GL830 USB-to-SATA bridge. Storing the rootfs on USB this way means slowing things unnecessarily down. On the M3 your best bet is to boot from eMMC since this is the fastest storage option you have. This is different to other incompatible SBCs that are also called "Banana Pi" that lack eMMC and where you might benefit from the rootfs stored on USB or even SATA (M1). But on the M3 the approach to boot from USB especially using the ultra-slow onboard USB-to-SATA bridge is simply moronic.

 

Next thing: Since it is not SATA but only USB you can never rely on something like 'root=/dev/sda1' since a connected USB thumb drive might be /dev/sda on the next reboot and your rootfs will never be touched since being now /dev/sdb1. To escape from that you've to use partition UUIDs instead. I documented the whole stuff already where it belongs to and won't repeat it here again to prevent uneducated users from doing harm to their installations (again: Booting from USB on the M3 is adopting a strategy suited for different SBCs wrongly).

 

The best strategy to deal with the M3's 'SATA port' is to ignore it. Performance of a connected disk is unnecessarily low (especially writes -- see above) and using the SATA-power connector to power a disk means risking sudden power-offs more often than necessary since the M3 is prone to running in undervoltage/undercurrent situations. It's strongly recommended to turn off every power savings if you try to use a HDD this way since when your M3 is busy and disk spin-up leads to another 1A peak current needed then it's time to pick your solder iron to bypass the crappy micro USB connector unfortunately being used for DC-IN.

 

BTW: I updated my RPi-Monitor template for Banana Pi M3 or let's better say A83T/AXP813 to be able to also monitor the 'cooling states': http://linux-sunxi.org/User:Tkaiser#Preliminary_RPi-Monitor_template_for_A83T

 

If you've installed RPi-Monitor already, it's enough to stop it, then do as root

cd /etc/rpimonitor/ && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-A83T.tgz | tar xzf -

restart RPi-Monitor, and you're already done (of course you should do this in a two-step process and check the MD5 checksum ef7220daadad5726b32b0d2270d4bffd first)

[maxman190]

(( I bought this before doing research on it... I encountered everything you brought up... Is it possible to burn the linux image onto emmc? Also, whenever I use the Arch Linux image that was recently released, my M3 keeps locking up and crashing. The watchdog detecting lockup on CPU 0 or something...

[tkaiser]

Is it possible to burn the linux image onto emmc? Also, whenever I use the Arch Linux image that was recently released, my M3 keeps locking up and crashing.

 

Of course it's possible to burn images to eMMC -- see above. Regarding your experiences with any of the OS images they provide: Please open one, two or three new threads in their forum asking for help.

 

They won't answer as usual since their strategy is pretty clear: Using the 'Banana' brand trying to sell as much incompatible crap as possible. You can help others to avoid your mistake (buying the M3) by creating warning threads in their forum. I already gave up to participate there since their strategy seems to work (selling hardware without software/support and waiting again for the community to fix their mistakes)

 

And be prepared: They're just liars. Now a person called 'Nora Lee' claims being the Banana Pi PM from Foxconn. That's the very same person that produced this misleading marketing crap for the Banana Pi M2: 

 

There she plays a video file being 26.2 MB in size and 5 minutes long as 'proof' that they've HW acceleration for 1080p video decoding in Linux. (details in this post). You can't believe a single word they tell. They're only interested in getting their hardware sold and don't care about anything else.

[maxman190]

Lol, so I decided to just mess around with the board using my multimeter.... I touched the negative probe to GPIO pin 2 and touched the positive probe to pin 6, the probes were like 2-4mm thick, so I accidentally touched the positive probe (while still touching pin 6) to either pin 5 or pin 8 or maybe all 3 together, then the SMD ferrite bead (https://www.dropbox.com/s/9pssmriob7prlnz/20151214_180731.jpg?dl=0) to the left of micro usb/dc power, sparked and the board won't turn on anymore...

 

Is it possible that only the ferrite bead burnt and nothing else? I think I can replace it... but even then, the schematics sinovoip posted doesn't have the values listed on the components...

[tkaiser]

Is it possible that only the ferrite bead burnt and nothing else? I think I can replace it... but even then, the schematics sinovoip posted doesn't have the values listed on the components...

 

Ask the vendor. In case they care about customer support they should answer soon. 

[maxman190]

Ask the vendor. In case they care about customer support they should answer soon. 

HAH good one.

[tkaiser]

HAH good one.

 

Please do it. Ask in the forum at banana-pi.org so others can learn what to expect from this vendor. Again and again. At least others are warned that there's no support available.

[maxman190]

Please do it. Ask in the forum at banana-pi.org so others can learn what to expect from this vendor. Again and again. At least others are warned that there's no support available.

Done. Atlhough, I'm pretty sure the person replying won't know what the schematics even do...

[tkaiser]

Another update. The 'Team BPi' seems to also monitor this thread. At least they started to adopt changes I made to the sources and published a few days ago above: http://pastebin.com/xvJ04Pi2

 

Everything from Dec 15 is just partially adopting the aforementioned stuff: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/commits/master

 

And while this is good news (they're at least able to learn a little bit) their customers can't benefit since 'Team BPi' has no online update mechanism and all these changes do not affect the rootfs but kernel/initrd living in the first sectors of SD card or eMMC. Every OS image they provided so far can't be upgraded and users are forced to reflash their media when (if?) they release new OS images containing all these fixes.

 

Their 'development style' still sucks and they still do not activate 1-Wire. That's the only company on this planet selling an SBC that is not able to use 1-Wire sensors since they don't give a sh*t about software at all. They even set CONFIG_DEFAULT_MMAP_MIN_ADDR to a value that leads to all sorts of problems when trying to use the Banana Pi M3 with a normal user account (not root) but since they neither test the crappy software they release nor care this is a problem the unfortunate customers have to deal with.

 

Since I stumbled across the most weird combination of two devices ever today (Raspberry Pi 2 with its limited I/O and network bandwidth and WD's "PiDrive" as an ownCloud self-hosting device) I had a short look on this PiDrive today (since it could've been a nice addition for an ODROID-C1+ for example -- unfortunately not true): https://community.wdc.com/t/technical-questions-regarding-pidrive/142658/1

 

To be able to compare the miserable throughput of this PiDrive (being marketed as a native USB drive by WD -- LOL!) I recompiled the RPi 4.1.5 kernel with enabled UASP (to no avail since it doesn't work) and used my usual test SSD and also the usual UASP/SAT capable enclosure with JMS567 bridge: Thanks to mainline kernel and btrfs I'm able to reach 34.5/37 MB/s (write/read) on a Raspberry Pi! Compare this with the lousy 15/30 MB/s you get with the 'SATA implementation' the Banana Pi M3 ships with.

 

And I doubt we'll ever be able to use btrfs with the M3 since mainlining efforts for u-boot/kernel are still in early stage. It's just unbelievable: Even a single core 700 MHz SBC using only one single USB port on its SoC is able to outperform the expensive Banana Pi M3 easily when it's about I/O bandwidth. 

[Guest marc]

i just paid for one , now reading all this , i just put it in the bin

[tkaiser]

they still do not activate 1-Wire. That's the only company on this planet selling an SBC that is not able to use 1-Wire sensors since they don't give a sh*t about software at all. 

 

Another funny update on the M3 (and the M2 as well, this SBC also suffers from lack of support). The reason you can not use 1-Wire sensors on both Banana Pi M2 and M3 is that the vendor has no clue how to setup settings correctly. Banana Pi M2 and M3 are the only SBCs on this planet where you can't use popular thermal sensors like DS18B20 since the vendor's software support sucks.

 

So what to do? You've to fix the problem yourself (it's easy, all that's missing is CONFIG_W1 and also CONFIG_W1_SUNXI + the driver but 'Team BPi' simply forgot to include this driver).

 

Now a user created a patch https://github.com/BPI-SINOVOIP/BPI-M2-bsp/pull/5 ( based on earlier work for the A20) for the M2 that will work also with the M3. And what is 'Team BPi' doing? Instead of merging the pull request and immediately providing a fix to their customers, they simply ignore it. As usual. They don't give a sh*t whether you can use an SBC as an SBC or as a paperweight. But since their customers also don't care it's just another example for a great business model.

[Guest Massimo M.]

Thanks! I would use this board for a HEVC mediaplayer. 

Without support is a crap!

[maxman190]

Another funny update on the M3 (and the M2 as well, this SBC also suffers from lack of support). The reason you can not use 1-Wire sensors on both Banana Pi M2 and M3 is that the vendor has no clue how to setup settings correctly. Banana Pi M2 and M3 are the only SBCs on this planet where you can't use popular thermal sensors like DS18B20 since the vendor's software support sucks.

 

So what to do? You've to fix the problem yourself (it's easy, all that's missing is CONFIG_W1 and also CONFIG_W1_SUNXI + the driver but 'Team BPi' simply forgot to include this driver).

 

Now a user created a patch https://github.com/BPI-SINOVOIP/BPI-M2-bsp/pull/5 ( based on earlier work for the A20) for the M2 that will work also with the M3. And what is 'Team BPi' doing? Instead of merging the pull request and immediately providing a fix to their customers, they simply ignore it. As usual. They don't give a sh*t whether you can use an SBC as an SBC or as a paperweight. But since their customers also don't care it's just another example for a great business model.

Ugh... Since I already the board and I can't return it, I tried to make the best of it.... I tried all their images for M3, for some reason I can't detect any temperature on anything on the board, does M3 not capable of sensing the temperature? Since I'm new to this whole Linux thing, what do you do with the config files that is in the Github? Do you compile it yourself to make your own Linux image? It's fine if you don't have the time to give me the details, but I'd appreciate if you can point me the right direction, like what to google and stuff.

[tkaiser]

The A83T used on the M3 has an internal temperature sensor and I provide RPi-Monitor templates to monitor this stuff (see above).

 

Regarding useable OS images from 'them': well, they suck more or less and you won't see Armbian support anytime soon for any device based on A83T. Why don't you try to get support from the vendor? Why don't you push them to provide something more useable? Why do all the M3 users accept that they bought an expensive paperweight and do not complain publicly so others could learn to avoid the so called 'Banana Pi' M2/M3?

[maxman190]

The A83T used on the M3 has an internal temperature sensor and I provide RPi-Monitor templates to monitor this stuff (see above).

 

Regarding useable OS images from 'them': well, they suck more or less and you won't see Armbian support anytime soon for any device based on A83T. Why don't you try to get support from the vendor? Why don't you push them to provide something more useable? Why do all the M3 users accept that they bought an expensive paperweight and do not complain publicly so others could learn to avoid the so called 'Banana Pi' M2/M3?

I would try to push them, but I see you and a few other members trying to do that as well on their website, but it didn't seem to do anything. You guys have more credibility and more knowledge than I do, so I figured that it would be pointless for me to complain.

[tkaiser]

I would try to push them, but I see you and a few other members trying to do that as well on their website, but it didn't seem to do anything. You guys have more credibility and more knowledge than I do, so I figured that it would be pointless for me to complain.

 

If users don't start to complain again and again publicly nothing will change. Foxconn/SinoVoip will happily advertise false features (they've no problems to spread lies as long as people are tricked into believing them and buy their hardware) and trust in the community to fix their mistakes over time.

 

The only useable OS distributions for everything they shipped after the M1 (Lamobo R1, Banana Pi M2 and now Banana Pi M3) are not provided by them but by community members. And since they're no team players and do not only refuse to cooperate but actively hold back necessary informations regarding their hardware again and again this has to stop. They know for example Armbian is the only OS image that really works on the M2 and the best Debian based for the M1(+) and R1. And what do they do? Instead of donating to the Armbian project they produce a shitty Armbian rip-off for the M3 to damage Armbian's image.

 

But since none of their customers really complains their business model (selling incompatible crap as 'Banana Pi') works perfectly.

[Tido]

@maxman190   because you already have device. Be persistent, do not give up and write every couple of days about your specific problems with your favorite image.

 

Either you start a fresh topic with your favorite image-name or continue with that one.

@lionwang   @BPI_Justin (coder)  @noralee (product mgr)

 

remember you must be stubborn 

[tkaiser]

Either you start a fresh topic with your favorite image-name or continue with that one.

 

Better create new threads every day. Like @sinovoip does: This account floods the forums with outdated/useless crap he/she found somewhere else on the net just to let threads that contain criticism disappear...

 

This is the only way others could learn that there's something wrong with R1/M2/M3 and that people stop buying this unsupported hardware. And only if that happens Foxconn/SinoVoip would change their priorities.

[tkaiser]

Just another update. The Foxconn/SinoVoip marketing staff is really convinced that M3 customers must be morons. It seems they produced a new camera module for the various Banana Pi variants and to showcase the capabilities they promote a video that is downscaled to 320x240 pixels and even then artefacts can be seen when trying out the camera in Android:

 

http://forum.banana-pi.org/t/banana-pi-bpi-m3-test-ov8865-camera-with-android-image/959

 

I would've never thought that it might be even worse than with the M2 but they prove me wrong

[kometchtech]

is init=/bin/systemd is not enabled, this is a known issue?

 

http://forum.armbian.com/index.php/topic/342-dbus-error-when-using-systemctl/

[tkaiser]

is init=/bin/systemd is not enabled, this is a known issue?

 

 

Sorry, what are you're talking about? I ask since Banana Pi M3 isn't supported by Armbian yet and I doubt that will change anytime soon.

[kometchtech]

Sorry, what are you're talking about? I ask since Banana Pi M3 isn't supported by Armbian yet and I doubt that will change anytime soon.

thought associated with the following errors occur when you attempt to run the systemctl command, so all the previous threads.

 

Failed to get D-Bus connection: Unknown error -1

[tkaiser]

thought associated with the following errors occur when you attempt to run the systemctl command, so all the previous threads.

Failed to get D-Bus connection: Unknown error -1

 

Again: What are you talking about? Armbian does not support Banana Pi M3. If you use the insanely broken Armbian rip-off 'Team BPi' provides then please ask them what they fucked up (but since they fucked up so many things in all of their crappy OS images they obviously have no clue which skills they lack   )

[tkaiser]

Another update on the great 'development efforts' 'Team BPi' shows. A few hours ago they finally managed to add 1-wire support to their kernel tree for the Banana Pi M3.

 

Missing 1-Wire support was brought to their attention several times through their forums in the last months, a user provided the necessary driver as pull request for the M2 back on 3rd Dec., it took them only 24 days to merge this pull request (hard work you know?), and then just additional 19 days to get the idea to activate 1-wire for Banana Pi M3 also.

 

What does this mean for unfortunate M3 customers already using their OS images? Simply nothing since 'Team BPi' still provides no kernel/u-boot update routines. Most probably they will release a couple of new fishy OS images the next days/weeks that suck not that much any more. But it's still close to unbelievable they don't provide an online update routine so users can benefit immediately from fixes to their BSP they commited on Github.

 

We've told them so many times how easy it is to achieve this but they still don't care about anything else than selling their hardware and tricking users into believing some sort of development/support progress would be made.

 

Same with the issue kometchtech brought to our and their attention (adding "init=/bin/systemd" to the bootargs which is necessary for every OS image that makes use of systemd -- and these are a lot). This is something they should've to adjust in sunxi-pack/chips/sun8iw6p1/configs/*/env.cfg but they refuse to and provide countless crappy OS images that all do not fully work instead.