Davey Darko

Yesterday he had also a great day, banned one account, censored a whole thread away and in two other threads important information:
here he deleted the last post mentioning that there's now also an Armbian Desktop image available (beta) And in this thread he deleted posts containing the following information: Firefox works without any problems on Armbian, that's simply since we install the armhf version by default on the desktop image since the arm64 version shows problems (this 'trick' can of course also be used to cure even the most crappy OS images for Pine64: on the broken Debian images from Pine wiki it's just 'apt-get purge firefox && apt-get install firefox:armhf' and those steps in between) Chromium with our Armbian desktop image is just a simple 'apt-get install chromium', there's really no need to install .deb packages from linaro or somewhere else. Using Chromium with '--disable-seccomp-filter-sandbox' is a bad idea, it would be better to address the problem (kernel fix needed?) If one wants to use '--disable-seccomp-filter-sandbox' though this can be added to all 'Exec' occurences in /usr/share/applications/chromium-browser.desktop So he managed to make Pain64 land great again, instead of informing people that there is software available that doesn't suck they (Pine Inc folks and their beloved premium moderator) ensure that no one knows, that people still use outdated, smelly and broken OS images containing numerous serious flaws and that nothing will change. Users are not informed that there are working 3rd party OS images existent in the meantime and users aren't tought how to use Firefox if they want since one person is allowed what he does best all the time: censoring everything he doesn't understand.

Awesome - I spent the whole morning reading this thread (and it killed my morning - which is a good thing!).
 
I learned more reading this whole 4 page thread - than in five months hanging around the Pine64 forum - I call that "moderator" a couple of nasty names - Pompous Princess - or Merkin777...  Can't believe the amount of bullshit information that "A" hole has steered me wrong with!
 
Thanks for all the insiteful info from contributors on this forum and this thread!

The out of control moderator just banned me. I PM that tllm or whatever the guys moniker is about the mods temper tantrum before I was banned. He first sent me a warning just because I gave neg rep on 3 of his posts, I hadn't even posted in that thread at that point. He does not have the temper to be a moderator on an Internet forum in my humble opinion.
 
I get better information here anyway, just like with OrangePis. Thanks Armbian!

Now setting display resolution in uEnv.txt is supported for Pine64 default kernel:
root@pine64:~# cat /boot/uEnv.txt ethaddr=ca:17:10:f7:2b:29 disp_mode=720p60 Available modes are listed in boot script. Al least 720p60 works for me in addition to default 1080p60

I also added DVI compatibility option (disp_dvi_compat=on), untested.

I added a script lurking around on my disk for some time to Armbian's repo to be hopefully included into future Armbian releases when testing looks good: https://github.com/igorpecovnik/lib/blob/master/scripts/h3consumption
 
Since it's just a script you can include it in your running Armbian installation simply by downloading it from Github -- try it this way please:
sudo -s wget -q -O /usr/local/bin/h3consumption "https://raw.githubusercontent.com/igorpecovnik/lib/master/scripts/h3consumption" chmod 755 /usr/local/bin/h3consumption h3consumption -H h3consumption -p The last 2 calls will show the verbose help text along with current settings. This might then look like this:
 
 
 
Mode of operation/test:
Please read through the description (-H output) first and check also the referenced links Use -p to get currently used settings Use the other switches to modify settings Do not use -p now but instead do a reboot first and then check again -p You might also have a look at /etc/rc.local and /etc/defaults/cpufrequtils to get an idea where the script does things for a better understanding Two examples (will go into details later in different thread😞
On an Orange Pi Plus 2E 'h3consumption -c 1 -m 1296 -d 408 -g off -e fast' reduces default idle consumption from 1650 mW by 780 mW to just 870 mW On an Orange Pi Lite 'h3consumption -D 132 -c1 -g off -u off' reduces default idle consumption from 1060 mW by 660 mW to just 400 mW (same low consumption running identical settings possible with NanoPi M1, Orange Pi One/PC/PC Plus and maybe the larger boards too when GBit Ethernet PHY can be completely disabled) Please note: the -D switch allows to use DRAM clockspeeds that are way below Allwinner's defaults and what's expected to work ok (since DDR3 shouldn't be clocked lower than 300 MHz and Allwinner used 408 MHz clockspeed as lower limit). While clockspeeds as low as 132 MHz seemed to work reliably in my tests and it should be ok to test these out when having in mind that this is an experimental feature you won't be able to go lower than 408 MHz anyway without a kernel patch (available in post #14 here) with all available official Armbian releases. So you've to either use the kernel .deb I provide in the other thread or wait for a new round of Armbian images (no idea how Igor's plans look like)

Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation.
 
Hi All,
 
I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room.
 
Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together.
 
However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as:
No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing.  
I should also note that this guide on the terrible Orange PI forums, helped me with my issues.
 
Step 1) Adjust /etc/lirc/hardware.conf
 
Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf
 
For Ubuntu Xenial (September 2017):
 
The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = ""
# /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD=""  
For Debian Jessie (~year 2016):
 
By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG.
 
Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works:
# Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service
  As lirc is actually already running and installed in Armbian, do the following:
 
root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. 
 
Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work):
  user@orangepipc:~$ lsmod Module                  Size  Used by mali_drm                2732  1 drm                   178255  2 mali_drm mali                  123208  0 ump                    29379  3 mali sunxi_cir               1601  0 8189es               1076034  0   Step 3) Find out what '/dev/input/eventX' device is your IR receiver   If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example:
anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals:
Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest
    Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input )   Armbian has the 'evtest' program installed, point the IR remote (in my case a  LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'.   root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events:   Event type 0 (EV_SYN)   Event type 1 (EV_KEY)     Event code 152 (KEY_SCREENLOCK)   Event type 4 (EV_MSC)     Event code 4 (MSC_SCAN) Key repeat handling:   Repeat type 20 (EV_REP)     Repeat code 0 (REP_DELAY)       Value    500     Repeat code 1 (REP_PERIOD)       Value    125 Properties: Testing ... (interrupt to exit)  
Pressing the remote reveals events like:
Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news.
 
 
Step 5) Configure lirc to map IR input to key presses or events.
 
Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys.
 
