The ROCKPro64 is the most powerful single-board computer released by PINE64. It is powered by a Rockchip RK3399 hexa-core (dual ARM Cortex A72 and quad ARM Cortex A53) 64-bit processor with a Mali T-860 quad-core GPU. The key features include a PCI Express (PCIe) x4 open-ended slot, the use of LPDDR4 DRAM, and industry-standard heatsink mounting holes.

The ROCKPro64 is equipped with 2 or 4 GB of LPDDR4 system memory, and 128 Mb of SPI boot flash. There is also an optional eMMC module (up to 128 GB) and microSD slot for booting. The board is equipped with 1x USB 3.0 Type-C host port with DP 1.2, 1x USB 3.0 Type-A host port, 2x USB 2.0 host port, Gigabit Ethernet, PI-2 GPIO bus, MiPi DSI interface, eDP interface, touch panel interface, stereo MiPi CSI interface, as well as many other device interfaces such as UART, SPI, I²C, for makers to integrate with sensors and other peripherals. Many different operating systems (OSes) are freely available from the open-source community, such as Linux (Ubuntu, Debian, Arch), BSD and Android.

Getting started

This section gives important information to get the board up and running.

Video Playback

Hardware video acceleration is supported in recent kernels and user needs only to install the relevant Mesa packages/ports, specifically the Mesa DRI drivers for Mali GPUs (Midgard/Bifrost). One can confirm via software glxinfo, or having the library file such as …/lib/dri/panfrost_dri.so.

Ayufan has some old documentation on video playback here. For your ROCKPro64 the install should be

sudo apt-get install ffmpeg mpv libmali-rk-midgard-t86x-r14p0-gbm

(These modules are included in the Ayufan desktop releases.) At which stage rkmpv myvideo.mp4 will play a fullscreen, hardware assisted, version of your video. rkmpv is at /usr/local/bin/rkmpv

Using an NVMe Disk as rootfs

Forum member Bullet64 has documented how to move rootfs to an NVMe disk. This is useful until we get a full SPI option to boot from the NVMe.

Setup a Serial Console (UART2)

To use Serial Console you will a need operating system that supports it on your RockPro64, by default the serial console is provided for baud 9 600 which is far too slow for rockpro64 so consider using 1 500 000 (1.5Mbps) instead IF your serial console device supports it (many doesn’t which results in their inability to use the console).

In terms of connections you need to perform the following from your serial console-capable device e.g. Pine64’s Woodpecker available in store:

• GND <-> GND (pin 6)
• RxD <-> TxD (pin 8)
• TxD <-> RxD (pin 10)

After the configuration of your preferred operating system you can connect to the serial console using any of these commands:

$ screen /dev/ttyUSB0 1500000

$ picocom /dev/ttyUSB0 -b 1500000

$ minicom -D /dev/ttyUSB0 -b 1500000

Alternatively there is a detailed guide on forums: https://forum.pine64.org/showthread.php?tid=6387

GNU/Linux:

• With GNU/Linux on your RockPro64 the built-in support for serial console can be enabled by parsing parse e.g. console=ttyS2,1500000n8 in the kernel command line, many distributions make this available by default, but consider verifying the contents of /boot/extlinux/extlinux.conf if you encounter issues.
• NOTE: the n8 in the kernel argument means no parity, 8 bits per character

Booting from USB or PXE

The default choice of boot device is first eMMC (if present) then SDcard. See ROCKPro64 under “jumpers” for details on adjusting this sequence.

It is possible to flash the SPI to extend the options for boot devices to USB drives or PXE. The preferred method is now the rock64_write_spi_flash.sh script (see useful scripts above).

Background info and historic details of this usage can be found here.

Booting from SPI using u-boot

Always be prepared to recover from a broken SPI boot BEFORE flashing or you will end up with a broken boot.

In general the recovery is killswitching SPI through shorting pins 23 <-> 25 together and then loading u-boot from a storage device e.g. SD-card or eMMC where majority of GNU distributions e.g. Manjaro usually have u-boot packaged with the provided images.

Follow instructions in https://github.com/sigmaris/u-boot/wiki/Flashing-U-Boot-to-SPI#instructions-for-rockpro64

Boot sequence

The RockPro64 boot sequence has been documented here by sigmaris.

OTG Mode

