Don’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.
- 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.
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!