FriendlyArm NanoPi A64

Peter ScargillFriendlyArm, NanoPi A6483 Comments on FriendlyArm NanoPi A64

NanoPi A64Don’t you love reviews that tell you all about a new product, print out all the specs then leave you to discover the horrors all on your own because they didn’t ACTUALLY test the thing? Well, this isn’t one of those reviews. But I will give you the spec. Even if this particular board doesn’t get your interest, you might learn some things just as I did in the process of doing the review.

What is it ? The FriendlyArm NanoPi A64 is as you might expect a 64 bit SBC. It looks lovely, has 4 serial ports (you can only really use two as one is for debug, the other for Bluetooth), Gigabit Ethernet, WIFI and more – here’s a list. OH and it is cheap at (in US dollars) $25 plus post.

Important specs:

  • Allwinner A64 quad-core Cortex A53
  • GPU Mali400MP2
  • 1GB DDR3 Ram
  • Gigabit Ethernet
  • WIFI + Audio + IR + USBx2
  • 5v @ 2A

So on the surface of it a fast 64 bit processor – what more could you want – and it is small. You can buy an optional heatsink with fan – but there are no special pins to attach the fan to, unlike other products by the same company. No matter, it does not get warm enough to need the fan in my experience.

I could give you a lot of other technical information which most people would not understand or have time to read – so instead I will cut straight to the point.

Operating Systems: If you check, operating systems for this includes Ubuntu Core and Ubuntu MATE.  No Debian, no Android… so to some extent that defeats the object of having the decent graphics chip as you’re less likely to use it as a media centre than if you had Android. Well, I am anyway. I was disappointed not to see Debian but then that’s me. So I started off trying out the full Ubuntu Mate.

The download took an age and I have pointed out to FriendlyArm that they should take a look at how they make their file available – 8 hours to download an image is not very funny.  This would not normally bother me as I tend to look first at the Armbian and DietPi sites – but they have nothing for this board. You might think that an operating system tailored for other A64 systems like the PINE would be good – but no – won’t even boot.

So Ubuntu Mate came up fine first time – and I set off running my script – which didn’t work – NPN would not install. It turns out that ONE reason for this was not as you might expect, lack of support for 64 bit systems (though that could be an issue) but the fact that this was Ubuntu 15.10 – which is ancient.

With help from Mr Shark we set about upgrading this to 16.04 Xenial. Well, that took nearly a DAY and was definitely NOT fun. At the end of it, we had 16.04 running – but the Ubuntu equivalent of the APP store was empty. I installed Chromium without it, clicked on the shortcut and… nothing – it simply would not run.

I tried my script and MOSTLY everything worked. A couple of tweaks and all was well, but I was not happy about the Chromium issue. If that was bust, what else was bust?  I put the SD to one side and downloaded the much smaller Ubuntu CORE.

After downloading software for these boards you must issue a couple of resizing options – I’ve already suggested to FriendlyArm that this should be part of their start-up script – you don’t have to mess with this with the Raspberry Pi and could put off beginners. Same again – 15.10 version – oh, dear. Anyway…

I started the resize operation…

sudo umount /dev/sdx?
sudo parted /dev/sdx unit % resizepart 2 100 unit MB print
sudo resize2fs -f /dev/sdx2

No sudo.  What!!?!?!?!

I went off and grabbed SUDO. I started again.

No parted.

I grabbed that, ran the instructions and resized the board.

This time the upgrade was no so successful with lots of errors appearing – now I KNOW there are Linux fanatics out there dying to say “but that’s part of the fun”.  No, it ISN’T part of the fun. Writing code is part of the fun, not messing with something that should have been sorted.  It would be like buying a car and the engine is broken and the salesmen says “well, repairs are all part of the journey”.

Determined not to be put off, I went back to the original SD and decided to remove the entire desktop environment as it was not needed anyway. Well, I can tell you that most of the information out there on doing this is SHITE. No matter how many commands I ran – and how many confirmations I got that Mate desktop was no longer there, when I rebooted, up came the graphical environment.  Eventually, with help from Anthony, I got rid of the lot.  I ran my script and – lovely – all working.

I came to back this up using WinDiskManager and “sorry – the image is bigger than the disk” – apparently not all 16GB disks are created equal.

The backup: Having put all this work into getting a board up and running I was not about to change it failing due to an SD issue. It was at this point that I had my first attempt to do a live backup – hey – what did I have to lose. I’ll cut a long story short here as I got the sector numbers wrong in the first place…

dd if=/dev/mmcblk0 of=/dev/sda bs=1M count=15000 status=progress

So dd is a very well known Linux program if you’re into Linux – I’d heard of it but that’s it – so this was my first attempt. I had to get the image backed up onto my SD that would work, without going out and buying a larger SD just to see most of it going to waste. Someday I will write a script to go through my installations and rename all the commands. How about “backup”. But I digress.

So – IF means input file, OF means output file, 1M is the buffer size – in short if you miss that of it takes longer – and status=progress is relatively new and lets you see a moving count while copying instead of wondering if it was working or dead.

This, of course, is highly discouraged by the community –  attempting a backup while the system is running is asking for the death penalty or worse and for good reason! As for the count – not only was it incorrect, it was a GUESS – I figured I needed to copy enough to cater for all working areas of the SD – but somewhat less than the actual size or I’d be no better of and the system would gripe about not enough room as does WinDiskManager.

For good measure I also added another command – just because I’d seen this used in the FriendlyArm literature after resizing a disk…. resize2fs /dev/sda2