You can boot your ROCKPro64 into OTG mode with the use of the Recover button (see switch 28 under Layout#Switches). Note that there are 2 OTG ports on your ROCKPro64: the type-C USB 3 socket is definitely one. From the schematic it appears the USB 3 (type A) socket is the other, but this has yet to be confirmed.

The method is to power off the board. Then push and hold the Recover button and push and release the Power button.

• If you have an Ayufan bootable image in either the SD-card or eMMC then there are 4 OTG modes described here including Android fastboot, RockUSB and MaskROM modes. Releasing the Recover button as soon as the white LED lights counts as 1 blink. Keeping it pressed you will get 2 blinks of the white LED etc. Once the board enters OTG mode the red LED will be lit. In mode 1 the boot and linux-root partitions of the card with the Ayufan image (partitions 6 & 7 of a Linux installation) are made available as devices. In all cases the USB device made available at the host has device ID 18d1:d00d.
• If you do not have an Ayufan image in either the SD-card or the eMMC, then neither white nor red LEDs will light, but the board will enter MaskROM mode where the USB device made available at the host has device ID 2207:330c.

NVMe Drives

Please be aware that the PINE64 SSD interface card is intended for use with NVMe devices. These can be identified by the fact they have a single (Key M) notch, e. g. the WD Black devices.

While M2/NGFF SATA devices (with a Key B notch, typically have Key M as well) will physically fit, they will not work. e. g. WD Blue devices.

SATA Drives

SATA drives can be connected directly via the ROCKPro64 PCIe interface card. Please note the card does not include the power cable - that is a separate item. Equally you must be aware that connecting SATA drives in this manner means they will be drawing power from your ROCKPro64 - please ensure you are using a 5A or better power supply.

ExplainingComputers did a YouTube ROCKPro64 PCIe SATA card review and tests using a Ubuntu console and OpenMediaVault.

Wi-Fi & Bluetooth Module

If you have bought the Wi-Fi and Bluetooth module from the Pine store then instructions for connecting it can be found on the accessories page. Please note that the 0.7.9 Ayufan’s Linux releases (August 2018) have deliberately DISABLED support for this module in the search for stability. It can be tested and used with the Android image.

It can also be used on Manjaro by installing ap6256-firmware and wireless-regdb packages.

7" LCD Touch Screen

Instructions for connecting the LCD touch screen from the Pineare on the accessories page.

Note at present (August 2018) this screen is only supported by the Android image.

RTC Battery Backup

The Pine store has a couple of options for RTC battery backups: a AAA version here or a CR-2032 version here.. For the ROCKPro64, the backup plugs into the RTC connector, number 6 in the board layout diagram above, next to the USB3 and case screw point.

Board

Features

This section outlines the most important characteristics of the board and its components.

SoC and Memory Specification

The ROCKPro64 is based on the Rockchip RK3399.

CPU Architecture

• Dual-core Cortex-A72 up to 2.0GHz CPU
• Quad-core Cortex-A53 up to 1.5GHz CPU
• big.LITTLE architecture: Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU
• Cortex-A72:
  • 1-4x Symmetrical Multiprocessing (SMP) within a single processor cluster, and multiple coherent SMP processor clusters through AMBA 5 CHI or AMBA 4 ACE technology
  • AArch64 for 64-bit support and new architectural features
  • L1 cache 48KB Icache and 32KB Dcache for each A72
  • L2 cache 1024KB for big cluster
  • DSP & SIMD extensions
  • VFPv4 floating point
  • Hardware virtualization support
• Cortex-A53:
  • L1 cache 32KB Icache and 32KB Dcache for each A53
  • L2 cache 512KB for little cluster
• Full implementation of the ARM architecture v8-A instruction set
• ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation
• ARMv8 Cryptography Extensions
• In-order pipeline with symmetric dual-issue of most instructions
• Include VFP v3 hardware to support single and double-precision operations
• TrustZone technology support
• Full CoreSight debug solution
• One isolated voltage domain to support DVFS

GPU Architecture

• ARM Mali-T860MP4 Quad-core GPU
• The highest performance GPUs built on Arm Mali’s famous Midgard architecture, the Mali-T860 GPU is designed for complex graphics use cases and provides stunning visuals for UHD content.
• Frequency: 650MHz
• Throughput: 1300Mtri/s, 10.4Gpix/s
• OpenGL® ES 1.1, 1.2, 2.0, 3.1, 3.2, Vulkan 1.0*, OpenCL™ 1.1, 1.2, DirectX® 11 FL11_1, RenderScript™.

System Memory

• LPDDR4 RAM Memory Variants: Dual Channels 2GB and 4GB.
• Storage Memory: 128Mb built-in SPI Flash memory (as at August 2018 only support for USB boot).

Display

• Dual VOP: one supports resolutions up to 4096x2160 and AFBC; the other supports resolutions up to 2560x1600
• Dual channel MIPI-DSI (4 lanes per channel)
• eDP 1.3 (4 lanes with 10.8Gbps) to support displays, with PSR
• Digital Video port up to 4Kp60
• DisplayPort 1.2 (4 lanes, up to 4K 60Hz)
• Supports Rec.2020 and conversion to Rec.709

Video

• Digital Video output up to 4K@60Hz
• 4K HDR @ 30fps
• H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4Kx2K @ 60fps
• H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4Kx2K @ 60fps
• VP9, up to 4Kx2K @ 60fps
• MPEG-1, ISO/IEC 11172-2, up to 1080P @ 60fps
• MPEG-2, ISO/IEC 13818-2, SP@ML, MP@HL, up to 1080P @ 60fps
• MPEG-4, ISO/IEC 14496-2, SP@L0-3, ASP@L0-5, up to 1080P @ 60fps
• VC-1, SP@ML, MP@HL, AP@L0-3, up to 1080P @ 60fps
• MVC is supported based on H.264 or H.265, up to 1080P @ 60fps

Audio

• 3.5mm Phone Jack
• 3-pin S/PDIF header
• Audio via Digital Video port

Camera

• Dual MIPI CSI, dual ISP, maximum input resolution of 13M pixels

Network

• 10/100/1000Mbps Ethernet - Capable of pushing 941 MBit/s in iperf3
• Wi-Fi 802.11 ac/a/b/g/n with Bluetooth 4.01 (old version with 2x2) / Bluetooth 5 (new version with 1x1) (optional)

Storage

• microSD - bootable, supports SDHC and SDXC
• eMMC - bootable (optional eMMC module)
• 1x USB 3.0 host port
• 1x USB Type-C OTG port with alternate mode DP output
• 2x USB 2.0 dedicated host port

Expansion Ports

• 2x20 pins “Pi2” GPIO header
• PCI Express 2.1 x4 (four full-duplex lanes) open-ended port, limited to the Gen1 speed

Working Features

RockChip themselves have tables of supported features at 4.4 and mainline kernel versions in their wiki here.

GPIOs

GPIO Pins

Notes:

• pulled high to 3.3V through 2.2kOhm resistor

Linux /dev/gpiochip Assignments

On Linux, using the new /dev/gpiochip API, the _n_ in GPIO_n___XX_ appears to correlate to the number of the /dev/gpiochip_n_, and the _XX_ to the definition RK_P_XX_ of lines in include/dt-bindings/pinctrl/rockchip.h of the Linux kernel source. Having these named in the dts would be nice.

You can use libgpiod to drive them, and test them with the included tools (gpioinfo, gpioset, …)

For example, gpioset 4 25=1 (run as root) would turn pin 22 on. Do beware that poking the wrong GPIO pin can lock up your system.

The conversion table at right is also available as a C header file.

Layout

Main Chips

• RK3399 system-on-chip (1)
• LPDDR4 SDRAM 1 (18)
• LPDDR4 SDRAM 2 (3)
• SPI NOR flash memory (17)
• RK808 power management (near 19)
• RTL8211 ethernet transceiver (near 25)
• ES8316 Sound Codec (on rear of board)
• The heatsink mounting holes around the RK3399 are 59 mm apart

Switches

The Power button (11, SW3): is the same as on your mobile phone - press and release after about 1 second to power on. Press and hold for about 3 seconds to power off.

The Reset button (10, SW901): performs a reset.

The Recover button (28, SW900): used to enter maskrom mode.

Connectors, Sockets and Headers

LEDs

A green LED next to the 12V input barrel connector will light as long as there is 12V applied to the connector. (Even if the RockPro64 is powered off.)

A white LED behind the reset button will light as long as the RockPro64 is running (it comes on a few seconds after power on, when control is passed to the operating system.)

A red LED behind the reset button is DIY - it is lit for example if the board is in OTG mode with an Ayufan image, or if an Android image is in standby mode.

Yellow and green LEDs on the LAN socket behave in a standard way.

Jumpers

They are used for boot device selection, as described in the following section.

Disable eMMC

There is an unlabelled (on the PCB silk-screen) 2-pin jumper (16) between the eMMC socket (14) and the SPI chip (17). It is designated as SW4 on the schematic diagram under “Board Information, Schematics and Certifications”. The default condition is OPEN (no jumper). It is useful for controlling the boot as follows:

Default boot device (with no SPI software) is eMMC, then SDcard. If both the eMMC and the SDcard contain bootable images then the eMMC can be disabled by installing the jumper. This completely removes the eMMC from the resulting OS. If you wish the eMMC to be visible in the booted OS the jumper should be removed 2 seconds after applying power (and before the white LED comes on).

The possible combinations are summarised in the table below.

• 1 = present
• 0 = not present

Disable SPI (while booting)

There is a second possibility to jumper your ROCKPro64: If you mess-up your SPI and are unable to boot, jumpering pins 23 (CLK) and 25 pin (GND) on the PI-2-bus header will disable the SPI as a boot device. (This was taken from the IRC logs, 09 August 2018 @ 17:23) You have to remove the jumper 2 seconds after having started your RP64 (before the white LED turns ON) otherwise the SPI will be missing and you won’t be able to flash it. Ayufan images contain (at the moment) only one script for the SPI and the RP64, it’s “rockpro64_reset_spi_flash”. Other SPI scripts are dedicated to the R64 (as it is written on the name) and it will mess-up your RP64 SPI if you use them.

Software

Releases

This page contains a list of all available releases and tools for the ROCKPro64 in alphabetical order.

Linux

AOSC

AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. Originally AnthonOS (an OpenSUSE derivative built with SUSE Studio), then remade as a Debian derivative with customized KDE 4 UI and CJK support. To learn more about AOSC, please visit the official AOSC website

Download:

• https://aosc.io/downloads/ (supports the microSD card and eMMC, 8GB or more)

Armbian

Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored. To find out more about Armbian and available options please visit their site. If you are booting from a Micro SD card, then both Linux kernel versions will work. If you are trying to boot from an eMMC module then the 4.4.y will work, but the newer 5.10.y will not.

Download:

• https://dl.armbian.com/rockpro64/archive/

Batocera Linux

Batocera Linux is an open-source and completely free retro-gaming distribution that can be copied to a USB stick or an SD card with the aim of turning any computer/nano computer into a gaming console during a game or permanently. Visit the project’s website here (https://batocera.org/). You can follow the ongoing discussion about batocera.linux on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=7084)

Download:

• https://batocera.org/download

Debian

Debian is an operating system and a distribution of free software. See the forum thread here.

Download:

• Debian 11 Bullseye
• Debian 12 Bookworm (recommended)
• Daily netboot images

Instructions:

• Download: firmware.rockpro64-rk3399.img.gz
• Download: partition.img.gz
• Create the disk image:
  • For Linux: zcat firmware.rockpro64-rk3399.img.gz partition.img.gz > complete_image.img
  • For Mac: gzcat firmware.rockpro64-rk3399.img.gz partition.img.gz > complete_image.img
• Write the image to your boot device:
  • For Linux: dd if=complete_image.img of=your_chosen_boot_device bs=4M
  • For Mac: see Getting started

Notes:

• An Ethernet connection is required for the above installer
• Remember to leave some space before your first partition for u-boot! You can do this by creating a 32M size unused partition at the start of the device.
• See the troubleshooting section if you encounter issues with GPU acceleration.

DietPi

DietPi is a lightweight, yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the ROCKPro64 build on the PINE64 forum thread.

Download:

• Direct download from dietpi.com

LibreELEC

Download:

• Official LibreELEC build image (look for PINE64 RockPro64-LibreELEC-RK3399.arm-x.x.x-rockpro64.img.gz, supports microSD card and the eMMC module of 8GB or more.)

Manjaro ARM

Manjaro is a user-friendly Linux distribution based on the independently developed Arch operating system. To learn more about Manjaro please visit Manjaro forum.

Download:

• from Github

Notes:

• Decompress the image (unxz*) before flashing, or decompress on the fly while flashing (*xzcat in a root shell, Etcher, or others)
• A display and keyboard will be required for first boot.
• Initial setup includes: keyboard layout, locale, username, user password, and root password.
• The installer will expand the root partition to use the remaining space on the storage device you’ve flashed.

Nems Linux

NEMS stands for Nagios Enterprise Monitoring Server and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more about NEMS on the PINE64 and available tweaks to the installation please visit the PINE64 forum thread.

Download:

• Download page with torrent seed or direct download.

NixOS

NixOS is a Linux distribution built on top of the Nix package manager using declarative configuration to allow reliable system upgrades. More information can be found on the NixOS wiki.

Download:

• nixos-installer-rockpro64

OpenMediaVault

OpenMediaVault is the next generation network attached storage (NAS) solution, click this link to OMV main page to learn more. Forum thread concerning this release can be found here

Download:

• Stretch 32bit (armhf): Direct download from ayufan’s github
• Stretch 64bit (aarch64): Direct download from ayufan’s github

Notes:

• You need to enable root login in OMV WebGUI
• OpenMediaVault Plugins can enhance the system

OpenWrt

OpenWrt ​is a highly extensible ​GNU/​Linux ​distribution for embedded devices ​(typically wireless routers). Unlike many other distributions for these routers, OpenWrt ​is built from the ground up to be a full-featured, easily modifiable operating system for your router. In practice, this means that you can have all the features you need with none of the bloat, powered by a Linux kernel ​that’s more recent than most other distributions.

Download:

• https://openwrt.org/toh/pine64/rockpro64_v2.1

postmarketOS

postmarketOS extends Alpine Linux to run on smartphones and other devices. At the time of writing, the only user interface provided through prebuilt images for the ROCKPro64 is Plasma Bigscreen.

Download:

• https://postmarketos.org/download/

R-Cade

Retro Center’s R-Cade, the 4K Media Center Arcade. RCade Features 100+ retro-gaming systems, a lightweight web browser, and full 4K UHD media playback.

Download:

• Direct download from Retro Center’s GitHub (USB, microSD and eMMC boot)

Recalbox

Recalbox allows you to re-play a variety of videogame consoles and platforms in your living room, with ease|Visit the project’s website here (https://www.recalbox.com/). You can follow the ongoing discussion about Recalbox on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=7194)

Download: {{Template:Outdated release}}

• download release from mrfixit2001 github.

SkiffOS

Minimal cross-compiled OS optimized for hosting distributions in Docker containers. Provides the reliability of firmware with the ease-of-use of package managers. Uses the Buildroot cross-compilation tool for support for all Pine64 boards.

Use configuration packages to configure the distribution:

• core/gentoo: Gentoo optimized for Rockpro64
• core/nixos: NixOS arm64

You can also configure the skiff core yaml file to configure multiple distributions to run in parallel.

The boot-up OS can be upgraded independently from the containers.

Download:

• The repository and instructions can be found here.

Slackware

Slackware is the world’s oldest actively developed Linux distribution, providing a modern user land (applications) and Linux Kernel, within a more classic Unix Operating System environment.

Resources:

• Installation instructions.
• Installation video guide

slarm64

slarm64 is an unofficial aarch64 / riscv64 Slackware Linux port. You can follow the ongoing discussion about slarm64 on the RockPro64 on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=6823) or this forum thread for more general slarm64 information: https://www.linuxquestions.org/questions/slackware-arm-108/slarm64-aarch64-unofficial-slackware-4175613287/.

Downloads:

• download (supports microSD card, look for slarm64-current-aarch64-xfce-rockpro64-x.xx.x-build-xxxxxxxx.img.zst)

Flashing the distribution to the eMMC:

• Flash the image to micro SD, power up the board with micro SD and login
• Copy the image file to micro SD by using SFTP. The image file must have the .img file extension.
• After finish copy the file, power off the board and add eMMC module to the board
• Boot the board, run below command for flashing to eMMC module
• Run dd if=[image file] of=/dev/mmcblkX bs=10M (example: sudo dd if=slack-current-aarch64-xfce_29Sep18-4.4.162-rockpro64-build-20181126.img of=/dev/mmcblkX bs=10M)
• then edit these two files in eMMC module:
  • mount /dev/mmcblk1p1 /media
  • echo "rootdev=/dev/mmcblk1p1" >> /media/boot/uEnv.txt
  • sed -i 's:mmcblk0p1:mmcblk1p1:' /media/etc/fstab
• After that, power off the board and remove the microSD card. Then boot with only the eMMC module.

Twister OS

Twister OS brings a desktop computing experience for SBCs, right out-of-the-box. Including themes, applications, tools, and optimizations to get the most out of your SBC. For more information on Twister OS, please visit the official site. You can follow the ongoing discussion about Twister OS on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=12192).

Download:

• Twister OS Armbian-Reforged XFCE Desktop image (2.8GB, supports the microSD card and eMMC modules with 16GB and more)

Void Linux

Void Linux is a general purpose operating system, based on the monolithic Linux kernel. The official guide can be found at Guide. At this time there are no RockPro64 images available.

The following creates a bootable image from an existing Void Linux installation:

• xbps-insall -Syu to update the xbps installation of the installation
• create ROCKPro64 image with the void-mklive software (from github.com):
  • create a rootfs via mkrootfs.sh: sh mkrootfs.sh -o void-aarch64-muls-ROOTFS-yyyymmdd.tar.xz
  • sh mkplatformfs.sh rockpro64 void-aarch64-muls-ROOTFS-yyyymmdd.tar.xz
  • sh mkimage.sh -s 7GiB void-rockpro64-PLATFORMFS-yyyymmdd.tar.xz
• write image to sdcard or eMMC: dd if=IMAGE-FILENAME of=DEVICENAME bs=2M
• If mkplatformfs.sh errors with ROCKPro64 not supported, install xbps-src from https://github.com/void-linux/void-packages and build the ROCKPro64 package.
• Tip: write a new U-Boot to the image if you see on the serial console the boot-up stalls:
  • get the two U-Boot files from pkgs.org, the aarch64 files:
  • dd if=idbloader.img of=DEVICENAME seek=64
  • dd if=u-boot.itb of=DEVICENAME seek=16384

BSD Images

FreeBSD

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms. The RockChip FreeBSD page has instructions for installing FreeBSD. Version 13.0 and greater include prebuilt images.

Download:

• Images for various FreeBSD releases can be found here

Notes:

• The wiki has instructions on enabling the PWM cooling fan.

NetBSD

Download:

• download latest release build from NetBSD by select 64bit - RockPro64 (size: 339 MB)

Notes:

• Instructions concerning enabling SSH can be found here or the bootable image from armbsd.org can have the MSDOS partition modified to setup SSH using this method.

OpenBSD

OpenBSD is a security-focused, free and open-source, Unix-like operating system based on the Berkeley Software Distribution. Official instruction to get OpenBSD on ROCKPro64 is here, and blogs on installation is here and here. Forum discussion is here.

Chromium OS

The Chromium OS community build image for microSD card and eMMC module, version beta (R76). To learn more please visit the forum.

Download:

• https://github.com/ayufan-rock64/chromiumos-build/releases/

Android

Android 9.0.0

Stock for DD method [eMMC Boot] [20200804]

• Use ‘dd’ to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred.
• Please allow 3-5 minutes boot up time on first time for initialization
• Supports new RockPro64 AP6256 Wifi/BT module
• Support Sony IMX214 camera module and works on both MiPi-CSI ports
• This build supports PINE64 7" LCD panel with tablet UI (not Android TV)
• DD image for 8GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): 7287fd0846616354615c8d3eff6a2a92 ***** File Size: 602MB
• DD image for 16GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): 78352bbf21198d062af8bab2217ee691 ***** File Size: 611MB
• DD image for 32GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): c5c8dce419478f75f85f893ee4808dbd ***** File Size: 624MB
• DD image for 64GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): aab1cf4d30c4d16e6ce2672f3ecae935 ***** File Size: 666MB

