tkaiser

Since the question came up a few days ago on linux-sunxi IRC and Igor2 provided a nice tutorial to activate Ethernet Gadget mode, I added the necessary one-liner patch to our repo (disabled by default) and built now a kernel with all the necessary stuff patched and enabled: http://kaiser-edv.de/tmp/4U4tkD/Armbian_3.4.112_g_ether_kernel.tar.bz2
 
To get the idea please read through Igor2's Readme: http://igor2.repo.hu/tmp/opi_usb_gadget.txt
 
You should run a recent Armbian installation (apt-get update/upgrade), then extract the contents of the tar archive above somewhere, install the stuff using dpkg and then reboot:
tar xf Armbian_3.4.112_g_ether_kernel.tar.bz2 sudo dpkg -i linux-*.deb sudo reboot Then to be able to use the OTG as Ethernet Gadget device I found that we need a slight modification (since it's not /sys/bus/platform/devices/sunxi_usb_udc/role but /sys/bus/platform/devices/sunxi_usb_udc/otg_role):
echo -n 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role modprobe g_ether echo -n 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role Et voilà: In the very same moment the MacBook that powers the BPi M2+ I test with notified me that a new network device appeared and this looks like:
bash-3.2# system_profiler SPUSBDataType [...] RNDIS/Ethernet Gadget: Product ID: 0xa4a2 Vendor ID: 0x0525 (PLX Technology, Inc.) Version: 3.33 Speed: Up to 480 Mb/sec Manufacturer: Linux 3.4.112-sun8i with sunxi_usb_udc Location ID: 0x14200000 / 5 Current Available (mA): 500 Current Required (mA): 2 BSD Name: en6 So from now on I can use the H3 board as network interface en6
 
If you know how to benefit from something like that (eg. using an USB powered NanoPi M1 -- BPi M2+ is simply too expensive -- as encrypting network device, eg. for offloading OpenVPN stuff), please try the aforementioned stuff out and report back.
 
I wonder whether we should not enable this one-line patch and the appropriate kernel config by default...

Since the question came up a few days ago on linux-sunxi IRC and Igor2 provided a nice tutorial to activate Ethernet Gadget mode, I added the necessary one-liner patch to our repo (disabled by default) and built now a kernel with all the necessary stuff patched and enabled: http://kaiser-edv.de/tmp/4U4tkD/Armbian_3.4.112_g_ether_kernel.tar.bz2
 
To get the idea please read through Igor2's Readme: http://igor2.repo.hu/tmp/opi_usb_gadget.txt
 
You should run a recent Armbian installation (apt-get update/upgrade), then extract the contents of the tar archive above somewhere, install the stuff using dpkg and then reboot:
tar xf Armbian_3.4.112_g_ether_kernel.tar.bz2 sudo dpkg -i linux-*.deb sudo reboot Then to be able to use the OTG as Ethernet Gadget device I found that we need a slight modification (since it's not /sys/bus/platform/devices/sunxi_usb_udc/role but /sys/bus/platform/devices/sunxi_usb_udc/otg_role):
echo -n 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role modprobe g_ether echo -n 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role Et voilà: In the very same moment the MacBook that powers the BPi M2+ I test with notified me that a new network device appeared and this looks like:
bash-3.2# system_profiler SPUSBDataType [...] RNDIS/Ethernet Gadget: Product ID: 0xa4a2 Vendor ID: 0x0525 (PLX Technology, Inc.) Version: 3.33 Speed: Up to 480 Mb/sec Manufacturer: Linux 3.4.112-sun8i with sunxi_usb_udc Location ID: 0x14200000 / 5 Current Available (mA): 500 Current Required (mA): 2 BSD Name: en6 So from now on I can use the H3 board as network interface en6
 
If you know how to benefit from something like that (eg. using an USB powered NanoPi M1 -- BPi M2+ is simply too expensive -- as encrypting network device, eg. for offloading OpenVPN stuff), please try the aforementioned stuff out and report back.
 
I wonder whether we should not enable this one-line patch and the appropriate kernel config by default...

Next try. This time I did not use the BPi M2+ (read as: any H3 device featuring an OTG port!) as transparent bridge between its Ethernet and the USB OTG port but configured a working connection between OTG port and USB port of my MacBook using a static IP configuration. On BPi M2+ I used this interface file:
 
 
 
This results in somewhat weird settings (hwaddress being ignored) but since everything's working fine I don't care that much:
 
 
 
Again approx. 115 Mbits/sec iperf throughput when using a short (AWG20 rated) USB cable between both devices. I also tried out my 'well known crappy cable' (I use normally to demonstrate how bad Micro USB for DC-IN is). This is 1m long instead of 20cm and throughput here is just 109 Mbits/sec (no transmission retries shown via ifconfig so it seems there's either a lower layer involved to verify data integrity or it's just latency due to cable length)
 
Potential use cases:
Simple wired interconnection: You have an OPi Lite and don't want to use an Ethernet dongle: Make the Lite the dongle. In g_ether mode all that's needed is connecting the Lite via USB to a second device and the Lite appears there to be an external USB-Ethernet adapter. You get transfer speeds that slightly exceed Fast Ethernet just using a simple USB cable USB-to-Ethernet adapter: Use an NanoPi M1 or BPi M2+ as external USB-to-Ethernet dongle (needs bridging -- see above). Both boards can be powered through the Micro USB OTG port (but then you have to take care to limit max cpufreq to approx 600 MHz to not exceed 500mA consumption. Or you use a device known to provide more amperage: USB3 ports have to provide 900mA and with Apple MacBooks from 2012 or younger you get 1100mA on the USB ports) Wi-Fi dongle: Using the same method you can attach any OPi Lite (or any of the other boards having a Wi-Fi interface) via USB to a host and using a bridged connection between wlan0 and usb0 the H3 SBC starts to act like a WiFi dongle. The last 2 use cases above are pretty boring or even weird. Now the fun stuff:
Use a cheap H3 device like OPi One between a slow router and the internet to offload VPN encryption (zador came up with this link a few weeks ago. You get the idea even just by looking at the pictures) Use a cheap H3 device as secure VPN endpoint (allow accesses to your VPN only when they originate from a sealed H3 device that will be used as Ethernet adapter from Windows machines... where tampering/installing software might not be allowed by an IT department or you simply can't trust them) Use Linux' transparent proxy support to implement an ad filter on a cheap H3 device between host and Internet (pretty easy using eg. squid and the gazillions of available tutorials) I'll have to test that with Windows soon since a customer of us has the problem that their centralized IT department doesn't allow installation of any software on their road warrior's laptops, they've to deal with a web based application that can't be fixed right now due to IT weirdness but the whole problem seems solveable by providing a bunch of NanoPi M1 that act as intelligent network devices (providing 3G access and fixing the web application on the fly through a transparent proxy approach -- it's just exchanging half a million article numbers )
 
BTW: NanoPi M1 and BPi M2+ start when powered through the Micro USB OTG port. On every Orange there's a switch in between that needs a small tweak: http://blog.atx.name/orange-pi-pc-first-impressions/ (Orange Pis also accept DC-IN through the Micro USB port but won't start so unless you fix that you need to provide DC-IN either through the barrel jack or GPIO pins)

In the meantime I found a 2nd use case: Using NanoPi M1 as Ethernet dongle doing fancy network stuff (for example handing this out to others to force them connecting them to their local network only through the H3 Ethernet dongle to ensure an uncompromised VPN endpoint for example)
 
NanoPi M1 could be powered reliably through an USB computer port given a short USB cable with low resistance is used and some settings are adjusted to ensure consumption never exceeds 2.5W which is possible limiting CPU clockspeed to 600 MHz for example (500mA should be provided at 5V --> 2.5W)
 
Why NanoPi M1 instead of small Oranges? Since the latter would require a little hardware tweak to power on when connected to an USB computer port through their OTG port: http://blog.atx.name/orange-pi-pc-first-impressions/

Post #6.
 
 
What do you plan to do with the M1? Using it with a 5MP camera module? I ask since this is still the only use case or why to buy a NanoPi. To be honest: Apart from the camera module NanoPi M1 with 1GB DRAM is almost identical to Orange Pi PC but the latter is faster (due to better voltage regulator and better overall heat dissipation limiting throttling situations) and costs less even when shipping is also considered. I still feel I'm overseeing something.
 
BTW: Regarding French Post I made some (pretty bad) experiences. My daughter moved to Montpellier last year and it was always 'adventure time' sending her parcels

Another "funny" use case: use OTG port for FEL, loading u-boot, kernel, initramdisk and few other files, then in initrd script configure g_ether and use rootfs on NFS through USB link.

I think there should be some trade-offs somehow. That maybe why Wens suggested me to look at the "dynamic overlays" path, where basic pins will be present in mainline DT, but not activated a special peripherals until some overlays would be loaded.

Next try: I removed the line from /etc/rc.local and added usb0 to /etc/network/interfaces as outlined here (assigning a static MAC address and changing the port role to OTG from within the 'pre-up' condition). I also added creation of br0 bridge device containing both eth0 and usb0:
root@bananapim2plus:~# cat /etc/network/interfaces.g_ether auto lo iface lo inet loopback # Wired adapter #1 auto eth0 iface eth0 inet dhcp auto usb0 iface usb0 inet dhcp hwaddress ether 82:bc:09:47:28:a9 pre-up /bin/sh -c 'echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role' auto br0 iface br0 inet dhcp bridge_ports eth0 usb0 (beware: this way the device itself won't be reachable via IP from the network since DHCP will fail with this configuration and it's just a transparent bridge between eth0 and usb0). The usb0 NIC on the Linux side appears as en6 on my MacBook when connected through USB:
bash-3.2# ifconfig en6 en6: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 6a:95:6f:ac:30:2b inet6 fe80::6895:6fff:feac:302b%en6 prefixlen 64 scopeid 0xe inet 192.168.83.200 netmask 0xffffff00 broadcast 192.168.83.255 nd6 options=1<PERFORMNUD> media: autoselect (10baseT/UTP <full-duplex>) status: active bash-3.2# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.83.1 UGSc 13 0 en6 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 8 10366 lo0 169.254 link#14 UCS 0 0 en6 192.168.83 link#14 UCS 2 0 en6 192.168.83.1/32 link#14 UCS 1 0 en6 192.168.83.1 bc:5:43:be:c1:e1 UHLWIir 14 506 en6 1169 192.168.83.200/32 link#14 UCS 0 0 en6 192.168.83.245 0:c:29:9c:17:3a UHLWIi 1 306068 en6 1200 So time to test raw throughput to another GBit connected OS X machine (192.168.83.245): ~115 Mbits/sec in both directions. This is the limitation of the g_ether device since BPi M2+'s GBit Ethernet device eth0 isn't here the bottleneck (680/930 Mbits/sec between BPi M2+ and the Mac Mini). So network performance of the g_ether device slightly outperforms a Fast Ethernet port (below 100 Mbits/sec). Nice.

...has been reduced to $5 maybe due to some public poking

We should stop talking about Samsung SoCs when it's Nexell instead: http://forum.armbian.com/index.php/topic/1409-sysbench-quick-cpu-perf-amd64-phenom2-pine64-xu4-a20/?view=getlastpost

Hi @tkaiser,
 
Unfortunately, this task isn't finished ...
First, all my patches have been submitted to linux-sunxi mainline almost 3 months ago and nothing is merged yet.
Several reasons lead to that : patches format, email issues, email headers corrupted, this last one is been solved/workarounded recently : Maxime Ripard told me that my tests using "git send-email" worked but earlier tests with "msmtp" didn't. I should now resend my patches soon as "v5"...
Then, still the goal of the patches : kernel gurus which to avoid to beef up DTS, want to keep them as little as possible, claiming it take time to parse it (ridiculous statement here since we are not using 8bits MCU), and peripherals such I2C/SPI should not be enabled on all boards by default, stealing GPIOs (well, there so much GPIOs, is that really important to save them ?). @Wens suggested me strongly to go with overlays like C.H.I.P guys did.
So, this is a new task for me : getting familiar with Dynamic Overlays loaded from UserSpace !
I will have to study that , recompile new kernel of the OF flag, tests, overlay prototypes, etc.
I hope to met expectation, especially that "time is the missing ingredient" !
 
Ciao !

Thx for firmware and instructions. @slinde and/or @markbirss: Please remember that fex file should be exchanged (and reboot in between) and one minor tweak should also be applied, see my last comment: https://github.com/igorpecovnik/lib/commit/60e935b34e3ed8b2ed14cf812fc30b08506b1651#commitcomment-17864605
 
EDIT: F*ck, we're moving really quick! So I think @Igor has to add the firmware bits to the specific package (and then please also change the USB detect mode since we're then finally done with X2)

