return and return, select BPI-M2+, about 81min it complete
i get the image ‘Armbian_5.14_Bananapim2plus_Ubuntu_xenial_3.4.112.raw’ at ‘output/images’
then i dd it to tf card
cd output/images
sudo dd if=Armbian_5.14_Bananapim2plus_Ubuntu_xenial_3.4.112.raw of=/dev/sdb bs=10MB
sudo eject /dev/sdb
it runs well on BPI-M2+, root’s default password is 1234, we can change it to bananapi, and create a new user pi with the same password.
81 minutes is quite long but a few other Armbian devs did a great job to reduce that on subsequent runs. I just let a Jessie desktop image rebuild for BPi M2+ (we add now Wi-Fi/BT firmware as Debian package so that it can be easily upgraded later using apt-get update|upgrade):
This is 7 minutes including rebuilding the whole kernel and creating a complete OS image from scratch including desktop environment (server images run below 3 minutes). Now Bluetooth should work on BPi M2+
For testing purposes we support FEL boot (see documentation) on all supported sunxi devices. So no need to burn an SD card at all if you just want to test something out. Simply choose the FEL option, let an image build, connect your Board and it will boot via USB/NFS.
Our build system does not only support BPi M2+ but also M1, M1+, M2 and Lamobo R1 (except of M2 both with legacy and vanilla/mainline kernel)
For desktop images with full HW acceleration we currently only support Jessie due to dependency hell (will be extended to Xenial soon)
We tried many times to convince ‘Team BPi’ that they should start to adopt our build system (instead of creating crappy OS images by taking just Armbian rootfs) since quality of the OS images would automagically improve. To no avail as usual…
As a beginner, I try to understand part of what you said.
Armbian developers do a lot of great work.
I compile slow for many reasons, such as virtual machines, download the dependent packages, etc., my network environment is not very good.
This is just the first attempt, the future will continue to focus on Armbian.
That’s the reason our build system is caching almost everything (compile cache, apt cache, cached rootfs) and that’s why a first run might take 80 minutes but subsequent runs when you choose same distro and kernel variant might then run less than 5 minutes for the same task
mikey at allwinner , and maybe fixed this issue, driver all include at before image version, just for application layer have some issue, we need to let it work fine .