Stock for RK Flash tool [eMMC Boot] [20200804]

• Please unzip first and then using Android tool to flash in
• The OTG port located at USB type-C connector, needs USB type A to type C cable.
• Direct download from pine64.org ** MD5 (GZip file): 9ac830527814521e15b009fa2503c9e3 ** File Size: 589MB

*Stock for DD method [eMMC Boot] [20200708]

• Use ‘dd’ to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred.
• Please allow 3-5 minutes boot up time on first time for initialization
• Supports new RockPro64 AP6256 Wifi/BT module
• This build supports PINE64 7" LCD panel with tablet UI (not Android TV)
• DD image for 8GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): ef5f5a890a9270734e0adee21f006837 ***** File Size: 597MB
• DD image for 16GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): 179bd684a468f800a86f7c658a543bef ***** File Size: 606MB
• DD image for 32GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): d930b757c4427be07b83c37a9c8494a1 ***** File Size: 630MB
• DD image for 64GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): 09a970d68a10bdb3d6495d55860940e6 ***** File Size: 660MB

Stock for RK Flash tool [eMMC Boot] [20200708]

• Please unzip first and then using Android tool to flash in
• The OTG port located at USB type-C connector, needs USB type A to type C cable.
• Direct download from pine64.org ** MD5 (GZip file): 6d060ddd47ebcfd5cfcdbf90ec042c97 ** File Size: 589MB

