manuti

The following is a short overview what you can expect from small and big H3 devices when used as a NAS. I chose the least capable device (OPi Lite for $12: not even Ethernet and just 512MB DRAM) and the best possible (OPi Plus 2E for $35: GBit Ethernet, 3 USB host ports exposed that do not have to share bandwidth, 2GB DRAM).
    I wanted to test also a H3 device in between with 1GB DRAM but since results are somewhat predictable I dropped the whole idea (the performance bottleneck on all Fast Ethernet equipped devices will be network unless you add the $7.50 for an USB-Ethernet dongle -- see below -- and all other Gbit Ethernet capable H3 devices are not priced competitive)   Low end   3 weeks ago I ordered 2 cheap USB3-Ethernet dongles (Realtek RTL8153 based and recommended by @Rodolfo): http://www.ebay.com/itm/141821170951   They arrived in the meantime so I thought: Let's make OPi Lite an Ethernet device. With our current legacy kernel config and network settings you simply connect the adapter and an Ethernet cable, boot and have eth0 up and running (well, this should apply to most available USB-Ethernet adapters since we enabled every device available in kernel config). The dongle according to lsusb: Bus 001 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.   Since I want Lite's both USB host ports for disks, I used the OTG port and a Micro USB to USB adapter: a simple iperf test against a GbE device showed 270/300 Mbits/sec (depending on direction).   Power requirements when adding Ethernet using this dongle: Plugging in the dongle without network cable attached: +700mW Connecting network cable to USB dongle (GbE!): another +400mW GbE transmission in one direction (limited to ~300 Mbits/sec): another +800mW So you can calculate with ~2W additional peak consumption per Ethernet adapter (at least 1.1W more if connected to a GbE network -- this is slightly more than the average 0.9W on Gbit Ethernet equipped SBC when the usual RTL8211E PHY establishes a GBit connection)   I connected then a 3.5" Seagate Barracuda with external PSU (ext4 since with a 3.4 kernel we can not use more interesting filesystems like btrfs -- iozone shows ~35MB/s in both directions), compiled Netatalk 3.1.18 and tested NAS performance from my MacBook (no further tuning except 'echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' -- without this write performance totally sucks):     Read performance is quite ok given that iperf shows just 270-300 Mbits/sec but write performance needs some tuning (not today). By looking at 'iostat 5' output it was obvious that write buffers were flushed only every few seconds so for normal NAS useage with small files the whole problem doesn't exist and it also should be possible to increase performance (not today). Anyway: search the net for correctly measured performance numbers of other SBC used as NAS and you will be already satisfied given that we're talking here about a $12+$7.50 combination   High end   Orange Pi Plus 2E is -- in my very personal opinion -- the best H3 device available if you think about NAS useage. It is equipped with the maximum amount of DRAM H3 can deal with, has Gbit Ethernet, exposes all 3 USB host ports + 1 OTG and comes with 16GB of pretty fast eMMC. At a competitive price (please keep in mind that you can install the OS on eMMC so you don't have to add the price of an SD card here).   You can attach up to 4 USB disks (with mainline kernel and UASP capable enclosures they will show sequential speeds close to 40 MB/s, with legacy kernel it's ~5MB/s less)     What you see here is the result of Gbit Ethernet paired with way more RAM and a test data size too small (only 300 MB fit perfectly into memory) so this is the increase in speed you will benefit from in normal NAS situations (dealing with files that do not exceed a few hundred MB in size). In case you try to write/read files larger 1 GB (or use software that often uses sync calls to ensure data is properly written to disk) be prepared that USB 2.0 becomes the bottleneck. In these situations sequential transfer speeds between NAS and clients will drop down to ~32MB/s without further tuning (applies to legacy kernel, for mainline see new post coming in the next days)   Anyway: Please keep in mind that these are 'single disk' measurements. You can attach up to 4 disks to an OPi Plus 2E (using individual spindown policies to save energy or RAID modes to improve performance and/or availability), with Armbian defaults at least two of them can be accessed concurrently at full speed (USB2 maxing out at ~35MB/s and GbE being able to exceed 70MB/s easily) and with some tuning that might apply even to 3 disks accessed at the same time.   And if I compare these benchmark results based on defaults (burning Armbian to SD card, firing up the NAS software, measuring performance, done) with what had to be done prior to being able to simply use Armbian as 'NAS distro of choice', eg. these one year old results with A20 then choosing OPi Plus 2E is a no-brainer.   Regarding OPi Lite (or One or the smaller NanoPi M1) as NAS: This was more proof of concept than a recommendation. Being able to use as much RAM as possible for buffers is something especially a NAS / fileserver benefits from. So choosing a device with only 512MB is not the best idea. 'Native' Gbit Ethernet as present on a few H3 devices also clearly outperforms USB based solutions (iperf throughput with a recent Armbian without any tuning: 680/930 Mbits/sec). And if you add costs for USB-Gbit-Ethernet adapter and SD card the smaller boards aren't priced that competitive any longer.