There's plenty of information on how to use irrecord, command I used was:
/etc/init.d/lirc stop ...to first stop the service, then:
irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'.
 
 
Step 6) Test with irw
 
Now that I recorded my configuration file with irrecord:
/etc/init.d/lirc start .. to start lird service again
 
then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button:
root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray!
  Step 7) Create a /etc/lirc/lircrc file to run commands
 
sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player:
# http://www.lirc.org/html/configure.html begin    button = KEY_R    prog = irexec    config = mpv  /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin    button = KEY_W    prog = irexec    config = killall mpv & echo "SADFACE!" & end begin    button = KEY_B    prog = irexec    config = mpv http://sj256.hnux.com & end   You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command.     So there you go, Rickrolling with a simple press of the red (KEY_R) button :-)  
 
 
Additional References:
[Guide] Android + InfraRed (IR) + Kodi 
How to setup Remote Control for Linux

Thanks for your help! By linux-sunxi community standards it took quite long (almost 8 hours between receiving your board and nailing the problem down) but when I took the bike to buy a new multimeter I met a friend and we ended up temporarely in Augustiner Keller drinking a Maß
 
BTW: Unfortunately I did the Samba tests not with 'my' board before so I can now only provide sequential performance numbers in direction Pine64 --> client (since even when powered through Euler connector your board behaves badly in RX direction, I have no bench PSU here so I can't try out whether providing 5.3V or 5.4V already cures the GbE issue):
 
That's a samba share on a RAID-0 made out of 2 Samsung 120GB SSDs (now part of a burn-in test since both SSDs are for a customer's server working there in RAID-1 mode): One EVO 750 and one PM851:
 
 
 