Stock for DD method [eMMC Boot] [20190427]

• Use ‘dd’ to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred.
• Please allow 3-5 minutes boot up time on first time for initialization
• Please ignore “internal problem with your device” popup message if appear on Android boot-up page.
• This build supports PINE64 7" LCD panel with tablet UI (not Android TV)
• DD image for 16GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): 3BA4C72D81BCFC4C21B3B5D2BCB4F9F7 ***** File Size: 609MB
• DD image for 32GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): 4965CCF50A8F06CEB2E4A6828A21F31C ***** File Size: 627MB
• DD image for 64GB eMMC module ** Direct download from pine64.org ***** MD5 (GZip file): 748EC28FE5D5395D33E858C913D744BF ***** File Size: 663MB

Stock for DD method [microSD Boot] [20190506]

• DD image to microSD card and boot.
• Use ‘dd’ to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred.
• Please allow 3-5 minutes boot up time on first time for initialization
• Please ignore “internal problem with your device” popup message if appear on Android boot-up page.
• This build supports PINE64 7" LCD panel with tablet UI (not Android TV)
• DD image for 8GB microSD card ** Direct download from pine64.org ***** MD5 (GZip file): E1C551E8106E178841E1C3F71432194A ***** File Size: 599MB
• DD image for 16GB microSD card ** Direct download from pine64.org ***** MD5 (GZip file): 73592FDD5A2F52F08020F16AD99E8C8C ***** File Size: 609MB
• DD image for 32GB microSD card ** Direct download from pine64.org ***** MD5 (GZip file): 74DE0FE528F210E4DD483B411A71904B ***** File Size: 627MB
• DD image for 64GB microSD card ** Direct download from pine64.org ***** MD5 (GZip file): D7626BD50443A88AEB9254C88C575284 ***** File Size: 663MB

Stock for RK Flash tool [eMMC Boot] [20190427]

• Please unzip first and then using Android tool to flash in
• The OTG port located at USB type-C connector, needs USB type A to type C cable.
• Please allow 3-5 minutes boot up time on first time for initialization
• This build supports PINE64 7" LCD panel with tablet UI (not Android TV)
• Direct download from pine64.org ** MD5 (GZip file): 046BA4A07933120809FBE1B9577B7341 ** File Size: 592MB

Android 8.1.0

Stock for DD method [eMMC Boot] [20180828]

• Use ‘dd’ to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred.
• Please allow 3-5 minutes boot up time on first time for initialization
• This build supports PINE64 7" LCD panel with tablet UI (not Android TV)
• Direct download from pine64.org ** MD5 (XZ file): 9AEE21BC1B9DE886DCB0E64FA123988A ** File Size: 414MB

Stock for DD method [microSD Boot] [20181212]

• Use ‘dd’ to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred.
• Please allow 3-5 minutes boot up time on first time for initialization
• This build supports PINE64 7" LCD panel with tablet UI (not Android TV)
• DD image (for 8GB microSD card and above)
• Direct download from pine64.org ** MD5 (XZ file): 5A6BB7FCD7B3F77FCEE99CE462AE7405 ** File Size: 616MB

Stock for RK Flash tool [eMMC Boot] [20180828]

• Please unzip first and then using Android tool to flash in
• The OTG port located at USB type-C connector, needs USB type A to type C cable.
• Please allow 3-5 minutes boot up time on first time for initialization
• This build supports PINE64 7" LCD panel with tablet UI (not Android TV)
• Direct download from pine64.org ** MD5 (XZ file): 4DACFE927BB09EE9C56B5232A7F624EE ** File Size: 415MB

Android 7.1.2

Stock for DD method [eMMC Boot] [20180518]

• Use ‘dd’ to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred.
• Please allow 3-5 minutes boot up time on first time for initialization
• This build supports PINE64 7" LCD panel with tablet UI (not Android TV)
• Direct download from pine64.org ** MD5 (XZ file): 33622034ACDBC31A7D7BB01ED634E29B ** File Size: 345MB

Stock for RK Flash tool [eMMC Boot] [20180518]

• Please unzip first and then using Android tool to flash in
• The OTG port located at USB type-C connector, needs USB type A to type C cable.
• Please allow 3-5 minutes boot up time on first time for initialization
• This build supports PINE64 7" LCD panel with tablet UI (not Android TV)
• Direct download from pine64.org ** MD5 (XZ file): 90C1991DADAE13ADC94E927F171F8920 ** File Size: 342MB

Android SDK

Android P SDK [v9.0]

• Direct Download from pine64.org ** MD5 (TAR-GZip file): 3CEBEEFD1A873BEEEC149148A785D92E ** File Size: 125.16GB

Slash TV OS

Android 7 based system including Play Store, working only from SD card (does not boot when installed on eMMC)

• https://drive.google.com/drive/folders/1K5YhWaB7Xstuv2HCo1HkpglCEm9x-RIM

Development resources

The Ayufan github page

• github.com/ayufan-rock64/linux-build/

Below are the LPDDR4 driver for RK3399

• rk3399_loader_v1.10.112_support_1CS.bin, this is 800Mhz version used in Android Build
• rk3399_ddr_666MHz_v1.11.bin, this is alpha version
• rk3399_ddr_933MHz_v1.11.bin, this is alpha version

ROCKPro64 related files

• ROCKPro64 Kernel file
• trust.img

Miscellaneous tools

