Home > Allwinner A6X, Android, Hardware, Linux, Testing > Pine A64 Board Quick Start Guide & Benchmarks with Android 5.1

Pine A64 Board Quick Start Guide & Benchmarks with Android 5.1

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.

Click to Enlarge

Click to Enlarge

The bottom of the board has two RAM chips, and not much else.

Click to Enlarge

Click to Enlarge

I was quite surprised by the size, as it’s quite bigger than I expected.

Click to Enlarge

Click to Enlarge

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:

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.

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:

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:

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:

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.

Click to Enlarge

Click for Original Size (1920×1080)

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.

Click to Enlarge

Click to Enlarge

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.

Click to Enlarge

Click to Enlarge

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:

The results connected to my Ethernet switch are just fine:

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:

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.

  1. tkaiser
    May 31st, 2016 at 19:33 | #1

    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

  2. May 31st, 2016 at 20:16 | #2

    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.

  3. Rambler44
    May 31st, 2016 at 20:19 | #3

    Would a Samsung EVO+ be good for random IO performance? I heard a bit of good about it and I trust that company.

  4. May 31st, 2016 at 21:01 | #4


    32G / 64G

    … while 128G EVO+ is much worse in random IO.

    You can’t trust them 😉

  5. tkaiser
    May 31st, 2016 at 22:36 | #5

    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 (seems the card’s controller is doing some calibration or something like that). I fooled myself multiple times when testing until I realized that.

  6. Theguyuk
    June 1st, 2016 at 04:34 | #6

    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?

  7. June 1st, 2016 at 09:12 | #7

    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.

  8. June 1st, 2016 at 09:38 | #8

    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.

  9. Nz1
    June 1st, 2016 at 12:45 | #9

    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.


    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.

  10. tkaiser
    June 1st, 2016 at 14:22 | #10

    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 benchmarks with Samsung cards directly after purchase (showing performance too low)

  11. tkaiser
    June 1st, 2016 at 14:27 | #11

    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 not seem Allwinner or anyone else is porting a more recent Android version than 4.4 to H3 SoC.

  12. Aaron C
    August 15th, 2016 at 21:49 | #12

    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.

  13. tkaiser
    August 29th, 2016 at 00:08 | #13
  14. tkaiser
    August 29th, 2016 at 16:09 | #14

    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 😉

  15. van
    September 17th, 2016 at 07:43 | #15

    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.

  1. No trackbacks yet.