I simply measured time to complete copying a 1GB file from the USB RAID-0 via SMB from Pine64 to my MacBook:
macbookpro-tk:~ tk$ du -sh /Volumes/raid-0/1gb_zeroes.file 1,0G /Volumes/raid-0/1gb_zeroes.file macbookpro-tk:~ tk$ time cp /Volumes/raid-0/1gb_zeroes.file /tmp/ real 0m14.152s user 0m0.003s sys 0m1.804s So the bottleneck is storage (the RAID-0 maxing out at 73MB/s -- OS X Finder dynamically adjusts the read block size to the maximum, something you have to take into account since it affects performance of the first test run being made!) which is good news if we keep in mind that
mainlining progress for A64 is progressing nicely with dvfs / cpufreq scaling support network performance with mainline kernel will be way better than now with mainline kernel we can make use of UASP with A64 (which will enable us to get close to 40MB/s per disk) we can configure the upper USB port (now OTG in host mode) to be a full USB host port by fiddling around with magical bits So in case one uses a Pine64+ that's not affected by the GbE hardware flaw (or the voltage drops can be avoided by providing higher DC-IN voltage) with mainline kernel we're soon able to get single disk NAS performance close to 40MB/s or 80MB/s when using 2 disks and relying on RAID-0. With a somewhat stupid RAID-0 setup (using two powered USB hubs on each USB port and two disks behind each hub) it should even be possible to get close to 100MB/s (the USB2.0 limitation of hitting a 40MB/s barrier is a per device limit. But whether performance improves when adding USB hubs to the scenario or not depends on the hub in question -- some add too much overhead and then performance decreases. And of course it's better to choose any other ARM board that is more suited for NAS usage).
 
Yes, that's MB/s above and not Mb/s. On a board affected by the GbE issue and still showing PHY problems (but not that much compared to powering through crap connector).
 
Pine64+ performs pretty well with GbE and can handle that even if some moderators constantly tell the opposite in pine64 forum.

We have initial support for Pine64/Pine64+ for a long time in our repository but not released any official images yet. Since this will change soon a sneak preview what to expect.
 
Hardware related issues:
 
Please don't blame Armbian for the few design flaws Pine64 and Pine64+ show:
These boards use Micro USB for DC-IN which is the worst possible decision. Most USB cables have a resistance way too high and are responsible for severe voltage drops when consumption increases, then the tiny Micro USB contacts have also a pretty high contact resistance and also maximum amperage for this connector is limited to 1.8A by USB specs. So in case you want to do heavy stuff immediately look into linux-sunxi wiki page for Pine64 to get the idea how to use the pins on the so called Euler connector to power the board more reliably. If you think about buying a Pine now consider ordering their PSU  too since there cable resistance shouldn't be a problem (should also apply to the Micro USB cables they sell) The only led on this board is a power led that immediately lights when power is provided. Pre-production samples had a green led, on the normal batches this has been replaced with a red led. So there's no way for an OS image to provide user feedback (activate an led when u-boot or kernel boots) and the red light has often been interpreted as 'something is wrong' USB: you find 2 USB type A receptacles on the board but only one is a true USB host port, the other/upper is A64's USB OTG port exposed not as Mini/Micro USB (with ID pin to be able to switch roles) but as a normal type A port. Expect performance to be lower on this port. I've also never been able to do disk benchmarking on the upper port but that might have changed in the meantime (I only have a pre-production developer sample here). Please note also that the maximum amperage available on the USB port is 650mA so connecting bus-powered USB disks might already exceed this so be prepared to use a powered USB hub in between A64 is prone to overheating but unfortunately the Pine64 folks do not sell the board with an effective heatsink by default (compare with ODROID-C1+ or ODROID-C2 for example how it looks like if the vendor cares about heat dissipation). They promised to provide a good heatsink as option but at least I'm not able to find one in their online store. But a heatsink is mandatory if you plan to run this device constantly with high loads, otherwise throttling will occur (when we tested an unrealistic heavy workload without a heatsink -- cpuburn-a53 -- A64 had to throttle down to as less as 600 MHz (for some numbers see IRC log from a while ago) Not a real hardware issue but a problem anyway: the HDMI driver in Allwinner's BSP does not negotiate any display output with a lot of displays that are connected with a HDMI <--> DVI converter or use non-common resolutions. Better do not expect any display output if your display is neither connected directly using HDMI nor capable of 1080p (we can't do anything here since Allwinner's driver uses closed source blobs and no documentation or code with useable license exists) On a couple of Gbit equipped Pine64+ users report that they're not able to negotiate Gbit Ethernet reliably and have to force the connection to Fast Ethernet (since we know that the RTL8211E PHY used on the boards needs an additional ~350 mW when negotiating a Gbit Ethernet connection this might be related to power problems or maybe different PHY batches or something else). Confirmed in the meantime to be a hardware issue. Now combine Micro USB encouraging users to combine this SBC with crappy phone chargers, 'smart' hubs/chargers that do only provide 500mA since Pine64 isn't able to ask for more and crappy USB cables leading to voltage drops (all sorts of power related issues 'by design' due to crappy Micro USB connector) with a missing custom led able to be used to provide user feedback while booting and the inability to use a lot of displays then you might already get what a support nightmare this device is.
 
The only reliable DOA detection method without a serial console is to ensure you have a working SD card (test it before using either F3 or H2testw as outlined in our docs), then check download integrity of the Armbian image (again see the documentation), then ensure you burn the image correctly to SD card (see docs), insert SD card, power on the board and wait 20 seconds. If then the leds on the Ethernet jack start to flash randomly at least the kernel boots and after waiting an additional 2 minutes you'll be able to login with SSH or serial console (for the latter better choose the EXP header over the Euler connector -- reason here)
 
Anyway: In case you run in booting or stability problems with Armbian on Pine64/Pine64+ be assured that it's not an Armbian issue. You run into any of the problems above therefore please try to resolve them on your own and send your complaints to Pine64 forum and not ours: http://forum.pine64.org/forumdisplay.php?fid=21  (really, we don't do hardware and these issues are all related to hardware design decisions)
 

 
Expectations:
 
The Pine64 folks did a great job raising expectations to the maximum. They advertised this board as 'first $15 64-Bit Single Board Super Computer', promised an average consumption of just 2.5W, the SoC remaining at 32°C and a few other weird things while they already knew that reality differs a lot (the journey started here last Dec).
 
Pine64 is not a 'Super Computer' but most probably the slowest 64-bit ARM board around due to A64 being limited regarding maximum cpufreq and overheating issues (40nm process being responsible for) and lack of fast IO interconnections (only one real USB 2.0 host port present, no eMMC option possible, no SD card implementation using the faster modes). If you then combine the high expectations with a rather clueless kickstarter crowd (many of them not even getting that they did not buy products but backed a project) and the hardware flaws it's pretty obvious why their forums are full of complaints and why they receive so much boards as being DOA that work flawlessly in reality.
 
