tkaiser

Unfortunately (for the community) from business perspective for SBC manufacturers investing money in software support won't give as much feedback in money/revenue as investing, for example, in marketing - advertisements, paid and free samples reviews and so on. At least in a short term perspective.
In a long term, when perception of company's name associates more and more with crappy support, they can simply rename their company and new boards to "something-else pi" and start from scratch with "clean" karma.

https://github.com/igorpecovnik/lib/tree/master/scripts/update-motd.d
 
I also did some rework based on those ideas. Battery info is also included, but need further testing. One full charge / discharge cycle is needed for auto calibration.
 
- info that is not needed is hidden: if no updates available, if there is only one user logged, if there is no temperature readings, ....
- each info has it's own configurable red point
 
Not included anywhere ... yet. Only testing.

AXP202/209 sysfs interface patch for axp20x MFD drvier in mainline kernel
 
 
âžœ ~ % ls /sys/power/axp_pmu/{ac,vbus,battery,charger,pmu,control,ocv_curve} /sys/power/axp_pmu/ocv_curve /sys/power/axp_pmu/ac: amperage connected used voltage /sys/power/axp_pmu/battery: amperage capacity charge charging connected power ts_voltage voltage /sys/power/axp_pmu/charger: amperage cell_activation charging low_power /sys/power/axp_pmu/control: battery_rdc disable_fuel_gauge set_vbus_direct_mode charge_rtc_battery reset_charge_counter /sys/power/axp_pmu/pmu: overheat temp voltage /sys/power/axp_pmu/vbus: amperage connected strong used voltage âžœ ~ %  Shortlog:
 
 
 
How to test:
Patches for next and dev branches are included in Armbian build framework, use standart procedures to build and install new kernel.
.. or you can download this prebuilt kernel for next branch.
Latest version of the patch, basic documentation and battery calibration utility are available on GitHub.
 
TODO list:
Find and fix bugs.
Check if can be converted into a separate kernel module, preferrably power supply class driver.
 
Limitations:
AXP202/AXP209 only for now.
Things are implemented according to datasheet and my understanding of it.
 
Default settings for main battery according to datasheet:
Target voltage: 4.2V
Charging current: 500mA/1200mA (?)
 
Defaut settings for RTC battery:
Charging: disabled by default.
Target voltage: 3.0V
Charging current: 200uA
 
Standart disclaimer:
Code looks simple enough, but i wouldn't recommend using it on production environment yet. Bugreports are welcome, but I'm not responsible for kernel panics, lost data and exploded PMUs.
 
 

As already pointed out the problem seems to be that SG support (SG --> 'SCSI generic' that is necessary for some USB implementations) is currently built as a module. Modules are stored on the rootfs below /lib/modules. In case the rootfs is not already mounted and the SG module is needed to access the rootfs you're simply lost.
 
And unfortunately this applies to your USB disk and also to your USB thumb drive situation. Again: Either recompile the kernel with CONFIG_CHR_DEV_SG=y  instead of a module or wait for the next version. 

@all
FYI, kernel 4.4.0 is out
 
Tested USB OTG on cubietruck; OTG autodetect and vbus (automatically enabling power on OTG port when OTG cable is plugged in) works with some extra kernel modules, will upload my kernel config later.
As a side-effect, I can use onboard miniUSB port as a serial console (only after systemd starts necessary getty service, of course).
Onboard audio works if DMA driver is loaded via /etc/modules or if it's compiled as built-in.
 
Edit: extras for /etc/modules:
# sunxi musb OTG sunxi # serial gadget (old) driver - required g_serial # ACM - for serial port emulation usb_f_acm Edit 2: For Debian Jessie (or stretch) gadget serial device name is /dev/ttyGS0, so command to enable it would be
sudo systemctl enable getty@ttyGS0.service

Whatever that means...
 
The Turris Omnia is based on a SoC that does not guarantee lowest throughput as with Allwinner's A20 and costs me 125,- bucks including shipping/VAT. It's a no-brainer to prefer this over the crappy Lamobo stuff.
 
When my Wi-Fi AP dies sometimes in the future, I will replace it temporarely with another AP and then check prices/situations regarding available mini-PCIe Wi-Fi cards. That's what you get with a modular design providing SATA, 2 x USB3, 3 GbE PHYs and a few PCIe lanes and a SoC providing plenty of I/O and network bandwidth.