• Windows ADB driver package
• MAC address
• Guide to install stock Android build to eMMC module
• Tools to burn Android build into a bootable microSD card
• Tools that allows developer flash image into eMMC’s Loader/Parameter/Misc/Kernal/Boot/Recovery/System/Backup partition

Device Tree Overlays on Mainline

If your U-Boot has been compiled with CONFIG_OF_LIBFDT_OVERLAY (which Manjaro’s is), adding device tree overlays the mainline way is very simple and easy.

Writing Your Device Tree Overlay

First off, you’ll have to write a device tree overlay. In this example, we’ll enable the ROCKPro64’s I2C bus that’s exposed to the pin headers, and declare that a PCF8574 GPIO extender is hanging off it.

/dts-v1/;
/plugin/;

&i2c8 {
	status = "okay";
	#address-cells = <1>;
	#size-cells = <0>;

pcf8574: pcf8574@20 {
	compatible = "nxp,pcf8574";
	reg = <0x20>;
	gpio-controller;
	#gpio-cells = <2>;
};
;

We’ll go through this file line by line.

• /dts-v1/; specifies that this file is a DTS file.
• /plugin/; specifies that this is not just a regular device tree source file, but an overlay.
• &i2c8 { references the i2c8 node in the device tree we’re applying on top of, meaning we’re going to modify this specific part of it.
• status = "okay"; enables the i2c8 node. It’s set to “disabled” in the tree we’re applying on top of, specifying the property like this overrides it.
• #address-cells = <1>; is already set in the base tree, but since the compiler doesn’t know what the base tree is, it’ll yell at us if we don’t set this.
• #size-cells = <0>; same as above.
• pcf8574: pcf8574@20 { adds a child node labelled pcf8574 to the i2c8 node, which is a PCF8574 controller at address 0x20.
• compatible = "nxp,pcf8574"; the compatible string of the node, letting the kernel know what driver it needs to load for it.
• reg = <0x20>; the I2C address the device is listening on, in hexadecimal.
• gpio-controller; declares that this node is a GPIO controller.
• #gpio-cells = <2>; required for GPIO controllers.

Assuming we’ve saved this as pcf8574.dts, we can compile it as follows:

dtc -O dtb -o pcf8574.dtbo -@ pcf8574.dts

This creates a compiled pcf8574.dtbo from the pcf8574.dts input file, and with -@ we preserve the labels of nodes, which in turn allows something to more easily overlay onto this overlay.

Loading It

Next, copy your compiled device tree overlay file—in the previous example pcf8574.dtbo*—somewhere into your /boot, for example */boot/dtbs/overlays/.

Then we modify /boot/extlinux/extlinux.conf and add the line emphasised in bold to it:

LABEL Manjaro ARM
KERNEL /Image
FDT /dtbs/rockchip/rk3399-rockpro64.dtb
*FDTOVERLAYS /dtbs/overlays/pcf8574.dtbo*
APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 root=LABEL=ROOT_MNJRO rw rootwait quiet splash plymouth.ignore-serial-consoles

To specify multiple overlays, simply separate them with space on the same line.

Now after a reboot, the device tree overlay file should be applied, and your kernel will see the new device. You can confirm this by dumping the device tree the kernel uses, and grepping it for whatever you added:

dtc -I fs /sys/firmware/devicetree/base | grep -A4 'pcf8574'

Further Reading

• Linux Kernel Documentation - Devicetree Overlay Notes
• Embedded Linux Wiki - Device Tree Usage
• CounterPillow’s overlay-examples repository

Installing Arch Linux ARM

Commands to be run as a normal user are prefixed with $, commands to be run as root are prefixed with #. We assume your target device is /dev/sdX, adjust accordingly.

Obtaining and Building U-Boot And TF-A

The first step is to compile the open firmware (TF-A) and the open bootloader (u-boot).

Clone u-boot git repository:

$ git clone https://source.denx.de/u-boot/u-boot.git

Clone TF-A git repository:

$ git clone https://github.com/ARM-software/arm-trusted-firmware.git

Build TF-A (you will need aarch64-linux-gnu-gcc and arm-none-eabi-gcc for this)

$ cd arm-trusted-firmware
$ make realclean
$ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399

Next, export the path to your compiled BL31 in the shell you’ll build u-boot in. Adjust the path as necessary.

$ export BL3/path/to/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf

Build U-Boot (you may need to install additional packages to successfully compile, such as bc, python-pyelftools, or swig):

$ make mrproper
$ make rockpro64-rk3399_defconfig
$ make CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

Preparing The Block Device

Here we assume your block device is /dev/sdX, adjust as needed.

Create a new partition table:

# parted -s /dev/sdX mklabel gpt

Create the partitions for loader and u-boot:

# parted -s /dev/sdX mkpart loader 64s 8MiB
# parted -s /dev/sdX mkpart uboot 8MiB 16MiB

Create the partition for u-boot’s environment (optional, but you’ll have to adjust the following offsets if you don’t do it):

# parted -s /dev/sdX mkpart env 16MiB 32MiB

Create the “efi” boot partition and mark it as bootable:

# parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB
# parted -s /dev/sdX set 4 boot on

Create the root partition:

# parted -s /dev/sdX mkpart root ext4 544MiB 100%

Creating The File Systems

Now create the file systems for boot and root:

# mkfs.vfat -n "efi" /dev/sdX4
# mkfs.ext4 -L "rootfs" /dev/sdX5

Flashing U-Boot

Flash idbloader.img and uboot.img:

# dd if=idbloader.img of=/dev/sdX1
# dd if=u-boot.itb of=/dev/sdX2

Fetching The Root File System Tarball

Fetch the root filesystem tarball and the PGP signature

$ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig}

Fetch the gpg keys:

$ curl 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x68b3537f39a313b3e574d06777193f152bdbe6a6' | gpg --import=-

Compare the key ID provided in the above command with the one listed here: https://archlinuxarm.org/about/package-signing (Take good note of the domain and HTTPS)

Verify the tarball’s authenticity

$ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig

Installing The Root File System

# mount /dev/sdX5 /mnt/alarm-root
# mkdir /mnt/alarm-root/boot
# mount /dev/sdX4 /mnt/alarm-root/boot
# bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/alarm-root

Editing fstab

Find your partition UUIDs for both partitions using lsblk:

$ lsblk -o NAME,SIZE,MOUNTPOINTS,PARTUUID

In /mnt/alarm-root/etc/fstab, put the lines

PARTUUID=_root-uuid-here_  /       ext4    defaults        0       1
PARTUUID=_boot-uuid-here_  /boot   vfat    defaults        0       2

with your UUIDs in place of the placeholder.

Writing extlinux.conf

Create a /mnt/alarm-root/boot/extlinux/extlinux.conf with these contents:

default l0
menu title ROCKPro64 Boot Menu
prompt 0
timeout 50

label l0
menu label Boot Arch Kernel
linux /Image
fdt /dtbs/rockchip/rk3399-rockpro64.dtb
append initrd=/initramfs-linux.img earlycon=uart8250,mmio32,0xff1a0000 console=ttyS2,1500000n8 root=LABEL=rootfs rw rootwait

Once done, unmount the partitions:

umount /mnt/alarm-root/boot

umount /mnt/alarm-root

Finishing Setup

SSH in as root with password root and run

# pacman-key --init
# pacman-key --populate archlinuxarm

Troubleshooting

No Video or GPU Acceleration on Debian

If you can log in through serial but don’t get any video or GPU acceleration on Debian, this is likely due to Debian’s decision to compile the devfreq governors as loadable modules but not including them early enough for panfrost to be able to be provided with one of them.

The usual sign of this being the case is the following line in the kernel log: [drm:panfrost_devfreq_init [panfrost]] **ERROR** Couldn’t initialize GPU devfreq

To fix this issue, run the following as root and reboot:

echo governor_simpleondemand >> /etc/initramfs-tools/modules
update-initramfs -u -k $(uname -r)

PCIe probe failures on Linux kernel boot

While booting the Linux kernel, you might experience PCIe probe failures, which render the attached PCIe device inaccessible. The “drivers: pci: introduce configurable delay for Rockchip PCIe bus scan” thread on the Linux kernel mailing list (LKML) discusses this issue and proposes a fix.

Manjaro ARM applies the following patches to the kernel package, which fix the issue:

• 1005-rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch
• 1007-arm64-dts-rockchip-Add-PCIe-bus-scan-delay-to-RockPr.patch

Hardware

Hardware tweaks

Enabling PCIe 2.0

By default, the RockPro64 runs the PCIe slot at gen 1 speeds because there might be stability issues with gen 2 speeds. The port can be switched back to gen 2 speeds by adding the following device tree overlay.

1. Copy and paste the device tree overlay file below into a new file (you could name it pcie-2.0.dts):

   // Pulled from: https://forum.armbian.com/topic/23574-howto-enable-pcie-gen2-to-get-max-speed-of-nvme-rockpi-4b/
   /dts-v1/;
   /plugin/;
   
   &pcie0 {
           max-link-speed = <0x03>;
   };
   

2. Compile the device tree into a binary file. Note that you will need dtc installed.

   dtc -I dts -O dtb -@ pcie-2.0.dts -o pcie-2.0.dto
   

3. Copy or move the device tree from the current directory into the boot partition (in this case into the /boot/dtbs/overlay/ folder). If you haven’t yet created the /boot/dtbs/overlay/ folder, then create it with sudo mkdir /boot/dtbs/overlay/

   sudo cp pcie-2.0.dto /boot/dtbs/overlay/
   

4. Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a extlinux.conf file), then add the following line to the file /boot/extlinux/extlinux.conf:

   FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb
   

If you already have an FDTOVERLAYS line, then add a space at the end of the current line, then add this overlay file after that. See here for details on this process: Device Tree Overlays on Mainline

The resulting /boot/extlinux/extlinux.conf file might look like below after adding this dtb file:

LABEL Manjaro ARM
KERNEL /Image
FDT /dtbs/rockchip/rk3399-rockpro64.dtb
FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb
APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil

Overclocking (and undervolting)

The RK3399 can be overclocked. See here for details: Overclocking/RK3399-based devices. By overclocking, you do risk damaging your hardware, however, it is possible to achieve small, but measurable improvements in performance with an overclock. The overclock can be applied with a device tree overlay file.

Below is an example device tree overlay for CPU overclocking on the RockPro64. It may or may not work well on your device, but some have found that these speeds are stable. The example below bumps the little cores up to 1.608GHz from 1.416GHz and bumps the big cores up to 2.088GHz from 1.8GHz.

1. Copy and paste the device tree overlay file below into a new file (you could name it cpu-overclock.dts):

   // Pulled from: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
   /dts-v1/;
   /plugin/;
   
           &cluster0_opp {
                   opp00 {
                           opp-hz = /bits/ 64 <408000000>;
                           opp-microvolt = <800000>;
                           clock-latency-ns = <40000>;
                   };
                   opp01 {
                           opp-hz = /bits/ 64 <600000000>;
                           opp-microvolt = <825000>;
                   };
                   opp02 {
                           opp-hz = /bits/ 64 <816000000>;
                           opp-microvolt = <850000>;
                   };
                   opp03 {
                           opp-hz = /bits/ 64 <1008000000>;
                           opp-microvolt = <900000>;
                   };
                   opp04 {
                           opp-hz = /bits/ 64 <1200000000>;
                           opp-microvolt = <975000>;
                   };
                   opp05 {
                           opp-hz = /bits/ 64 <1416000000>;
                           opp-microvolt = <1100000>;
                   };
                   opp06 {
                           opp-hz = /bits/ 64 <1512000000>;
                           opp-microvolt = <1150000>;
                   };
                   opp07 {
                           opp-hz = /bits/ 64 <1608000000>;
                           opp-microvolt = <1200000>;
                   };
           };
           &cluster1_opp {
                   opp00 {
                           opp-hz = /bits/ 64 <408000000>;
                           opp-microvolt = <800000>;
                           clock-latency-ns = <40000>;
                   };
                   opp01 {
                           opp-hz = /bits/ 64 <600000000>;
                           opp-microvolt = <800000>;
                   };
                   opp02 {
                           opp-hz = /bits/ 64 <816000000>;
                           opp-microvolt = <825000>;
                   };
                   opp03 {
                           opp-hz = /bits/ 64 <1008000000>;
                           opp-microvolt = <850000>;
                   };
                   opp04 {
                           opp-hz = /bits/ 64 <1200000000>;
                           opp-microvolt = <900000>;
                   };
                   opp05 {
                           opp-hz = /bits/ 64 <1416000000>;
                           opp-microvolt = <975000>;
                   };
                   opp06 {
                           opp-hz = /bits/ 64 <1608000000>;
                           opp-microvolt = <1050000>;
                   };
                   opp07 {
                           opp-hz = /bits/ 64 <1800000000>;
                           opp-microvolt = <1150000>;
                   };
                   opp08 {
                           opp-hz = /bits/ 64 <2016000000>;
                           opp-microvolt = <1250000>;
                   };
                   opp09 {
                           opp-hz = /bits/ 64 <2088000000>;
                           opp-microvolt = <1250000>;
                   };
           };
   

2. Compile the device tree into a binary file. Note that you will need dtc installed.

   dtc -I dts -O dtb -@ cpu-overclock.dts -o cpu-overclock.dto
   

3. Copy or move the device tree from the current directory into the boot partition (in this case into the /boot/dtbs/overlay/ folder). If you haven’t yet created the /boot/dtbs/overlay/ folder, then create it with sudo mkdir /boot/dtbs/overlay/

   sudo cp cpu-overclock.dto /boot/dtbs/overlay/
   

4. Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a extlinux.conf file), then add the following line to the file /boot/extlinux/extlinux.conf:

   FDTOVERLAYS /dtbs/overlay/cpu-overclock.dtb
   