So why bringing Armbian to Pine64? Since for some (headless) use cases these boards are really nice and also cheap, A64 support is progressing nicely thanks to our awesome linux-sunxi community and also a few more A64 devices will be available soon.
 
What do you get with Armbian on Pine64?
 
User experience will not be much different compared to longsleep's minimal Ubuntu image. If you prefer Debian then at least you can be assured that our images do not contain bad settings and silly bugs like the one's from official Pine64 downloads section (since they fiddle around manually with their OS images for example all Pine boards running these have the same MAC address by default which will cause network troubles if you've more than one board in the same collision domain).
 
We use the same thermal/throttling settings like OS images based on longsleep's kernel (since we helped developing them back in March), we use the same BSP kernel (patched by Zador up to the most recent version back in May) and share a few more similarities since our modifications were sent back to longsleep so all OS images for Pine64 might be able to benefit from.
 
Differences: You don't need to execute longsleep's various platform scripts since kernel and u-boot updates are done using the usual apt-get upgrade mechanism in Armbian. You also don't need (and should not use) scripts like pine64_tune_network.sh since they decrease network performance with Armbian (stay with our defaults unless you're an expert). And a few more tweaks might result in better performance and at least by using Armbian you have the usual Armbian experience with some additional tools at the usual location, automatic fs resize on first boot and so on.
 
We already provide a vanilla image currently based on kernel 4.7 but that's stuff for developers only, see below.
 
Performance with legacy Armbian image:
 
'Out of the box' CPU performance with A64 is not that great unless you are able to benefit from the new CPU features: A64 uses Cortex-A53 CPU cores that feature 64-bit capabilities (which are not that interesting since A64 devices are limited to 2 GB DRAM anyway at the moment) but more interestingly ARMv8 instruction set can be used which might increase performance a lot when software will be compiled for this platform. Best example: the commonly mis-used sysbench cpu test: When running an ARMv6 'optimized' sysbench binary on an ARMv8 CPU then performance will be 15 times slower than necessary (applies to the RPi 3 or the upcoming Banana Pi M64 when used with their OS images)
 
But as soon as ARMv8 optimized code is used A64 can really shine in some areas. I used the default sysbench contained in Ubuntu Xenial's arm64 version, tried it with 20000 settings and got less than 8 seconds execution time (an RPi 3 running Raspbian has the faster CPU cores but here it will take 120 seconds -- just due to different compiler switches!). Then I tried whether I can optimize performance building sysbench from source using
export AM_CFLAGS="-march=armv8-a -mtune=cortex-a53" and got 11 seconds execution time, so optimized code led to a huge performance loss? Not really, I checked out sysbench version 0.5 by accident and there for whatever reasons execution with ARMv8 optimization or in general takes longer (great! benchmark version influences execution time, so one more reason to never trust in sysbench numbers found on the net!). Using the '0.4' branch at version 0.4.12 I got an execution time of less than 7.5 seconds which is a 10 percent increase in performance for free just by using appropriate compiler flags:
 
 
 
 
Another great example how using CPU features or not (NEON in this case) influences performance and 'benchmarking gone wrong' numbers are Linpack's MFLOPS scores. By choosing the package your distro provides instead of using one that makes use of your CPU's features you loose at lot of performance, ruin every performance per watt ratios and behave somewhat strange
 
Someone sent me Linpack MFLOPS numbers generated with Debian Jessie which is known for horribly conserative compiler settings when building packages -- if you switch your distro from Jessie to Ubuntu Xenial for example you get a 30 percent improvement in sysbench numbers, yeah that's the 'benchmark' we already laughed at above.
 
With Jessie's/Raspbian's hpcc package, Pine64+ gets a score of 1625 MFLOPS and RPi 3 just 1035. So is Pine64 1.6 times faster than RPi 3? Nope, that's just 'benchmarking gone wrong' since these numbers are the result of a joke: Using tools for 'High performance computing' with standard settings (no one interested in HPC would ever do that). By using the correct Linpack version that makes use of NEON optimizations on both CPUs we end up with 3400 MFLOPS (Pine64 at 1.3 GHz) vs 3600 MFLOPS (RPi 3 at 1.2 GHz).
 
So if we're talking about this use case (HPC -- high performance computing) RPi 3 easily outperforms A64 (please keep in mind that the 3400 MFLOPS I got are the result of overclocking/overvolting at 1296 MHz, Pine64 is limited to 1152 MHz by default so we're talking about 3000 MFLOPS for A64 vs. 3600 MFLOPS for RPi 3's SoC. So it's not Pine64 being 1.6 times faster but RPi 3 being more suited for Linpack numbers and this type of benchmarks only shows how wrong it is to use distro packages that are built using conservative settings (which is a must if the distro wants to support a wide range of different SoCs!)
 