Me too. Please stop using Armbian now and use any of the other available OS images: http://www.orangepi.org/downloadresources/

Hello,
 
I wish to share my research on getting OpenGL to work on Mali GPU. I realize Armbian focuses on server images, but I suppose many people would be interested nevertheless. I have a Banana Pi Pro and an Orange Pi PC, which both have a compatible GPU. Perhaps it will work on other boards as well.
 
Here are the commands I used to get OpenGL to work.
 
1. Install:
# install GLX Gears, mesa GL and GLU libraries apt-get -y install mesa-utils # install development tools apt-get -y install build-essential automake pkg-config libtool ca-certificates git cmake subversion # install required libraries apt-get install libx11-dev libxext-dev xutils-dev libdrm-dev x11proto-xf86dri-dev libxfixes-dev # get source code git clone https://github.com/robclark/libdri2 git clone https://github.com/linux-sunxi/libump git clone https://github.com/linux-sunxi/sunxi-mali git clone https://github.com/ssvb/xf86-video-fbturbo git clone https://github.com/ptitSeb/glshim # install mali driver cd sunxi-mali                                                                    git submodule init                                                               git submodule update                                                             git pull                                                                         wget http://pastebin.com/raw.php?i=hHKVQfrh -O ./include/GLES2/gl2.h             wget http://pastebin.com/raw.php?i=ShQXc6jy -O ./include/GLES2/gl2ext.h    make config ABI=armhf VERSION=r3p0                                               mkdir /usr/lib/mali                                                              echo "/usr/lib/mali" > /etc/ld.so.conf.d/1-mali.conf                             make -C include install                                                          make -C lib/mali prefix=/usr libdir='$(prefix)/lib/mali/' install            cd .. 2. Build
# Step 1: build and install helper libraries cd libdri2 autoreconf -i ./configure --prefix=/usr make make install cd .. cd libump autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 2: build video driver cd xf86-video-fbturbo autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 3: build GL wrapper cd glshim cmake . make cp lib/libGL.so.1 /usr/lib/ # replace the software GL library with the wrapper cd .. 3. Configure your system
- configure your kernel to allocate memory for the GPU
- make sure mali and mali_drm kernel modules are loaded
- give your user permissions to access /dev/ump and /dev/mali
- configure Xorg to use fbturbo driver
 
4. Test:
# run a basic test glxgears # install and run a GL benchmark apt-get -y install globs /usr/lib/globs/benchmarks/GL_pointz/gl_pointz # try to run a real game apt-get -y install billard-gl billard-gl This all worked out for me rather nicely. The only issue I have encountered is a segfault that many GL programs get when they shut down. I'm currently debugging this issue, but it would be helpful to know others experience it as well, and perhaps get some advice from people experienced in GLX or SDL.
 