If you already have an FDTOVERLAYS line, then add a space at the end of the current line, then add this overlay file after that. See here for details on this process: Device Tree Overlays on Mainline

The resulting /boot/extlinux/extlinux.conf file might look like below after adding this dtb file:

LABEL Manjaro ARM
KERNEL /Image
FDT /dtbs/rockchip/rk3399-rockpro64.dtb
FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb
APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil

Getting WiFi working (new WiFi module)

Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name brcmfmac43455-sdio.AW-CM256SM.txt. You can copy this file to the new name (that the driver looks for) with the following commands:

cd /usr/lib/firmware/brcm/
sudo cp brcmfmac43455-sdio.AW-CM256SM.txt brcmfmac43455-sdio.txt

Then, reboot and WiFi should start working. Details for this method are here: https://forum.pine64.org/showthread.php?tid=16635&pid=117061#pid117061

However, on a 5GHz network with wireless-regdb installed and the regulatory domain set to ‘US’, the adapter is almost unusable. Speeds are usually 0 bits per second. Sometimes a few packets can get through every few seconds, but that is it. On a 2.4GHz network, this is not an issue. This “can” be resolved by setting the regulator domain to ‘GB’ or ‘CN’, but this isn’t a solution for you if you are in the USA, for instance. There are various other brcmfmac43455-sdio.txt files online that one can try. Some work better than others. Since these are text files where each line represents a property value, one can combine parts of these files to generate new firmware files for testing. One such combination yields decent results. This can be achieved by applying the patch below to the default brcmfmac43455-sdio.AW-CM256SM.txt file. With this firmware file, it is possible to get about 140Mbps up and down with this patch (with the regulatory domain set to ‘US’).

