Pine64
| Pine64 | |
|---|---|
 | |
| Manufacturer | Pine64 |
| Dimensions | 133mm x 80mm x 19mm |
| Release Date | February 2016 |
| Website | Pine64 Wiki |
| Specifications | |
| SoC | A64 @ 1152MHz |
| DRAM | 512MiB/1GiB/2GiB DDR3L @ 672MHz (Samsung K4B2G1646Q-BCK0 / Samsung K4B4G1646Q-HYK0 * 2 / Samsung K4B4G0846E * 4) |
| NAND | none |
| Power | DC 5V @ 2A, 3.7V Li-Ion battery connector, Euler connector |
| Features | |
| Video | HDMI (Type A - full) |
| Audio | 3.5mm headphone/microphone plug |
| Network | (optional) WiFi 802.11 b/g/n (Realtek 8723BS), 10/100/1000Mbps Ethernet (Realtek 8211E) (plus version), 10/100Mbps Ethernet (Realtek 8201FN) (non-plus version) |
| Storage | µSD |
| USB | 2 USB2.0 Host |
| Other | DSI, CSI, TP, RTC |
The Pine64 is a cost-optimized board sporting ARMv8 (64-bit ARM) capable cores.
Contents |
Identification
There is a pine cone like logo next to the uSD slot, also it says "Pine64" under the logo. Also on the SoC there is a quite prominent "A64" print.
On the back of the device, the following is printed:
Designed in Silicon Valley, California. Built in Silicon Delta, China.
The PCB has the following silkscreened on it:
A64-DB-Rev B 2015-12-17
In android, under Settings->About Tablet, you will find:
- Model Number: Pine A64
- Build Number: tulip_t1-eng 5.1.1 LVY4BE 20151210 test-keys
Different models
So far there are three different models:
- The Pine64 with 512MB DRAM
- The Pine64+ with 1GB DRAM
- The Pine64+ with 2GB DRAM
The last two seem to be identical apart from the installed DRAM size. Differences between the Pine64 and the Pine64+ are:
- The Pine64 only supports Fast Ethernet. So the PHY chip will be a Realtek 8201 instead of the 8211 on the bigger model. The 8211 speaks RGMII, while the 8201 is using the MII interface. This requires differences in the DT.
- The smaller model will lack the connectors for the touchscreen, LCD screen and the camera port.
Sunxi support
Current status
There are Linux images using an updated and enhanced version of Allwinner's BSP kernel, that work reasonably well and provide a graphical GUI along with support for most features of the board.
Upstream kernel support is work in progress, so far there is a "close-to-mainline" branch (based on 4.7-rc1) which supports UART, MMC (uSD card), GPIO, I2C and Ethernet (missing USB and any kind of graphics or sound support). Out-of-the-box arm64 distributions boot reasonably well with this kernel.
This firmware log and 4.4-rc kernel dmesg provides some information about the system.
Images
End Users: Here are links to current images that are community supported:
- Ubuntu by Longsleep (from Pine64.pro)
- Arch Linux image (not supported anymore)
- Debian Mate (from Pine64.pro)
- Debian XFCE (from Pine64.pro)
(You should also cross-check the Wiki page that's linked under Manufacturer Images.)
Developers: Get apritzel's github basic image first. For instructions see the README.md in there for now.
longsleep has also built a minimal Ubuntu image combined with the the BSP Kernel that can be downloaded here. You will find instructions here on how to set it up.
This image is intended for developers and comes with the following:
- BSP Linux Kernel 3.10.65+
- BSP U-Boot
- Ubuntu Ubuntu 16.04 (Xenial Xerus) aarch64
- HDMI at 1080P
- HDMI analog audio (alsa, pulseaudio)
- Ethernet (including 1000M)
- USB
- Wifi
BSP
Allwinner's BSP contains an arm64 Linux kernel based on Linaro's LSK-3.10.65 (includes Linaro and Android patches). It has traces (commented or not-configured code parts) of nasty experiments (like entering the kernel in AArch64 EL3 or running in secure EL1). This released/leaked code does not exactly match what's on the provided Android images. The BSP kernel is entered in non-secure El1, thus denying any kind of virtualization (like KVM).
Manual build
You can build things for yourself by following our Manual build howto and by choosing from the configurations available below.
U-Boot
Sunxi/Legacy U-Boot
The Allwinner provided BSP package contains U-Boot source code, which contains a 32-bit port based on the 2014.07 release. The code as in the tarball does not even compile, also the whole port is severely crippled, just enough to boot an Android system from MMC. Limitations include: missing booti support (no direct kernel image load, only Android kernel images can be used), no network support, only loading data from Android partitions (no filesystem support), completely non-standard DT bindings, no support for easy FDT loading, etc. For the complete rant see the Wiki history ;-)
However the existing code base was fixed and extended by longsleep to allow loading kernels directly (using booti and proper FDT support) and adding filesystem support, thus overcoming the most severe limitations. The most current code base can be found here.
At the moment this U-Boot version is required to boot BSP kernels.
Mainline U-Boot
Basic support has been merged in 2016.05-rc1. It supports serial console and MMC (µSD card), but no Ethernet or USB yet. The booti command is supported to load Linux arm64 kernel images, also bootefi is available to launch Aarch64 EFI applications (like grub2).
The port is a 64-bit version, so the Allwinner provided boot0/ATF pair will not boot this without further changes/patches. Also SPL support is still missing, because:
- we are missing the required magic DRAM initialization bit to replace boot0's DRAM init code
- the SPL must run (or at least start) in AArch32 mode, since this is the state in which the boot ROM hands over execution.
There are possible solutions for both problems (especially the last one) and they should be available over time. This will eventually enable SPL support.
To compile it, check out the latest U-Boot tree and use:
$ export CROSS_COMPILE=aarch64-linux-gnu- $ make pine64_plus_defconfig $ make
You will want to use the resulting u-boot-dtb.bin file.
You may want to use these additional fixes on top.
Linux Kernel
Sunxi/Legacy Kernel
Mainline kernel
Mainline kernel support is work in progress. For a first experience, grab a firmware image and flash it to a micro-SD card:
# zcat pine64_firmware-20160601.img.xz | dd of=/dev/sdx bs=1M
(replacing sdx with the device name of your micro-SD card).
This image contains Allwinner's boot0 (for initializing the DRAM), an ARM Trusted Firmware version (for 64-bit initialization, PSCI support and basic PMIC setup) and an upstream U-Boot, plus the device trees for both board variants.
Then get the latest "close-to-mainline" kernel tree and build it (in an existing kernel tree):
$ git remote add a64 https://github.com/apritzel/linux.git $ git fetch a64 $ git checkout -b a64-v5 a64/a64-v5 $ export CROSS_COMPILE=aarch64-linux-gnu- $ ARCH=arm64 make clean defconfig $ ARCH=arm64 make -j4 Image
Copy the built kernel image (from arch/arm64/boot/Image) to the first FAT partition of the micro-SD card. Then put this SD card into the Pine64 board, connect a serial console to either the Euler connector or the EXP headers and power the board. You will see the kernel being loaded and booted, but finally fail due to the missing root file system. By creating a logical partition (sdx5) on that micro-SD card and populating it with an off-the-shelf arm64 root file system you should be able to log in and explore the system.
Tips, Tricks, Caveats
Boot sequence
The A64 SoC is wired to come out of reset in 32-bit monitor mode. As other Allwinner devices, the A64 SoC starts executing BROM code (mapped at address 0), which is consequently ARM32 code. The complete BROM code can be found at address 0x2c00 and has a total length of 32KB. To enter FEL mode, power on the board without a SD card inserted. If the code does not detect a FEL condition, it will load 32KB from sector 16 (8 KByte) of the microSD card to SRAM and will execute this. At least the first instructions of this code need to be still 32-bit ARM code.
The Allwinner firmware continues in 32-bit, loading U-Boot (32-bit also) from the microSD card at sector 38192 (19.096 KByte). It also loads a (hacked) version of ARM Trusted Firmware (ATF) into DRAM and code for the arisc management core into SRAM. Finally it does a RMR write to warm-reset the SoC in AArch64 execution state and jumps to the ATF entry point by putting its address in the RVBAR register. ATF will then initialize the boot core for non-secure execution and drop to non-secure AArch32 EL1 to run U-Boot.
U-Boot then runs happily in 32-bit. Only just before it starts the kernel, it uses a custom smc service call back into (Allwinner's version of) ARM Trusted Firmware to hand over the kernel entry point. The ATF code will then return into _AArch64_ non-secure EL1, but using the provided kernel entry point instead of returning to U-Boot.
FEL mode
The Pine64 board will fail over to FEL mode if it doesn't detect a card present in the µSD slot.
A tricky and potentially confusing part is that the only Micro USB receptacle (labelled as "POWER JACK") is used exclusively for providing power to the board, and is not connected to any USB controller in the SoC. The actual USB OTG controller in the SoC is connected to the upper USB host receptacle. So it needs a somewhat special USB cable (A male to A male) or an adapter (A male to Mini/Micro B female) to connect your Pine64 board to your desktop PC, which is running the sunxi-fel tool.
As soon as you boot your Pine64 into FEL mode (remember, don't insert a SD card) you should find a new USB device:
$ lsusb Bus 001 Device 005: ID 1f3a:efe8
$ ./sunxi-fel version AWUSBFEX soc=00001689(A64) 00000001 ver=0001 44 08 scratchpad=00017e00 00000000 00000000
SPI NOR Flash
It should be possible to have an extra hardware accessory, pluggable into the Raspberry Pi compatible expansion header to add a small SPI NOR Flash on SPI0 pins. It can store a bootable firmware and provide all the fashionable "industry standards" compatibility for running AArch64 server grade Linux distributions (not exactly now, but maybe some time in the future). The Bootable SPI flash page provides additional details.
Expansion headers
Documentation about the pin assignments and more specifications (like the physical dimensions of the board) can be found in the Hardware section of the official Pine64 Wiki.
AXP803 PMIC
The default voltages after cold boot seem to be at least a little bit off. For example, the voltage on the Euler connector's 3.3V pin is in fact 3.0V until the Allwinner's bootloader configures the PMIC (very likely the default voltage from DCDC1). It means that the U-Boot bootloader will have to configure AXP803 early and relying on the defaults is not a very good idea.
The DRAM voltage is provided from DCDC5, which is set to 1.5V by default according to the AXP803 manual. Moreover, the AXP803 manual is explicitly recommending to use DCDC5 specifically for DRAM. This is safe even with 1.35V DDR3L chips, because they are compatible with 1.5V too.
CPU clock speed limit
The voltage-frequency table for Allwinner A64 can be found in FEX files included in the A64 SDK:
; dvfs voltage-frequency table configuration ; ; max_freq: cpu maximum frequency, based on Hz ; min_freq: cpu minimum frequency, based on Hz ; ; lv_count: count of lv_freq/lv_volt, must be < 16 ; ; lv1: core vdd is 1.30v if cpu frequency is (1104Mhz, 1152Mhz] ; lv2: core vdd is 1.26v if cpu frequency is (1008Mhz, 1104Mhz] ; lv3: core vdd is 1.20v if cpu frequency is (816Mhz, 1008Mhz] ; lv4: core vdd is 1.10v if cpu frequency is (648Mhz, 816Mhz] ; lv5: core vdd is 1.04v if cpu frequency is (480Mhz, 648Mhz] ; lv6: core vdd is 1.04v if cpu frequency is (480Mhz, 648Mhz] ; lv7: core vdd is 1.04v if cpu frequency is (480Mhz, 648Mhz] ; lv8: core vdd is 1.04v if cpu frequency is (480Mhz, 648Mhz]
Based on the data from this table, 1152MHz @1.3V is the fastest cpufreq operating point. Additionally, the AXP803 PMIC uses 1.1V default voltage for DCDC2/DCDC3 (VDD-CPU). Which means that the the CPU can be safely clocked up to 816MHz before the PMIC is initialized.
Serial port / UART
The board connects 4 of the SoCs UART to easily accessible header pins. There is UART2 on the RPi connector, also UART3 and UART4 on the Euler connector. UART0 is the main UART used by Allwinner's firmware for boot and debug messages and is accessible on pins 29 (TXD), 30 (RXD), 25/34 (GND) on the Euler connector (this is not mentioned in the official connector description). Alternatively you can use the UART0 on the EXP connector, accessible on pins 7 (TXD), 8 (RXD), 9 (GND). The RX pin on there is connected via a FET to the SoC's pin, so it prevents injecting power via this line.
Using screen to connect to the UART0 for example on OS X:
$ sudo screen /dev/cu.usbserial 115200
All of the UARTs use 3.3V voltage levels. Look at UART howto for further instructions.
A connected UART cable is leaking power and this causes some annoyances. For example, unplugging and plugging back a power cable does not reboot the board cleanly. Thus ensuring the availability of a reset button is recommended for doing any reasonable software development.
The board does not have a hardware reset button out of the box, but a button can be easily connected to the appropriate pin on the expansion connector. Also a standard micro switch (upright version) can be soldered on the board next to the USB sockets to ease early development ;-)
Pictures
Pine64+ (2 GB)
Pine64+ (1 GB)
Pine64 (512 MB)
See also
wiki.pine64.org Further info on the hardware and firmware
forum.pine64.org Discussion on pine64