Anyway: I's obvious that in case you want to use Pine64 for number crunching or performance stuff in general evaluating whether compiling packages from source might improve performance is a great idea (at least it's obvious that from a performance point of view using an ARMv6 distro with ARMv8 SoCs is stupid -- reality with Raspbian running on RPi 3 and BPi M64). ARMv8 also provides crypto extensions that might be used with OpenSSL for example. Didn't look into it yet but maybe huge performance gains when using a Pine64 as HTTPS enabled web server or VPN endpoint are possible just like we've already seen with sysbench.
 
Network performance: Pine64+ combines the SoC internal GbE MAC implementation (the same as in H3 and A83T SoCs from Allwinner) with an external RTL8211E PHY as used on most GbE capable SBC. Default iperf performance with Armbian/Xenial: +900 MBits/sec in both directions (920/940 MHz) so no need for further tuning (please read through this explanation here why blindly trusting in iperf numbers is always stupid and why it's neither necessary nor useful to further tune network settings to get better iperf numbers).
 
 
  Please keep in mind that for yet unknown reasons a couple of Pine64+ are reported to not reliably work at Gbit Ethernet speeds. Please also keep in mind how settings might matter. If you run a standard iperf test in 'passive benchmarking' mode you might get throughput numbers 200-250 Mbits/sec lower than ours maybe just due to a wrong cpufreq governor. Ethernet throughput scales linearly with CPU clockspeed with most cheap ARM SoCs (our only known exception from this is Solid-Run's Clearfog which uses a SoC optimized for IO and network throughput) so by using the ondemand governor with wrong/default settings for example you ensure that an idle SBC will only slowly increase clockspeed when you start your iperf test. This is Armbian switching from interactive to ondemand governor now being below 700 Mbits/sec just due to adjusting CPU clockspeed too slow:    
 
The other stuff normally 'benchmarked' is not worth mentioning/testing it so just as quick notes:
A64 is showing the same SDIO limitation as most other SoCs limiting sequential transer speeds to/from SD card to ~23MB/s (do the math yourself: SDIO with 4 bit @ 50 MHz minus some overhead is 23 MB/s) -- fortunately that's rather uninteresting since random IO matters on SBCs and there it's your choice to choose between crappy cards that horribly suck or follow our recommendations and choose a really fast card. But Pine64 can not use the faster eMMC interface so if you really need high IO bandwidth and high IOPS better choose a different device USB is USB 2.0 so expect ~35MB/s with BSP kernel and ~40MB/s with mainline kernel and UASP capable disk enclosures for individual USB connections (UASP + mainline kernel might show high random IO numbers if used together with an SSD!) HW accelerated video decoding is already possible (see here for the codec matrix) and situation with HW accelerated video encoding looks promising too: http://forum.armbian.com/index.php/topic/1855-ffmpeg-with-cedrus-h264-hw-encoder-a64-cmos-camera/ In case one is interested in performance testing on SBCs monitoring what's happening is mandatory. Currently our armbianmonitor tool does not install the necessary templates on A64 so still my script to install this stuff on A64 should be used: http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-a64.sh (read the script's header how to install)
 
Performance with vanilla Armbian image:
 
Not interesting at all at the time of this writing since while Pine64 happily boots mainline u-boot/kernel it's way too early to do tests in this area. Currently there's no access to the AXP803 PMIC from mainline kernel so not even VDD_CPUX voltage regulation works and as a result cpufreq scaling is also not working and the SoC is clocked pretty conservative. Since most performance relevant stuff running on cheap ARM SoCs depends on (switching as fast as possible to) high CPU clockspeeds benchmarking is absolutely useless now.
 
You should also keep in mind that many core features still not work with mainline kernel so this is really stuff for developers (who normally prefer their own way to boot their freshly compiled kernels). So please don't expect that much from vanilla images for A64 boards now, better choose the legacy variant.
 
The future?
 
A few more A64 boards are announced or already available as dev samples, for example the aforementioned BPi M64 (possible advantages over Pine64: sane DC-IN, real USB OTG, more USB host ports behind an internal USB hub, eMMC available and custom leds being able to provide user feedback, everything else is more or less the same as the 2 GB Pine64+) or Olimex working on both an SBC and an A64 based Laptop.
 
And then Xunlong announced 2 new SBC based on Allwinner's H5. H5 (product brief) seems to be A64's bigger sibling providing video/GPU enhancements, 3 true USB host ports in addition to one USB OTG (just like H3 where we can use all 4 USB ports that do not have to share bandwidth), integrating a Fast Ethernet PHY (just like H3) but lacks PMIC support (again just like H3, so no mobile useage, no battery support out of the box and it gets interesting how VDD_CPUX voltage regulation will work there -- maybe 'just like H3' again).
 
Since A64 shares many/most IP blocks with H3 and A83T from Allwinner I still hope that H5 will be just a mixture of A64 and H3 and we will get full support based on what we now have for these 2 other SoCs pretty fast. But that's 100 percent speculation at this moment
 
Update regarding longsleep's pine64_tune_network.sh script. Benchmark results don't get automatically worse when applying the tweaks from his script but the result variation gets huge (730 - 950 Mbits/sec, exceeding 940 Mbits/sec is already an indication that buffers are invoked):
 
 
 
So better enjoy defaults unless you really know what you do since network performance tuning works in different directions. Stuff that might increase throughput might negatively affect latency and vice versa. So if you start to tune, tune for your specific use case!

We provided this week experimental Armbian images with mainline kernel for a few H3 boards. On the official download pages there are a few variants with 4.6.7 lurking around and here you find some with 4.7.2: http://kaiser-edv.de/tmp/w8JAAY/
  Those for the NEO are also suitable for NanoPi M1 and OPi One/Lite, the one for OPi PC Plus can be used on any of the larger Oranges (no Ethernet on +/+2/+2E -- don't ask please, this is stuff for later) since they all use the same more sophisticated voltage regulator being able to adjust VDD_CPUX in 20mW steps (VDD_CPUX is the voltage the CPU cores are fed with). The procedure is called dynamic voltage frequency scaling and the idea behind is to lower voltage on the CPU cores when they're running at lower clockspeeds and vice versa.   Works pretty well with legacy kernel in the meantime but it required a lot of work to come up with optimal settings that are still reliable (undervolting the CPU causes stability problems and data corruption!) while also providing best performance results (lower VDD_CPUX voltage, less heat, later throttling). For details please read through the whole issue here: https://github.com/igorpecovnik/lib/issues/298   So what has changed with mainline kernel now? In Armbian we use megi's kernel branch containing Ethernet and dvfs/THS patches and a few others. What's still missing and what do you get now when trying out these mainline images? No HDMI, no audio, no sophisticated SBC stuff like I2C, SPI and so on (unless you know how to deal with device tree overlays).   But USB, Ethernet on all Fast Ethernet equipped devices (no network on GbE models currently!), cpufreq scaling / dvfs, working WiFi and with 4.7 also the opportunity to test out USB OTG and the new schedutil cpufreq scheduler.   My 4.7.2 Armbian releases contain also a new armbianmonitor variant that can deal with mainline kernel on H3 boards (different templates needed and a different method to get VDD_CPUX values -- fex file vs. device tree) and can install cpuminer. Why cpuminer? To test the efficiency of throttling settings -- see below. As usual RPi-Monitor can be installed using 'sudo armbianmonitor -r' and now cpuminer will be installed by 'sudo armbianmonitor -p' (p for performance measurements).   To let cpuminer run in fully automated mode do a 'touch /root/.cpuminer', then minerd in benchmark mode will immediately start after booting and results will be collected by RPi-Monitor (not on the status page but only on the statistics page -- actual values aren't interesting only behaviour over time!)   Dvfs settings for Orange Pi PC and the other SY8106A equipped H3 devices already look good and work quite well (although I would tweak them here and there) while those settings for the H3 devices with the more primitive voltage regulation do not.   I used a NanoPi NEO for the test but the results apply to all H3 boards that use only 2 different VDD_CPU voltages: NanoPi M1/NEO/NEO-Air and OPi One/Lite. Unlike the Oranges NanoPI M1 and NEO overheat more easily, the latter especially (maybe due to smaller PCB size, single bank DRAM configuration and LDO regulators nearby the SoC?). And tested on the only remaining NEO that does not wear a heatsink.   In the beginning I allowed 1200 MHz max cpufreq but since I neither used heatsink nor fan throttling had to jump in to prevent overheating. In this mode H3 started running cpuminer at 1200 MHz, clocked down to 1008 MHz pretty fast and from then on always switched between 624 MHz (1.1V VDD_CPU) and 1008 MHz (1.3V VDD_CPU). The possible 816 MHz (1.1V) in between were never used. Average consumption in this mode was 2550 mW and average cpuminer score 1200 khash/s:     I then limited max cpufreq to 816 MHz through sysfs and let the test continue. In the beginning H3 switched between 624 and 816 MHz but since SoC temperature further decreased H3 stayed then all the time at 816 MHz and below 75°C (the highest allowed cpufreq at the lower VDD_CPU core voltage with megi's settings!). Average consumption in this mode was 2420 mW and average cpuminer score 1350 khash/s.   This is how cpufreq and temperatures correlated over time:
  So we got an increase in performance from 1200 to 1350 khash/s (+12.5%) while being able to lower consumption by 130 mW (2550 mW vs. 2420 mW) so not only performance increased but also performance per watt ratio if we manually adjust maximum cpufreq and forbid everything above 816 MHz. Quite the opposite of what one would expect   At least it should be obvious that dvfs settings for the small H3 devices need some attention. I monitored consumption through AXP209 on a Banana Pro feeding the H3 device through its USB port. The high voltage fluctuations due to the NEO's voltage regulator constantly switching between 1.1V and 1.3V can be seen until 8:12, then the '30 minutes average value' stabilized at 8:42 and the real consumption difference could be read: 130 mW:         With legacy kernel we defined a lot more possible cpufreq/dvfs operating points so let's give it a try: Same hardware setup (same NEO, same USB-to-Micro-USB cable from Banana Pro to NEO, same upright position for nearly identical thermal behaviour), same DRAM clockspeed (408 MHz) but different DVFS/THS settings of course:     If we compare mainline kernel with max cpufreq limited to 816 MHz and legacy kernel we get 4.7.2: 1350 khash/s, ~74°C, constant 816 MHz cpufreq, 2420 mW reported consumption 3.4.112: 1150 khash/s, ~80°C, 648-720 MHz cpufreq, 2610 mW reported consumption Looking at numbers 1 to 3 it simply feels weird: lower clockspeed, lower performance but higher temperatures. Would be an indication for different thermal readouts between mainline and legacy kernel (we had the same issue half a year ago when switching from BSP u-boot to mainline: temperature readouts 10-15°C lower).   But fortunately I also monitored consumption and there it's 200 mW more. On the same hardware with the same hardware setup. So there is really something happening on the NEO that wastes more energy when running minderd with legacy kernel and that might be responsible for higher temperatures and more aggressive throttling leading to lower performance (at least that's the only possible reason I can imagine)   Since we already know that on the NEO adjusting DRAM clockspeed with legacy kernel makes a huge difference regarding consumption and temperatures (see post #13 here) maybe the whole problem is related to different DRAM config on the NEO (single bank vs. dual bank on all other H3 devices) and something's wrong with mainline kernel here? Don't know but already decided to repeat the test with NanoPi M1 (dual bank DRAM config but also the primitive 1.1/1.3V voltage regulation)

And Gentoo, OpenSuSE, CentOS, Fedora and maybe a few hundred other Linux distro variants that might run on armhf/arm64 hardware. What's this whole thread about?
 
BTW: Armbian is different. It's not just another boring Linux distro (since then you could also use the plain Debian or Ubuntu stuff) but it's an automated build system capable to use Debian/Ubuntu and the images created in the end are the result of developing this build system over the years combined with a lot of knowledge regarding 'how to do it right'.
 
You won't have fun with this small ARM boards if not every detail here and there matches perfectly. And that's what Igor started with and what the Armbian team still tried to provide.
 
Basically three parts are involved: bootloader stuff (currently that's proprietary SoC specific bootloader stuff + u-boot, later we might have to deal with UEFI on aarch64), the kernel and the rootfs containing a Linux distro. The last part is the most irrelevant/boring one, the two former are way more important. As an example: sometimes kernel stuff won't work if hardware isn't initialized correctly already by u-boot and so on. That's what Armbian is about: Doing things right. And the distro used is close to irrelevant (the Armbian build system currently also allows to replace the whole OS distro in the last step with some other armhf/arm64 Linux rootfs -- somewhat weird but it works and would in many cases provide superiour results compared to 'original ARM Linux images')

Another update. To change easily the HDMI resolution and take care of HDMI-to-DVI converters (they need special settings otherwise display shows wrong colors), I improved h3disp a bit. Unless this is part of new OS images you can grab it at the usual location: http://kaiser-edv.de/tmp/4U4tkD/h3disp.sh
 
8c17768ba915c63df1354d1e524bc350  h3disp.sh
 
If called without arguments it just outputs a help text now. But you can specify display resolution and whether you've to use DVI or HDMI on the command line:
root@orangepione:~# h3disp.sh -m 348974398 /usr/local/bin/h3disp.sh: Illegal video mode "-m 348974398". Try one of the following: 480i use "-m 480i" or "-m 0" 576i use "-m 576i" or "-m 1" 480p use "-m 480p" or "-m 2" 576p use "-m 576p" or "-m 3" 720p50 use "-m 720p50" or "-m 4" 720p60 use "-m 720p60" or "-m 5" 1080i50 use "-m 1080i50" or "-m 6" 1080i60 use "-m 1080i60" or "-m 7" 1080p24 use "-m 1080p24" or "-m 8" 1080p50 use "-m 1080p50" or "-m 9" 1080p60 use "-m 1080p60" or "-m 10" Two examples: h3disp -m 1080p60 -d' (1920x1080@60Hz DVI) h3disp -m 720i' (1280x720@30Hz HDMI) Simply save it as /usr/local/bin/h3disp.sh, make it executable (chmod 755 /usr/local/bin/h3disp.sh) and enjoy resolution switching the easy way (just kidding -- but at least it's easier than tweaking fex files manually -- our goal is still to provide a solution to use any display resolution sometimes in the future).
 
BTW: The script should also work with Xunlong's or loboris' OS images but untested there. Feedback welcome.

It's not that hard to build ffmpeg on Armbian, directly from official source. I will show all steps i am using and all codecs i install, if some is not needed, skip and remove it from ffmpeg ./config. First i create some temporary folder, it's named "t" in this example. Then we can get dependencies with "apt-get build-dep". As ffmpeg is present in Ubuntu repositories, we can get directly:
sudo apt-get update sudo apt-get build-dep ffmpeg But in Debian ffmpeg is not present, so we can get deps for libav:
sudo apt-get update sudo apt-get build-dep libav It's also a good idea to have ffmpeg support samba, so we can install it too:
sudo apt-get install samba samba-common attr samba-vfs-modules smbclient Get some more dependencies:
sudo apt-get install autoconf automake build-essential libass-dev libfreetype6-dev libsdl1.2-dev libtheora-dev libtool libva-dev libvdpau-dev libvorbis-dev libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev pkg-config texinfo zlib1g-dev We will probably need this packages too:
cd t wget http://www.tortall.net/projects/yasm/releases/yasm-1.3.0.tar.gz tar xzvf yasm-1.3.0.tar.gz cd yasm-1.3.0 ./configure --prefix=/usr make -j2 sudo make install cd .. tar -xjvf fribidi-0.19.7.tar.bz2 cd fribidi-0.19.7 ./configure make sudo make install cd .. http://savannah.nongnu.org/download/freetype/ wget http://download.savannah.gnu.org/releases/freetype/freetype-2.6.3.tar.bz2 tar xjvf freetype-2.6.3.tar.bz2 cd freetype-2.6.3 sh autogen.sh make setup ansi make -j2 cd .. Let's install some codecs, avoid what you don't need:
sudo curl https://yt-dl.org/downloads/2016.02.27/youtube-dl -o /usr/local/bin/youtube-dl sudo chmod a+rx /usr/local/bin/youtube-dl https://sourceforge.net/projects/lame/files/lame/ tar -xzvf lame-3.99.5.tar.gz cd lame-3.99.5 ./configure make -j2 sudo make install cd .. git clone http://git.videolan.org/git/x262.git cd x262 ./configure --prefix=/usr --enable-static --enable-shared make -j2 sudo make install sudo ldconfig cd .. git clone git://git.videolan.org/x264.git cd x264 ./configure --enable-static --enable-shared make -j2 sudo make install sudo ldconfig cd .. video4linux/libv4l2 git clone git://linuxtv.org/v4l-utils.git cd v4l-utils ./bootstrap.sh ./configure make -j2 sudo make install cd .. http://downloads.sourceforge.net/opencore-amr/fdk-aac-0.1.4.tar.gz tar xzvf fdk-aac-0.1.4.tar.gz cd fdk-aac-0.1.4 ./configure --prefix=/usr --disable-static make -j2 sudo make install cd .. wget http://downloads.xiph.org/releases/opus/opus-1.1.tar.gz tar xzvf opus-1.1.tar.gz cd opus-1.1 ./configure make -j2 sudo make install cd .. wget http://storage.googleapis.com/downloads.webmproject.org/releases/webm/libvpx-1.5.0.tar.bz2 tar xjvf libvpx-1.5.0.tar.bz2 cd libvpx-1.5.0 ./configure --prefix=/usr --disable-examples --disable-unit-tests make -j2 sudo make install cd .. sudo apt-get install flac git clone https://github.com/libass/libass.git cd libass ./autogen.sh ./configure --prefix=/usr make -j2 sudo make install cd .. https://www.xiph.org/downloads/ wget http://downloads.xiph.org/releases/ogg/libogg-1.3.2.tar.xz tar xJvf libogg-1.3.2.tar.xz cd libogg-1.3.2 ./configure make -j2 sudo make install cd .. wget http://downloads.xiph.org/releases/vorbis/libvorbis-1.3.5.tar.xz tar xJvf libvorbis-1.3.5.tar.xz cd libvorbis-1.3.5 ./configure make -j2 sudo make install cd .. If you need x265 (as H3 support HEVC/H265) this is a tricky one and took me some time to deal with, because of a bug, so it need special attention. We need shared libraries but we will get error during make. So first some dependencies:
sudo apt-get install mercurial cmake cmake-curses-gui build-essential hg clone https://bitbucket.org/multicoreware/x265 We have to modify one file, so shared version can be build. Open the following file:
nano /t/x265/source/common/primitives.cpp
and locate this lines:
- #if ENABLE_ASSEMBLY && X265_ARCH_ARM == 0 void PFX(cpu_neon_test)(void) {} int PFX(cpu_fast_neon_mrc_test)(void) { return 0; } - #endif } #endif Remove the two lines with "-" in front and save (ctrl+o, ctrl+x). Now we can build what we need:
cd x265/build/linux ./make-Makefiles.bash #> c > g make -j2 sudo make install sudo ldconfig cd ~/t As we have all packages and codecs we need, we can build ffmpeg:
wget http://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 tar xjvf ffmpeg-snapshot.tar.bz2 cd ffmpeg ./configure --prefix=/usr --enable-nonfree --enable-gpl --enable-version3 --enable-vdpau --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libpulse --enable-libv4l2 --enable-libx264 --enable-libx265 make -j2 sudo make install This will take a while, but i think it worth.