BPI-M3 new image:bpi-m3 Ubuntu 16.04 Beta Mate

You weren’t kidding. Not even nano is installed, /etc/fstab is empty, and the Ubuntu port sources are downloading from .tw. These are just the first 3 things I stumpled upon, before pulling out my sdcard again for another format.

I know this says “beta” but this won’t do. And I’m pretty annoyed that I have to reinstall an image every time there’s a slight update to things.

I think I’ll stick to @tkaiser’s modified 15.04, even though 15.04 is EOL when it comes to support from Ubuntu. Perhaps a 15.10 image could be arranged if we all ask nicely, or maybe even a 16.04 LTS image could be arranged when it comes out on April 21st?

If not, then I guess I’ll end up buying an RPI3, and go back to having a USB hub running for the hard drive. This is not worth the hassle and the Welsh are just better at it.

You could try to build a community Xenial distro for M3. @bruberg seems experienced enough to help.

Using Armbian’s build system you could create a rootfs that can be combined with a freshly created image relying on Allwinner’s A83T BSP. If you follow Armbian’s instructions and by doing a


you get a whole image no one has tampered already. Then you would mount this image, edit and remove some stuff this way:

LOOP=$(losetup -f)
losetup $LOOP /path/to/Armbian.raw
partprobe $LOOP
mount ${LOOP}p1 /mnt/

(adjust the contents as outlined below) and then

umount /mnt/
losetup -d $LOOP

You would alter /mnt/etc/default/cpufrequtils to use 480/1800 MHz, create /mnt/root/.machine.id that it reads “Banana Pi M3”, remove /mnt/etc/apt/sources.list.d/armbian.list (since Armbian’s kernel updates are useless and u-boot updates would destroy the bootloader) and also /mnt/boot and /mnt/lib/modules.

Then do a ‘cd /mnt && tar armbian_rootfs.tar *’, mount the 2nd partition of the M3 image, delete there everything except of boot/, lib/modules/ and lib/firmware/ and untar the created archive. Then you have an image that has never been booted, that will ask for a new root password on first boot, that will regenerate SSH keys on first boot (if you use any of SinoVoip’s OS images this doesn’t happen – think about if you connect your board to the internet :wink: ), that will resize the partition automagically on first boot, that redistributed IRQs accross CPU cores, that has armbianmonitor ready and so on.

It might even be possible to build an OS image with full HW acceleration. You will need probably some binary stuff for the PowerVR GPU you find in latest SinoVoip images and you might be able to benefit from hw accelerated video decoding through Cedrus/Vdpau since maybe the minimal support patch for A64 already ‘unlocks’ A83T (H3, A64 and A83T share the same IP here but maybe a different cedrus_get_ve_version version). In case you want to try it out better choose ‘BUILD_DESKTOP=yes’ above since then all of our accelerated armhf desktop packages become part of the image.

And in case you really look into it you could also teach SinoVoip how to produce an OS image that can be flashed through FEL mode. Simply combine the adjusted Armbian rootfs with these instructions: Build Livesuit Image for BPI-M3 to burn via phoneixsuit

It’s really that easy, I just tried it out with a virgin jessie rootfs on the base of the last image for M3 I published:

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

Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.42-BPI-M3-Kernel 

System load:   4.72            	Up time:       7 min		Local users:   2            	
Memory usage:  14 % of 2011Mb 	IP:  
CPU temp:      73°C           	
Usage of /:    5% of 59G    	

Last login: Thu Apr 14 17:22:19 2016 from macbookpro-tk.fritz.box
tk@bananapim3:~$ sudo -s
[sudo] password for tk: 
root@bananapim3:/home/tk# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
17:33:45: 1608MHz  4.92  17%   7%   8%   0%   1%   0%   73°C
17:33:50:  480MHz  4.93  18%   7%   8%   0%   1%   0%   73°C
17:33:55:  480MHz  4.61  17%   7%   8%   0%   1%   0%   66°C
17:34:00:  480MHz  4.32  17%   7%   8%   0%   1%   0%   65°C
17:34:05:  480MHz  4.06  17%   7%   8%   0%   1%   0%   64°C
17:34:11:  480MHz  3.81  17%   7%   8%   0%   1%   0%   64°C
17:34:16:  480MHz  3.59  17%   7%   8%   0%   1%   0%   64°C
17:34:22: 1608MHz  3.86  17%   7%   8%   0%   1%   0%   71°C
17:34:27: 1608MHz  3.95  18%   7%   8%   0%   1%   0%   71°C
17:34:33: 1608MHz  4.60  18%   7%   8%   0%   1%   0%   70°C^C
root@bananapim3:/home/tk# grep processor /proc/cpuinfo 
processor	: 0
processor	: 1
processor	: 2
processor	: 3
processor	: 4
processor	: 5
processor	: 6
processor	: 7

Whole boot log (you can see automatic rootfs expansion and so on): http://sprunge.us/SXBE