Nope, it's the other way around: the BCM53125 has 5 GbE PHYs (external Ethernet ports) and 2 RGMII ports (to connect one or two SoCs) but A20 has only one RGMII interface. And ONLY if the BCM53125 would act differently when both RGMII ports are used (not as a dumb layer2 switch by default but in this mode interconnecting only 1 GbE PHY with RGMII port A and the 4 other GbE PHYs with RGMII port B ) then it could be used as a router. We neither have a SoC that features 2 RGMII interfaces nor the necessary knowledge whether the switch IC can boot up in this different default state.
 
Regarding the Lamobo R1S: This is actually two boards in one combining the A20 with a MIPS SoC using another 256 MB of RAM and running OpenWRT. It would have to be confirmed in which state the MT7621A internal 5 port switch boots (also bridging all ports or differentiating between WAN and LAN) to judge. BTW: Before buying a crappy SinoVoip product again I would combine any other A20 device with something like the WiTi board (based on the very same MT7621A but using all the features of this SoC like USB3 or 2 x SATA and so on). Fortunately the R1S seems to be a prototype only.

A20 is simply the wrong SoC since it lacks the necessary interconnects. What you're thinking about might work with the i.MX6 Quad for example. It features SATA II (90-100 MB/s in both directions), a somewhat limited GbE implementation (400 Mbits/sec -- you might want to use this with RGMII and an external GBit Ethernet PHY for WAN) and a single PCIe 2.x lane to be used with a GbE PCIe controller connected to the BCM53125 for example.
 
Then you've a quad core Cortex-A9 solution utilising up to 4 GB RAM (twice as much as with any Allwinner SoC) and acting like a router should act. How the BCM53125 behaves in this mode is irrelevant, you need not even drivers for this IC since it should be a dumb layer 2 switch. But you could also use MDIO to define additional VLANs (and you might even rely on VLANs for routing purposes if you don't care about security).
 
In case you really care about powerful Wi-Fi too you would've to rely on a SoC made for that (providing a few more PCIe lanes to be used with different Wi-Fi mini-PCIe cards or combine i.MX6 with PCIe switches maybe just to realise that you're running in bandwidth issues). A good example is Marvell Armada 38x as used on the Clearfog or Turris Omnia.
 