--- brcmfmac43455-sdio.AW-CM256SM.txt   2023-04-27 19:16:47.000000000 -0500
+++ brcmfmac43455-sdio.txt      2023-05-21 11:42:22.058517093 -0500
@@ -21,19 +21,18 @@
ltecxpadnum=0x0504
macaddr=00:90:4c:c5:12:38
manfid=0x2d0
-maxp2ga0=64
-maxp5ga0=80,82,76,77
-mcsbw202gpo=0x99355533
-mcsbw205ghpo=0x99855000
-mcsbw205glpo=0x99755000
-mcsbw205gmpo=0x9df55000
-mcsbw405ghpo=0xd9755000
-mcsbw405glpo=0xb8555000
-mcsbw405gmpo=0xed955000
-mcsbw805ghpo=0xd9555000
-mcsbw805glpo=0xc8555000
-mcsbw805gmpo=0xe9555000
-muxenab=0x10
+maxp2ga0=70
+maxp5ga0=73,74,73,73
+mcsbw202gpo=0x99333322
+mcsbw205ghpo=0x8a875444
+mcsbw205glpo=0x8a875444
+mcsbw205gmpo=0x8a875444
+mcsbw405ghpo=0xda844333
+mcsbw405glpo=0xda844333
+mcsbw405gmpo=0xdb844333
+mcsbw805ghpo=0xda555444
+mcsbw805glpo=0xdb555444
+mcsbw805gmpo=0xda555444
nocrc=1
ofdmlrbw202gpo=0x0033
pa2ga0=-112,6296,-662

To use this patch, copy it off into a file and use the patch command. However, it might be easier to apply the patch by hand. To do this, open the file /usr/lib/firmware/brcm/brcmfmac43455-sdio.txt (after completing the copy step above), delete the line with maxp2ga0=64 through the line with muxenab=0x10.

Then add the following in its place:

maxp2ga0=70
maxp5ga0=73,74,73,73
mcsbw202gpo=0x99333322
mcsbw205ghpo=0x8a875444
mcsbw205glpo=0x8a875444
mcsbw205gmpo=0x8a875444
mcsbw405ghpo=0xda844333
mcsbw405glpo=0xda844333
mcsbw405gmpo=0xdb844333
mcsbw805ghpo=0xda555444
mcsbw805glpo=0xdb555444
mcsbw805gmpo=0xda555444

Reboot and the Wi-Fi (at least for 5GHz networks) should work well. It is not exactly clear what these fields do, so the impact this has on the Wi-Fi module or your ability to operate it legally in your country is not certain. It seems that this file is passed directly to the hardware, where it is interpreted by the Wi-Fi module itself. However, given that this file is simply a combination of other existing files for similar hardware, it might be fine to use. The patch above only pulls in lines from the following firmware file: https://github.com/reMarkable/brcmfmac-firmware/blob/master/brcmfmac43455-sdio.txt. This code comes with the following license - which is not replicated here because it will fill this wiki with text - see the link here for the license: https://github.com/reMarkable/brcmfmac-firmware/blob/master/LICENCE.

Stabilizing the system (underclocking the RAM)

⚠️ WARNING

As pointed out by CrystalGamma, “normal accesses should simply work, though with higher access latency than necessary (since it uses the same number of cycles as would be necessary for a higher frequency), but I’d be slightly worried about refresh, since it also issues refresh based on number of cycles as would be used for a higher frequency, instead of actual time elapsed”. In other words, “the risk is refreshes coming to late, though it’s probably within tolerance with this little of a frequency diff”.

To put it simply, the suggested changes to DRAM configuration may actually cause system instability or data corruption under certain circumstances.

By default, it seems that the some RockPro64 devices are not stable. This seems to manifest as gcc segfaulting randomly. Usually, this can be “fixed” by starting the build again and hoping gcc doesn’t crash. If the build finishes or crashes at a different point, this is a good indicator that the system is not stable. The issue seems to be that the RAM is running a little too fast and some bits are getting randomly flipped. Other frequencies are possible, but the highest officially supported frequency below 800MHz is 666MHz, which is still a big step down from the default frequency of 800MHz provided by ManjaroARM. It is also possible to set arbitrary frequencies in u-boot. Frequencies that have been tested with this method are 702MHz and 752MHz. It seems that there is only a slight performance decrease at 752MHz compared to 800MHz.

By default, this PKGBUILD uses the default RAM speed of 800MHz. Uncomment the line that begins with “patch” to enable the 752MHz patch. Details are in the comments at the top of the PKGBUILD. If you would like to try out other frequencies, follow the instructions in the comments at the top of the PKGBUILD.

After building and installing, the install hook will prompt you on if you want to install the new build of U-Boot to EMMC. If you want to, press Y, otherwise, hit N and then copy and paste the printed dd commands and modify them to write to the correct device (change the /dev/mmcblk part).

After installing U-Boot and rebooting, U-Boot should print out that it set the RAM to 400MHz (initially). Then a few lines down, the RAM should be set to 752MHz.

Hardware compatibility

Please contribute to the hardware compatibility page, which lists hardware which has been tested with the rockpro64, whether successful or not.

Hardware compatibility

PCIe devices

NVMe SSD drives

USB hardware

USB C alternate mode DP

Note that only USB C alternate mode Display Port will pass video. Any HDMI, DVI or VGA port must be converted internally by the device from Display Port - or the device won’t work for video.

eMMC / SD drives

Other hardware

Limitations

Older firmware overwrites actively used memory

Some people get system freeze when:

• use SATA disk with ROCKPro64 PCIe card (maybe on newer PCIe card ASM1062 vs ASM1061)
• or do read or write 4GB to the flash (not using PCIe)

If you connect the serial console you will see a Linux kernel oops: (a)synchronous external abort.

Both issues are in fact the same software BUG. There is no hardware problem. Currently, most OS do use uboot with a rockpro blob FW which use memory that Linux kernel is not aware of.

People are currently fixing this BUG, but it may take some time. In the mean time, you can fix it manually.

The latest u-boot can boot the rockpro64 without any blobs from rockchip.

Install first arm-none-eabi-gcc and aarch64-linux-gnu-gcc compiler, then run the following commands:

Prerequisite packages (Debian/Ubuntu): device-tree-compiler python gcc-arm-non-eabi flex bison gcc-aarch64-linux-gnu gcc make

git clone https://github.com/ARM-software/arm-trusted-firmware.git atf
make -C atf CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
git clone https://gitlab.denx.de/u-boot/u-boot.git u-boot
cd u-boot/
git checkout v2020.01-rc5
make rockpro64-rk3399_defconfig
BL31=../atf/build/rk3399/release/bl31/bl31.elf make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu-

Which gives you idbloader.img and u-boot.itb. Copy them to the rockpro64, and run the following: (Or put your SD card into your PC)

sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64
sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
sync

PCIe Controller Hardware Error Handling Bug

There is an issue with the rk3399 pcie controller that is currently unmitigated:

• LKML Original Thread
• LKML Additional Information

The rk3399 pcie controller throws either a synchronous abort or a SError when a pcie device sends an unknown message.

The error type is determined by which cpu cluster handles the message.

Virtualization

The PCIe controller on the rk3399 is not behind an IOMMU. This means it is not possible to safely pass through PCIe devices to a virtual machine.

3D printable ITX mounting brackets

Allows mounting a ROCKPro64-A or Quartz64-A board inside a regular PC case that conforms to the ITX standard, using 3D printed brackets:

• AMF/STL/STEP files plus the original FreeCAD file used to create the models https://wiki.pine64.org/wiki/File:RP64-A_Q64-A_to_ITX_mounting_brackets.zip
• Make sure to flip the two brackets by 180 degrees on one of the horizontal axes (X/Y) in your slicer of choice before printing to avoid unnecessary supports
• To allow enough clearance between the board and the bracket you either need to print four copies of the washer model or add nut(s) between the board and the bracket
• If using nuts for the clearance between the board and the brackets, make sure it creates at least 3.2mm of spacing in between
• Depending on the accuracy and calibration of a 3D printer, slight deviation can occur and you likely need to manually widen some of the holes to allow screws to fit

Cases

Acrylic Open Enclosure

• Acrylic enclosure

NAS case

Please follow this this link for detailed instructions on how to assemble the ROCKPro64 NAS Case.

The NAS Case instructions also contains detailed information about:

• what the NAS Case ships with
• What additional things you need to purchase for your NAS Case
• What optional things you can consider purchasing for your NAS build
• What OS Image we recommend you use for your NAS build
• IO accessibility after installing the ROCKPro64 into the NAS Case
• NAS Case Exploded View
• NAS Case Drawing

Powering From An ATX Supply

Powering the ROCKPro64 single-board computer from an ATX power supply allows the board to be powered with more than just two disks, and is a reliable and safe way to power it from your household mains.

Shopping List

Components

• An ATX breakout board. Get one with fuses. For extra safety, replace the fuses with your own trusted ones once you get it.
• Some 24 AWG or thicker copper wire, 0.5m of length at most, go thicker if you want to use longer wire. Also go thicker if you’re using copper-coated aluminium.
• A 2.1mm ID/5.5mm OD barrel jack connector

Tools

• A soldering iron, e.g. the Pinecil, with some solder
• Some wirestrippers suitable for the thickness of wire you chose

Assembly

• Slide the stress relief over both the wires you will use
• Solder the positive side of the wire to the centre contact of the barrel connector
• Solder the negative side of the wire to the outside contact of the barrel connector
• Fasten the stress relief/barrel connector housing
• Connect the positive side to your ATX breakout board’s 12V terminal
• Connect the negative side to your ATX breakout board’s GND terminal
• Plug in the ATX power supply into the ATX breakout board, with the PSU turned ‘off’ at the flip switch in the back
• Set the power switch on the ATX breakout board to the on position
• Stand out of reach of any glass fuse shrapnel (e.g. put the breakout board in a housing), plug in the ATX power supply and flip its switch on
• If it didn’t blow up, you did it right, and can now hopefully plug the ROCKPro64 into the ATX breakout board using the cable you’ve made

Further Steps

If you got one of the green breakout boards with the glass fuses and the red LED, then User:CounterPillow made a 3d printable housing for it. It screws together with heat-set brass inserts. Download .zip containing STEPs and STLs as well as the FreeCAD project file

Serial buffer circuit

Connecting to the ROCKPro64 single-board computer serial interface can sometimes be tricky, as the lack of buffering can cause the Uboot-SPL to stop functioning due to transient voltage spikes during startup. This simple circuit allows a user to hot-plug their serial connection at any time, or can be left attached full time.

Shopping List

Components

You may have some or all of these in your junk/parts drawer. They’re all common value, and easily recovered from scrap circuit-boards.

• 3"x4" perf board, will be used for construction of the circuit
• misc breakout board wires, or any random copper wire that works, I used ribbon cable from an old floppy harness.
• misc jumper wire with headers, a three-pin header, and a one-pin header, since you’ll be connecting to the RP64 mainboard pin headers in different places
• Transistors, 1 (one) NPN-type, 2n2222 or equivalent; and 1 (one) PNP-type, 2n2907 or equivalent
• Resistors, 3 (three) 4.7kΩ 1/4-watt; and 2 (two) 10kΩ 1/4-watt
• Serial interface jack, 3-pin TRS audio jack works well, as does RJ45 or DB9. You only need, and use, 3 pins though.
• Double-sided sticky tape, at least 1"x1", to mount the perf board to your case.

Tools

• A soldering iron, e.g. the Pinecil
• solder, fine gauge, anything suitable for electronics
• Wire strippers, suitable for the thickness of wire you chose
• Diagonal cutters, to trim excess leads from components and wires

Assembly

• Start by creating “vias” using a stretch of bare wire for both ground and +3.3v along the long edges of the perf board; ground on one side, +3.3v on the opposite
• At one end of the perf board, start laying out the parts for the NPN transistor portion of the circuit, then solder down.
• At the opposite end, lay out the PNP transistor portion, and solder down.
• Connect up the serial interface jack, using enough wire to reach your desired mounting point on your case, from the mounting place for this board
• Solder the jumper wires to the perf board for the serial jack
• Solder the header jumpers to the perf board, making sure they’re long enough to reach the RP64 headers with a bit of slack.
• Let cool, affix the double-sided tape, and mount to your case.

Install

• Mount your serial port
  • Serial RX <-> DCE RX (in)
  • Serial TX <-> DCE TX (out)
• attach the header jumpers to their respectively labeled points on the various headers
  • RP64 Ground <-> pi2bus-6
  • RP64 RX (in) <-> pi2bus-8
  • RP64 TX (out) <-> pi2bus-10
  • RP64 3.3v <-> pi2bus-1

Circuit

Further information

Datasheets

Rockchip RK3399 SoC information:

• Rockchip RK3399 SoC Brief
• Rockchip RK3399 Datasheet V2.1
• Rockchip RK3399 Technical Reference Manual part 1
• Rockchip RK808 Datasheet V0.8

LPDDR4 (200 Balls) SDRAM:

• Micron LPDDR4 Mobile LPDDR4 Datasheet

eMMC information:

• PINE64 eMMC module schematic
• PINE64 USB adapter for eMMC module V2 schematic
• PINE64 USB adapter for eMMC module PCB in JPEG
• 16GB Foresee eMMC Datasheet
• 32GB/64GB/128GB SanDisk eMMC Datasheet

SPI NOR Flash information:

• WinBond 128Mb SPI Flash Datasheet
• GigaDevice 128Mb SPI Flash Datasheet

Heatsink related info:

• ROCKPro64 Passive Heatsink Dimension Drawing
• Heatsink Thermal Pad Specification

Wireless related info:

• AMPAK AP6256 11AC WiFi + Bluetooth5.0 Datasheet (v. 1.3) (v. 1.7)

Ethernet related info:

• Realtek RTL8211F 10/100/1000M Ethernet Transceiver Datasheet

Peripheral related info:

• asmedia ASM1061 PCIe SATA 2.0 Datasheet

Remote control button mapping:

• Official Remote Control for the PINE64 Button Mapping

Audio Codec (ES8316) (under board):

• Everest ES8316 Audio Codec

PWM controlled fan, SPDIF, and RTC Battery Backup headers:

• JST-PH connector

Other resources

• ROCKPro64 Forum
• PINE64 shop
• Rockchip Linux GitHub Repo
• Rockchip Open Source Wiki
• ExplainingComputers have a video review of the RockPro64 here, including linux first boot.

Useful articles and blog posts

If you want to dive in to the ecosystem, here’s a short list of various articles and blog posts that can help you set up your soft- or hardware development environment.

• Blobless boot with RockPro64 by Andrius Štikonas
• EBBR on RockPro64 by Marcin Juszkiewicz

Schematics and certifications

• Board dimensions: 133 mm x 80 mm x 19 mm
• Power input: 12 V, 3 A or 5 A, using 5.5 mm (OD) / 2.1 mm (ID) type M barrel DC connector
• ROCKPro64 Schematic v2.1 (Second Batch Production Release)
  • ROCKPro64 v2.1 Board Top Outline in AutoCad DXF format
  • ROCKPro64 v2.1 Board Bottom Outline in AutoCad DXF format
  • ROCKPro64 v2.1 Board Top Outline in PDF format
  • ROCKPro64 v2.1 Board Bottom Outline in PDF format
• ROCKPro64 Schematic v2.0 (Pilot Production Release)
  • ROCKPro64 v2.0 Board Top Silkscreen in PDF format (contains component labels)
  • Engineering Change Notice for v2.0 to turn on 3.3V power on PCIe
• ROCKPro64 AP6359SA Wifi/BT Schematic
• ROCKPro64 Pi-2 Pin assignment and definition
• ROCKPro64 3D model

Certifications:

• Disclaimer: Please note that PINE64 SBC is not a “final” product and in general certification is not necessary. However, PINE64 still submit the SBC for FCC, CE, and ROHS certification and obtain the certificates to proof that SBC board is capable on passing the testing. Please note a final commercial product needs to performs its owns testing and obtains its owns certificates.
• ROCKPro64 FCC Certificate
• ROCKPro64 CE Certificate
• ROCKPro64 RoHS Report