While transferring this new semi Armbian image over SSH to burn it on eMMC I was reminded that SinoVoip chose to NOT fix this bug I reported ages ago so time to limit maximum clockspeed to 480 MHz (network transmissions break otherwise, it’s not the eMMC)

In case you try this with a Xenial rootfs please think about adjusting the paths to script.bin/uEnv.txt in u-boot scripts to point to /boot/ instead. Then you’re able to choose resolution (and also switch between HDMI/DVI) easily using h3disp afterwards.

Oh please do upload it somewhere. I’m having compile issues at the ./compile.sh -step, and I’m pretty sure the VirtualBox will explode at some point.


No support, no guarantees, this is an ‘official’ image from SinoVoip not containing their latest AXP fixes with replaced Armbian 5.07 rootfs and the aforementioned tweaks. I would expect that no video/3D HW acceleration works but as headless server it should perform good.

Login with root/1234

You will then be asked to change the root pwd and to create a new user account. Many of the stuff outlined in our documentation applies to this rootfs: http://www.armbian.com/documentation/

But please keep in mind that this is not even 50% Armbian since kernel/u-boot are from M3 BSP and you get only normal Debian packages via online updates but not the most important parts. But as already said: The contained rootfs can be used to create a nice image (even from a security point of view if you forget how horrible Allwinner’s 3.4.39 kernel is and how many fixes are missing :wink: )


Kernel update and so on is possible by downloading manually a few Debian packages from https://github.com/BPI-SINOVOIP/BPI-files

You need the following three and install all of them using ‘dpkg -i’


Then kernel/u-boot aren’t exchanged yet but you have to do this

bpi-bootsel /usr/lib/u-boot/bananapi/bpi-m3/BPI_M3_720P.img.gz

And then you can simply use bin2fex/fex2bin (contained in Armbian) to convert/modify script.bin (eg. fixy the ‘average load above 1’ problem or enable DVI displays, configure better throttling). The stuff can be found below /usr/lib/u-boot/bananapi/bpi-m3/linux/ and needs a reboot after modifications.


And again: Of course it doesn’t work this way: There’s a syntax error that prevents loading the correct script.bin (reported back 6 weeks ago but as usual @sinovoip doesn’t give a shit) and the whole stuff has to be copied onto the first partition since they try to read from there.


mount /dev/mmcblk0p1 /mnt/ cp -rp /usr/lib/u-boot/bananapi/bpi-m3 /mnt/bananapi/

Then fix the 8th line in /mnt/bananapi/bpi-m3/linux/uEnv.txt so that it reads ‘script=script.bin’ and make adjustments to /mnt/bananapi/bpi-m3/linux/script.bin instead. After a reboot it should finally work.

1 Like

Thumbs up, you’re quite a hero :slight_smile:

However, I decided to give it a retry and use a 64bit VirtualBox instead. I got a little further this time, but I’m stuck on these errors: [ o.k. ] Creating board support package [ orangepih3 ] [ o.k. ] Fingerprinting [ Armbian 5.07 Orangepih3 Ubuntu xenial default Linux ] [ o.k. ] Building package [ linux-xenial-root-orangepih3 ] [ o.k. ] Starting build process for [ orangepih3 xenial ] [ o.k. ] Creating new rootfs for [ xenial ] [ o.k. ] Installing base system [ Stage 1/2 ] I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id 790BC7277767219C42C86F933B4FE6ACC0B21F32) I: Retrieving Packages I: Validating Packages I: Found packages in base already in required: locales I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Checking component main on http://localhost:3142/ports.ubuntu.com... E: Couldn't find these debs: debconf-utils [ error ] ERROR in function create_rootfs_cache [ debootstrap-ng.sh:173 ] [ error ] Debootstrap base system first stage failed [ o.k. ] Process terminated [ error ] ERROR in function unmount_on_exit [ debootstrap-ng.sh:559 ] [ error ] debootstrap-ng was interrupted [ o.k. ] Process terminated

I’ve installed debconf-utils via apt-get, but something tells me that’s not the solution. Is it because localhost:3142/port.ubuntu.com (and thus Xenial) doesn’t have debconf-utils?

Thx for bringing that to our attention. Fix follows, in the meantime please exchange ‘–include=debconf-utils,locales’ with ‘–include=locales’ in


and try again. BTW: In /usr/local/bin/sun8i-corekeeper.sh this should be adjusted (since A83T is octa core and since Armbian doesn’t support the M3 we install this for the quad core H3 only)

    for c in 0 1 2 3 4 5 6 7 ; do

BTW: I ran some benchmarks on this Armbian/SinoVoip hybrid with Armbian’s THS, dvfs and cooler_table settings. First runs seemed 30% faster compared to Raspbian 8.0.

I soldered back in Dec a barrel plug to the M3 to prevent sudden shut-offs due to undervoltage under high load – compare with http://linux-sunxi.org/Banana_Pi_M3#Sudden_shut_offs_.2F_maximum_consumption_.2F_cooling_vs._consumption