Edit: I know glxgears is not a real benchmark, but let me give you some numbers to make it clear what I'm talking about. Results are from Orange Pi PC clocked at 1296000 Hz (and are CPU-bound):
user@bananapi:~$ glxgears LIBGL: Initialising glshim libGL: built on Jun 12 2016 06:12:01 LIBGL: Current folder is:/home/user libGL:loaded: libGLESv1_CM.so libGL:loaded: libEGL.so 2074 frames in 5.0 seconds = 414.688 FPS 2071 frames in 5.0 seconds = 414.085 FPS 2070 frames in 5.0 seconds = 413.915 FPS ^C

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

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

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)

Just as an addition since as usual stuff already exists on the internet:
Regarding the combination of rsync with btrfs: https://github.com/oxplot/rsyncbtrfs And in case mainline kernel is used and a custom Armbian image not using ext4 but btrfs instead the whole approach will be even more efficient since then 'btrfs send/receive' could be used between SBC and backup host: https://github.com/yoshtec/snapbtrex

For private projects consider https://bintray.com or similar. Those services are reliable and usually free for such usage.

Now information collection regarding OPi Lite is almost done. I tried to enhance the wiki article for Orange Pi One combining it with Lite and also tried to add everything that's known/relevant now: http://linux-sunxi.org/Xunlong_Orange_Pi_Lite
 
Please help improve state of information/documentation since I made mistakes for sure (as usual ). Get a linux-sunxi account please and correct what's wrong. Thx.

What an amazing team! Thank all of you so much for all the work... I did a fresh install on one of my OPi Lites and wireless is up and running in no time - and it works pretty damn good, much better than a RPi3 sitting in the exact same spot on my bench!

Wifi is fixed on all H3 boards. I will push new update later in the evening where 8189fs and 8189es are updated. I made brief testing and AP mode also works on both chips.

Well, your work is wonderful, and I really think you're doing a great job.  I think there's similar attitude problems at Banana Pi communities.
 
I want you to continue supporting Orange Pi H3 boards, for sure.  They are the most powerful working implementation I have found so far.

Wow! Guess who made the original picture: http://linux-sunxi.org/File:Orange_Pi_One_Top.jpg#filehistory
 