Well, it was a bit of a long shot – I took out the original SD (mmcblk0) and put the new SD (which had been sitting in a USB holder and hence appeared as SDA  – and put the new SD in. Applied power and….

Success: Well, I was expecting nothing so as not to be disappointed – to my surprise – up came the prompt. I checked all of my programs and bingo – everything works.  I followed advice from Anthony who was being kept up to date and dumped an empty file called “forcefsck” into the outer directory (i.e. just created an empty file with Nano (the editor)). Rebooted – no error messages – job’s done!

WiFi: The NEXT step having satisfied myself that the board works and realising I could steal my M3 case as the sizes are the same, was to get WIFI working. After above I was not that confident. I read up about the command “nmcli”.  This stubbornly refused to work until I realised I was actually typing “nmclie” every time… at which point a quick scan of the networks immediately showed up my local WIFI access point. I stumbled on this item, detailing usage.

Even with one coffee and even though listing the WIFI was easy enough, actually getting a connection proved to be a challenge. Anyway, after reading this item…http://askubuntu.com/questions/461825/connect-to-wifi-from-command-line/461831#461831 I managed to get the WIFI working by putting the relevant login information into a new file /etc/wpa_supplicant.conf and trying out the commands. To cut a long story short I soon realised I had a WIFI connection, disconnected the Ethernet connection, rebooted and lo – WIFI. All seemed like a lot of hard work BUT what WAS noticeable was the speed. Where the likes of the Orange Pi have given me unreliable connections where you could SEE in using the terminal that the WIFI was not right, this seemed to go like a rocket.  I tried an apt-get update/upgrade… seemed as fast as the Ethernet version.

Benchmarks: I could not, originally,  test my Raspberry Pi due to some missing dependency when loading SYSBENCH. But I did look here…  and in particular the following tests:

sysbench –num-threads=1 –test=cpu –cpu-max-prime=20000 –validate run

sysbench –num-threads=4 –test=cpu –cpu-max-prime=20000 –validate run

well, someone apparently produced results of 768 seconds for the RPi2 on 1 thread and for the RPI3, 192 seconds for 4 threads – fair enough…

Finally, I managed to get my RPI2 updated to grab Sysbench and do the same test – 202 seconds for 4 threads… but here’s the thing….  the A64 using the identical test –  4 threads –  8 seconds. I did say it looked FAST but really?

I have another Pi2 sitting doing nothing – zilch on the bench – I installed the same Sysbench and ran the same test again on the Pi2 and on the A64 – 8 seconds for the A64, 123 seconds for the Pi2.

Conclusion – the A64 on a simple CPU test, ABSOLUTELY and utterly WIPES THE FLOOR with the Raspberry Pi units.

Eventually: So – am I happy? Yes – I have a rather fast board to play with.  I contacted FriendlyArm to find out the status of their version of the GPIO control software to see if it is available for this board.  Erm, no.  That is going to make it a little difficult for Node-Red to control ports.

So would I recommend this to others?  If you’re comfortable with what you have read here and hopefully find my efforts a bit on the amateur side then yes, it looks like a really good board and it is certainly well-made and I DID get everything to work in the end (and I am by no means a Linux expert). If you struggled with this blog – I suggest looking elsewhere or wait for WAY more support to appear. GPIO could be fun getting to work.

Some of these other-board manufacturers do a cracking job – many of these boards are well made, well priced and generally very professional, but I’m sorry, all those claims for I2c, SPi, GPIO etc. are MEANINGLESS to most of use unless backed up – at the least this board needs an up to date version of Debian or Ubuntu complete with GPIO support and examples and right now that is not on offer. I know how I2c works, I know how to use it. I neither know nor, in any ware, care AT ALL how it is implemented in the operating system of how to implement it myself. Life is too short.

But give it time, if you’ve read my other reviews I’m usually quiet supportive. If you want more info – simply look up NanoPi A4, there is a ton of info on their WIKI.

Follow-up and WIFI: Two days later and I’m still messing with these boards – I have Ubuntu pretty much the way I want is and DD continues to do the job for backing up – so I have two of them, identical, sitting side by side. I used this link to get colourful terminal commands (why on earth in the 21st century are we still using boring black and white for Linux terminals) and I I have both machines accessible by name (FriendlyARM1 and FriendlyARM2) on WIFI and now the final touch –  I was pondering a cron job to make sure they recover from duff wifi but on test, disconnecting the WIFI – the terminals go dead, reconnecting the WIFI – in both cases they recovered automatically. I tried this several times – a shame some other operating systems and boards don’t fare so well!

83 thoughts on “FriendlyArm NanoPi A64”

  1. Short update: The most recent official images by friendlyarm are now xenial (16.04).
    Seems like most of the problems described are fixed by now.

    I got this board for like 20€ and just using it as a snapcast client. (https://github.com/badaix/snapcast/ )

    I just tried ubuntu core: Sudo is supplied, build-essentials + git too – building works (fast). Oddly, cron was not on board, but installed without problems.

    Wifi and audio are working out of the box. The board runs stable with 1A power-supply, even when compiling.

    Beeing able to build is essential with arm64 hardware – not many arm64 builds out there.

    About resizing: FriendlyArm wiki states, you should do it under a host pc – not on the system itself.

    Well, I’m quite satisfied. Have expected much more trouble with the software.

  2. Hello.
    Does someone has a linux with working SPI driver for the NanoPI A64 ?
    Because I can’t get support about this from FriendlyARM/FriendlyElec

  3. Because I didnt read here about a Non-FriendlyARM alternative OS-version for the NanoPi A64 – I would leave a comment here 🙂

    My NanoPi A64 is running better with the following OS:
    https://github.com/avafinger/nanopi-a64-firmware

    This is not only a Firmware – is a complete Ubuntu 16.04 xenial with LXDE-Desktop
    and kernel 3.10.105

    My NanoPi A64 also doesnt get hot – so I didnt use a fan.

    The only thing with that is that creating the bootable MicroSD-Card is a little bit dificult,
    but the instructions in the bottom of the page are quite well 🙂

    You need a Linux-System for creating the Boot-Card – so I did use my second NanoPi = the NEO2
    with a single-slot MicroSD-Card Reader/Writer.

    The NanoPi A64 seems to a good board, but with bad support 🙁

  4. Finally someone who dares saying it: Setting up Linux and running into prpblem after problem is indeed not part of the fun.
    I guess this board is not for me

  5. If you want Android 6 basic version and gpio try a more costly Khasdas Vin s905x board.

    I own up to getting one free so bias.

  7. How did you manage to update Ubuntu? I also own a FA A64 board.
    Did someone try a Generic AArch64 Installation?
    Thanks in advance

    Andy

    1. I managed it just through scouring the web after doing the usual apt-get update and upgrade.. there’s another one which someone in here will no doubt remind of us to ensure you’re on the latest release… anyway, the boards are sitting at one side as having gotten them working reliably – I can find no way to get the IO working – zero support by the look of it. It would be so easy for FriendlyArm with a variety of boards to grab the source for WiringOP and customise it to particular boards but they do seem more interested in selling hardware, sadly – as do others.

      1. >> the usual apt-get update and upgrade <<
        Yes tried this but it always looses internet connection (not network, I can see my other devices). Nearly managed to do a dist-upgrade but then connection broke, don't know why.
        Could ping my router without any problems 🙁
        Not very familiar with Ubuntu/MATE.

        It was easier to set up Arch on my Pi1 only via ssh 😉

        1. dist-upgrade – that’s the one – I did this over hardwired Ethernet – and it took HOURs – but it worked. The MATE bit was of no interest to me – i.e. the graphical side- I ended up removing that as it just uses up resources.

  8. Hi Pete,
    I’m still playing with a Orange Pi Zero (512) regularly. I’ve had some random drops in network that self recover (i.e. can’t connect then try again a few minutes later and it works). I’ve got quite a complicated Armbian setup with 3 interfaces – eth0 connected to my cat 5 network, wlan0 working as an access point via Host APD and DNS Masq and then a Huawei 3G dongle in the USB port which is the internet connection shared via HostAPD.

    I’ve not played with the wlan0 ‘hotspot’ connection enough to see if that keeps alive 100% or not but the ethernet connection isn’t 100% reliable for ssh intermittently. I’ve got Node Red running on this and mosquitto and have also got a couple of LEDs wired to the GPIOs which I’m setting high and low using bash scripts that invoke little Python scripts.

    I’ve got NodeRED and your big timer on there switching my bedside lamp on every morning as an extra morning alarm – the lamp plugged into an ITEAD S20 socket running ESPEasy firmware accepting HTTP requests to switch the relay on/off and MQTT to send button press messages back to my Pimatic/MQTT setup on my main Raspberry Pi. I also have my ‘man cave’ ceiling light connected via an MQTT enabled ITEAD Slampher (with ESPEasy firmware for http/mqtt comms – sorry, not using your ESP8266 firmware at the moment as ESPEasy has been up and running on my other devices for so long its too familiar and too reliable for me to change right now!).

    I’ll feed back more info when I’ve had more time to play with it in a “test to fail” setup rather than just configuring things and carrying out quick tests but big timer/node red/mqtt seems to work several days in a row without reboot…

    1. Hi Darren. Not in any order – I’d expect Node-Red/BigTimer/MQTT to last months or years without reboot. When I came back to the UK in October, the heating system with similar software and a Raspberry Pi had been running for several months without issue – but not on WIFI of course (the M3 units are sitting here working utterly reliably on WIFI but I have to say, you can tell it is WIFI and not an Ethernet connection).

      For ITead the best software up to now seems to be https://github.com/arendst/Sonoff-MQTT-OTA-Arduino and I’m pleased to say I contributed one or two ideas to that (like the second SSID). The reason being it is still small enough to allow OTA on the smaller FLASH chips. My software is different, for the longest time it has handled high resolution PWM and RGB lighting (with fading in and out) as well as RGB animation and a ton of other features – in other words it is intended for other uses than simple lighting control – if I’m doing the latter I use the Arendst code.

      The jury is still out in my view on the Orange Pi Zero – we’re in the hands of third parties as the people who make them just want to push out hardware (that is the case with most, sadly). Every now and then I’ll try the latest software to see how it is coming along – because there is no doubt – the low cost/small size combo of the Zero is very attractive.

    1. Yup, I’m reading that as “yes, we DID forget to put the fan connector on”. I’m still waiting for a response from them on a way to use the GPIO.

      1. Pete, there’s no need for 2 pin fan connector since both the 4 pin header as well as pins 4/6 on the 40 pin header could be used (at least that’s what I understand from the information in the wiki: VDD_5V is available on several pins and since it’s next to GND on two connectors there really is no need to add another 2 pin header somewhere)

        BTW: I tried out this fan just once when testing around with NanoPi M3 just to remove it immediately and replace it with an improved cooling solution for tests (still annoying since too noisy): https://forum.armbian.com/index.php/topic/1285-nanopi-m3-cheap-8-core-35/page-2#entry13803

        And this is how I modified the heatsink in the meantime following @lex idea: https://forum.armbian.com/index.php/topic/1285-nanopi-m3-cheap-8-core-35/page-3#entry15291 (if I ever need better heat dissipation I will combine this with a slow running large fan but for normal workloads this improved passive heatsink should suffice)

        1. I have two of them – one sounds like a jet aircraft, the other makes almost no noise – could be a fan issue here. Thankfully I sent off for a bunch of the fans a while ago – will try a replacement for the noisy one. As it appears to run quite cool there may be another option – running the fan from 3v3. I made my own humidifier a little while ago from an ultrasonic vaporiser…. because the “steam” is cold, it tends not to rise. I had to use a fan to compress the chamber and send the steam up through a pipe. I used one of these fans and of course it was WAY too noisy for a bedroom… so I connected it to 3v3 instead of 5v – where many weeks later it is still turning on and off to schedule utterly reliably!

          Am I right in saying there is no Armbian for the M3? Can’t see it – all I can find is DietPi and that of course is Debian – having gotten used to Ubuntu I was kind of looking forward to that but the FriendlyArm site again just has an out of date CORE version.

          1. Yep, no Armbian for NanoPi M3. DietPi just takes an already existing OS image made by someone else, doesn’t care about appropriate settings, kernel and u-boot version. So if there’s a Jessie image available anywhere they can turn it into DietPi.

            Armbian works completely different, our OS images are built from scratch (downloading sources, compiling from sources, debootstrapping the whole OS image) and we don’t even start to support a device as long as u-boot and kernel sources aren’t available and handling with those can be considered sane. And situation with M3 is horrible here (ugly and outdated kernel version).

            That being said it’s still pretty easy to turn a Debian OS image into Ubuntu since it’s just exchanging the rootfs. That way some binaries might become faster but it’s still an OS image someone else fiddled already around with (absolute no go since you never know whether backdoors are contained) and as long as kernel situation doesn’t improve we don’t touch it (since it’s moronic to keep a distro up to date when countless bugs live in the kernel and will never be fixed. If you’re happy to run a device with a kernel containing more security flaws than features then you know the alternatives).

            As an example: The famous Dirty COW bug has not been fixed in FA’s kernel for NanoPi M2 and M3 so you get a well known root exploit with both FA’s software offerings and DietPi.

            1. All good information, thanks for that.

              I should point out that at this point after spending a lot of hours experimenting – right now the ONLY solution that gives me reliable WIFI – including automatic recovery from access point failure – on the M3 and the A64 – is FriendlyArm images. I’ve done lots of testing – simply pulling the access point out of the wall and plugging back in – with their images -reconnection every time. The A64 is Ubuntu – the M3 Debian – oh and there was no setup or special installation needed. Just saying.

              1. Well, I consider WiFi on the M3 starting with PCB rev 1605 broken by design since the internal aerial leads to laughable 140 Kbits/sec in one and ~2 Mbits/sec in the other direction. Comparing with a NanoPi Air under exactly same conditions (that’s important!) I get ~20 Mbits/sec (which is still lousy but given that 2.4 GHz in my area is so much overcrowded at least acceptable): http://www.friendlyarm.com/Forum/viewtopic.php?f=42&t=379#p1222

                So even if Armbian would start to support M3 I wouldn’t spend a single second on WiFi drivers for this device.

                With NanoPi M64 it’s different, the RTL8189ETV is the same as used on the first Orange Pi models and when combined with a good external aerial somewhat ok-ish (but still only 2.4 GHz band, 1T1R antenna, low power == low performance and behind a slow SDIO bus so reasonable throughput is impossible with this cheap stuff). So in case Armbian will ever support this device (most probably not since A64 is somewhat boring) you can expect that WiFi will work there too in a reliable way (at least we never got complaints from OPi Plus, 2 and Plus 2 users regarding this WiFi chip/driver)

                1. well, so we have to choose between a distro that WORKS (*1) but have “famous bugs” (*2), or a distro which “maybe” can support a board (*3), or had support already but is loosy (*4)… ok, well, choose done… not talking about all your disrespect towards DietPi…

                  *1 as Peter tested, on wifi reconnect, too… oh, which is something you never fully answered to his questions about why on armbian wifi is mostly gone on reconnect…

                  *2 which are a serious problems maybe for 1% of their users, only those who are crazy enough to put those boards exposed to public internet… oh, most of us buy these boards to have them full of software like node-red and to NOT having to rely on a cloud (“someone else’s computer”) which can be unavailable or shutdown completely from today to tomorrow…

                  *3 if you decide it’s not “boring”…

                  *4 because you put your only board “in production”, like you said in previous comments about your Orange Pi Zero, so we can’t be sure its situation will enhance in the future…

                  1. Re: ‘armbian wifi is mostly gone on reconnect’ is simply not true. There’s not only Pete who tests Armbian images but a few more people. Though still no idea why it doesn’t work at Pete’s location.

                    WiFi on my OPi Zero is broken so maybe it’s also an hardware issue on Pete’s single board (but I fiddled around before WiFi stopped working on mine so I would suspect I damaged my board myself). According to download numbers there are 1000 people around using Armbian happily on the Zero. And ‘reconnect’ is a network-manager feature working on all boards (in the same way and reliably unless you exchange the AP since network-manager treats another AP using the same name as different AP of course).

                    Regarding distro: Why don’t you simply choose the one you want? I only tried to explain why and how Armbian differs from something like DietPi.

                    Armbian is a build system maintained by developers caring about security that generates OS images from scratch. The stuff we care most about (u-boot, kernel, settings) is also the stuff we spend most time on (that’s the reason you see continually kernel updates on all our images even if hardware manufacturers abandoned their own devices long ago and that’s also the reason why known exploits usually are fixed within 24 hours). We contribute to Armbian to ensure that we’re able to use sane/safe distros on our devices since otherwise many use cases wouldn’t be possible.

                    DietPi is something completely different. People take whatever Debian Jessie images they find somewhere, delete packages, add scripts, don’t care about u-boot, kernel and settings. So when you use DietPi for Raspberries or H3 boards then this is something totally different compared to DietPi running on NanoPi M3. Since on the former DietPi uses Raspbian/Armbian as base so you get kernel updates and security fixes, on the latter you get a lot of exploitable bugs and no such updates ever.

                    So if you don’t care about this stuff why not choosing DietPi where available?

                    Regarding this NanoPi M64: from my point of view (+30 different SBC lying here around) I see no reason to spend a single second on this board since it’s… boring (A64 is maybe the slowest 64-bit ARM SoC around, only 1 USB 2.0 OTG and 1 host port –> low I/O bandwidth). I also wonder whether Pete would’ve ever considered buying this board. FA did some very interesting hardware but the M64 is IMO not amongst (still eagerly waiting for the M1 Plus since this board is way more interesting for my use cases).

                    1. On people reporting… I’ve been doing this blog a long time and I know how many people do stuff with the software I produce – and how many write in to say things don’t work.

                      FAR to often people assume it is their fault – or just go off and do something else. If you have 1000 people using Armbian on the Zero, here is a guess… 500 will have gone onto something else by now. Of the 500, many will never turn off their router. So let’s say 100 have turned off the router or had a power cut and the Zero didn’t come back up – half will have just rebooted the board not having any great need for reliability or just not being bothered. Of the remaining 50, 49 will either assume it is their fault or something unrelated – that leaves me. Without fail, removing power to the access point (tried two different ones) and restoring – the WIFI will not reconnect. Right now I’m sitting in front of two A64 units and two M3 units on WIFI – all of which reconnect every single time… so – either I have a bust ZERO – and if that is the case and yours is bust – then perhaps there’s a REAL issue with the ZERO itself…. or the software is not recovering from lost signal – has to be one or the other.

                      Why did I buy the A64? I didn’t – they sent me samples (I also have the Pine 64 which is currently happily running Android 7 – more than can be said of just about any other board of this type) and yes I’ve told FriendlyArm how I feel about lack of support for GPIO and old operating systems and yes they agree that more needs to be done – at least they respond – the Orange Pi people have not responded to a single email – ever. Up to now I’m favouring the NanoPi M3 and Odroid C2. Initially I stuck Android (old Android) on the M3 but now I come to run Debian, updated it seems to run very well.

                  2. Re: OPi Zero: I did just the initial support for legacy kernel and since I did this for maybe 10 other devices before this is stuff that needs maybe an hour including necessary fixes.

                    BTW: Since I mentioned NanoPi M1 Plus before: the moment I spotted this new device in FA’s Github repo I added it immediately to Armbian: https://github.com/igorpecovnik/lib/commit/acbbd441902d9dbe42f1574c7f5804bd4fedbac8 (I did the same with NanoPi Air and OPi Zero before and to our surprise images worked out of the box even without having access to dev samples at that time).

                    Since there exists the great linux-sunxi community and since a few devs really like OPi Zero and upstream Linux support is also nearly done you can be assured that situation will improve even if I will never do any work on this device. Armbian consists of a few more devs and the real work here (eg. improving WiFi driver) is done by linux-sunxi community anyway.

                    2. Pete, I tried reconnect many times and it always worked as expected. As already said: this is a network-manager feature (searching for all configured SSIDs if access has been lost and reconnecting to the one with strongest signal). But as also already said since I can’t test any more with OPi Zero I’ve no idea to further diagnose what’s happening.

                      That being said I tried to summarize current WiFi issues with OPi Zero in Armbian forum a few moments ago: https://forum.armbian.com/index.php/topic/2808-orange-pi-zero-went-to-the-market/?p=23528

  10. For the sake of it, I tried the Android 7 image on the A64 – not as much as a flashing light.
    Oh, well.

  11. Two more things to mention (just read through your review now). I don’t get why you mention Bluetooth since this board has no support for it (it’s just an old RTL8189ES WiFi chip, the same as used on the first H3 Orange Pi).

    Regarding Android: thanks to Jon Smirl and Kamil Trzciński a community based Android (up to 7.1) is available for Allwinner A64 devices (the whole story started on Pine64). So if FriendlyARM is smart they send a dev sample to Jon or Kamil and get support for free since it’s essentially just adopting a few settings and maybe adding the WiFi driver if not already present in sources.

      1. BTW: In the meantime Allwinner themselve released an Android 6.0.1 (security patch level dec 2015 — LOL!). Problem for FriendlyARM might be that since they started with H3 SoC Allwinner’s business unit 3 is responsible for them while A series SoCs are supported by BU2. Somewhat weird but it’s reported that each BU has own engineering/software teams that code on their own.

      2. Tkaiser – MrShark – Android links please without which I can’t encourage FriendlyArm. I’ve already asked them to do something about the Ubuntu.

    2. I have no idea why I mentioned Bluetooth – but I’ve removed it. I will pass that info onto FriendlyArm as not having Android seems daft. Mind you – I’d be happy if they’d just update the old Ubuntu on offer.

    3. Did I mention the board runs cool – I’ve a heatsink on it but not put the fan on as they didn’t provide a special connector for it – but by the temperature of the heatsink I don’t really think that is needed – mind you – I’m not doing anything graphically intensive – or graphically anything.

      1. As already said: Allwinner’s default settings with their so called BSP kernel für all of their SoCs are brain-dead. They kill CPU cores instead of throttling and they never come back. No idea whether FA adjusted these settings or not.

        But a simple ‘grep -c processor /proc/cpuinfo’ should do the trick. That’s also one of the differences between Allwinner’s own Android and the community based one (which uses the Linux kernel settings community developed back in March last year). With Allwinner’s Android you end up pretty fast with just a single CPU core active, see all the results here where ‘multithreaded’ performance is identical with single core performance: http://browser.primatelabs.com/geekbench3/search?utf8=✓&q=A64

        ‘Graphically intensive’ doesn’t matter that much since Linux makes no use of the Mali GPU (and in Android it’s just clocked with 408 MHz)

      2. Sorry, the reason why I mentioned this ‘killing CPU cores’ thing is that once this happened later on the system only runs on 1 or 2 CPU cores and then that alone might be responsible for that board remaining always cool.

        And with Allwinner default settings it’s really weird to watch what’s happening since board starts to overheat and then their kernel disables 1-3 CPU cores within seconds. FA removed the warning messages printed to syslog so the only chance to get an idea whether this has happened is checking count of active CPU cores with ‘grep -c processor /proc/cpuinfo’

          1. Sorry, overseen that. I don’t know of a 64-bit distro for RPi 3 but haven’t spend any time on research here since RPis are too limited for my use cases (the ‘only 1 USB connection to the outside problem’).

            I would at least use the ARMv7 Ubuntu image on RPi 2 and 3 and if there’s something that needs high CPU performance then building software from sources with ARMv8 settings should suffice (64-bit kernel isn’t that important, it’s more about software making use of ARMv8 instruction when Cortex-A53 cores are available).

            1. the only pure 64bit OS is suse right now… but it’s a mess to install, requires a suse account with a 1 year free subscription code just to activate regular updates… tried with 3 different email addresses and related codes, never succeeded to get that registration work, always says code is not valid…

                  1. Ah, now I got it. Good to know so I won’t even try Suse then (the proprietary firmware having more control of the hardware than the ARM CPU cores is already enough… add then activation hassles and you lost me)

                    BTW: Related problem: NanoPi M3. Also Cortex-A53 CPU cores but only horribly outdated 32-bit kernel and 32-bit userland. But if you need CPU performance and use appropriate compiler switches (and huge heatsink, good PSU and a fan) then this is a beast: 12.5 GFLOPS compared to the 3.6 GFLOPS for RPi 3 or 3.0 for A64: https://forum.armbian.com/index.php/topic/1285-nanopi-m3-cheap-8-core-35/page-3

                    On SBC that can make use of only 1 GB DRAM this ’64-bit thing’ isn’t that important as long as you’re able to build software from sources and are able to use ARMv8 instruction set 🙂

                    2. Pete, answering questions about ‘faster’ isn’t that easy. If it’s solely about ‘raw CPU horsepower’ then the Samsung/Nexell S5P6818 as used on NanoPi M3 outperforms most other SoCs (at least the M3 is the CPU performance leader in my list of +30 SBC lying here around).

                      That’s even true when looking at single threaded performance (it’s an octa-core SoC and most workloads don’t scale linearly or at all with CPU core count so high synthetic benchmark scores from boards with many CPU cores don’t mean that board performs better compared to one with lower benchmark scores but significantly less CPU cores).

                      But there exist corner cases where the SBC that can run an arm64 distro outperform the M3 since for the latter only armhf distros are available (ARMv8 vs. ARMv7).

                      And then there’s stuff like I/O. When the workload is partially storage bound then an M3 running off a crappy SD card might be magnitudes slower than an ODROID-C2 when combined with Hardkernel’s larger/expensive eMMC modules (they simply rock and are unbelievable fast, especially random I/O)

        2. Well, that’s a new instruction for me to mess with – one could put that into the prompt!!!

          grep -c processor /proc/cpuinfo says “4”

  12. Your conclusion regarding CPU performance unfortunately is absolutely wrong. Sysbench is crap to compare different systems. With sysbench you only test compiler switches and version but not CPU performance.

    Sysbench shows 30% better scores when running on the same hardware with Ubuntu Xenial compared to Debian Jessie. Why? Since Jessie uses a horribly outdated GCC version (4.9) compared to Xenial (5.4). For details read post #17 here: https://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/#entry14439

    Sysbench shows 15 times faster execution when code is built for ARMv8. That’s the only reason A64 looks faster than eg. RPi 3. The only problem here is that Raspbian and derivates use compiler settings for ARMv6 and the stupid prime number calculation sysbench solely relies on to ‘report’ CPU performance needs ARMv8 compiler switches to boost execution times. See https://forum.armbian.com/index.php/topic/751-rfc-support-cortex-a53arm64/#entry12462 for actual numbers.

    RPi 3’s SoC is slightly faster than A64 when same compiler switches are used. Using an optimized Linpack we measured 3.6 GFLOPS on RPi 3 (with compiler settings for ARMv8 of course and not Raspbian/DietPi defaults) while getting 3.4 GFLOPS when overclocking A64 to 1.3 GHz. So in reality we’re talking about 3.6 vs. 3.0 GFLOPS since without a massively improved heat dissipation it’s not possible to let A64 run with 1.3 GHz in a stable way.

    1. Addendum: Most distros these days include sysbench 0.4.12. Most recent sysbench version is 0.5. As soon as any distro uses the more recent version those CPU performance numbers get even more stupid/useless.

      When I tested with version 0.5 I got 11 seconds execution time vs. 7.5 when using 0.4.12 with same compiler switches. Just search for the words ‘sysbench version 0.5’ in https://forum.armbian.com/index.php/topic/1917-armbian-running-on-pine64-and-other-a64h5-devices/

      Sysbench might be able to run MySQL benchmarks (that’s the original purpose of this tool) but the CPU test is insanely useless and misleading and has nothing to do with CPU performance (only compiler switches and version and even the tool’s version number plays a more important role than the hardware this stupid anti benchmark is running on).

    2. Well, I’m just as happy to be enlightened about Sysbench (don’t profess to have Linux skills having spent a lifetime avoiding it) because although the board is clearly faster than a Pi2 and the WIFI works in a different league to the Orange Pi Zero, the figures did seem somewhat over the top and now we know why.

      At this point, having achieved almost all I need to with the board, the far more important stalling point is I/O. With the power that backing things up gives one to experiment, I have tried everything I can think of from WiringPi for another A64 unit, through to basic Linux I/O and no matter what I cannot control the I/O pins on this board. Unless FriendlyArm come back with a miracle I will conclude that the only usable IO on the board comes in the form of the serial ports (which do work).

      1. Just a quick note regarding ‘Pi2’: in the meantime Broadcom stopped producing the older BCM2836 SoC with Cortex-A7 (ARMv7) cores and replaced it with A53 based BCM2837 known from RPi 3 on the RPi 2B. Default clockspeed is limited to 900 MHz but that’s just to ensure consumption remains at the same level and can be easily lifted up to 1200 MHz if needed.

        In other words: Most CPU intensive tasks will run faster on the recent RPi 2 than on any A64 based board. Especially when avoiding distros that are made slow intentionally since they use binaries built with ARMv6 architecture settings (Raspbian, DietPi and so on). The obvious advantages of A64 are Ethernet on an own bus being magnitudes faster than RPi and at least 2 real USB ports. But as already said: If I would’ve to choose a slow and cheap 64-bit board I would better choose H5 than A64 since there the count of real USB ports is twice as high.

  13. Peter, ever done speed test with IPERF? It’s a command line tool that stresses network to give you comparable results and analyze bottlenecks…

    just install it with usual: sudo apt-get install -y iperf3
    there are windows binaries, too: https://iperf.fr/iperf-download.php

    then just run it in server mode (better on a pc with gigabit eth): iperf -s
    and from an other of your boards connect to it: iperf -c IP_OF_SERVER
    without other command line switches, test lasts about 10 seconds…

    there are public IPERF servers, too: https://iperf.fr/iperf-servers.php
    but just to test your internet connection, in this case… the internet bandwidth will sure be less then your local one…

    take a look from 6:40 of this video, just first example found: https://www.youtube.com/watch?v=LDlRN8uy6FY

    about its defaults, from its manual:
    Using the default options, iperf is meant to show typical well designed application performance. ‘Typical well designed application’ means avoiding artificial enhancements that work only for testing (such as splice()’ing the data to /dev/null). iperf does also have flags for ‘extreme best case’ optimizations but they must be explicitly activated.

  14. Hi Peter, Im not sure, but DietPi support a lot of nanopi board, yourd might be in the list. I love dietpi because its small and easy to install a preset of software ( bit like linux when I started playing with it late 90’s).

    1. Hi – fully aware of DietPi and I use them often… no support yet – but I have to say having struggled with this board and the software I am beginning to warm up to it. I have 3 usable serial ports – and I’ve just tested the WIFI and it is access-point failure-proof. My only gripe now is apparent lack of support for (non-root user) GPIO – I’m looking around for solutions, I may get simple GPIO running but I’m thinking I2c etc is out of the question without support – I just wish these people were aware of and supportive of Node-Red but I’m thinking… unlikely. Talking of which – new update for the latter – just installed it on the A64 – lovely.

  15. I had the same experience with the backup. Still I am missing the final solution how to bu my system without buying a 32GB for my 16GB system. I like to stick with my Pi3 and I need to make a bu soon to prevent disaster. Did you succeed with the dd command? I think I will make an empty Raspbian as from the RPI site and bu the full system with node red and everything else, but all emails swapping out SD cards pfff..

    1. Yes the dd command did work 3 times. I’m about to try again now that I have one of the units working with WIFI and all my libraries etc…

    2. Leo, I often dd from the raspberry Pi to the CIFS link to my NAS:

      #!/bin/bash

      # Variables
      CIFSPATH=”//server.nom/path/” # CIFS path
      CIFSNOM=”userNom” # CIFS User
      ECIFSPSWD=’$64C6E!2DDH@C5′ # CIFS Password Encrypted wit rotXX

      # These aren’t secure, they’re meant to stop casual viewing and nothing more
      #
      rot49() {
      tr ‘\!-~’ ‘P-~\!-O’ <<< "$1"
      }

      # SecretPassword
      # $64C6E!2DDH@C5
      # pswd=$(rot49 '$64C6E!2DDH@C5')

      # CIFSPATH //SmbServer/path
      if [ -z "${CIFSPATH}" ]; then
      echo "Samba server path undefined"
      exit 1
      fi

      # CIFSNOM = SmbUserID
      if [ -z "${CIFSNOM}" ]; then
      echo "Samba username not defined"
      exit 1
      fi

      # CIFSPSWD = SmbUserPassword
      if [ -z "${ECIFSPSWD}" ]; then
      echo "Warning: Samba user password not defined"
      fi

      sudo mount -t cifs "${CIFSPATH}" -o username=${CIFSNOM},password=$(rot49 ${ECIFSPWDW}) /mnt -o iocharset=utf8,file_mode=0777,dir_mode=0777

      And the dd command:

      dd bs=1M if=/dev/mmcblk0 /mnt/pi.iso

  16. Thanks for looking at all these boards, I’m looking for something that is Pi like but with bppt EMMC support. I think the Pine A4 looks like the one I’ll go with. Hope I can turn off the graphics (headless) and use the memory in the OS.

    Hey I’m a Linux Fanatic (okay not as much anymore as I’ll let the user run what they want). Most of my systems are Linux (some custom firmware, a few Windows). Having said that, I’m not a lunatic who must load Gentoo and fine tune the system to an inch of its life.

    On sudo; wow, shocked that an Ubuntu distro didn’t have sudo … I wonder if the vendor set the root password? Having asked that, I’d recommend setting the root password (sudo password root) as there are instances where root must log in (like a bad disk on boot) and not everyone can set init=/bin/bash from grub (do these boards even used grub?).

    My main purpose for these little systems are to be the headless intelligence of my Smart Home.

    1. Well, me too – which is one reason I’m rather taken by the FriendlyArm A64 – the operating system as supplied is absolute crap and it was not easy getting it the way I wanted it – but the speed… well, I’m amazed. This could end up controlling my house.

    2. Some of the OrangePi boards have EMMC support, I believe. I have an Orange Pi PC Plus 2E (or something like that) and I think that has. I must confess, I never really dabbled with it long enough so I can’t tell you whether or not it’s any good as I’ve spent more time with the smaller, cheaper OrangePi boards as they do most of what I’m after.

      1. IMHO EMMC seems a lot faster than SD and so it is likely given the benchmark results I got for the A64 that SD will be the limiting factor with this board. That and the apparent lack of support for I/O.

  17. Yeah. No.

    Let me elaborate.

    You, sir, have a lot more patience than I. I feel it’s more like going to Home Depot to buy a tool. Then going home where you have to use your tools to fix the new tool. Yeah. No.

    Thanks for the review, keep up the good work!

    1. Try Armbian on your board. Mine does not get very hot. See reviews this is the first one I have not found a solution for.

  18. you don’t need to create an empty file using an editor like nano… you can just “touch” it… touch updates timestamps of a file, IF it exists… otherwise, it creates an empty file… so:

    touch /forcefsck

    is enough to force a filesystem check on next reboot (after which that empty file is wiped away)

  19. about long download times from China: i remember TKaiser published a script somewhere to fast download, can’t find it, maybe if he reads can add a link…

    about the fun of deal with problems: no, it’s not about being fanatic (i’m not, nor i’m a taleban), but about being masochist… that distro is shit, and a shame for friendlyarm who continue to put out boards with just A LITTLE more support than orange pi does… but none of them reaches the mediocrity, for sure…

    1. I DID find that the line drawing in the likes of MC came up as characters – but after running

      sudo dpkg-reconfigure locales

      and selecting ISO-8859-1 as well as UTF-8 then rebooting – all was ok after that.

      There are two things I’d say about this – FriendlyArm have provided considerably more feedback and response than Orange Pi (precisely ZERO responses to any questions I have ever raised and their main contact seems to be a separate individual) – but I also think perhaps they are rushing products out too quickly without putting enough time into software.

      And I have written to them and told them that they need to put more effort into providing good, working operating systems with support for GPIO. They did this for the H3 chip with a boatload of examples provided on board – but with this board, nothing as yet.

      There is a general comment I would make about ALL such companies – they claim to support Android yet put out ancient copies of Android – who for example would want to use Android 4 when we are up to Android 7. Personally I don’t want to use anything below Android 6 because the latter has good handling of SD (you can treat SD as internal memory) whereas previous versions required a not-very-good cluge.

      I don’t understand the logic – chucking out new boards – but not supported – developers won’t like them – won’t recommend them to their bosses in a job – or friends in hobbies.

      I’ve not tested WIFI or Bluetooth on this board but I should say – it does look fast.

    2. I think it’s the support level on offer that spawns the name of these devices – “nano” and “zero” etc. Notice how none of the devices have a model name including words such as “mega” or “super” …?

  24. Hi Pete,

    Interesting write up – as always – you’ve got more patience than me – what you’ve described above sounds like something far too embryonic to be of use to many ‘shallow end of the pool’ enthusiasts. That’s the great thing about blogs like this – sharing knowledge and information about the current state of various new boards so that others don’t get mislead and buy something that isn’t quite ready for general use.

    I’ve got a FriendlyArm NanoPi2 Fire but I found that it ran really hot so I’m always wary of being a ‘bleeding edge’ adopter of some of these boards and my experience with the NanoPi2 Fire nearly put me off the OrangePi Zero but that seems to run nice and cool – I’d bought my first one of those prior to reading your write up having already dabbled with various earlier OrangePi boards (One, Lite, PC Plus, Plus 2E).

    There’s something strangely addictive about dabbling with random new SBCs – I’m glad I’m not alone in this interest – my colleagues (despite also working in IT) just don’t understand my fascination but there are a few bargain gems out there if you don’t get put off by a few less well developed boards.

    I found the Pine A64+ pretty good but have yet to fix the slow ethernet bug (I think that’s been resolved?) and I never really got to grips with my LattePanda (how DO they come up with these names…?!) so when people ask “what are you going to use THIS one for?” I am pretty genuine with my answer of “I have absolutely no idea … but I’ll think of something” !

    1. pine64 has an hw bug, as far as i remember, which prevents full gbit eth… in armbian they put a patch to limit the problems… only newer revisions of the board are correct…
      lattepanda is SLOW AS HELL if you don’t put a good heatsink+fan on it… fan, the side that should be colder is UNDER, not UPPER… without proper heat dissipation, windows goes throttling and reduces DRASTICALLY performances…

Comments are closed.