Again regarding the i.MX6: The Dual core variants have also PCIe (so you can combine the internal GbE MAC with a 2nd real PCIe NIC) but lack SATA therefore the quad core variant would be the best solution to build something comparable to Lamobo R1 that does NOT suck (Utilite Standard/Pro both use an Intel I211 as 2nd NIC that shows way better performance than the i.MX6's internal GbE implementation). There exist many vendors selling i.MX6 based SoM solutions so this would be the route to go to get something comparable to the R1 for 30 bucks more (the SoC alone is more expensive than an A20 and an additional PCIe controller increases costs also)
 
But for a router/NAS combination encryption performance might also be interesting and so I would have a look at hardware accelerated encryption (Freescale's CAAM or Marvell's CESA). I would assume Marvell wins and the Turris folk will try hard to get CESA drivers upstream. Then Armbian support for the Clearfog might automagically benefit from this too.

Clearfog PRO with R1 in the back
 
After a day of playing, I am running full featured Armbian, Debian Wheezy, built with Armbian script from sources. We had to fix few things in U-boot and upgraded kernel to .82 but generally it was easy to boot the board. Of course SolidRun also provide some basic images.
 
Three(3) phys, USB and PCI is detected in kernel 3.10.82 - I don't have much hardware to plug in so I can't do much tests at this point. There is no CPU governor (yet?), so I assume it's running full speed (1.6Ghz) all the time. There are dip switches on the board to set cpu / dram speed ...
____ _ __ / ___| | ___ __ _ _ __ / _| ___ __ _ | | | |/ _ \/ _` | '__| |_ / _ \ / _` | | |___| | __/ (_| | | | _| (_) | (_| | \____|_|\___|\__,_|_| |_| \___/ \__, | |___/ Welcome to ARMBIAN (Debian wheezy 3.10.94-marvell) Last login: Sat Jan 9 10:11:28 2016 from desktop Load: 0.00, 0.01, 0.05 - Board: 64.6°C - Memory: 973Mb root@armada:~# Waiting for:
I decided to drop idea to put an AC card into the board since it's simply too problematic and expensive (66USD). This card doesn't have support in legacy kernel, in 4.4 have no idea if everything else already works + I have only one AC device in the lab. The Wireless card I choose is not fresh new but it's cheap (14USD) and reported working on Linux: Atheros AR5BXB112 AR9380 450Mbps. If I get stability and around real 300Mbps is good enough.
 
M2 drive. I'll put one 128G INSSD128GM.26M2242 TRANSCEND MTS400 128GB SSD SATA3 M.2 2242 TS128GMTS400 which should be big enough for most cases.
 
Mpci2sata for one ordinary SATA. 
 
SFP module. Haven't found the proper one yet.
 
With Armbian tools it's possible to build (I collect and fix all patches) and should be possible to boot kernel 4.3.3 and 4.4 - next.
 
Network performance (over TP link switch). 
Windows desktop -> Clearfog [ 3] 0.0-10.0 sec 1.09 GBytes 938 Mbits/sec [ 3] 0.0-10.0 sec 1.07 GBytes 922 Mbits/sec [ 3] 0.0-10.0 sec 1.09 GBytes 938 Mbits/sec Clearfog -> Windows desktop [ 4] 0.0-10.0 sec 1.04 GBytes 889 Mbits/sec [ 5] 0.0-10.0 sec 1.02 GBytes 878 Mbits/sec [ 4] 0.0-10.0 sec 1.03 GBytes 882 Mbits/sec To be continued ...
 
Edit #1: Board boots with 4.3.3 / Eth: no, USB: yes, mPci: yes
Edit #2: Jessie image download
Edit #3: Legacy kernel upgraded to 3.10.94
Edit #4: Network performance
Edit #5: If eth0 connected to gigabit, + cca. 2°C more heat on CPU in idle
Edit #6: mSATA is working with patched U-boot
Edit #7: mSATA and mPCI can be enabled in any combination. Tested one wireless card ...
Edit #8: boot time when installed to low performance 32Gb mSATA, power -> Login prompt <= 10s, (-3s waiting at u-boot) = cca. 7sec
Edit #9: I2C working out of the box. Tested with display, communication is slow. Perhaps only the settings
Edit #10: USB somehow buggy on current legacy kernel. I was trying to use Temper to collect temperature ... it worked once, next reading hang the device and I need to unplug / plug. Haven't debug. USB flash memory working normal.
Edit #11: Added cpu freq scalling 800/1600Mhz -> less heat in idle
Edit #12: Kernel 4.3.3 & 4.4 / Eth: yes, USB: yes, mPci: yes, mSata: yes ... and doing preliminary testing with Atheros AR9380 N wireless card // Kernel not ready yet
Edit:#13: Added mSATA to SATA card, patch a driver to unlock cheap - (consumer grade!, 13 USD shipped) AR9380 AR5BXB112 wireless card to operate at 5Ghz. Running STABLE
Edit:#14: Booting from m2 120G SATA drive
Edit:#15: Measuring temperature on the edge of heatsink = 39-42 while ambient is around 20.
Edit:#16: Added external 2.5 inch mechanical SATA drive powered from Clearfog +5V from header

In the area here 2.4GHz is already dead. No need for that. The Turris people charge $209 ($139 while campaign is running) without Wi-Fi vs. $285 ($189 now on Indiegogo). So the difference for "antennas, pigtails and 2 Wi-Fi cards" is $76 and $50 while the campaign is running.
 
Since the Omnia's case and PSU aren't of any use for me (will build as usual an own enclosure for board + disk) I'll wait a bit and will order then a card from here with some other network/PoE/solar stuff: http://www.i4wifi.eu/miniPCI-cards-1/
 
 
 
Well, SATA and mSATA differ here only mechanically so you can always use simple adapters to convert between (if you also want to supply power to disk/SSD then it gets tricky since voltage levels are different -- but fortunately that doesn't apply to my case, I just want the Omnia as a powerful edge router, print server and also for encrypted TimeMachine backups serving a couple of Macs here using a large 3.5" HDD)

The problem is that you are able to bring up a VLAN config only after the switch already interconnected WAN and LAN ports. If you don't care about security or just want to fool yourself: Then this is a perfect choice. If you're concerned about security then this is a no-go. Unfortunately the vast majority of Lamobo R1 users is a bit concerned about security and knows exactly nothing about this problem. That's why at leat I insinst to point that out.
 
Regarding SATA and either the Clearfog Base/Pro or the Turris Omnia. If it's really too hard for you to image that you can use a simple mechanical adapter to get 1 or even 2 SATA ports then I'm not able to help you, sorry:
 

 
Marvell ARM SoCs are unlike Allwinner's dedicated for NAS and router things, they've several PCIe lanes and also 2/3 GbE interfaces that do not suffer from performance problems like the R1 does. According to Turris they also try hard to get CESA working so VPN and other sorts of encryption stuff won't burn the CPU but run on a dedicated crypto engine. They will try to send their patches upstream. SinoVoip/Foxconn neither develop own stuff nor are the crappy results worth a look.
 
And while Tido is still begging to get schematics for the crapboard I prefer vendors that provide a complete set of documentation on their own: http://wiki.solid-run.com/doku.php?id=products:a38x:documents or https://www.turris.cz/en/hardware-documentation(at the moment only older products available, the Omnia will follow soon)
 
BTW: You might be surprised that the A20's OTG port is not a full replacement for an USB host port. But maybe you don't care that much like you don't care about the security implications the R1 switchboard shows.
 
I'll stop here since the discussion gets a bit futile -- at least for me (being happy that such a superiour device like the Omnia is available for that low price -- no, I'm not the type of guy that wants to play only with the cheapest crap available, therefore never ever an R1 again )

Whether the BCM53125 is capable or not has to be confirmed. If it can not be configured to separate 1 GbE PHY from the other 4 at startup the switch is not useable for routing purposes. Since BroadCom usually doesn't send out the informations you need unless you sign an NDA and order high numbers of components I doubt we will ever know. Anyway it's not useable together with the A20 as far as I understand (since you can only combine the internal EMAC/GMAC with either one externel Fast or GbE PHY).
 
Therefore the whole idea to use this switch for routing purposes is still just a moronic idea that can't work. It's that simple, just try to accept it. A device that interconnects the networks it has to separate by default can not be called a router. After powering on or when the configuration is not appropriate it's just a dumb layer 2 switch that might be configured to use VLANs (and it has to be confirmed if the VLAN implementation is sufficient from a security point of view). 
 
Regarding the power issues nothing has been 'solved'. Only workarounds exist and both the manufacturer of the device and resellers leave it up to you to find the description of possible workarounds somewhere else. I already linked exactly to this thread for a reason: http://www.bananapi.com/index.php/forum/general/391-why-the-sata-disk-doesnt-work-on-bpi-r1?start=36#3624
 
If we only had to deal with software issues maybe this device could be recommended. But the many hardware design flaws (power, Wi-Fi, heat) can't be fixed and as we've seen recently the manufacturer simply doesn't give a shit about these issues. Foxconn/SinoVoip replaced the DC-IN barrel jack on Banana Pi M3 pre-production samples with the crappy micro USB connector and results are as expected. Sudden power-offs already with slight load: http://forum.banana-pi.org/t/banana-pi-bpi-m3-android-5-1-1-image-update/754/5
 
The manufacturer only cares whether you buy his products and not whether you can use them too. Only possible conclusion: Avoid these products or fool yourself.

I'm getting tired of all that crap people believe without thinking just a second.
 
Any 2D/3D game running in Android fully utilises the GPU core(s) therefore you won't see that much CPU activity. But GPU activity can lead to high consumption too (ARM just recently announced Mali-470 as being twice as energy efficient as the outdated Mali400 from 2008 used on the A64!) Any video playback running in Android fully utilises the VPU/CedarX therefore you won't see that much CPU activity. But VPU activity can lead to high consumption too Any marketing person producing a video to proof that while playing a game consumption does not exceed 2.5W, pausing a game and then showing the consumption ONLY while the SoC is totally idle (neither before pausing the game nor after the PSU's display is shown) showcases just the opposite: If consumption is just 2.5W while being idle the consumption MUST be higher while gaming. It's that simple: If consumption would not exceed 2.5W while playing Angry Birds they would've shown it in the video. But they prefered to show idle consumption only so the conclusion is simple Apart from that that's also an interesting statement regarding the target audience BTW: Both A20 and H3 boards I've here idle at 1.5W-1.7W. Therefore either the A64 wastes energy when being idle (unlikely since Cortex-A53's strength compared to A7 is not more performance but just less consumption when using optimised software) or there's something wrong with the board or (cpufreq/dvfs) settings.

Latest version being 4.2.x? And do you realize that repackaging the work others have done is quite simple?
 
@Igor: Might be the best idea to close/delete this thread to prevent further misuse.
 
@gerhardw: 'Integrating' a new kernel build including some patches for a switch IC into a distribution that's already prepared for and using mainline u-boot/kernel isn't comparable to the challenges the Pine64 people try to delegate to the community now. All they have is the A64 BSP from Allwinner that's suited for Android device developers. And while this BSP might be a good choice for those sort of people that do not care about sane code, kernel versions or software at all (they just want to sell their tablets using Android Lollipop) the standard SDK/BSP makes it really hard to transform it into a flexible build environment necessary for any SBC.
 
I would suspect mainline kernel/u-boot will be ready maybe sometimes in 2016 so all the Pine64 guys can do is to try to find someone who knows the platform, who knows Linux, who knows Allwinner's horrible BSP and can disassemble the BSP into something flexible and useable (relying on Allwinner's outdated u-boot and 3.10 kernel in the meantime). Currently it seems they search for someone that does that for free 

Running Android you are able to use GPU/VPU with HW acceleration and the ARM cores aren't used that much. Unfortunately linux is a different story and you'll come across users that really like to benefit from the 'quad-core A53 at 1.2GHz' since you advertise this as an SBC. Then you probably realise the difference (Allwinner SoCs aren't fast but cheap. Since the A64 is said to be able to be clocked up to 1.2 GHz I would suspect it's rather slow compared to other A53 designs and produced in an inefficient 28nm 40nm process)
 
Regarding benchmarks: They're all wrong. A good starting point when it's only about CPU performance is http://slideshare.net/brendangregg
 
But in your situation there's something special: Since you focus on Android CPU performance doesn't matter that much. It's GPU/VPU performance and the former definitely sucks (Mali400MP2 -- old and slow). But most people won't realise that since they focus on irrelevant metrics like "64 bit is twice as much as 32 bit" or "2 GB RAM is twice as much as 1 GB" or "15$ is less than $16" even if they can't tell how that really affects their use cases. You're lucky guys
 
But in case you really want to provide a good 'Linux experience' there's a lot to do.

True That's why I wrote 'The idea the R1 is based on is good'. But you're absolutely right: the SoC, the board and the single layer 2 switch for both WAN and LAN ports are wrong. The new Marvell ARMADAs with 2 or 3 independent GbE interfaces seem to be way more suited. 
 
13 days left: https://www.indiegogo.com/projects/turris-omnia-hi-performance-open-source-router#/
 
You get just the board for $99 + shipping -- given the state of R1's Wi-Fi (unuseable crap) it's simply a no-brainer to throw the R1 into the bin and pledge. I would believe the 500K stretch goal will also be reached so you get also a *good* metal case for this board for the same price.
 
Apart from that: Thanks for all the useful links. Will look through them (next year ) but not with the R1 in mind but more focused on A20's GMAC and SATA performance in general (still hoping for the quad-core A20 successor Olimex spread rumours about)

The only feature that's interesting on the Raspberry Pi is that one can use the VPU correctly now (after a few years). We use RPi B+ as IP camera (even when the CPU core is clocked with just 200 MHz the VPU is able to provide a 1080p@30 fps h.264 encoded video stream) or for digital signage, often combined. In the meantime also lightweight distros exist like http://dietpi.com
 
For everything else the RPi is always the worst choice due to its one single USB 2.0 connection to the outside.
 
Supporting the RPi would mean Armbian either focuses on a completely new use case (desktop stuff -- VPU) or on a completely new user base (clueless people).

I got my USB/UART for odroid XU4 from Hardkernel/South Korea, for testing.

The only feature that's interesting on the Raspberry Pi is that one can use the VPU correctly now (after a few years). We use RPi B+ as IP camera (even when the CPU core is clocked with just 200 MHz the VPU is able to provide a 1080p@30 fps h.264 encoded video stream) or for digital signage, often combined. In the meantime also lightweight distros exist like http://dietpi.com
 
For everything else the RPi is always the worst choice due to its one single USB 2.0 connection to the outside.
 
Supporting the RPi would mean Armbian either focuses on a completely new use case (desktop stuff -- VPU) or on a completely new user base (clueless people).

I think working on CSI is still "work in progress" in mainline kernel. And regarding the OV5460 it's not worth the efforts. This is a "5MP" camera and I've never seen anyone being able to get more than 640x480 pixels with questionable quality out.
 
I tried to get an idea why and stumbled across a freescale forum (IIRC) where one engineer said that it's hard to write a driver for this module without loading/using BLOBs with tables for conversion (or something like that) on the camera first. In short words: If you don't sign an NDA with Omnivision you won't be able to write a driver for this module that doesn't suck.
 
We still use the RPi (B+) for this purpose. And the difference are just the drivers (for both the VPU -- HW accelerated h.264/1080p@30fps -- and OV5647 -- image quality)
 
Today I stumbled across these links: http://www.arducam.com/camera-modules/raspberrypi-camera/  and http://www.arducam.com/camera-modules/5mp-ov5640/
 
No idea how to deal with currently (maybe they've drivers that work better, but this still won't help with mainline kernel)

It's possible to both overvolt the CPU and undervolt the board
 
These are two different things. You define in the so called dvfs table a few operating points with a relationship between CPU clockspeed and voltage provided to the CPU cores. The basic principle is that you define the Vcore voltage as low as possible since this helps with consumption, temperatures and longevity. But the problem is that if you need higher clockspeeds you also have to increase the Vcore voltage to still let the chip run reliably.
 
There exist some recommended values from Allwinner for every SoC ("Vcore not lower than 1.04V and not higher than 1.2V for example") and responsible vendors follow these advices. Most H3 devices (OTT boxes) come with a dvfs table only containing 2 operating points:
1200 MHz @ 1.3V 1008 MHz @ 1.2V This is OK and leads to a Vcore voltage of 1.3V when clocked at 1008 MHz or above and 1.2V when running slower (most devices are configured to clock lower when idle and to increase clockspeeds only under full load -- and only then Vcore increases also). Xunlong then simply stayed with 2 operating points and increased both cpufreq and Vcore voltage (necessary to reach the 1.53 GHz they advertise as "1.6 GHz"):
1536 MHz @ 1.5V 1200 MHz @ 1.3V That means the H3 is always volted with the maximum all other devices use (1.3V) and if clockspeeds exceed 1200 MHz even with 1.5V (0.1V above the recommended upper limit). And this overvolting is the root cause for all the thermal problems Orange Pi users experienced in the past. I tried to document the overvolting/overclocking history here.
 
Regarding DC-IN it's something different. There you should supply 5V but since many USB cables are simply crap and micro USB has very tiny contacts you might run in undervoltage situations easily (DC-IN dropping below 4.6V or even lower). SoCs that are accompanied by a PMIC/PMU will be powered-off in such a situation by the PMU to prevent damage. The Orange Pi PC has no PMU but a few voltage regulators that might work even with 4.5V. But for connected USB peripherals or HDMI this is already way too low. Therefor the barrel plug the Orange Pi's are equipped with is an advantage compared to boards that use [micro] USB since you've to consider that DC-IN also has to provide power to external USB devices and other board components.
 
And as you can see above it always depends. When you want to use the Orange Pi PC just as a headless server and let it run at 1.2 GHz with a sane dvfs table the whole board's consumption won't exceed 3.5W so 5V/1A would already be enough. In case you attach 4 bus-powered USB drives even 5V/3A won't suffice (you would've to study the schematics or simply try it out to get a clue where the limits are)

Yeah! And since you included iozone to the list of default packages I'm proud to present the fastest USB 2.0 device in the world: The Orange Pi PC: 39 MB/s write and 41.5 MB/s read (average value of 4K/1M record size). I've never seen better results. Mainline kernel and UASP did the job.
 
All I did was overwriting the contents of the 'Plus' .dtb with the one from OPi PC followed by a reboot.

This "up to 1.6 GHz" marketing chitchat is the source of all the heat problems the H3 is blamed for. But you can simply fix that by using better dvfs entries. In the meantime the linux-sunxi devs developed a dvfs table and thermal values (throttling and in case of emergency shutting CPU cores down) that work even without a heatsink in most situations.
 
Every Raspberry Pi has just a single USB 2.0 connection to the outside. All USB ports and network have to share this: http://linux-sunxi.org/Sunxi_devices_as_NAS#Network.2Fstorage_not_blocking_each_other
 
Given that we will see rather sooner than later the H3 being supported by mainline kernel (at least for the headless stuff you're talking about) the OPi PC might be worth a try (4 independent USB ports and also independent 100 Mbits/sec networking). Regarding encryption: Allwinner SoCs do contain a crypto engine called 'Security system' still being work in progress in mainline kernel: http://linux-sunxi.org/Mainlining_Effort#Major_drivers
 
But even without that the H3 should outperform any RPi 2 in your setup due to better I/O and network bandwidth. The H3's integer performance when clocked at 1.2 GHz is also better than the BCM2836's (even when clocking the latter with 1.0 Ghz which should work flawlessly even without a heatsink).
 
The RPi 2 is superiour in different areas due to driver support (both GPU and VPU) but as long as it's about integer performance and bandwidth (both I/O and network) the H3 wins. 

Another look at another SBC: The Orange Pi PC from Shenzen based Xunlong.
  The company claims to have done the original ODM work for Banana Pi as Foxconn contractor and started with 2 'Orange Pi' models based on the same A20 SoC shortly thereafter: 'Orange Pi' and 'Orange Pi Mini' -- both supported by Armbian from the beginning.   Then they released the 'Orange Pi Plus' based on a newer Allwinner SoC: the H3 (quad-core Cortex-A7 running at 1.2GHz). This SoC is intended for dirt-cheap OTT boxes, is equipped with 4 independent USB 2.0 PHYs and also an integrated 100 Mbits/sec Ethernet PHY (but can still provide GBit Ethernet using an external PHY like RTL8211 as Xunlong implemented it on the 'Plus').   The 'Orange Pi 2 [Plus]' followed, then the $15 'Orange Pi PC' was released and a new 'Orange Pi One' has been recently announced to be available for less than $10. CNX provided a nice comparison table here (but keep in mind that "SATA" means not SATA but an ultra-slow GL830 USB-to-SATA bridge and that "4 USB ports" means "slow due to shared bandwidth and internal USB hub")   In my opinion the only H3 based Orange Pis worth a look are the 'PC' and the upcoming 'One' since the H3's feature set is quite unimpressive but its design makes it possible to produce really cheap boxes/boards without that much additional components on the PCB (no PMU needed and already containing an internal Ethernet PHY and 4 USB PHYs).   The H3 SoC has been blamed for overheating way too much but fortunately this is just the result of Xunlong trying to advertise their H3 based SBCs as being able to run at "up to 1.6 GHz" and community members providing OS images with overclocking in mind. They did a really bad job modifying both dvfs and thermal settings and therefore their forums are full of complaints that CPU cores are shut down due to overheating or that you would need large heatsinks and also a fan to be able to use the H3 reliably.   Fortunately these issues have been resolved in the meantime, the linux-sunxi community moves forward really fast with u-boot/kernel mainlining efforts for the H3 and real OSHW designs will also follow soon (Olimex plans to release two SBC based on H3). So I believe we will be ready with Armbian support for Olimex' and Xunlong's boards as soon as mainline kernel will be ready for H3. Igor started already to support the H3 based Orange Pis in Armbian-- see below.   Let's have a look at existing hardware: The $15 Orange Pi PC. For latest informations always rely on the linux-sunxi wiki.   Getting started   To power the board you've to provide 5V through the power barrel connector or GPIO pins 2/4/6 (2/4 are connected to the DC-IN test point and 6 to GND). You can not power the board through micro USB since unlike other sunxi devices the H3 comes without PMIC/PMU (therefore also no support for a battery)   In case no SD card is inserted the SoC tries FEL boot mode through the micro USB port. OS images for the H3 can be found on the orangepi.org web site. As usual the manufacturer supplied images are broken more or less so better start with the ones from community member loboris (if you use them don't forget to donate!)   Unfortunately these intensified Xunlong's overvolting/overclocking attempts and increased a few values even more. But fixing is easy: I created a simple script (for Debian based distros only) that temporarely converts script.bin and replaces the wrong values with the linux-sunxi ones (should work with other H3 based Orange Pis as well)   On the left loboris' overvolted dvfs table while idling through all available cpufreqs and on the right after repair:     If you repaired dvfs/thermal settings you'll be surprised that you neither need a fan nor heatsink -- the H3 idles at 1.5W and exceeds ambient temperatures only by 20°C without a heatsink. But be prepared that thermal throttling might occur under high load if you safe the heatsink. You'll find a few comparisons with and without heatsink here: http://linux-sunxi.org/User:Tkaiser#Tests_with_just_a_heatsink   Since we want to use the OPi PC as cheap home automation controllers we evaluated the possible input voltage range. Good news: DC-IN voltage can vary between 4.5V - 5.5V when you neither need USB nor HDMI (DC-IN will be directly routed to the power pins of USB/HDMI).    Also the cheap camera module Xunlong sells for the different H3 models works flawlessly with just 4.5V. This makes it possible to power the board through 'el cheapo' passive PoE using the 2 unused cable pairs in Cat 5/6/7 cables. Real PoE works with 48V to avoid voltage drops over longer distances and it's a bit crazy to try PoE with just 5V. But when you use similar distances between PoE injector and devices and inject for example ~6V then the voltage range of 4.5V-5.5V will be fine. I suggested to Xunlong's Steven Zhao already to adopt passive PoE on the next Orange Pi One directly -- but he didn't get back to me.   I also developed a heavily undervolted dvfs table for headless useage (won't work with a connected HDMI display since the Vcore voltage seems too low for the display engine) that works here with 2 OPi PC without problems (tested under full load up to 1.2 GHz): http://linux-sunxi.org/User:Tkaiser#Headless_without_connected_USB_peripherals_and_4.5V_DC-IN ( don't think about adopting these settings unless you're willing to verify they work!)   Consumption/temperatures in headless mode:   The OPi PC idles at 240-600MHz: 1.5W, 20°C above ambient temperature. All thermal values being read-out internally using RPi-Monitor -- see below. I used also the H3 without heatsink so be prepared that temperatures are way lower if you attach a heatsink to the SoC.   Full load (cpuburn-a7 and sysbench running in parallel) on all 4 CPU cores:   240 MHz: not exceeding 2.0W, 25°C above ambient temperature 600 MHz: not exceeding 2.5W, 32°C above ambient temperature 1200 MHz: not exceeding 3.3W, 50°C above ambient temperature   2 CPU cores deactivated and testing again:   240 MHz: not exceeding 1.9W, 23°C above ambient temperature 600 MHz: not exceeding 2.1W, 29°C above ambient temperature 1200 MHz: not exceeding 2.8W, 40°C above ambient temperature   The multithreaded performance of 4 x 600 MHz and 2 x 1200 MHz is identical but when running at 600 MHz on all 4 cores the H3 already outperforms older dual-core Allwinner SoCs like the A20 easily. And since the lower the clockspeeds the less the Vcore voltage the SoC stays cooler and consumes less. Using a quad-core SoC for IoT stuff seems like overkill but if you clock the SoC down the 4 cores make perfectly sense.   Therefore we go with the following settings for 'IoT controllers' to ensure they don't exceed 2.5W consumption even under full load: echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq   With 8 OPi PC and a passive PoE injector like this one with these settings you're able to power the whole setup with a regulated 6V/4A PSU easily. And you still have the ability to double the performance of any device temporarely through echoing 1200000 to scaling_max_freq when needed.   Who would've thought that you can use H3 based Orange Pis as energy efficient IoT devices consuming between 1.5W and 2.5W without a heatsink since common knowledge was 'you need a fan!' just a few weeks ago.   Camera module   Xunlong sells also a cheap $6 camera module for the H3 based Orange Pi models based on GalaxyCore's GC2035 2MP sensor. When you want to use it with the OPi PC you'll also need an expansion board. When you order you've to tell Xunlong that you're using the OPi PC and they send the board together with the module:     The image quality is really horrible but at least you're able to use it with fswebcam or motion. I prefer the lowest resolution possible (640x480 pixels after applying these patches) because it makes no sense to store images with higher resolutions. At least motion works with the 2 fps settings currently possible and you might use OPi PC + camera module for surveillance purposes to detect motion.   Regarding consumption/temperatures: when running motion together with the camera continuously consumption increases by 500-600 mW and SoC temperatures by 2-3°C (clocked at 240-600 MHz)   For our use cases the H3 matches perfectly. If you fix the overvoltage/overclocking problems Xunlong introduced then you get a device that consumes between 1.5W and 2.5W and being already more performant when running at 600 MHz than older dual-core Allwinner SoCs. Using a quad-core SoC for IoT things makes sense since the SoC can run at very low core voltages which really helps with saving energy.   Other use cases   Regarding I/O bandwidth the H3 provides 4 independant USB ports that might be able to benefit from UASP with mainline kernel soon. So any H3 device with GBit Ethernet would make a nice NAS device. But since the older A20 features native SATA a better solution for building a NAS would be to get a pcDuino 3 Nano Lite for the same price. Some background infos as usual in the wiki: http://linux-sunxi.org/Sunxi_devices_as_NAS   At the moment some people are trying hard to get OpenELEC running on the H3 and also progress is made to use HW accelerated video decoding. Since this stuff is WiP you should monitor these threads closely:   OpenELEC HW accelerated video decoding   RPi-Monitor   I adjusted RPi-Monitor templates for the H3 and also wrote a small daemon to be able to monitor temperature/consumption related to Vcore settings (using the dvfs table settings in script.bin). Please refer to the thread in the Orange Pi forums.   All you've to do is to install RPi-Monitor in the usual way, stop it and then do the following (depending on your distro being wheezy/jessie based) followed by a reboot:  cd / && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-H3.tgz | tar xzf - update-rc.d rpimonitor-helper defaults 90 10 systemctl enable rpimonitor-helper systemctl start rpimonitor-helper Update: In the meantime this has become a simple one-liner confirmed to work an all Debian based OS images for H3 boards. And in case you're running Armbian then it's just a a simple 'sudo armbianmonitor -r' call that installs/adjusts everything needed on any H3 board.