Sinovoip Banana Pi M3
Banana Pi M3 is a A83T based development board produced by Sinovoip.
Despite its name, the M3 is incompatible to previous Banana Pi boards (Banana Pi/M1/M1+/Pro/M2/M2+), due to a different SoC - requiring different boot loaders and drivers. It's another attempt to cash in on the Banana Pi's popularity with a SBC only sharing brand, name,
form factor and GPIO header.
|Info to Nora Lee: Please stop doing the marketing spam and join #linux-sunxi on freenode (IRC) to talk about why this edit was reversed the second time. If you keep changing info to untrue facts, your account will get blocked.|
|Sinovoip Banana Pi M3|
|Dimensions||92 mm x 60 mm|
|Release Date||Nov 2015|
|Website||M3 product page|
|SoC||A83T @ 1.2-1.8Ghz|
|DRAM||2GiB LPDDR3 @ 672 MHz (SK hynix)|
|NAND||8GB eMMC 4.5 (Samsung KLM8G1GEAC-B001)|
|Power||DC 5V @ 2A DC-IN via µUSB or barrel jack, solder pads for LiPo battery|
|Video||HDMI (Type A - full), MIPI/DSI|
|Audio||3.5mm TRRS/OMTP plug (stereo+mic), HDMI, on-board microphone|
|Network||BT4.0/WiFi 802.11 b/g/n (Ampak AP6212), 10/100/1000Mbps Ethernet (Realtek RTL8211E)|
|Storage||µSD (max 64GB), eMMC, SATA 2.0 (via GL830 USB-to-SATA bridge, +5V power on JST XH 2.5mm connector)|
|USB||1 µUSB 2.0 OTG and an internal Terminus Technology Inc. 4-Port HUB feeds 2x USB 2.0 Type-A ports and the SATA bridge|
It's an SBC with blue PCB silkscreened "BPI-M3" in white where you can easily recognise A83T/AXP813 on the PCB's top side.
All OS images the manufacturer provides are based on Allwinner's 3.4.39 kernel. Mainlining efforts for the M3's A83T SoC just started so things won't improve that soon.
- Official download page with M3 section containing various Linux images based on kernel 3.4.39
- Android 5.1.1 image provided by SinoVoip
All the OS images are based on u-boot 2011.09 and kernel 3.4.39 using an initrd and do not provide script.bin/uEnv.txt support.
3 Months after releasing the first OS images the situation still hasn't improved. SinoVoip fixed some stuff in their Github repo but still doesn't provide a way to apply these updates to existing OS images. As the result of a quick try to let Armbian support the M3 (nope) here is an archive BPI-M3-3.4.42_uEnv_Script_bin.zip (md5sum 360a32fe9d470296abebc4af0825acc9) containing boot-resource.fex, boot.img, env.fex, u-boot.fex and 3.4.42-BPI-M3-Kernel.tar. It can be used to cure all available OS images for Banana Pi M3 (and for other A83T/H8 devices also I would suspect). It contains all BSP fixes for the M3 up to Feb 2016 and also a higher kernel version. To use it unpack the archive, choose an OS image $image as target and then do
dd if=u-boot.fex of=$image bs=1k seek=19096 dd if=boot-resource.fex of=$image bs=1k seek=36864 dd if=env.fex of=$image bs=1k seek=69632 dd if=boot.img of=$image bs=1k seek=86016
Mount afterwards the 2nd partition of the image and unpack 3.4.42-BPI-M3-Kernel.tar below /lib/modules. You should then be able to create uEnv.txt and script.bin on the 1st partition (a weird howto available in the official Banana Pi forum)
No support in the community maintained sunxi-3.4 kernel is planned. Allwinner's kernel sources for the A83T can be found now here.
The manufacturer uses an u-boot.2011-something version without support for script.bin
Use the Sinovoip_BPI_M3_defconfig (supported since v2016.03) build target.
Since the M3's bsp uses an aging u-boot from 2011 no script.bin support exists therefore you've to adjust display settings in the fex file. Some can be found in SinoVoip's M3 repo.
Use the sun8i-a83t-bananapi-m3.dtb device-tree file for the mainline kernel.
Tips, Tricks, Caveats
The BPi-M3 features 3 LEDs located between IR receiver and microphone: A red one indicating power that can't be turned off and a green and blue one accessible through sysfs after latest fixes are applied to kernel sources and hardware initialisation.
Both green and blue LED can then be controlled through sysfs and appear below /sys/class/leds/. To show the available triggers do a
cat /sys/class/leds/green_led/trigger and set this to none if the default heartbeat blinking annoys you. Since the timer trigger also exists BananaLEDd should be useable to show disk activity and average load (to be confirmed) since BananaLEDd supports LEDs accessible through sysfs starting with version 1.2
Be aware that the A83T SoC used on the M3 isn't SATA capable and therefore the SATA port is provided by a cheap USB-to-SATA-bridge. This means you can neither expect SATA performance nor full SATA functionality and the used chip is also known to be buggy and reporting the disk size wrong. While the used GL830 bridge supports S.M.A.R.T. attributes it does not support S.M.A.R.T. status notification (overall health indicator of the disk – instead of PASSED or FAILED you will only get SMART Status not supported: Incomplete response, ATA output registers missing). Fortunately the GL830 seems to have no 2TB limitation.
Expected SATA performance is even worse compared to Orange Pi Plus that relies on the same old GL830 chip since on the M3 all externally available USB host ports and the SATA bridge are connected through the internal hub to one single USB port and therefore have to share bandwidth. First tests don't look that promising: tests done with a fast SSD/ext4 at two different clockspeeds: 13/23 MB/s @ 480 MHz vs 15/30 MB/s @1800 MHz write/read. Using an external Micron JMS567 that is known to get close to 40 MB/s sequential transfer speeds @ 1800 MHz exceeded 35/34 MB/s write/read with same SSD/ext4. It seems the GL830 wasn't the best choice to provide a SATA port on the M3.
The u-boot button triggers FEL mode.
Allwinner's kernel for H3 and A83T seem to implement identical thermal throttling strategies depending on fex settings that can be read out through sysfs: /sys/devices/virtual/thermal/thermal_zone0/trip_point*. If these values are set in incremented order first throttling will occur and only if this still doesn't help CPU cores will dropped. By tuning these settings you might get the opposite of what's intended: a slower system due to less available CPU cores.
With Allwinner's kernel there's also something like fan control implemented. Below /sys/devices/virtual/thermal/cooling_device0/ you can read out cur_state that will be adjusted depending on fex settings between 0 and max_state.
Without a heatsink you won't exceed 1.2GHz when running CPU intensive tasks, when choosing a good one and enough airflow you might get up to 1.6 GHz and everything above needs an annoying fan. The good news: This is still no overvolting/overclocking since it's just about better heat dissipation to avoid throttling. The bad news: You need to solder a sane way to provide more than 5V/2A to the board -- see below.
USB 2.0 Hosts
In opposite to CubieBoard5, the M3s hardware design does not make use of all USB connections offered by the SoC (A83T).
The HSIC port is connected to the Terminus Technology Inc. 4-Port USB hub. On this hub is attached the USB-to-SATA bridge and the 2x available USB Type-A ports. Therefore these 3 connectors have to share the bandwidth of a single USB2.0 connection.
1x OTG MicroUSB
It seems that the hub's fourth port is routed to solder pads located between onboard microphone and GPIO header.
Powering the board / exchanged DC-IN connector
The pre-production samples of this board had the usual 4.0/1.7mm barrel jack for DC-IN BPi M2/M2+ also use. This has been replaced by a Micro USB jack on the first production batch in Dec 2015 leading to the usual sorts of problems banana-pi.org forums are full of (see also next paragraph for some reasons). Starting in May 2016 Micro USB has been replaced by the 4.0/1.7mm barrel jack again so powering is possible more reliable now. The Micro USB receptacle on the longer board side is USB OTG, also connected to the board's PMIC and while looking like an alternative way to power the board that's not recommended unless you love underpowering situations, reboot loops and the like.
In case you're unlucky enough to own an M3 from the first production batch have a look at the gallery below where to measure / fix undervoltage/undercurrent problems you'll run into sooner or later.
Sudden shut offs / maximum consumption / cooling vs. consumption
In case you experience shut offs when connecting peripherals or operating the device under high load have a look at the gallery below where to measure and where to solder a fix. This is especially recommended when you want to make use of the promised performance (octacore @ 2.0GHz according to the manufacturer). If you use the device without heatsink consumption through CPU cores will seldom being able to exceed 4W-5W since thermal throttling will decrease clockspeeds automagically and dynamic voltage frequency scaling (dvfs) will then also reduce Vcore.
With an applied small heatsink and outside of an enclosure under constant full load the A83T will jump between 1008 MHz and 1200 MHz due to thermal throttling. At the latter cpufreq Vcore will be already set to 920mV while being set to 840mV at 1008 MHz:
Under these conditions CPU activity is responsible for the board consuming between 5.5W-6W. If you improve heat dissipation by using a large heatsink or even a fan you will let thermal throttling jump in later with drastical consequences.
Due to the dvfs settings Vcore will be increased to 1000mV or even 1080mV when reaching 1800 MHz. And then CPU activity alone is responsible for a whopping 8W consumption. And while this might work in a test environment with just a serial console attached it can't work in a normal environment with a connected display, a few USB peripherals and a connected disk needing another 4-5W exceeding 12W easily. Micro USB is rated 5V/1.8A max: 9W or maybe 10W under best conditions (most likely due to crappy USB cables the board's PMU will diagnose undervoltage way earlier and shuts down).
In case you improve heat dissipation be prepared for shut-offs unless you solder a sane DC-IN solution and use 5V/3A at least (won't help with micro USB due to the tiny contacts)
Booting from different device
Using the BSP and the OS images SinoVoip provides it's only possible to boot from /dev/mmcblk0p2 (compare with /proc/cmdline). To change that you've to grab the BSP and adjust sunxi-pack/chips/sun8iw6p1/configs/*/env.cfg to be able to boot using NFS or USB (please remember: the M3 has no SATA any more, just an ultra-slow onboard USB-to-SATA bridge). If you try to adjust root= to point to any USB location always keep in mind that device nodes might not be persistent across reboots therefore always use the partition UUID instead. In case you want to boot from a partition that's currently mounted as /dev/sda1 do a gdisk -l /dev/sda1 and use the UUID it prints, eg.: root=PARTUUID=1A40C346-C1F0-4613-B3AB-1FA3C6B6F343. Don't use the output of blkid, these aren't the partition UUIDs!
Please always keep in mind that booting from a connected SATA disk behind the GL830 is the worst idea ever since every BPi M3 ships with 8GB onboard eMMC which is more than twice as fast as any disk behind the slow GL830 bridge.
HDMI to DVI converters
When trying to use HDMI to DVI converters with Allwinner's 3.4.39 kernel a small fix has to be applied. The contents of sysconfig.fex have to be adjusted (and the whole BSP has to be rebuilt since there's no support for script.bin) so that the following has been added to the [hdmi_para] section:
hdcp_enable = 0 hdmi_cts_compatibility = 1
Since the A83T/R58/H8 has only support for MIPI/DSI to drive LCD displays none of the available LVDS/RGB LCDs sold for older incompatible Banana Pi variants can be used. SinoVoip sold a 7" TS LCD panel since summer 2015 with just 800x480 pixels that's also incompatible to the Banana Pi M3 since it's also using LVDS/RGB as interface. In the meantime SinoVoip provides a new variant of this 7" LCD with a controller board featuring both MIPI/DSI for the M3 and LVDS/RGB for M1/M1+/M2. Of course they re-used the same article in their aliexpress shop so be prepared that reviews/ratings found there are for the older variant and not the current one.
In case WiFi isn't working (reliably) with an external antenna that's an intentional feature of this board. Don't try to fix it in software unless you desoldered a small resistor on the PCB (that's not a bad joke but an official suggestion obviously not taking into account that different PCB revisions exist)
ESD & over-current protections
Based on the schematic Rev 1.1 (October 16, 2015) the board incorporates the following protections:
x - no protection, ESD - Electrostatic Discharge, OC - Over-current
|1||DCIN & Micro USB (power)||x||x||A ferrite bead with a power supply bypass capacitor|
|2||Micro SD||ESD||OC||Over-Current protection provided by U5?|
|5||USB1||ESD||OC||Over-Current protection provided by U6?|
|6||Dual USB2||ESD||OC||USB Hub current limited by U7?|
|7||Additional 2-pin USB||ESD||N/A||This is just a 2-pin connector on PCB|
|9||SATA (power)||x||x||Power is routed directly from power DCIN/Micro USB connector|
|12||Ethernet||x||N/A||Over-current protection is not applicable|
|15||Audio jack||ESD||N/A||Output current is internally limited by SoC|
Adding a serial port
Locating the UART
The UART header is between u-boot button and the Ethernet port. Just attach some leads according to our UART howto.