You're using sysbench (calculating prime numbers, on some CPUs with optimized engines -- eg. NEON/ARMv8 -- on some not). Sysbench can not be used to compare different architectures (unless your job is to calculate prime numbers, then this might matter for you since you get your prime numbers in less time). Do a simple google search for
sysbench kitchen sink site:armbian.com

Hi all,
 
since we're currently collecting tasks to be done by community to get a nice board (OPi Plus 2E) in return I thought I sum up where we currently are regarding working H3 OS images with mainline kernel:
 
Our main showstoppers for releasing H3 images with mainline kernel are still: missing/non-working THS stuff (see explanation here), native Ethernet driver not finished and a few minor bits.
 
My last attempt to check situation has been a few days ago. Since megi rebased his THS stuff (also containing the various USB and Ethernet patches) I chose his 4.6 branch to give it a try (see commit 224550b). Unfortunately I ran into kernel panics when testing on my OPi PC Plus and so I gave up again.
 
But since we got another report (see below, issue #360) trying out the stuff on both OPi One and PC and reporting different/interesting results in the meantime I believe this THS stuff should be solveable quite easily and it's just one missing bit here or there. So this would be a great opportunity for someone claiming a task to finish:
 
Get kernel 4.6 (or even better 4.7-rc) up and running including the following:
Ethernet (required) USB, leds, serial and so on (required and works already since this is just .dts stuff) THS (required -- please also see issue #360)) WiFi (nice to have but then please both 8189ETV/8189FTV -- both patches for our legacy kernel are backported from mainline versions so it should be rather simple) HDMI (nice to have) SPI, I2C (nice to have, IIRC @martinayotte has everything up and running with 4.x already?) Anyone?   Edit: THS update: http://irclog.whitequark.org/linux-sunxi/2016-06-13#16729515;

Just successfully tested another Realtek usb wifi dongle with the OPI ONE. Both AP and managed mode work as decribed for 0bda:0179 Realtek Semiconductor Corp. in instructions.
 
lsusb
 
Bus 001 Device 009: ID 0bda:8179 Realtek Semiconductor Corp. ( noname identified as 8188EU )
 
Aliexpress Link : http://www.aliexpress.com/item/1pc-Mini-USB-WiFi-Wireless-802-11-n-g-b-150M-LAN-Adapter-Network-Card/32292872916.html

Hi all,
 
since we're currently collecting tasks to be done by community to get a nice board (OPi Plus 2E) in return I thought I sum up where we currently are regarding working H3 OS images with mainline kernel:
 
Our main showstoppers for releasing H3 images with mainline kernel are still: missing/non-working THS stuff (see explanation here), native Ethernet driver not finished and a few minor bits.
 
My last attempt to check situation has been a few days ago. Since megi rebased his THS stuff (also containing the various USB and Ethernet patches) I chose his 4.6 branch to give it a try (see commit 224550b). Unfortunately I ran into kernel panics when testing on my OPi PC Plus and so I gave up again.
 
But since we got another report (see below, issue #360) trying out the stuff on both OPi One and PC and reporting different/interesting results in the meantime I believe this THS stuff should be solveable quite easily and it's just one missing bit here or there. So this would be a great opportunity for someone claiming a task to finish:
 
Get kernel 4.6 (or even better 4.7-rc) up and running including the following:
Ethernet (required) USB, leds, serial and so on (required and works already since this is just .dts stuff) THS (required -- please also see issue #360)) WiFi (nice to have but then please both 8189ETV/8189FTV -- both patches for our legacy kernel are backported from mainline versions so it should be rather simple) HDMI (nice to have) SPI, I2C (nice to have, IIRC @martinayotte has everything up and running with 4.x already?) Anyone?   Edit: THS update: http://irclog.whitequark.org/linux-sunxi/2016-06-13#16729515;

Thanks for at least some encouragement While you (tkaiser) are absolutely focused on headless systems, others might be on desktop/graphics. So at least for them this will be interesting for a while. I will join you with maintaining desktop version shortly. If I want to make Kodi working with libvdpau-sunxi, Armbian is much nicer platform to develop on and I can help you with squashing some bugs in the meantime. Currently I'm a bit short on time, but I will contribute for sure.

Since I listed the history of different BSP kernels and settings a few posts above and have been asked by a fellow what's different between a recent Armbian Xenial desktop build and for example this OS image here based on loboris' build script... I thought: let's give it a try.
 
First big surprise: All the overheating issues we thought would've been resolved are still there in an OS image released a few weeks ago!
 
This image uses the insane overvolting settings from loboris so H3 is all the time fed with at least 1.3V and jumping up to 1.5V (see on the left the Vcore values). This way it's ensured that even when the board is totally idle SoC temperature will be close to 60°C (I've a heatsink applied to my Orange Pi PC Plus I tested with so be prepared that without a heatsink it gets even worse):
 

 
I installed RPi-Monitor and let the thermal fix script do its job to cure the installation:
root@OrangePI:~# wget -q -O - http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-h3.sh | /bin/bash Installing RPi-Monitor. This can take up to 5 minutes. Be patient please [x] done Checking and installing sunxi-tools if not available [x] done Patching RPi-Monitor to deal correctly with H3 [x] done Now you're able to enjoy RPi-Monitor at http://192.168.83.156:8888 root@OrangePI:~# wget -q -O - http://kaiser-edv.de/tmp/H9rWPf/fix-thermal-problems.sh | /bin/bash Trying to fix thermal settings on this board. This might take a few seconds up to 3 minutes. Please be patient. Starting now. Done Successfully repaired broken overvolting/overclocking settings. Reboot necessary for changes to take effect root@OrangePI:~# reboot Afterwards the VDD_CPUX voltage switched fine grained, temperatures looked better but of course this is still far from perfect since in loboris kernel the 1.3 GHz cpufreq step is missing so now with the sane settings maximum cpufreq isn't 1536 MHz but 1200 MHz.
 
I made also quick sysbench runs using 'sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4' (these are the three temperature peaks you see in the graph above):
Insane overvolted settings allowing 1536 MHz max: 116.3053 seconds After applying thermal fixes allowing 1200 MHz max: 117.9727 seconds And finally after rebooting the board into the normal Armbian installation allowing 1296 MHz max: 109.2925 seconds Since I refrain from using an annoying fan both the insane overvolted settings and the sane known as 'bronco settings' perform identical which is absolutely no surprise since with loboris overvolted settings H3 overheats way too early and therefore throttling is more heavy than with sane settings. Running with Armbian performance increases automagically since we optimized also our kernel settings and allow way more cpufreq steps (interested in details? Then read from here on)
 
I wanted to test other stuff (GPU/X11) but unfortunately loboris kernel not only misses the 113 patches we apply to the newer BSP kernel (just a few hundred security fixes still missing between 3.4.39 and 3.4.112) but also essential USB HID drivers eg. for my Apple keyboard and mouse so I wasn't even able to login. I then thought about replacing the old kernel with our latest Armbian kernel:
 
 
 
But to no avail since after converting our kernel image to the uImage the outdated u-boot on all the older OS images expects I rebooted and our kernel paniced since I failed to provide a way to look for the rootfs: http://pastebin.com/ehyk1XhQ
 
Anyway: I won't waste any more time with this since it's just crazy to use an image based on a horribly outdated 3.4.39 kernel lacking so much fixes and features. I could confirm that the most recent version of the GC2035 camera driver we included in Armbian yesterday is way better than the one included in this/loboris image, that thermal/performance settings still suck, no support for Wi-Fi on the new Oranges there, no access to eMMC (though it should work with loboris install_to_emmc script but I haven't tested since I don't want to wipe out my nice Armbian installation on eMMC) and so on.
 
Since I also don't know which real world applications make use of OpenGL ES (apart from irrelevant benchmarks and some games where it seems to be confirmed that Armbian's switch to the new BSP kernel and clocking Mali 400 with 600 MHz increases performance by 30%) I saw also no need to further waste time with testing other images. But as usual: YMMV

I'm glad to give something back to Armbian.

Banana Pi M2
PS: I don't use the latest Armbian toolchain. I'm using the .ignore_changes feature.
root@m2-bare:~# uname -a Linux m2-bare 4.5.4-sunxi #2 SMP Sat Jun 11 13:05:21 CEST 2016 armv7l GNU/Linux root@m2-bare:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 17: 0 0 0 0 GIC-0 29 Edge arch_timer 18: 11870 265608 31223 36550 GIC-0 30 Edge arch_timer 21: 0 0 0 0 GIC-0 50 Level sun4i_timer0 22: 0 0 0 0 GIC-0 83 Level sun5i_timer0 27: 0 0 0 0 GIC-0 82 Level 1c02000.dma-controller 28: 1653 0 0 0 GIC-0 92 Level sunxi-mmc 29: 8549 0 0 0 GIC-0 94 Level sunxi-mmc 30: 27 0 0 0 GIC-0 104 Level ehci_hcd:usb1 31: 0 0 0 0 GIC-0 105 Level ohci_hcd:usb2 40: 2251 0 0 0 GIC-0 60 Level sun4i-ts 41: 425 0 0 0 GIC-0 32 Level serial 42: 43646 0 0 0 GIC-0 114 Level eth0 48: 0 0 0 0 GIC-0 72 Level 1f00000.rtc 57: 0 0 0 0 sunxi_pio_edge 4 Edge 1c0f000.mmc cd 181: 43 0 0 0 sunxi_pio_level 0 Level brcmf_oob_intr IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 3407 15690 13225 7318 Rescheduling interrupts IPI3: 6 8 3 6 Function call interrupts IPI4: 0 0 0 0 CPU stop interrupts IPI5: 0 0 0 0 IRQ work interrupts IPI6: 0 0 0 0 completion interrupts Err: 0 root@m2-bare:~#

I did another test over night with 624MHz. It pretty much looks the same.
 

Beelink X2 running "lima-memtester 100M" and the setting "dram_clk = 648". Grey background entire time, but only running 1 core at end--it is possible that I messed up the heatsink when I opened it up to solder serial out.

Here is the result of my Beelink X2 running "lima-memtester 100M" and the setting "dram_clk = 648". Test went well, cube was spinning with grey background the whole time. I can see it disabled one cpu-core after about 30min.
 

Since we're now dealing with a few more H3 devices and some vendors also provide OS images and users get confused a small note regarding kernel situation with H3 at the moment and also an update regarding performance relevant settings (by tweaking these intelligently H3 devices might run multiple times faster!).
  Mainline kernel:   The linux-sunxi guys are doing a great job writing all the stuff necessary from scratch and sending it upstream so that H3 and boards are more and more supported by the stock linux kernel available from kernel.org. For us at Armbian the missing Ethernet driver for H3 was the showstopper that prevented us releasing Armbian images with kernel 4.x so far.    In the meantime or since we had to realize how horribly some H3 boards might overheat (BPi M2+ is currently the worst example but it turned out that NanoPi M1 and Beelink X2 behave the same) missing THS support in mainline kernel is another important reason that prevents Armbian releases for H3 boards. We tried to run the boards downclocked to just 816 MHz just to realize recently that BPi M2+ with specific test workloads has to throttle down to 240 MHz (and needs to kill CPU cores so under worst case conditions we could drive the M2+ only with 2 cores at 240 MHz which is a really bad joke -- so we need throttling working with mainline kernel to release Armbian vanilla images to the public)   BSP kernel:   So while we're testing with mainine kernel stuff from time to time all we now have to release to endusers are some variants of Allwinner's Android kernel for H3 devices (called BSP kernel -- BSP is for 'board support package', that's an ugly tarball with an 3.4.39 kernel Allwinner throws at manufacturers who want to create H3 devices).   Allwinner's 1st BSP kernel variant:   Allwinner published 3.4.39 Android kernel sources last year here. All the official OS images for Orange Pis rely on this stuff (still version 3.4.39 and not even a fix for the rootmydevice security issue). This BSP variant also shows somewhat strange throttling settings (not throttling down while still running on all 4 CPU cores but killing CPU cores one after another without bringing them ever back without a reboot). So be prepared that you get horrible performance results with these settings (that explains the horribly low performance scores that are published on phoronix.com for various H3 based Orange Pi boards)   Loboris' kernel:   The aforementioned kernel sources are basically the stuff Boris Lovosevic (loboris) used to provide the first useable OS images for Orange Pis. He did a really great job fixing tons of issues (eg. enabling GBit Ethernet on OPi Plus or 1-Wire, camera support and so on). Unfortunately he was member of team overclocking so with his so called dvfs settings (dynamic voltage frequency scaling) the Oranges were overvolted (to be able to provide overclocking) and showed all sorts of strange symptoms (insanely high temperatures and stability issues). But this wasn't related to kernel functionality, just settings influencing power supply to the SoC/CPU and enabled overclocking.   Yann Dirrson's fork:   When we at Armbian started supporting H3 boards we relied on different kernel sources (ssvb, one member of the linux-sunxi community used Allwinner's original BSP sources, patched Mali support in to create a small OS image being able to test DRAM reliability. Another linux-sunxi guy forked this kernel tree and patched in a few more stuff (also some of loboris' great work) so we started using this fork as our basis.   1st Armbian legacy kernel:   Igor immediately started to patch the horribly outdated 3.4.39 kernel up to the most recent 3.4.y version (3.4.110 back then IIRC) and we threw in a bunch of other patches to improve this and that. Also as the result of still ongoing efforts to maximize performance/throttling settings Armbian shipped with totally different thermal settings which led in the end to pretty good performance of the boards (since we refrained from overvolting and developed sane settings)   Alwinner's 2nd BSP kernel variant:   When FriendlyARM announced their H3 based NanoPi M1 they also released a newer H3 user manual and also a new BSP kernel variant they obviously both got from Allwinner in the meantime. Jernej maintaining the unofficial H3 OpenELEC fork looked immediately through and spotted a lot of changes.    2nd Armbian legacy kernel:   So we (Armbian and jernej/OpenELEC) decided to switch to this newer BSP kernel, Igor cleaned up some stuff and again rebased all patches (up to 3.4.112 IIRC) to the new kernel sources and we adopted all other patches that were still relevant (we could drop a few). This way we could solve the ugly kswapd bug that plagued us before (one CPU core 100% active and eating up memory) and if I understood correctly also some HDMI/display area improved a lot.   Currently only Armbian and Jernej's unofficial OpenELEC fork use this kernel with all our many patches on top (maybe a few hundred security relevant and also a lot of functionality improvements): https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default(currently exactly 112 rather large patches that add support for various hardware, new features, many fixes)   The SinoVoip experience:   While all this happened Foxconn/SinoVoip released their BPi M2+ (a close clone of Orange Pi PC/Plus) and decided to rely on loboris' unmaintained and outdated 3.4.39 kernel for whatever reasons. Since BPi M2+ doesn't use the superiour voltage regulator used on the bigger Oranges at least no overvolting/overclocking is possible here. But for yet unknown reasons this board overheats terribly so we at Armbian adjusted our throttling settings very very low so be prepared that with official SinoVoip OS images strange things might happen when you put some load on this board.   Further improvements:   In the meantime we further improved thermal/performance behaviour and patched also the kernel so that when the board recovers from heavy overheating killed CPU cores are brought back when temperatures are normal again. In addition to that we provide way more cpufreq steps to allow finetuning throttling behaviour based on environmental conditions (as example: when you're running your device in a small enclosure more throttling will occur and you will benefit from more cpufreq steps in lower regions around 900-1000 MHz. If you go the other route and add a good heatsink and some airflow through a fan Armbian will provide you with a tool able to unlook higher cpufreq steps later this year on supported boards)   Summary:   Now a short overview about kernel situation combined with thermal/performance settings: Official Orange Pi images from Xunlong: 3.4.39, no rootmydevice fix, tons of security fixes missing, performance issues after medium load due to killed CPU cores Orange Pi images from loboris: 3.4.39, no rootmydevice fix, tons of security fixes missing, thermal/stability problems due to overvolting, missing sane cpufreq steps (not possible to use 1.3GHz for example) Official Banana Pi M2+ images from SinoVoip: 3.4.39, rootmydevice fixed, tons of security fixes missing, performance issues after higher load due to killed CPU cores Official NanoPi M1 images from FriendlyARM: 3.4.39, still no rootmydevice fix, tons of security fixes missing, unknown status regarding thermal/performance settings Armbian/OpenELEC: 3.4.112, rootmydevice fixed within hours (not an issue on OpenELEC), applied all available fixes from 3.4.y LTS release, constantly improving thermal settings (which means: performance)

TL;DR: All available H3 boards do not differ that much. But the few differences sometimes really matter!
 
The following is an attempt to compare the different available H3 SBC that are supported by Armbian. The majority of boards is made by Xunlong but in the meantime two more vendors started cloning the Xunlong boards (and also Olimex is preparing H3 boards as OSHW). Both Foxconn/SinoVoip with their Banana Pi M2+ and FriendlyARM with their NanoPi M1 tried really hard to copy everything as exact as possible (the so called pin mappings -- how the many contacts the used H3 SoC is providing are routed to the outside).
  All the boards share the same 40 pin GPIO header (trying to be compatible to the newer RPi boards) and since all the other pin mappings are also 99 percent identical you can for example boot a NanoPi M1 with an Armbian image for Orange Pi PC without loosing any functionality (except of camera module) and the same applies to BPi M2+ that will boot happily an Armbian image for Orange Pi Plus 2E (except of camera module and WiFi/BT)   In fact all the various H3 boards just differ in a few details:  Amount of DRAM No, Fast or GBit Ethernet Voltage regulator and 'thermal design' (responsible for performance in full load situations) Storage capabilities (pseudo SATA and eMMC or not) Count of available USB ports (with or w/o internal USB hub) Some additional features like camera modules, WiFi/BT and additional/optional connectors (here it's important to check for driver functionality/availability. If there's no driver providing the necessary functionality then these 'additional features' are pretty much useless -- camera connector for example) Why focussing on the H3 SoC for this comparison? Since some of these boards are priced pretty competitive Mainlining support for H3 SoC and these boards is progressing really nicely so we'll be able to run these boards with mainline kernel pretty soon (thanks to the great linux-sunxi community) 2D/3D/video HW acceleration is available with legacy kernels (again thanks to the great linux-sunxi community) The feature set is nice for many use cases (quad core SoC, GBit Ethernet and 4 useable USB ports on some boards make a really nice low cost/power server) It got somewhat confusing regarding the many available Oranges and now also the cloned Banana and NanoPi This is also in preparation of a broader overview of the capabilities of all the boards Armbian currently supports now focussing on the H3 family. So let's get into details:   Amount of DRAM   That's an easy one. The H3 SoC supports up to 2 GB DRAM. The available and announced boards use either 512MB, 1 GB or 2 GB DRAM (low-power DDR3L on the bigger Oranges and DDR3 on OPi One/Lite, BPi M2+ and NanoPi M1). In case you're using Armbian it simply depends on the use case. And also it's necessary to understand that Linux tries to use all your RAM for a reason: Since unused RAM is bad RAM. So don't be surprised that Armbian will eat up all your RAM to cache stuff which improves performance of some tasks but the kernel will immediately release it when other tasks have a demand for it. If still in doubt please enjoy http://www.linuxatemyram.com.   If you want to use your boards with the unofficial H3 OpenELEC fork too please be aware that OpenELEC benefits from at least 1 GB RAM since then the whole filesystem remains in memory and no accesses to a probably slow SD card happen. Prior to jernej/OpenELEC and Armbian resolving the kswapd bug a few weeks ago the 512 MB equipped boards performed rather poor. But now it seems that the unofficial OpenELEC fork runs pretty well also on the boards with less available RAM.   Whether 1 vs. 2 GB RAM make a difference absolutely depends on the use case and no general recommendations can be made.   Since OpenELEC has been mentioned it should be noted that the current implementation of the unofficial OpenELEC port for H3 boards makes use of the cedarx-license-issues-library (no clear license preventing the use if you care about legal issues -- please have a look at http://linux-sunxi.org/Kodi for further details)   Networking:   The H3 SoC contains an Ethernet implementation that is capable of 10/100 MBits/sec Ethernet and also GBit Ethernet. A PHY (that handles the physical interconnection stuff) for Fast Ethernet is already integrated into the H3 SoC but to be able to use GBit Ethernet an external GbE capable PHY is needed (the RTL8211E used on all boards adds approx 1.2$ to the costs of the board in question).   Most H3 boards use the internal Fast Ethernet PHY so wired networking maxes out at ~95 Mbits/sec. Orange Pi Plus, Plus 2, Plus 2E and BPi M2+ provide GBit Ethernet (+600 Mbits/sec with legacy and exactly 462 Mbits/sec with mainline kernel) while Orange Pi Lite saves an Ethernet jack at all. The good news: Even with the Lite you can use wired network adding a cheap RealTek USB3-Ethernet dongle like this which is confirmed to exceed 300 Mbits/sec in a single direction.   The currently available boards have either no WiFi (NanoPi M1, OPi 2 Mini, One and PC), rely on RealTek 8189ETV (OPi 2, Plus, Plus 2), the newer RealTek 8189FTV (OPi Plus 2E, Lite, PC Plus) or a WiFi/BT combination: AP6181 is used on the BPi M2+ but the vendor didn't manage to get BT working at the time of this writing. Currently only jernej's OpenELEC fork and Armbian have a working driver included for the new 8189FTV chip on the fresh Orange boards that seems to perform quite ok and provides client/AP/monitor mode. Can't say that much about that since in my very personal opinion all these 2.4GHz onboard WiFi solutions are simply crap   Voltage regulator and 'thermal design':   This is a very important differentation: All Orange Pi boards use a programmable voltage regulator to adjust the voltage the SoC is fed with. The SY8106A used on every Orange except of One and Lite can be controlled though I2C and adjusts the so called VDD_CPUX voltage in 20mV steps. This is important since 'dynamic voltage frequency scaling' relies on the principle of providing less voltage to the SoC/CPU when it clocks lower. So when the board is idle also the supplied voltage will be reduced resulting in less consumption and also less temperature.   Since H3 is somewhat prone to overheating being able to adjust VDD_CPUX is also important when we're talking about the opposite of being idle. The SY8106A equipped Oranges reduce very fine grained the core voltage when they start to throttle down in case overheating occurs under constant heavy load. As a direct result they will automagically perform better since reducing VDD_CPUX voltage also reduces temperature/consumption so both CPU and GPU cores in H3 due not have to throttle down that much.   Quite the opposite with BPi M2+. For whatever reasons SinoVoip saved put a the same programmable voltage regulator on their board as OPi One, Lite and NanoPi have but does not implement voltage switching so H3 there will always be fed with 1.3V. In addition it seems 'Team BPi' didn't take care of heat dissipation through PCB design (it seems Xunlong added a copper layer to the PCB that helps dramatically spreading the SoC's heat) and so with BPi M2+ (and NanoPi M1 too) you have to be prepared that you need both a heatsink and a fan to let this board perform under full load since otherwise heavy throttling occurs or when you use a kernel that does not implement throttling (4.6/4.7 right now for example) be prepared that H3 gets either destroyed or will crash through overheating if you run something heavy on BPi M2+ or NanoPi M1. We're still investigating whether this crappy thermal behaviour might be related to DRAM also (DDR3 vs. low power DDR3L on the Oranges) It seems this thermal behaviour is not that much related to the DRAM type used but more to PCB design (maybe using large internal ground/vcc planes optimizing heat dissipation on Oranges.   NanoPi M1 and Orange Pi One/Lite use a rather primitive GPIO driven voltage regulator that is able to just switch between 1.1V and 1.3V VDD_CPUX which already helps somewhat with throttling.   A rather demanding benchmark using cpuminer (a bitcoin miner making heavy use of NEON optimizations and assembler instructions) that knows a benchmark mode where it outputs the khash/s rate. On the left OPI+ 2E with the superiour SY8106A voltage regulator switching CPU frequency between 1200 and 1296 MHz. On the right little OPi Lite with the SY8113B voltage generator able to switch between 1.1V and 1.3V and with slightly lower performance since throttling prevents clocking that high. And in the middle as only board with applied heatsink on H3 poor Banana Pi M2+ using the same SY8113B voltage regulator but always feeding the H3 SoC with 1.3V (for whatever reasons!).      Storage capabilities:   The H3 SoC doesn't feature native SATA capabilities so the 2 boards that have a SATA connector (Orange Pi Plus and Plus 2) implement that using an onboard USB-to-SATA bridge. Unfortunately the chip used there -- a Genesys Logic GL830 -- is horribly slow limiting sequential transfer speeds to 15 MB/s write and 30 MB/s read. It also does not support the USB Attached SCSI Protocol (UASP) so when using mainline kernel attached disks an especially SSDs couldn't show their full random I/O performance.   Given that common USB-to-SATA bridges used in external USB enclosures show way better sequential performance (35 MB/s in both directions and close to 40 MB/s when using an UASP capable bridge together with mainline kernel) the SATA port on these 2 SBC can not be considered a feature worth a buy.   Every H3 board has a TF card slot (Micro SD card) and some of the boards feature onboard eMMC storage. The H3 can cope with TF cards that are compliant to the SD, SDHC and SDXC standards so rather large cards with more than 64 GB capacity can also be used (be aware that there do not exist that much cards with a capacity larger than 128 GB. Chances are pretty high to get a counterfeit card especially when the price looks too good to be true ). You should also be aware that all H3 boards show the same sequential speed limitations (maxing out at ~23 MB/s) so choosing cards that are rated way faster aren't worth a buy. Better have a look at random I/O performance that is more important in most use cases.   The eMMC used on various boards is pretty fast (sequential speeds maxing out at ~75 MB/s and especially random IO way faster than the fastest tested SD cards which is important for desktop useage and databases for example) so you don't make a mistake choosing any of the eMMC equipped H3 boards (BPi M2+, Orange Pi Plus, Plus 2, Plus 2E or PC Plus). You find detailed test results of current SD/TF cards as well as all the eMMC variants used in these two threads: http://forum.armbian.com/index.php/topic/954-sd-card-performance/ http://forum.armbian.com/index.php/topic/990-testers-wanted-sd-card-performance/ Count of available USB ports:   The H3 SoC features 3 USB2.0 host ports and one USB OTG port. With Armbian we configure the OTG port as a host port that shows pretty similar performance so on some H3 boards (Orange Pi PC, PC Plus and Plus 2E) you can benefit from 4 USB2 ports that do not have to share bandwidth.   Some other boards use an internal USB hub (Orange Pi 2, Plus, Plus 2) so the available USB ports have to share bandwidth in reality. Please keep that in mind when you compare the 4 USB Type A jacks OPi 2, Plus or Plus 2 feature (all being connected to a USB hub so having to share the bandwidth of a single USB 2.0 host port) with the 3 you can count on OPi PC, Plus 2E or NanoPi M1. On the latter boards you get full USB 2.0 bandwidth on each USB receptacle without the need to share bandwidth.   BPi M2+ does also not use an internal USB hub but only exposes 2 USB host ports on type A receptacles and the 3rd host port only without ESC protection via soldering (but since this board shows such a terrible thermal design and is relatively overpriced compared to other H3 boards that doesn't matter that much)   Additional features:   The only board featuring a Bluetooth capable chip from BroadCom is the BPi M2+. Currently the vendor admits that BT is not working so better don't count on this feature to be ever available.   Update: Jernej got BT already working in his OpenELEC fork so it's just a matter of time until it works with Armbian too.   The H3 SoC is able to output/intercept additional signals, eg. analog audio, Composite video (TV out), IrDA that are present on most of the boards. On the Orange Pi One many of those interfaces are only present as solder points (a bit too tiny to be used by the average maker) and on some other boards they are not present at all (BPi M2+ for example has neither composite video nor analog audio) so always check first what you need or want to use.   We have a nice sortable table in linux-sunxi wiki showing most of the important details: http://linux-sunxi.org/Table_of_Allwinner_based_boards   Camera modules:   Xunlong provides a pretty cheap 2MP camera module that should work with every H3 Orange Pi out there (they all have the necessary connector but for OPi One, Lite, PC and PC Plus you have to tell Xunlong that you also need a so called 'expansion board' that they ship free of charge if you add to your order that you need it. Starting with Armbian release 5.15 we also include an improved driver for this camera.   Regarding current state of available camera modules for Oranges, BPi M2+ and NanoPi M1 please look through this thread: http://forum.armbian.com/index.php/topic/1213-ov5640-camera-with-orange-pi/?view=getlastpost