Hello,
I am an owner of a Banana PI M3. I think someone may benefit from the step-by-step tutorial that I created to remove the Micro USB DC adapter and solder a barrel connector. It’s available here:
https://techcornerweb.wordpress.com/
I am also running some interesting experiments on the board and I will share the results of them later - to anyone interested.
Thanks for reading!
Regards, DA
very cool DIY , thank you for your cool work.
Your guide and blog looks very pro! Maybe You would be that smart enough so You could help sinovoip to create first fully functional Linux release for BPI-M3 ? 
I am still awaiting for video HW encode and Kodi… 
Regarding your goals:
- try to see if it was possible to port either Fedora24 or Centos7 to it, and then 2) try to setup a Xen or KVM host on it.
is simple (Team BPi does this around the clock to flood the forums with countless baidu and google drive links to OS images no one is satisfied with). Use any of their most recent OS images as basis and simply exchange mmcblk0p2 with any armhf rootfs you find on the net
is (currently) impossible since you chose one of the few sunxi boards without community support 
Mainlining efforts for A83T are far behind given how long this SoC is already available. You would need at least an u-boot version that brings up the SoC in Hyp mode (here you’re lucky since mainline u-boot 2016.05-rc3 contain basic support for A83T and BPi M3) and a more recent kernel than the crappy 3.4.x version @sinovoip ships with (and no, please don’t believe them a single word if they start telling jokes like “we’re working on mainline kernel” – this whole work is done by a few members of the linux-sunxi community)
In case you want to start prior to 2017 with virtualization better choose another board instead.
Addendum: The best choice currently would be the 2GB DRAM Pine64+ version. While this board also comes with crappy Micro USB for DC-IN it can also be powered absolutely reliable through GPIO pins too
There Allwinner’s provided BSP kernel is at 3.10.65 (we at Armbian patched this kernel up to the latest 3.10.y LTS version and longsleep commited all our patches to his kernel fork) and fully supports virtualisation: http://irclog.whitequark.org/linux-sunxi/2016-03-22#15869575;
Hi tkaiser, I’ve been reading you for a while. You are technically good and I agree with most of what you said, although often your tone is questionable
Regarding the kernel. I do not believe in anyone - not just Sinovoip - but really, no one. Seriously now. I am a former Red Hat employee and I do know few things about backporting patches.
The kernel released by Sinovoip is not a vanilla 3.4.x Linux kernel. It’s just the original Allwinner Android kernel. Despite that, I managed to backport all the A83t drivers to vanilla 3.4.112 - that wasn’t a problem. The problem is that Android changes some of the core kernel interfaces, specifically, I am stuck with the interface provided by the following files:
linux-3.4.112/lib/kobject.c linux-3.4.112/net/core/fib_rules.c linux-3.4.112/kernel/sched/sched.h linux-3.4.112/kernel/futex.c linux-3.4.112/kernel/printk.c linux-3.4.112/arch/arm/kernel/perf_event.c linux-3.4.112/mm/page_alloc.c linux-3.4.112/mm/vmscan.c linux-3.4.112/kernel/events/core.c linux-3.4.112/kernel/sched/rt.c linux-3.4.112/kernel/time/timekeeping.c
And I also have minor issues in the following files:
linux-3.4.112/net/ipv4/ping.c linux-3.4.112/net/netfilter/xt_socket.c linux-3.4.112/include/linux/ipv6.h linux-3.4.112/drivers/usb/host/xhci-pci.c linux-3.4.112/drivers/usb/host/xhci-ring.c linux-3.4.112/net/ipv6/reassembly.c linux-3.4.112/security/selinux/hooks.c linux-3.4.112/drivers/md/dm-crypt.c linux-3.4.112/fs/file_table.c
Doing a reverse-backport Android->Vanilla 3.4.39->Vanilla 3.4.112 - does not work on these sources. I think it’s doable anyway. But using only my free time it will take a while before I will achieve anything.
I will write more in the second part of my Banana PI M3 post. You can message me privately if you want more information.
Thanks, DA
Looking forward to that. In my very personal opinion none of the available octa-core SBC is great or even worth a look/buy. Their only purpose seems to attract people that judge solely by looking at specs on paper and completely forget about the software side and thermal issues all these boards are plagued with.
I thought again about this since it makes not that much sense that you’re doing this alone. Allwinner’s BSP/Android kernel for H3 and A83T is almost the same but around the H3 fork there exists a broader community (not here of course – all what’s happening here is the manufacturer not answering support questions, instead posting fake videos showing non-existing features or a crappy new non-functional OS image every few days and a few clueless users left that are happy with that).
In case you’re interested please have a look http://forum.armbian.com/index.php/topic/1380-h3-kernel-repo/ for example. The basis is a newer BSP kernel variant (I would suppose that @sinovoip got the same from Allwinner for BPi M3) and at least there the community is actively working with these kernel sources (me not that much, I’m keen to get mainline kernel working on H3)
Hi,
I had had a look at the github repo. Basically, they went down the same route of overlaying a vanilla 3.4.112 with the Allwinner Android patches as me - including mods for stuff unrelated to sunxi:
./fs/block_dev.c 9c103ce407a6e925c4e1b71e58f42e4b 30202c34207 < ./fs/btrfs/Makefile 46a57561e4b534cbfa6ddad5d87a9248
./fs/btrfs/Makefile 3a2f4e697c988bfcbfbeb4666d0c6777 30268c34273 < ./fs/cifs/cifsacl.c 00b2992a50cfce4aefe38a47be72d50a
./fs/cifs/cifsacl.c ba4c7fb77676a74940882b5869c24ff7 30281c34286 < ./fs/cifs/cifs_spnego.c b1a38be88021738020f72703aad278ab
./fs/cifs/cifs_spnego.c 38c44caac31ae71d66acdf4fc6b8b551 30312c34317 < ./fs/cifs/transport.c 30cf93eb4aa49399c521a20f155cca1d
./fs/cifs/transport.c 30c2e6da2067523d28eb7c65cc1ff9aa 30421c34426 < ./fs/eventpoll.c c7f18212e41f1f2f6315e478539d4009
./fs/eventpoll.c c278229a607fc2ac6063e446dc09e913 30500c34505 < ./fs/ext4/ialloc.c cdd4a6e825d980a557e97452bc8cea7a
./fs/ext4/ialloc.c 077bee13f745d0cc643cf65660a87b25 30502c34507 < ./fs/ext4/inode.c 0d63da920d3baeacfa8d2a9edd7bb72a
./fs/ext4/inode.c 06a93e67527198eed245fab3a9b8647e 30513c34518 < ./fs/ext4/resize.c 90b9b6944b5c828d1ea87390fd50dffc
./fs/ext4/resize.c 172ddc537562ba6e2a43e3bb5b47275b 30523c34528 < ./fs/fat/dir.c f4f940d47d6d0e6375a0d05f5189fb84
./fs/fat/dir.c 524de048811171e6bc17b8afca496112 30525,30528c34530,34543 < ./fs/fat/fat.h c6da72af55cffddfca92daed21aded62 < ./fs/fat/file.c f6bd1c6168356b4ea93f063e27314396 < ./fs/fat/inode.c 3ce480f811bfdccf87b3c672603cbf79
Nothing wrong with that - it’s actually the quickest way to achieve something. Things can always be refined later when you’ve got something working. But I wonder how you guys reconciled the situations where Allwinner Android kernel substantially diverges from vanilla kernel interfaces, like in mm/page_alloc.c or kernel/events/core.c. Did you evaluate on a case by case? Or just tried to stick with vanilla? Or with the Allwinner Android? Analyzing the consequences of either choice is non trivial, and it’s precisely where I got stuck. The alternative is just try both and make a guessestimate of which choice is more likely to work with the least effort. Did these discussions take place somewhere? Any chat or forum?
Thanks, DA
http://linux-sunxi.org/sunxi:Community_portal
The linux-sunxi community focuses more on mainline kernel while the H3 ‘sub community’ tries to deal with what’s currently available: And that’s mostly just the 3.4.x Android kernel while mainlining efforts are still progressing nicely (not that true regarding A83T). And depending on the use case different people focus on different kernels (since I’m ok with headless / server use mainline support for H3 is almost perfect, for the older sunxi SoCs support is even better)
Anyway it’s useless to discuss development stuff here