Pine A64 is one of the development boards with the best cost/performance ratio, as it sells as low as $15 + shipping. I received Pine A64+ board with 2GB RAM at the end of last month, and decided to start playing with Android, as Linux distributions such as Longsleep Ubuntu appear to require a little more work. So in this post, I’ll report my experience with installing and running Android 5.1 on the board, and share some Android benchmark results.
Pine A64 Board Pictures
You’ll receive the board in cardboard package with Pine64 branding.
You can check which version of the board you’ve been sent on the side of the package: PA64512 (512 MB RAM), PA641GB (1GB RAM), or PA642GB (2GB RAM).
The top of the board has been photographed often but here it is again. I’ve been sent the 2GB version without wireless module.
The bottom of the board has two RAM chips, and not much else.
I was quite surprised by the size, as it’s quite bigger than I expected.
From top left to bottom right: Raspberry Pi 2, Raspberry Pi Zero, Orange Pi One, ODROID-XU3, and Pine A64
Installing and Running Android 5.1 on Pine A64 Board
The list of Android and Linux firmware images can be found on Pine64 Wiki. The latest version of Android 5.1 has been released on May 5 2016 with SD card images for 8, 16, 32, and 64GB capacity, as well as Phoenix Card image with need to be installed with Windows or Linux tools. The only advantage of the Phoenix Card image is that it will not waste any bytes on your micro SD card, but since it should be negligible, I went ahead with the 32GB SD card image version:
|
1 |
wget http://files.pine64.org/os/android/android-ver5.1.1-20160505-pine64-32GB.zip |
I did so in a Ubuntu 16.04 computer, but other Linux distributions will have similar instructions, and in Windows you can either follow the instructions below with Windows for Linux subsystem or instead used Win32DiskImager program.
Once you’ve insert your SD card inside your computer (mine was a Toshiba class 10 32GB micro SD), check the device name with lsblk, which should be /dev/sdX or /dev/mmcblkY, with X some letter, and Y some numbers. I’ll call it <sd_device> below. First unmount partitions.
|
1 |
sudo umount <sd_device>* |
Normally, I’d use one command to extract, and once command to flash the image to the SD card, but since I was in a TV stick with 18GB free storage, I instead use a one liner to uncompress the 1.1 GB firmware and flash it to the micro SD card:
|
1 2 3 |
apt install pv unzip -p android-ver5.1.1-20160505-pine64-32GB.zip | pv | sudo dd of=<sd_device> bs=16M sync |
Now remove the micro SD card from your computer, insert it into the micro SD slot on Pine A64, connect Ethernet, a USB mouse and keyboard, and the power. My first board (and an early Android image) would not boot, so I connected the serial console to the EULER header: GND to pin 34, Tx to pin 30 and Rx to pin 29.
I ran minicom configured with /dev/ttyUSB0 115200 8N1 to find out what was going on:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
HELLO! BOOT0 is starting! boot0 commit : 2fe7b0a9fb512fae2996ec1a2ba89d535e1f3c4d boot0 version : 4.0.0 set pll start set pll end rtc[0] value = 0x00000000 rtc[1] value = 0x00000000 rtc[2] value = 0x00000000 rtc[3] value = 0x00000000 rtc[4] value = 0x00000000 rtc[5] value = 0x00000000 DRAM driver version: V1.1 rsb_send_initseq: rsb clk 400Khz -> 3Mhz PMU: AXP81X ddr voltage = 1500 mv DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3) DRAM clk = 672 MHz DRAM zq value: 003b3bdd DRAM error status 0 DRAM init error! initializing SDRAM Fail. |
The RAM clearly failed to initialize, so I reported this on the forum, and others had the same issue. I was sent another board, which booted just fine… sort of. The bootloader logo came very quickly, but then nothing happened, so I connect the serial console gain (I think a USB to TTL board is a must with Pine A64 at this stage of development), and I noticed a lot of erase operation on the micro SD card:
|
1 2 3 4 5 6 7 8 |
[ 349.994705] sunxi-mmc 1c0f000.sdmmc: *All wait r1 rdy 46 ms* [ 350.001104] mmc0:mmc_do_erase: erase from 41168912 to 41426943 arg 0x00000000 [ 350.723766] init: untracked pid 23550 killed by signal 9 [ 350.909829] sunxi-mmc 1c0f000.sdmmc: *All wait r1 rdy 46 ms* [ 350.917277] mmc0:mmc_do_erase: erase from 41431048 to 41689087 arg 0x00000000 [ 351.805289] sunxi-mmc 1c0f000.sdmmc: *All wait r1 rdy 45 ms* [ 351.811725] mmc0:mmc_do_erase: erase from 41705472 to 41951231 arg 0x00000000 [ 351.893824] sunxi-mmc 1c0f000.sdmmc: *All wait r1 rdy 4 ms* |
After 5 minutes it became quiet, and I though briefly the Android home screen, but it quickly fell back to another boot logo, and got stuck there. So I rebooted the board, and I got to the stock launcher in a little over one minute.
The Android firmware appears to be based on the smartphone version instead of the table version used in most Android TV boxes. A few apps are pre-installed such as the Google Play Store and ES File Explorer.
I could login to the Play Store, but soon I found that network connectivity did not seem to work well at all, and although I could browser app, the system was unable to download any, and later one I got an error message about network timeout while checking out apps. Internet connectivity issues do happen, and it’s seldom a problem with the board, so I went to ES File Explorer to install the apk manually through my SAMBA share, but networking was also unreliable on my LAN, which is not normal at all. The symptom was very similar to early Rockchip RK3288 TV boxes with Gigabit Ethernet, the link would show a Gigabit Ethernet connection, but the connection itself was unreliable, So I disconnected the board from my Gigabit switch (D-Link DGS-1005A), and instead connected it a 10/100M switch, and everything started to work as expected, so I installed apps from Google Play. The good news is that a firmware update might be able to fix the Gigabit Ethernet issue, if the root cause is the same as on RK3288.
My 32GB SD card has 26.27 GB usable by the user on a single unified partition.
Pine A64 Android Benchmarks
Let’s start with CPU-Z first to find a little more about the system.
Allwiner A64 processor has 4 Cortex A53 cores clocked at 480 MHz to 1.34 GHz with a Mali-400 MP2 GPU. The model is PINE A64 (tulip_chiphd), and the hardware 50iw1p1. The app detected 1987 MB RAM for the system with 26.27 GB for storage, and the resolution is set to 1920×1080. The system runs Android 5.1.1 on top of a 64-bit Linux 3.10.35 kernel.
We should not expect a Cortex A53 @ ~1.4 Ghz with a weak Mali-400MP2 GPU to get an amazing score, and the board got 24,568 points in Antutu 6.1.4, which is barely above the 21,500 points I got with Rockchip RK3229 quad core Cortex A7 based Zidoo X1 II TV box, and quite below the 35,000+ points in Amlogic S905 or Rockchip RK3368 based hardware platforms.
Vellamo pretty much confirm the performance with 1,292 points for multicore, 648 for Metal, and 1,610 for browser benchmarks, which compares to respectively 1,572, 763 and 2,002 points in K1 Plus TV box powered by Amlogic S905 quad core Cortex A53 @ 2.0 GHz.
3DMark Ice Storm Unlimited was used to get a score for the GPU, and 1,701 points is on the low side, but expected.
Finally, I tested the Ethernet connection using iperf for Android performing a full duplex transfer:
|
1 |
iperf -t 60 -c <server_ip> -d |
The results connected to my Ethernet switch are just fine:
|
1 2 3 4 5 6 7 |
Client connecting to 192.168.0.110, TCP port 5001 TCP window size: 136 KByte (default) ------------------------------------------------------------ [ 6] local 192.168.0.104 port 33317 connected with 192.168.0.110 port 5001 [ ID] Interval Transfer Bandwidth [ 6] 0.0-60.0 sec 654 MBytes 91.5 Mbits/sec [ 4] 0.0-60.1 sec 656 MBytes 91.5 Mbits/sec |
But switching to my Gigabit Ethernet switch confirm the problem I had earlier as the transfer only properly occurred in one direction instead of both:
|
1 2 3 4 5 6 |
Client connecting to 192.168.0.110, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 6] local 192.168.0.104 port 33464 connected with 192.168.0.110 port 5001 [ 5] 0.0-60.0 sec 3.55 GBytes 508 Mbits/sec [ 6] 0.0-169.1 sec 291 KBytes 14.1 Kbits/sec |
Overall performance is as expected, expect for Gigabit Ethernet, with only Fast Ethernet working reliably with my setup.
If you are interested in the board, you can purchase it on Pine64 online store for $15 (512MB RAM), $19 (1 GB RAM) or $29 (2GB) + shipping. Please note that the 512 MB version is only suitable for Linux distributions, and Android requires at least 1GB RAM.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
It should be added that a lot of the ‘user experience’ with Android and RemixOS depends on the random IO performance of the SD card in question.
Usual Android/RemixOS devices rely on fast NAND/eMMC while many or even most SD cards show horribly low random IO performance (the so called ‘speed class’ is more or less irrelevant since that’s sequential transfer speeds). Especially slow random writes can lead to a horrible Android user experience. More details here: http://forum.pine64.org/showthread.php?tid=191&page=6
@tkaiser
The problem is that there’s no SD class that defines random I/Os.
Even with a known card model with tested fast random I/Os, you can never be sure if your batch will be good too, since they may have changed the internals.
The slow download speed reported by users is likely a problem with the GMAC driver. Switching to fast Ethernet is much faster/more reliable.
@tkaiser
Would a Samsung EVO+ be good for random IO performance? I heard a bit of good about it and I trust that company.
@Rambler44
32G / 64G
http://forum.armbian.com/index.php/topic/954-sd-card-performance/
… while 128G EVO+ is much worse in random IO.
You can’t trust them 😉
@Jean-Luc Aufranc (CNXSoft) Yeah, I know. Having not any official random I/O classification means you’ve to buy and test yourself. At least my lesson learned from the testing we did at Armbian is: At the moment buying Samsung EVOs with 32 or 64 GB seems to be the best buy if the sequential transfer speeds are limited by the host/board (otherwise I would choose EVO+). And there’s another ‘funny’ problem associated with this: When you pull a fresh EVO/EVO+/Pro out of its package performance is worse compared to testing the same card after half an hour while intensively using it… Read more »
A lot of cards are fast burst write because their market is high speed, high definition photo and video. Wonder if that’s why they are not designed as mini hard drives. Pity you cannot use USB pendrives?
@Theguyuk
USB pendrives can have very poor random I/O performance too. See CrystalDiskMark randon I/O write for SSD (via USB) and a USB flash drive used in Voyo V2 review -> http://www.cnx-software.com/2015/10/03/review-of-voyo-v2-intel-atom-z3735f-mini-pc-with-battery-and-ssd/
The two lines to check are “4K” and “4K Q32T1” in CrystalDiskMark.
@tkaiser
In the case of eMMC flash, I noticed that flash with faster sequential speeds, still tend to perform better in Android, probably because they also have random I/Os, and they are probably designed to store the OS, contrary to SD cards and USB drives that are mostly used to store data.
Could it simply be that caching increases performance over time? But I guess you’ve already checked that.
OrangePI Plus 2E might be a good choice. It has 16GB emmc flash, 2GB Ram Gig ethernet for $35 plus usual inexpensive Aliexpress postage.
Works with Armbian and probably Android as well.
http://www.aliexpress.com/store/product/Orange-Pi-Plus-2-E-H3-Quad-Core-1-6GHZ-2GB-RAM-4K-Open-source-development/1553371_32665196281.html
I might get one. Last time I looked I couldn’t find a case though. Is a case important? Do people still worry about static or are these boards immune to it.
@Jean-Luc Aufranc (CNXSoft) There was zero caching involved and the effect on these Samsung cards is 100 percent reproducable. Just tried it out with a 64GB EVO+ that was ununsed a few weeks. When running the usual set of tests results were stable just after the 5th run which matches all Samsung results from the large test we made — see above Igor’s link. I observed this so far only with these Samsung cards (no other SD cards I tested or eMMC on various SBC) and the only importance this has is that you might easily fool yourself when doing… Read more »
@Nz1 If your use case is doing some specialized calculations with the ARMv8 instruction set the A64 clearly outperforms H3 as used on Orange Pis. But if you’re in need of high I/O bandwidth OPi Plus 2E is a real winner due to 3 real USB 2.0 host ports and the 1 USB OTG port being almost as fast. And this combined with 2GB RAM, Gbit Ethernet and really fast eMMC (I tested it just recently on OPi Plus 2/2E and Banana Pi M2+) makes a nice little server or desktop replacement. Since we’re talking about Android here: It does… Read more »
Crazy that this many months later, the GbE issue is still present, and it doesn’t seem like much is being done about it. I had hoped this would replace my RaspberryPi, but I’m thinking about going back to it.
Armbian arriving soon at Pine64 (or A64 in general): http://forum.armbian.com/index.php/topic/1917-armbian-running-on-pine64-and-other-a64h5-devices/
Update regarding networking performance: Armbian/Xenial outperforms official Pine64 OS images easily when looking at iperf numbers just due to taking care of settings used: http://forum.armbian.com/index.php/topic/1917-armbian-running-on-pine64-and-other-a64h5-devices/?view=getlastpost
The good news: By adopting settings changes other OS images can also perform better and by understanding how wrong it is to use iperf with SBCs people could start to relax instead of relying on crappy benchmark results spread accross the net 😉
@tkaiser
no, it will not replace little server or desktop or laptop. it is a joke to say so.
this small form factor are only for small little projects and still far away from capability to be a real daily pc.