|CPU||Quad-Core ARM Cortex-A53|
|Memory||up to 3 GB LPDDR2/ LPDDR3/ DDR3 / DDR3L|
|Video||MIPI DSI 1920x1200 @60fps, LVDS 1366x768 @60fps, RGB 1920x1200 @60fps, HDMI v1.4 4k @30fps|
|Network||GBit MAC, no PHY|
|Storage||NAND, NOR, MMC|
|USB||OTG, 1x Host|
|Other||BGA396, 0.65mm pitch, 15x15mm|
Allwinner A64 (sun50iw1) SoC features a Quad-Core Cortex-A53 ARM CPU, and a Mali400 MP2 GPU from ARM.
The A64 is basically an Allwinner H3 with the Cortex-A7 cores replaced with Cortex-A53 cores (ARM64 architecture). They share most of the memory map, clocks, interrupts and also uses the same IP blocks. Differences between the H3 and the A64 seem to be:
- The H3 has three USB host controllers, whereas the A64 has only one. Both SoCs have an additional USB-OTG controller, which is assumed to be used as normal host controller as well.
- The H3 DRAM controller supports up to 2GB of RAM, the A64 supports up to 3 GB. Despite being a 64-bit chip, this makes the SoC entirely 32-bit on the physical side.
- The H3 supports 5 UARTs, the A64 has 6 of them.
- The MMC controller has been updated to support faster transfer modes. The MMC clocks have changed on the way, now the MMC controller itself provides support for the output and sample phase.
- The H3 has SRAM A1 mapped at address 0, the BROM is at 0xffff0000. The A64 has its BROM mapped at address 0, SRAM A1 is mapped right behind it at 0x10000 (64KB).
- The pinmux configuration is still somewhat similar, but differs to an extent which makes them incompatible. A prominent example is (the debug) UART0, which is on PortA on the H3, but on PortB on the A64. H3 lacks PortB entirely.
A64 SoC Features
- ARM Cortex-A53 Quad-Core (r0p4, revidr=0x80) (scroll down for the PDF link)
- 512KiB L2-Cache
- 32KiB (Instruction) / 32KiB (Data) L1-Cache per core
- SIMD NEON (including double-precision floating point), VFP4
- Cryptography Extension (SHA and AES instructions)
- Affected by one critical erratum (only in AArch64 state): 843419
- ARM Mali400 MP2
- Featuring 1 vertex shader (GP) and 2 fragment shaders (PP).
- Complies with OpenGL ES 2.0
- DDR2/DDR3/DDR3L/LPDDR2/LPDDR3 controller (up to 3GB of 667MHz(DDR-1333))
- NAND Flash controller and 64-bit ECC
- H.265 4k @30fps, 1080p @120fps decoding
- H.264 1080p @fps decoding
- MPEG 1/2/4: 1080p @60fps
- VC1 1080p @30fps
- VP8 1080p @60fps
- AVS/AVS+ 1080p @60fps
- JPEG/MJPEG 1080p @30fps
- H.264 1080P @60fps encoding
- LVDS single link up to 1366x768 @60fps
- RBG with DE/SYNC up to 1920x1200 @60fps
- MIPI DSI 4-lanes up to 1920x1200 @60fps
- HDMI1.4 with HDCP1.2 up to 4k @30fps
- Supports parallel 8-bit YUV422 sensor
- Support CCIR656 protocol for NTSC and PAL
- Maximum still capture resolution 5M
- Maximum video capture resolution up to 1080p @30fps
- X-Powers AXP803, as seen used with A64 in Olimex Olinuxino A64 design
Allwinner H64 is targetted for OTT boxes and A64 for the tablets. Both are quad core Cortex A53 processors with a Mali-400MP2 GPU, H.265 4K video playback with basically the same interfaces and peripherals, but H64 also supports H.264 at 4K resolutions, while A64 is limited to H.264 @1080p, and H64 adds a TS interface.
The above mentioned manual details most peripherals. Some devices in the SoC are not described there, but have descriptions in other SoC's manuals:
- RSB: MMIO address and IRQ mentioned in the A64 manual, IP description in the A83T manual.
- PRCM: MMIO address mentioned in the A64 manual, IP description in the A83T manual.
Some remarks about the memory map.
Allwinner's BSP release contains source code of:
- a hacked 32-bit U-Boot port, based on the 2014.07 release
- a (not-mainlined) ARM Trusted Firmware port, based on the outdated v1.0 release
- a heavily modified AArch64 kernel, based on Linus' v3.10 release, plus Linaro LSK patches plus Android patches
In addition the BSP tarball contains some binary blobs, a toolchain and build scripts.
In general those bits are not in good shape (violating mainline coding standard both in form and content), are based on old and mostly no longer maintained releases and contains binary blobs (DRAM initialisation, power management, HDMI support). They are sometimes a good source of information for otherwise not (well) documented parts of the SoC.
The Allwinner provided BSP package for the Pine64 contains U-Boot source code, which provides 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. 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.
As of version 2017.07 the official mainline U-Boot fully supports the A64 SoC and various boards with it. This is the recommended way of booting boards when not using BSP kernels.
Basic support for the A64 SoC was merged into 2016.05-rc1. This covered UART, MMC and the required GPIOs and clocks. Ethernet support was added in 2016.09-rc1, USB with 2016.11-rc3. U-Boot 2017.03-rc1 saw the addition of the required DRAM init code, so SPL support was enabled. However this version lacked support for loading the ATF, which was merged into 2017.07-rc1.
This U-Boot implementation is a full featured 64-bit (armv8) port, it provides the full functionality of mainline sunxi U-Boot (including UEFI support). An aarch64 cross compiler is needed to compile U-Boot.
FEL mode - to download software into the device's memory via the USB OTG port - will be triggered if no other bootable media is found. Some devices feature an explicit FEL button to trigger this mode. The sunxi-tools repository contains a FEL boot stub, which can be written to an SD card to trigger FEL mode explicitly.
To actually load software via the FEL USB protocol (using
sunxi-fel from sunxi-tools), you have to use a FEL capable SPL. Since FEL booting is done entirely in AArch32 and requires returning to the Boot ROM in the same state afterwards, the mainline U-Boot SPL (using AArch64) does not support FEL boot. There is a branch maintaining a 32-bit port/config of U-Boot's A64 support, which allows to build a 32-bit, FEL-capable SPL binary. This is meant to be combined with the normal (mainline) AArch64 U-Boot proper and the normal ATF build. For convenience reasons binaries are provided. To boot a firmware stack via this method, after entering FEL mode use the following sunxi-fel command line:
$ sunxi-fel -v -p spl sunxi-a64-spl32-ddr3.bin write 0x44000 /path/to/arm-trusted-firmware/bl31.bin write 0x4a000000 /path/to/u-boot/u-boot.bin reset64 0x44000
This will load and run the SPL, load the ATF and U-Boot builds, then reset the board in AArch64 mode to execute the ATF, which will drop into U-Boot. Connect a serial console to proceed from there.
The mainline Linux kernel supports the A64 SoC quite well, at least for headless systems (serial console, ssh). Basic graphic framebuffer support can be achieved via simplefb/efifb already, native Display Engine support is progressing nicely.
First bits of A64 support have been merged into Linux v4.10-rc1, Working MMC and USB bring v4.11 into some kind of usable state. Ethernet support in v4.15 completes support of the basic (headless) peripherals.
The publically available SDKs contain kernel and u-boot trees which include and depend on several binaries. Allwinner is always violating the GPL in this way since A31. In the current A64 SDK, lots of blobs are included in kernel and U-Boot, including the critical DRAM code and the important HDMI code.
(The list below may be not finished, and do not list files related to non-A64 SoC)
(Only u-boot-2014.07 is checked here)