We complete our test with Rev.B
Good news is that Gigabit interface works well with Micrel/Microchip PHY and result is real Gigabit bandwidth. A20 although having Gigabit interface can’t make more than 700 Mbit I guess this is related to A20 capability to handle the data from GMAC. With A64 the speed is 932Mbit i.e. very close to 1Gb:
root@A64-OLinuXino:~# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 10.0.0.4 port 5001 connected with 10.0.0.1 port 41144 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 1.09 GBytes 932 Mbits/sec
For eMMC we followed the advice to make it dual voltage 3.3V and 1.8V with aim to have faster transfers and we implemented it in the hardware, but the tests show that transfer is same even at 1.8V is a bit lower. I don’t know if this is due to lame software settings we do in the eMMC drivers, or just the eMMC we use have same transfer on both voltages (we check datasheet and the eMMC we use have same speed quoted on both voltages), so this may be useless for our eMMC chip:
eMMC clock: 52 Mhz eMMC@3.3V root@A64-OLinuXino:/home/olimex# dd if=/dev/zero of=/mnt/output conv=fdatasync bs=384k count=1k; rm -f /mnt/output 1024+0 records in 1024+0 records out 402653184 bytes (403 MB, 384 MiB) copied, 33.0437 s, 12.2 MB/s eMMC@1.8V root@A64-OLinuXino:/home/olimex# dd if=/dev/zero of=/mnt/output conv=fdatasync bs=384k count=1k; rm -f /mnt/output 1024+0 records in 1024+0 records out 402653184 bytes (403 MB, 384 MiB) copied, 37.9408 s, 10.6 MB/s SDMMC clock: 40MHz SDMMC@3.3V root@A64-OLinuXino:/home/olimex# dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output 1024+0 records in 1024+0 records out 402653184 bytes (403 MB, 384 MiB) copied, 41.1578 s, 9.8 MB/s
With SDMMC as we don’t know what SD card will be inserted the clock is set to default 40Mhz.
After re-checking that everything works, we make last cosmetic changes to audio part we noticed in the last moment and will run Rev.C in production.
olimex 
Sep 19, 2016 @ 14:17:00
GPIOs spacings in 2.54mm?
Sep 19, 2016 @ 16:29:15
yes
Sep 19, 2016 @ 21:38:13
Too bad there’s no SATA or USB3. Gigabit Ethernet and A64 is awesome, but it would be nice to have some more serious storage capability.
Sep 19, 2016 @ 23:17:00
When will it be available for purchase?
Sep 20, 2016 @ 21:27:34
did you trace the power button to a pin? Because in Rev A it is not. This means if you want to turn it on externally (any other way then the little button on the one specific position) you need to add your own power management….
Sep 21, 2016 @ 14:30:44
Thank you for the suggestion, Clemens. Technically, you can remove the button and use the pads for such purposes but this might be stressful. We would be adding the option to have the same signal that goes to the button to be available on the headers. This is being added at the moment.
Sep 22, 2016 @ 13:06:07
to use the button pads is very impractical, esspecialy if you want to use the board in a small scale production. BTW this is a problem of most of your boards. Could you somehow ask if its possible to bring the power button signal to the headers on your other boards to? Or at least for future Layouts? This would make it so much easier to use your boards in custom enclosures.
Mar 21, 2017 @ 00:27:45
I agree, having an on/off signal would be very helpfull
Sep 21, 2016 @ 13:25:23
I would expect eMMC to have bigger performance advantage from the SD. 12MB is a n SD achievable speed…
Sep 21, 2016 @ 15:02:25
what memory do you think is inside the SD card 😉
Sep 21, 2016 @ 18:40:56
Is this in MLC mode?
Sep 22, 2016 @ 11:22:13
What memory do you think is inside of the high performance SSD hard drives? 😉 I guess, the sequential read/write performance is just a matter of how many channels can be accessed in parallel for data transfers. See http://www.cactus-tech.com/en/resources/blog/details/solid-state-drive-primer-8-controller-architecture-channels-and-banks
Expensive eMMCs and SSDs can be really fast. But cheap eMMCs, SSDs and especially SD cards may have a simplified hardware for the sake of cost reduction. Or just as a wild guess, maybe it’s easier to ensure reliability and industrial grade temperatures support by sacrificing speed?
Are there any cheaper and faster non-industrial grade eMMC alternatives, which could be used together with a cheap non-industrial grade Ethernet PHY? Or is this niche intentionally left to be filled by Orange Pi boards?
Sep 21, 2016 @ 20:34:06
Great card! However I agree with Stephen. The SATA connectors were one of the reasons why we (Libraries Without Borders) choose the Olimex card for the KoomBook project. The storage is one of our big needs for this project. Looking forward for the next evolutions!
Sep 22, 2016 @ 10:38:41
I agree with Stephen. The lack of SATA or USB3 might be a problem for the storage. Is there any chance OIlimex could include this in a next evolution of the card ?
Sep 23, 2016 @ 11:52:42
The Allwinner A64 SOC doesn’t have SATA or USB3, the only hope for external storage is the single USB2 host or an ethernet or WIFI NAS.
Sep 23, 2016 @ 16:09:51
Well, there is one USB2.0 host port (and also an unpopulated HSIC thingie where you might be able to solder an USB hub to?) and the USB 2.0 OTG port. We learned just recently that at least on Pine64 (where the OTG port is exposed as the upper type A port instead of ‘correctly’ as Mini/Micro port) the OTG port can be turned into a full USB host port using an own USB PHY: https://github.com/longsleep/linux-pine64/issues/34
So at least 2 USB2 ports are there but funnily the fastest interface will be GbE on this board. So booting from eMMC — SPI on Olimex’ yet not announced cost down variant available soon 😉 — with rootfs and everything else on NFS is maybe the fastest option you get (I miss random IO tests for the eMMC but maybe some software tweaks are necessary anyway so it’s too early to judge)
Regarding SATA: Allwinner announced an A20 successor with 4 Cortex-A7 cores in the meantime: http://linux-sunxi.org/File:Allwinner_R40_Datasheet_V0.1.pdf
Sep 23, 2016 @ 16:19:33
R40 is not pin to pin compatible with A20!
Sep 23, 2016 @ 23:35:47
@Olimex, regarding R40, maybe this will be the best that we will get (as a successor to A20). When they are available you can do a quick (benchmark) test to see if it is worth to redo some boards for the R40.
Jan 12, 2017 @ 11:20:36
It might be dumb suggestion, but I wonder if it’s possible to solder a SATA port that would connect to usb hub as a usbstorage through some unknown magic.
Sep 23, 2016 @ 23:44:15
The a64 has a hsic port which is just sitting there, idle, and microchip has some USB hubs with hsic upstream.
Gives us some additional usb ports for keyboard, mouse, disk.
Sep 24, 2016 @ 09:41:47
Allwinner H5 has more USB controllers in the SoC and might be a better choice for your use cases which need more USB receptacles. It is believed that Xunlong will have some low cost Allwinner H5 based boards soon(ish): http://forum.armbian.com/index.php/topic/1762-opi-3-and-opi-pc2-with-h5
BTW, they also seem to have an on-board SPI flash chip, which is very nice. It is a very good idea to always have either eMMC or SPI flash on every board, in order to store the bootloader/firmware there.
Sep 24, 2016 @ 10:56:37
Hi when will this available to purchase ?
Sep 24, 2016 @ 20:40:38
May be better testing is needed for the eMMC speed. I’ve seen dd under-perform in many configurations. At least use pv (http://www.ivarch.com/programs/pv.shtml), if running a full bonnie++ is too much. Or even `cat`. And test the device, not a mounted filesystem.
Sep 27, 2016 @ 13:35:58
I will never understand why people are interested only in sequential transfer speeds. Are we talking about development boards running an OS or digital cameras and video recorders?
Random IO is way more important and this is where most eMMC perform way better even if sequential transfer speeds seem to be identical compared to SD cards (and most SD cards out there horribly suck when it’s about random IO, even those capable of really high sequential transfer speeds)
Regarding bonnie/bonnie++ — never trust the tool you use: http://www.brendangregg.com/ActiveBenchmarking/bonnie++.html
I would recommend using iozone instead (and using ext4 as reference since different fs perform differently, especially ‘foreign’ fs like NTFS). In Armbian forum there exist 3 threads collecting numbers of various SD cards and eMMC implementations. But I fear posting the links my account here gets disabled due to being considered a spammer 🙂
Sep 27, 2016 @ 17:16:50
There is a simple reason: it is simple, usually highly repeatable and it gives an indication about the most painful moment – flashing the OS, or backing/restoring the whole image during development. Also it is usually the fastest possible (and thus repeatable) in all simple media combinations (excluding some special HDD/RAID).
{there is one more, I am professionally biased, since I work in digital forensics}
I am not saying bonnie++ or any other benchmark is trustable by default, just suggesting that dd, due to the way it is written, is definitely not a benchmark tool and testing hardware for performance is easier with the thinnest software (no file system that is).
Sep 27, 2016 @ 14:44:42
It would be awesome if this is the first board to integrate the High Speed MMC modes (both on the SD and eMMC).
Sep 29, 2016 @ 10:43:30
Does your u-boot supports TFTP boot? I am working on a Dockerfile to compile the whole thing for a pine64 board that had been donated to Kernelci.org, it you are interested, I will publish the link once it is working. Maybe also think about sending one board to those kernelci.org guys, there is no A64 on the sunxi list yet:
https://kernelci.org/soc/sunxi/
Oct 03, 2016 @ 18:30:19
Is there any future plan to make SOM based A64? This would be great for the people would like to customize.
Nov 02, 2016 @ 23:27:38
When will this board be available for sale ?
Mar 21, 2017 @ 00:30:17
Guys, when will this be avaliable? We need the damn thing!
Apr 07, 2017 @ 02:25:09
Been waiting so long the first round of Cortex-A72 developer boards are already hitting the market, like Firefly-RK3399, but is not open source hardware. As for Cortex-A53, I’m also not happy with the build quality of the PINE64. I’m hoping your A64 board comes out soon. I hope in 2018 you may think about a Cortex-A72 board. I don’t think the laptop replacement comes until Cortex-A73 by the end of the decade.