tkaiser

Why spreading so much confusion? Both boards have own wiki pages provided by technical writers so there's no need to focus on temporary mistakes their marketing folks might make.
 
Main difference between both boards is that Core2 features an RTL8211 GbE PHY while Core uses the SoC's internal Fast Ethernet PHY. And I hope they stay with H3 (or H2+ since essentially the same) on Core and H5 on Core2 and do not start with stupid SoC exchanges since this only leads to confusion and users picking up the wrong OS images.
 
Peripherals (heatsink included) are all compatible and they designed the boards fortunately backwards compatible. Pin headers soldered or not can be decided in the store at checkout time (I assume the Core when ordered together with the Mini Shield comes with them presoldered, I can't imagine FE repeating the same mistake as with the first NAS expansion bay).
 
Size of DRAM is choosable and eMMC optional. Which combinations might be available might change over time (based on feedback/demand)
 
There's USB OTG on the Micro USB port (other boards do it differently eg Tritium and NEO Plus 2 so it's worth to mention since both boards even without pin headers soldered can provide limited network connectivity through g_ether module) and the boards can be powered through pin headers too. Ethernet implementation is interesting since they offer the same Mini Shield for both variants so it should be possible to combine the Core2 with an external GbE MagJack as long as traces are short and most probably of same length ( didn't look into schematic yet).
 
Software support efforts seem to be minimal (more or less only DT stuff and maybe checking for GbE TX/RX delay adjustments) and at least with the Core I wouldn't consider Micro USB for DC-IN a show stopper...

By setting the speed with ethtool: https://github.com/armbian/build/blob/master/packages/bsp/h3consumption#L56 (h3consumption is essentially doing just that: adding a line with an ethtool call to /etc/rc.local).
 
Besides that you really don't want to use any nightly build for something productive (recently Ethernet stopped to work on H5 boards with latest nightly kernel) and there's a nice OMV image available for the board you're interested in which is the best idea if you want to start with OMV anyway...

Why spreading so much confusion? Both boards have own wiki pages provided by technical writers so there's no need to focus on temporary mistakes their marketing folks might make.
 
Main difference between both boards is that Core2 features an RTL8211 GbE PHY while Core uses the SoC's internal Fast Ethernet PHY. And I hope they stay with H3 (or H2+ since essentially the same) on Core and H5 on Core2 and do not start with stupid SoC exchanges since this only leads to confusion and users picking up the wrong OS images.
 
Peripherals (heatsink included) are all compatible and they designed the boards fortunately backwards compatible. Pin headers soldered or not can be decided in the store at checkout time (I assume the Core when ordered together with the Mini Shield comes with them presoldered, I can't imagine FE repeating the same mistake as with the first NAS expansion bay).
 
Size of DRAM is choosable and eMMC optional. Which combinations might be available might change over time (based on feedback/demand)
 
There's USB OTG on the Micro USB port (other boards do it differently eg Tritium and NEO Plus 2 so it's worth to mention since both boards even without pin headers soldered can provide limited network connectivity through g_ether module) and the boards can be powered through pin headers too. Ethernet implementation is interesting since they offer the same Mini Shield for both variants so it should be possible to combine the Core2 with an external GbE MagJack as long as traces are short and most probably of same length ( didn't look into schematic yet).
 
Software support efforts seem to be minimal (more or less only DT stuff and maybe checking for GbE TX/RX delay adjustments) and at least with the Core I wouldn't consider Micro USB for DC-IN a show stopper...

The above thing is a $10 accessory that can be ordered together with ROCK64 (and maybe other Pine Inc. devices like Pine64 or Pinebook?). It's an USB-to-SATA bridge (JMicron JMS578 based) to be used together with 2.5" SSD/HDD or 3.5" HDD. For the latter purpose it's equipped with a separate power jack suitable for the usual 12V 5.5/2.1mm power barrels (centre positive) you find PSUs with literally everywhere.
 
TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too.
 
Basics first:
Mechanical quality of USB jack is excellent, Pine folks took care that the jack fits really tightly in USB receptacles so USB3 contact issues should not be an issue here (tested on ODROID-XU4 which is my worst device in this regard. The Pine adapter worked great and these pretty nice XU4 USB3 storage performance numbers were produced with Pine's adapter) The device is not really black but it's just a very dark but translucent plastic. If it's connected to an USB port and thereby powered a solid blue led is shining through. Disk activity is shown with a blinking red led in parallel. If you hate blinking leds like me turning the device 180° over is sufficient JMS578 as USB-to-SATA bridge is an excellent choice since amazingly fast, 'USB Attached SCSI' capable, same with 'SCSI / ATA translation' and even TRIM (though software support for this still missing in Linux) When combined with 2.5" disks the whole power consumption happens through the USB cable. Keep in mind that USB2 ports are rated for 500mA and USB3 ports for 900mA max. ROCK64 AFAIK allows 650mA on the USB2 ports and 950 mA on the USB3 ports. In other words: chances are great to run in underpowering problems when you connect 2.5" disks to the USB2 ports and run heavy loads on it (see below). 3.5" HDDs need not only 5V but also 12V. Usually the motor spinning the platters is on the 12V rail while internal electronics and the stepper motors to move around the head(s) are on the 5V rail. Please always keep in mind that Pine's SATA cable unlike any 'real' 3.5" HDD disk enclosure uses the separately provided 12V only to feed pins 13-15 on the SATA power connector. 5V consumption for the JMS578 and the disk's 5V rail has still to be provided by the device the SATA cable is connected to since coming from the USB power lines. On 'real' disk enclosures the 12V are internally also used to generate the 5V so an external disk is NOT powered in any way by the connected host. With this cable it's different!  
Below is the standard SATA power connector pinout. 3.3V are usually not used, 12V are needed for 3.5" HDDs and 5V are always required. The JMS578 bridge chip needs some 5V juice too which is also taken from the connected host/board via USB power lines.
 

 
We already have a lot of performance numbers with fast SSDs connected to JMS578 (see https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 or there for example) so let's focus on real-world use cases this time: A large 3.5" HDD connected to a ROCK64 serving as a NAS or backup disk.
 
Let's start with some consumption numbers with an idle ROCK64. In the meantime I've 3 different ROCK64 generations on my desk (1st dev sample with 2GB and unusable USB3, 2nd gen dev sample with 4 GB and now a production board with 1 GB DRAM and a different Gigabit Ethernet PHY). Measurements done without PSU taken into account:
 
Pre-production board, 4GB, RTL8211E PHY:
Idle, Fast Ethernet active, nothing connected: 1100mW Idle, GbE active, nothing connected: 1430mW   
Production board, 1GB, RTL8211F PHY:
Idle, Fast Ethernet active, nothing connected: 1180mW Idle, GbE active, nothing connected: 1300mW Idle, GbE active, JMS578 connected: 1720mW Idle, GbE active, JMS578 with sleeping disk: 2850mW With RTL8211E PHY the difference between GbE and Fast Ethernet was 330mW (on most GbE boards with 8211E it's exactly like this: ~350mW) and now with RTL8211F the difference is just 120mW (difference on ODROID-C2 which also uses 8211F is 230mW). When adding the JMS578 cable w/o connected disk consumption increases by 400mW. In this (rather useless) mode the JMS578 hides itself on the USB bus (lsusb output shows nothing -- interestingly on ODROID HC1 which also relies on JMS578 this is different) and obviously JMS578's USB and SATA PHYs are powered off. As soon as a disk is connected but sent to sleep JMS578 now consumes +1.5W and appears on the USB bus (now JMS578 has to power 2 highspeed PHYs: USB3 and SATA 3.0).
 
So with production ROCK64 boards minimal idle consumption is 1.2W (PSU's own consumption excluded). But as soon as we connect this cable with a disk behind idle consumption more than doubles (+1550mW) even if we send the disk to sleep. That's bad news for use cases that require a connected disk only running from time to time since now the JMS578 consumes more energy than the board itself.
 
Edit: I discovered recently that the HDD I was testing with has a rather high standby/sleep consumption so the +1550mW are not JMS578 alone but maybe even largely the Seagate Barracuda. See here for details but keep in mind that while on ODROID HC2 also a JMS578 is used it runs a different firmware which influences idle consumption behaviour a lot. More details on JMS578 firmwares: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43735
 
What are the options? With ROCK64 production boards we're fortunately able to toggle power provided to USB ports: https://forum.pine64.org/showthread.php?tid=5001
 
So the SATA cable connected to an USB2 port would allow to regain lowest idle consumption since we could unmount the disk when not needed, then send the disk to sleep using 'hdparm -y' (JMS578 fully supports 'SCSI / ATA translation so you can access every disk feature with hdparm or other low level tools!) and finally switch JMS578 off by cutting power on  the USB2 port. My personal use case is a ROCK64 with a huge 3.5" HDD to backup various macOS devices in the household. Backup performance is close to irrelevant and the only events needing top 'NAS performance' would be large restores or 'desaster recovery'. In other words: for normal backup operation once a day it would be sufficient to connect the disk to an USB2 port.  Nope, doesn't work any more, see below for details.
 
How does performance look like with a 7.2k 3.5" HDD (Seagate Barracuda from a few years ago):
 
The Barracuda is totally empty so able to achieve nice maximum sequential performance scores since testing only on the outer tracks (~170 MB/s):
USB3 / UAS (7.9W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 11738 23147 25131 25087 1091 948 102400 16 62218 77830 84257 84768 4246 4136 102400 512 150052 148303 154342 163817 58563 97809 102400 1024 148290 148324 156772 164963 85125 113412 102400 16384 149840 149248 144297 151440 153146 133806 1024000 16384 167750 169544 172970 174205 160859 151406 When connected to an USB2 port performance drops a lot (maxing out at ~37MB/s):
USB2 / UAS (6.4W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 7735 7849 6821 7925 998 916 102400 16 17687 19040 20793 19430 3624 4096 102400 512 33472 33662 33738 34329 26020 33683 102400 1024 33836 34030 34855 35505 29941 28791 102400 16384 34294 34373 35599 36694 36174 33714 1024000 16384 33600 34516 36576 36902 36372 34111  
I tested backing up the same MacBook Air twice with ~70 GB data using Gigabit Ethernet (the usual Thunderbolt Ethernet adapter) and time difference was negligible comparing HDD connected to USB2 or USB3. When backing up through Wi-Fi there is no difference any more since Wi-Fi is the bottleneck. In other words: from a performance point of view for this use case connecting the SATA cable to an USB2 port and being able to totally cut power to both cable/JMS578 (+1.5W consumption) and a sleeping 3.5" disk (less than 0.1W consumption with almost all disks) is worth the efforts.
 
Once your MacBook gets stolen you simply disconnect the backup HDD from the USB2 and reattach it to an USB3 port and start the restore on your new device with +80 MB/s (Gigabit Ethernet now being the bottleneck) 
 
What about power requirements? ROCK64 only provides up to 650 mA on the USB2 ports! I tried to test this precisely with my usual 'monitoring PSU' approach. All I was getting were some nice kernel panics due to UNDERPOWERING. The Banana Pro I used to provide power (and measure consumption) simply does not provide enough current so Linux on ROCK64 started to fail in many funny ways once USB accesses happened.
 
So I had to revert on measuring with PSU included with a cheap powermeter (more realistic but not that precise).
 
When measuring only the 12V rail of my 3.5" Barracuda the disk consumed up to 18W when spinning up. In normal operation (either idle or with any workload) 12V consumption varied between 6W and 8W (12V only needed to spin the platters).
 
The 5V power requirements for JMS578 + 3.5" HDD disk were as follows:
USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW  
At least with my 3.5" HDD it worked pretty well to let it operate on both USB2 and USB3 ports when board powering was appropriate (with insufficient powering all weird sorts of issues popped up. My favourite was a kernel panic when issueing 'lsusb' after 30 seconds. Once I powered ROCK64 reliably all these 'software issues' were gone immediately -- again and again: insufficient powering is one of the most severe problem sources)

Just a heads up, I think the bigger issue between the revision 1.1 and 1.4 is that they removed the "U5" buck AVCC/RTC 3.3V converter, Instead in its place they put a "R9" 0 ohm resistor from the GPIO 3.3v regulator "u55". As such it makes sense that they removed the "Q11" gpio voltage enable switch, since now that switch must always be on.
In testing the voltages, the Rev 1.1 GPIO VCC is 3.37v, whereas the AVCC/RTC Vcc is 3.27v.
For Rev1.4 though, the GPIO/AVCC/RTC Vcc is actually 3.4v.
I am currently removing "R9" from rev 1.4 and installing a diode to drop some voltage. It may help to keep the device from overheating. If that doesn't help, perhaps adding a secondary 3.3v buck regulator can fix the issue.
 
Update: With the diode to drop voltage, the resulting voltage on AVCC/RTC is 2.91V.
This results in the following temp readings stable/finger tested:
19:02:53: 1200MHz  0.71  19%  11%   6%   0%   1%   0%   -2°C
19:02:58: 1008MHz  0.73  19%  11%   6%   0%   1%   0%   -4°C
19:03:03:  240MHz  0.67  19%  11%   6%   0%   1%   0%   -9°C
19:03:08:  240MHz  0.62  19%  11%   6%   0%   1%   0%  -10°C
19:03:13:  240MHz  0.57  18%  10%   5%   0%   1%   0%  -11°C
19:03:18:  240MHz  0.52  18%  10%   5%   0%   1%   0%  -17°C
19:03:24:  240MHz  0.48  17%  10%   5%   0%   1%   0%  -20°C
19:03:29:  240MHz  0.44  17%  10%   5%   0%   1%   0%  -21°C
This leads me to believe that the temperature may not be significantly if at all different between v1.1 and v1.4. It would make sense for the slight voltage difference of voltage on the AVCC pins would change the internal temperature readings. They probably don't have any sort of voltage reference internally, and that would lead to any sort of internal reading based on analog voltages to be affected by voltage changes of the AVCC power.
I will test this with a power supply on the seperated AVCC/RTC to see if it does indeed result in different internal readouts.
 
 
Alright, here's what I found:

All of these results are running the armbianmonitor right after start up and each show a "finger test" draw represents draw on the Avcc/rtc  from the power supply, and is quite stable.
 
Orangepi v1.4 test: r9 removed, AVCC&RTC=3.27 about 50mA draw during test:
Orangepi v1.4 test: r9 removed, AVCC&RTC=3.4V about 50mA draw during test:

Orangepi v1.4 test: r9 removed, AVCC&RTC=2.90V about 40-50mA draw during test
 
Results: The internal temperature sensing cannot be trusted, especially since there is no voltage reference.
Tomorrow I will try to place a 150mA 3.3V LDO regulator instead of "r9" and see if I can find a way to actually test temperature.

PS: I would add images if I could figure out how to do so outside of hosting them somewhere else.
 
Sidenote:
"R9" is glued down, so to minimize chance of lifting pads when desoldering try this:
1- apply generous amounts of flux from flux pen.
2) use solder wick to remove as much solder as possible
c Once all the solder is gone, rotate the part 90 degrees with flat end needle nose pliers while slightly pushing into the board.
 
If you managed to get enough solder off, the part should break free without lifting the pads. And if they do lift, you can always solder onto the test points on the board.

Should be fixed now in latest release: https://forums.resin.io/t/etcher-v1-2-1-release/2265

After latest armbian-config updates the following will now also be tweaked if OMV is installed this way:
Disable Armbian's log2ram in favour of OMV's folder2ram Device workaround for Cloudshell 1 (checks presence on USB bus -- for this to work the Cloudshell 1 must be connected when installing OMV!) Device support for Cloudshell 2 (checks presence on I2C bus and then install's Hardkernel's support stuff to get display and fan working -- for this to work the Cloudshell 2 must be connected when installing OMV!)) Cron job executed every minute to improve IO snappyness of filesharing daemons and moving them to the big cores on ODROID XU4 Making syslog less noisy via /etc/rsyslog.d/omv-armbian.conf  
So only remaining difference to the 'dedicated' OMV images is now the following: The dedicated OMV images
set the correct timezone at first boot replace swap entirely with zram limit rootfs resize to 7.3 GB and automatically create a 3rd partition  
BTW: There is currently no OMV uninstall routine and there will most probably never be one. While you could probably succeed with an 'apt purge openmediavault' this is also not recommended since too many leftovers will remain. If for whatever reasons after installing OMV you want to stop using it it's strongly recommended to start over from scratch with a freshly burned new image.

Confirmed on my Orange Pi Zero w/ 5.36/legacy. After some digging, the extra
[ ! -z "${SocTemp##*[!0-9]*}" ] on https://github.com/armbian/build/blob/master/packages/bsp/common/usr/bin/armbianmonitor#L346 that Igor added to make Soc readings more resilient with badly behaved kernels is the culprit.  I've added an issue for it, and some explanation as to what broke.
 

The reason is simple. If you insert a card when the board boots the H3 will always search for a bootloader there. If you insert the card later it won't be recognized (which might be able to be fixed by playing around with /proc/driver/sunxi-mmc.x/insert).
 
So to boot with inserted SD card the bootloader has to remain there and point to the rootfs on the eMMC (the numbering of devices will then also change!). This can be done by using our nand-sata-install.sh script and then not wiping out the SD card but keep the 1st MB intact and only adjust the partition table so that the SD card can be used for data.

All armbianmonitor thermal read outs are broken on at least pine64/legacy and odroidxu4/next

Adding unreliable overclocking settings on Allwinner and Rockchip devices is unfortunately pretty easy (and the proposed patch looks wrong already in the first line since increasing cpufreq by 100 MHz without adjusting the voltage at all). That's why stuff like https://github.com/ehoutsma/StabilityTester exists. Feel free to try it out, @ErwinH used the tool to develop a sane DVFS OPP table last year for Orange Pi PC2 with this (since we found out that this highly optimized Linpack is a great way to check for DVFS undervoltage caused instabilities already before the board freezes/crashes. That lesson was learned when dealing with unreliable overclocking on Pine64 before)

If that's true then this is a clear indication to better stay away from this at all (since 4.13 is already EOL this means he doesn't take care about the kernel part at all and now only thinks about an upgrade to please concerned users). More thoughts here BTW: https://www.cnx-software.com/2017/11/30/zeroshell-firewall-router-linux-distribution-works-on-x86-hardware-raspberry-pi-23-some-orange-pi-boards/#comments

Tried a new image on a Pinebook and am slightly shocked. A huge penguin is starting at me. When/where was the wallpaper switch from armbian06-1430-very-dark to armbian03-Dre0x-Minum discussed? I want to understand the reasons...

Good point I almost forgot about since this is set by default with OMV already (tested on day 1 when I started with OMV back in April -- OMV uses some internal preferences which then get fed into the daemon's config files automagically):
root@odroidxu4:~# testparm 2>/dev/null | grep sendfile use sendfile = Yes So I tested the opposite now with Armbian/OMV by setting 'use sendfile = no' in OMV's "/config/services/smb/extraoptions", verified with testparm and as expected read performance drops a lot (directory enumeration too) while write performance slightly increases:

So yes, 'use sendfile = yes' is important even with beefy hardware (I did a quick check also with performance governor but numbers are close to identical so it's not related with cpufreq scaling and also not a true CPU bottleneck -- watched utilization with htop, everything happens on the big cores and it looks like there's still some room... unlike with A20 where usually the smbd thread is bottlenecked by the CPU core it's running on)
 
As a comparison the 'use sendfile = yes' numbers from above again:

H2+/H3/H5 boards overview (early 2018 update)
 
For the methodology/categorization please see above. This is just a brief overview adding the boards that appeared within the last few months (Banana Pi Zero, NanoPi Duo, Orange Pi R1, Orange Pi Zero Plus, Sunvell R69) and will appear soon or are just released (ACT Power X-A1, Libre Computer's H2+/H3/H5 Tritium, NanoPi NEO Core and Core2):
 
NAS category (only due to Gigabit Ethernet available):
Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Core 2: H5, 512MB/1GB DRAM, eMMC, 1+3 USB ports useable, GbE on pin header NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB slow eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi Orange Pi Zero Plus: H5, 512MB, 1+1+2 USB ports useable, Wi-Fi X-A1: H3, 1GB DRAM, 8GB eMMC, 1+2 USB ports useable IoT category (cheap, small, energy efficient, most of them headless):
Banana Pi Zero: H2+, 512MB DRAM, no eMMC, 1 USB port useable, Wi-Fi/BT,  Fast Ethernet (pin header) NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi Duo, H2+, 256/512MB DRAM, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet (pin header) NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Core: H3, 256/512MB DRAM, optional eMMC, 1+3 USB ports useable, Fast Ethernet (pin header)
NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet Orange Pi R1: H2+, 256MB DRAM, 1+2 USB ports useable, Wi-Fi, 2 x Fast Ethernet (1 x USB RTL8152) OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI Tritium IoT: H2+, 512MB DRAM, 1+3 USB ports useable, Fast Ethernet
General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Sunvell R69, H2+, 1GB DRAM, 8GB eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet Tritium: H3, 1GB DRAM, 1+3 USB ports useable, Fast Ethernet Tritium: H5, 2GB DRAM, 1+3 USB ports useable, Fast Ethernet

H2+/H3/H5 boards overview (early 2018 update)
 
For the methodology/categorization please see above. This is just a brief overview adding the boards that appeared within the last few months (Banana Pi Zero, NanoPi Duo, Orange Pi R1, Orange Pi Zero Plus, Sunvell R69) and will appear soon or are just released (ACT Power X-A1, Libre Computer's H2+/H3/H5 Tritium, NanoPi NEO Core and Core2):
 
NAS category (only due to Gigabit Ethernet available):
Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Core 2: H5, 512MB/1GB DRAM, eMMC, 1+3 USB ports useable, GbE on pin header NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB slow eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi Orange Pi Zero Plus: H5, 512MB, 1+1+2 USB ports useable, Wi-Fi X-A1: H3, 1GB DRAM, 8GB eMMC, 1+2 USB ports useable IoT category (cheap, small, energy efficient, most of them headless):
Banana Pi Zero: H2+, 512MB DRAM, no eMMC, 1 USB port useable, Wi-Fi/BT,  Fast Ethernet (pin header) NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi Duo, H2+, 256/512MB DRAM, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet (pin header) NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Core: H3, 256/512MB DRAM, optional eMMC, 1+3 USB ports useable, Fast Ethernet (pin header)
NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet Orange Pi R1: H2+, 256MB DRAM, 1+2 USB ports useable, Wi-Fi, 2 x Fast Ethernet (1 x USB RTL8152) OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI Tritium IoT: H2+, 512MB DRAM, 1+3 USB ports useable, Fast Ethernet
General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Sunvell R69, H2+, 1GB DRAM, 8GB eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet Tritium: H3, 1GB DRAM, 1+3 USB ports useable, Fast Ethernet Tritium: H5, 2GB DRAM, 1+3 USB ports useable, Fast Ethernet

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

Did you read through this already? 
 

H2+/H3/H5 boards overview (early 2018 update)
 
For the methodology/categorization please see above. This is just a brief overview adding the boards that appeared within the last few months (Banana Pi Zero, NanoPi Duo, Orange Pi R1, Orange Pi Zero Plus, Sunvell R69) and will appear soon or are just released (ACT Power X-A1, Libre Computer's H2+/H3/H5 Tritium, NanoPi NEO Core and Core2):
 
NAS category (only due to Gigabit Ethernet available):
Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Core 2: H5, 512MB/1GB DRAM, eMMC, 1+3 USB ports useable, GbE on pin header NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB slow eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi Orange Pi Zero Plus: H5, 512MB, 1+1+2 USB ports useable, Wi-Fi X-A1: H3, 1GB DRAM, 8GB eMMC, 1+2 USB ports useable IoT category (cheap, small, energy efficient, most of them headless):
Banana Pi Zero: H2+, 512MB DRAM, no eMMC, 1 USB port useable, Wi-Fi/BT,  Fast Ethernet (pin header) NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi Duo, H2+, 256/512MB DRAM, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet (pin header) NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Core: H3, 256/512MB DRAM, optional eMMC, 1+3 USB ports useable, Fast Ethernet (pin header)
NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet Orange Pi R1: H2+, 256MB DRAM, 1+2 USB ports useable, Wi-Fi, 2 x Fast Ethernet (1 x USB RTL8152) OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI Tritium IoT: H2+, 512MB DRAM, 1+3 USB ports useable, Fast Ethernet
General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Sunvell R69, H2+, 1GB DRAM, 8GB eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet Tritium: H3, 1GB DRAM, 1+3 USB ports useable, Fast Ethernet Tritium: H5, 2GB DRAM, 1+3 USB ports useable, Fast Ethernet

Completely wrong it turns out.
Turns out the RK805 PMIC needs the voltage increased in 12.5mV steps and the frequency needs to be specific values too, they're defined in drivers/clk/rockchip/clk-rk3328.c.
They're defined up to 1.8GHz, but I didn't get any above 1.488 to work, cpufreq wouldn't load them.
It does run stable at 1.488GHz though, if you increase the voltage. I'm using 1.4375V, haven't tested any lower.
Done testing stability: Frequency: 1392000 Voltage: 1350000 Success: 1 Result: 0.0048034 Frequency: 1416000 Voltage: 1375000 Success: 1 Result: 0.0048034 Frequency: 1488000 Voltage: 1437500 Success: 1 Result: 0.0048034 I had to edit the script for min, max and cooldown freq as well as the Vcore regulator
Peaks around 78 degrees, with idle @408MHz 40 to 45C
 
minerd --benchmark reports 4.61khash/s (or 4.58 while armbianmonitor -M is running)
after a few minutes it's sitting around 79C

This (and iozone output) looks more correct. But currently with 5.35 on sunxi hardware the CPU cores won't ramp up the clockspeed correctly (fix will be in 5.36 so simply do an 'apt upgrade' on monday) so for a new round of NAS tests (LanTest and Explorer) you might want to use the cpufreq-set call from above to switch from ondemand to performance to get an estimate how NAS performance will look like next week again.
 
 
I understood it this way and just wanted to warn that things might happen you don't expect. It's stuff people normally don't think about, it happens way too often and it's always fun to try to recover from such stuff.
 
For example encodings and umlauts: you create something with an Ä in its name on a file server, then attach the disk directly to the client. Still looks like Ä but different representation. So you can see the file but don't access it (there exist 4 different Unicode Normalization forms with 2 being used here and there). That's why I would refrain from trying such stuff. If data is on a NAS share then only access it there with the same daemon as when you created the data (eg. only using SMB/Samba or only using NFS or only using AFP/Netatalk when macOS clients are in the network)

The problem is the created confusion and armbian-config is here only part of the problem but not of a solution. It just looks in a directory for files that follow a specific naming scheme (${OVERLAYDIR}/${overlay_prefix}*.dtbo), presents them as list, you can tick checkboxes, then something will be written to another file, done. What happens after the mandatory reboot might be surprising and what's displayed depends solely on the contents of a directory defined as $OVERLAYDIR (and the contents are subject to package updates that happen somewhere else) and is not related to the hardware in question.
 
A suitable UI (it's called USER interface for a reason since it should focus on the user) would try to address the job from the user perspective. That would require:
displaying what's available as selectable hardware and what's already active, therefore not needing a DT overlay! (not happening now, usb0host for example is displayed as inactive while it's active in reality or not -- the most basic principle of an UI is already violated here) allow to only do something that really works (a lot of overlays would require additional parameters and without them activation is pretty much useless) checking and trying to resolve overlay conflicts Creating such an UI that really works is days of works but would add least be something useful and not add further to the confusion that's already there. IMO the only stuff where the current armbian-config implementation helps (activating stuff on pin headers like USB, Audio (analog-codec and I2S, SPDIF where appropriate) without the need to specifiy additional parameters) could be avoided in the first place by activating this stuff by default.
 

Well, I never buy 'brands' but chipsets instead. If it's about USB-to-SATA I only buy (and search for) these and maybe ASM1351 soon. With USB3 hubs I only buy VIA812 (rev B or newer) and with Gigabit Ethernet only RTL8153 (I own one such combined thing also from ORICO but again I searched for the ICs used to ensure I get exactly the good ones).
 
Please be aware that some USB3 capable SATA bridges start to fail miserably with more recent kernels and you need to adjust some values to stop storage problems (and further decrease performance at the same time)

I tested with an OMV image I created today for Hardkernel (so they can test their new eMMC themselves). OMV relying on btrfs as usual. Then tried out nand-sata-install twice and testing with ext4 and btrfs as target:
Ext4 target: contents of /boot are not copied, fstab wrong: bogus /boot and /media/mmcboot entries. After fixing both problems manually (rsync and vi) it works: http://sprunge.us/LTSX Btrfs target: rootfs is copied from mmcblk1p2 to sda1 but fstab is created wrong: /media/mmcboot entry gets UUID of old / (mmcblk1p2) instead of ext4 /boot (mmcblk1p1) and the bind mount is wrong too. After fixing the 1st problem manually (exchange UUID in fstab) it works: http://sprunge.us/hJFX In the 2nd case I think these are just two simple bugs (using $root_uuid instead of $sduuid and let /boot point to non-existent /media/mmcboot/boot) so I decided to fix them and limit the target fs choice when the current rootfs is already btrfs to also just btrfs (so no normal Armbian installation using an ext4 rootfs should be affected and those OMV images are condemned to stay with btrfs) .
 
Works now: http://sprunge.us/XIZX