Unfortunately all PSUs with this connector were already in use so I switched back to powering through Micro USB. Now the board freezes somehow under heavy load when consumption exceeds 9W. Not really an improvement but at least different to back then. I still wonder whether it’s possible to power the M3 through GPIO pins. At least the ‘documentation’ doesn’t mention it.

So always ensure you avoid Micro USB if you want to run heavy workloads on the M3. And I won’t test further since it’s useless anyway :slight_smile:

Thanks for the fix!

I ran into a few minor errors while installing the base system, where some packages wouldn’t be installed. But I managed to force it with apt-get -f in debootstrap-ng.sh, and it worked fine. Worth a mention is, that it failed to install two packages, but debootstrap.log doesn’t mention which ones, and I can’t remember. No worries, it will probably just make my M3 explode :wink:

Now, for the “mount the 2nd image of the M3 image”-part. Can I use your Semi_Armbian image instead of compiling a whole new image from SinoVoip (and possibly ruin the process because of Murphy’s Law)?

Sure can you use it. But be aware that the installation of SinoVoip’s .debs still has to happen after the first boot (hard to automate since they constantly refuse to do it right or just to look how everyone else does it) and you should add /dev/mmcblk0p1 as /boot to /etc/fstab (just search inside’s Armbian’s lib dir how a correct entry would look like) when manipulating the base image. And also /etc/hostname should be changed (will read now orangepih3 in your case).

Sorry lionwang but he is the only person here who is helpfull with M3, your company did NOT even post correct images ever since… You can ban me if you wish, but I will never buy anything from you again! M3 was a mistake… M1+ is great but again only because it is supported by community… I had found more resources there than on your pages…

But hey I love M3, as a geek I have really cool paperweight :slight_smile:

1 Like

In fact unlike these pages here you find correct informations about Bananas ONLY on the linux-sunxi community pages: http://linux-sunxi.org/Main_Page

It’s now the fourth time I write this in threads that are read by @noralee, @projectbananapi, @sinovoip and @lionwang that they still provide wrong information regarding the newest Banana: M2+ has not two but one led and doesn’t support CAN bus. What do they? Simply giving a shit. They do not even correct such easy to fix mistakes: http://www.banana-pi.org/m2plus.html (still wrong, they only corrected the other obvious mistake and now M2+ is 65x65mm and not 55x55mm in size any longer)


It is more like none of us are trying and double checking information. I will go correct the specs again. We should have a place on our forum dedicated to website mistakes. That will make corrections faster.

It’s alive… IT’S ALIVE!

After installing those 3 debs and correcting a smaller error I had made in /etc/fstab, it’s now running flawlessly. Thanks for all the help and tips. I’ll be sure to save this page as a reference for future builds, as I have no intention of doing this once. However, the building process will be a wee bit different now that SinoVoip have finally made steps towards upgrading the ancient-as-f*ck u-boot?

Anyway, thanks again!

PS: Yes, the M3 is in dire need of a heatsink.

1 Like

Sorry, but do you really don’t get what’s wrong with that? Normally users should be able to rely on correctness of information provided by the vendor. Mistakes might happen from time to time and that’s not that much of a problem.

With SinoVoip it’s different for reasons unknown to me (I really don’t get it why they don’t try to improve in this area). You can not trust in any ‘information’ provided by them since they obviously haven’t set up processes to ensure writing correct documentation. You realize again and again that something normally called ‘product documentation’ is simply copy&paste gone wrong.

Look at this: [BPI-M3] how to use fatload uEnv.txt & script.bin & kernel uImage

This is maybe the most important software change they ever made since it would allow users to simply change stuff where they had to recompile the whole BSP from Github before. But as usual: The instructions are crippled/wrong/insufficient, it’s obviously not tested and of course it doesn’t even work.

The instructions already highlight the error:


will be defined but later not $scrip but $script will be used. It can NOT work unless fixed. And they don’t care even if someone in the forums points directly out what’s wrong. And it has been always like this since they simply don’t care about correctness of information. So you simply have no chance to provide correct information on the website since such thing does not exist here.

Same with the moronic thermal/THS settings that lead to ultra low benchmark scores for M2+ – they simply don’t care about doing it right. Led even to some media attention recently: http://www.cnx-software.com/2016/04/15/software-matters-how-did-sinovoip-cripple-banana-pi-m2-performance/

1 Like

we also have do many “bad” working . but we still work on it.

even you see orange pi have any R&D to do something??? it depend armbian and other open source user ,they just do many hardware. not do software. why you always to support they ,but not support us??

or you want we do nothing .just do a hardware for you.like orange pi???

open source project need open mentality. we just want your support and tolerant, let us make it better .

I bought a M3 and now I´m trying to find a use for it. Maybe i´ll put it to run Plex Client or Retropi to my kids (better than a paperweight).

I´m using your modification of the armbian distro. I would like to ask if there is any way to make the onboard wifi adapter to work. I´m not a Developer, but I have some experience in Linux.

Tks very much…