Someone sent me two pictures from Orange Pi forums (which I've not visited since 5 months), I combined those two images in Photoshop so that the image alone should be significant enough to get the idea and forgot to mention "@GUTEK@ the greatest artist on planet" since I didn't even know that the great @GUTEK@ was responsible for creating this masterpiece of art (combining a screenshot from schematic with someone else's photo). I truly apologyze for my mistake. Will correct that immediately!
 
OMFG! It was such a mistake starting to support Orange Pi H3 boards.

I had to blacklist the standard realtek module in order to get things to behave with the patched one that comes with the distro
lane@orangepione-2:~$ cat /etc/modprobe.d/wifi-blacklist.conf  blacklist rtl8192cu Prior to blacklisting, it would just crash and reboot as soon as the wifi module loaded.  
 
This was using one of the little rt8192 dongles from adafruit running an armbian image I built from the repo yesterday.

@p117
 
Welcome on board.
 
USB-dongles are usually auto-mounted on a newly created mount point in /media. This is how you force it to be mounted at a predefined
mount point.
 
1. Create a new mount point for your USB-dongle
 
sudo mkdir /mnt/mydrive
 
 
2. Plug in your USB-drive and check the partition name ( e.g. /dev/sda1 ) Your drive is most likely formatted as vfat.
 
sudo blkid
/dev/mmcblk0p1: UUID="56a9eae3-fd35-47d4-a01c-00251c2d6a8d" TYPE="ext4" PARTUUID="00003286-01"
/dev/mmcblk0: PTUUID="00003286" PTTYPE="dos"
/dev/sda1: UUID="4732-9959" TYPE="vfat"
 
3. Use the unique identifier (UUID) of the filesystem on your USB-drive and add an entry to your /etc/fstab
 
 
sudo nano /etc/fstab
 
#----sample fstab-entry to mount specific USB-drive
#    the unique identifier UUID can be queried with
#    blkid
#

UUID="4732-9959"  /mnt/mydrive   vfat    defaults,noatime        0 2
 
4. When you reboot, the USB-drive will be automatically mounted at /mnt/mydrive. Adjust permissions if needed.
 
5. Enjoy
 
 
 
 
 
 
 
 
 
 
 

Thanks!!! Awesome work!!!

There is a huge overscan on this boards and your login screen is hidden bellow. Just enter default login and pass and change resolution later, or adjust screen position with your monitor controls. If you use Desktop version of image, it will boot after you change your root pass, create new account and reboot. I was confused too at the beginning, but there is nothing wrong with the OS.

Yes I need to try again, maybe I made some mistakes testing your awesome OS running on the Orange Pi One.

It's important to believe blindly in numbers! At least when you try to be mislead as much as possible!
 
Yesterday Michael Larabel from Phoronix fired up his usual set of passive benchmarking tests for the new Raspberry Pi 3 and he still uses rather questionable results for other boards to compare with (he claims that it would be sufficient to use a board with 'factory settings', run a set of synthetic benchmarks, don't analyse the results or even think about whether they could be wrong and treat the results as the truth)
 

 
RPi 3 is 4 times faster than OPi PC and 6 times faster than OPi Plus? Really?
 
If you just try to think about these graphs for a second it's obvious that there must be something wrong: Testing Orange Pi PC and Plus individually already makes no sense at all (same SoC, same settings --> same performance results to be expected) and publishing results that vary that much is alarming: either your benchmark must be wrong or the conditions or the tester. If you just think a second it's obvious that Orange Pi PC and Plus have to be faster than Banana Pi M2 (also an Allwinner ARMv7 SoC clocked a bit slower) and that you should drop any results if you experience a difference of more than 10% between both boards that must perform identical.
 
So I took our Armbian 5.05 release candidate and tested 2 of Phoronix' benchmarks on an H3 based Orange Pi (and then stopped this waste of time):
 
C-Ray: 340 with Armbian vs. 1425 according to Phoronix. Using Armbian increased the performance by over 400% (if you're dumb enough to rely on 'benchmarking gone wrong')
John the Ripper: 558 with Armbian vs. 315 according to Phoronix. Using Armbian increased the performance by 77% (if you're dumb enough to rely on 'benchmarking gone wrong')
 
Confusing! Why is Armbian way faster?! And why does choosing Armbian speeds up your Orange Pi in one case over 4 times and in the other case just by 77%? Let's have a closer look:
 
How does Armbian differ:
We are able to use 1.3GHz as CPU clockspeed (might speed things up) For reliability reasons we clock the DRAM lower (might slow things down) Most importantly: We don't use braindead thermal throttling settings (and I used a heatsink/fan) And the latter is the most important issue that Michael Larabel seems to miss at all when he uses the 'benchmark' results he collected sometimes ago to compare between different hardware. It's 2016 now! Each and every more recent SoC is a throttling candidate. This has to be taken into account if you want to benchmark a SoC or a board. If you ignore this your results are plain bullshit (just like Michael's).
 
When he tried to 'benchmark' Orange Pi PC and Plus he obviously ran into the problem that the vendor's budget cooling settings favoured killing CPU cores instead of thermal throttling so he obviously ended up with just one active CPU core left after some time of testing. And while this was an important finding (OS images for Orange Pis all crap more or less back then and negatively influencing performance) it's also important that this is nothing the hardware has to be blamed for.
 
The very same board running with Armbian performs more than four times faster! Think about. So obviously the benchmarks Phoronix recommends do not test the hardware but something else instead.
 
To be clear: the Phoronix test suite is fantastic when used correctly. That means ACTIVE BENCHMARKING and not collecting meaningless numbers and then relying on these worthless numbers to draw the wrong conclusions. When using the Phoronix test suite correctly you can identify performance bottlenecks and boundary conditions that affect performance easily (wrong cpufreq governor, killed CPU cores, thermal throttling, wrong settings, whatever). And also what to do to increase performance (tweaking compiler/scheduler settings, constantly trying out to optimise things until it works better).
 
The worst thing you could do with the Phoronix test suite is to collect numbers without meaning (passive benchmarking) and then use them to draw the wrong conclusions (that's what most of Phoronix' users including the author of the test suite do all the times).
 
Back to the origin again: We started with the Raspberry Pi 3 and 'benchmarking gone wrong' the Phoronix way. You really should take the numbers Michael/Phoronix published with a grain of salt since he neither mentioned whether throttling happened nor he commented on the consequences for the RPi 3 if the RPi foundation understands that it's necessary to provide a Raspbian version that is ARMv8 optimised.
 
The RPi foundation claimed the new RPi 3 would outperform the RPi 2 by 50% using questionable sysbench results. If they would've optimised their Raspbian code base for ARMv8 they could claim the RPi 3 would be at least 15 times faster. Why? Because benchmarks are always wrong and using sysbench (that calculates prime numbers) can't be used any more to compare between different ARM architectures (or architectures in general): http://forum.odroid.com/viewtopic.php?f=136&t=19158(I'm really curious whether Phoronix gets that when 'benchmarking' ODROID C2)
 
TL;DR: Benchmarking is fine as long as you use it to optimise software and to rule out insufficient hardware. When used wrong it's misleading (unfortunately that happens most of the time)

Finally is in Spanish, I don't know why the system refuse to change for the first time. The worst thing is that: I don't know what of the many files touched and changed things is the way to change the Desktop language.

Yes - that is exactly what I mean. Real people doing real stuff for real. RK was progressing nicely and then unfortunately stumbled over their own greed. Actually, I would prefer a stripped OrangePi (ONE/LITE without LAN, WIFI, OTG) with 3xUSB2 and solder pads for the rest, power-optimized with a LiIon-battery-circuit for < $10. The next interesting board would be ARM64-based, exposing USB3 and featuring HW-accelerated graphics for <$20. LAN/WIFI/SATA are no problem with properly exposed USB at highspeed/superspeed, avoiding crappy components on the boards.

Maybe my UG802 (RK3066 dual core) with Picuntu running several days a week as torrent downloader since 2012 and update from Ubuntu 12.10 to 14.04 and I hope in next months go to 16.04 is a good example of benchmark. And also chinese people lost an opportunity to have a PiZero killer 4 years ago.
 

 

Nice try but still insufficient.
 
Using passive benchmarking is only great if you want to collect meaningless numbers. When you use those tests for active benchmarking purposes then it will be way more time consuming and the one thing you will do most often will be... throwing results away since they're completely irrelevant.
 
Regarding 'sysbench --cpu' and trying to compare ARMv7 and ARMv8 (applies to RPi 3 also if RPi foundation will sometimes in the future switch Raspbian's codebase to ARMv8) everything is outlined here already: http://forum.odroid.com/viewtopic.php?f=136&t=19158#p127223
 
Running sysbench storage tests on an SD card... c'mon what are yout trying to achieve? Producing numbers without meaning or just the insight that if you want to run anything storage intensive then you should avoid using SD cards at all (using eMMC when available or moving both rootfs and database storage location to USB or SATA where available).
 
This is the only lesson you can learn from any storage bench when used on SBCs! And what do people do instead? Create graphs that are based on meaningless numbers.
 
Please don't get me wrong. Synthetic benchmarks can be very useful. A storage benchmark that is done correctly might provide the insight that on an Orange Pi Plus (eMMC and an ultra slow USB-to-SATA bridge onboard) it's braindead to move the rootfs to USB (some people still call it SATA for reasons unknown to me) but instead use the eMMC since it's faster. But measuring SD card speeds on an Orange Pi Plus is just a waste of time.

Thanks a lot Igor.
With Bananapi Debian 3.1 jessie 4.0.5. on a Banana PRO
first run OK intrnal Wi-Fi - OK after copy in /boot/dtb/ the file sun7..bananapro.dtb over sun7...bananapi.dtb and reboot thanks