I purchased a PINE64 ROCKPro64 with 4GB of RAM.


Minicom configuration file (e.g. ~/.minirc.dfl):

pu baudrate         1500000
pu bits             8
pu parity           N
pu stopbits         1
pu rtscts           No 

Kermit doesn’t seem to support a baud rate of 15M.

Persistent storage

The ROCKPro64 includes 128Mb of SPI flash, a eMMC port, a SD card slot and a PCIe slot that can be used for an NVMe drive. I’ve populated the eMMC port with a 16GB module, the SD card slot with a 8GB card and the PCIe slot with a Samsung 970 EVO NVMe M.2 drive using a PCIe to M.2 adapter.

[email protected]:~$ lsblk --output NAME,SIZE
NAME           SIZE
mtdblock0        4M
mtdblock1       32K
mtdblock2      256K
mmcblk1       14.5G
mmcblk0        7.4G
nvme0n1      931.5G

Mainline support

As of 9/26/2019 the following is supported in mainline of the respective project:

Rockchip maintains a fork of U-Boot appears to be well maintained (see rockchip-linux/u-boot).

Another Chinese company named Firefly also uses the RK3399 in a product and maintain a fork of the kernel on Gitlab that was last updated March 14, 2018.

Complete images

Arch Linux ARM supports the Rock64 but not the RockPro64. The former includes a Rockchip 3328, while the later is based on the Rockchip 3399. The 3399 includes two additional higher performance A72 cores. The same processor is used in the Asus Chromebook Flip C101PA and Samsung Chromebook Plus.

Various images can be found on the ROCKPro64 Software Release page on the PINE64 wiki.

I was able to boot using a Debian image generated by a Github user that may be affiliated with PINE64 (see ayufan-rock64/linux-build). The default user and password for that image are both rock64.

In the announcement for Fedora 31 they stated that support for the RockPro64 and Rock64 was improved, but did not specify how. They linked to alt.fedoraproject.org/alt, which contains aarch64 images, but no documentation. Confusingly, they also maintain arm.fedoraproject.org, which does include documentation, however the arm-image-installer does not list any Rockchip-based PINE64 boards.


The boot process is best documented on the Rockchip wiki. It states that the idbloader consists of their a DDR initialization binary and in-house boot loader named miniloader or U-Boot TPL/SPL.

The boot ROM will attempt to load and run boot firmware from the SD card, eMMC or SPI flash (see boot jumper configuration.


Rockchip appears to be actively developing firmware and related tools in their rkbin repository on Github.

idbloader is described in a translation of the README as “by ddrbin, a level loader (miniloader or U-Boot SPL) merged directly in IDB format for burning to the binary of the IDB area.” IDB stands for identity block.

Rockchip build scripts and image layout

The Rockchip build repository contains a number of bash scripts to build U-Boot, the kernel, a rootfs and a single image. For the RK3399 the mk-uboot.sh script documents the process fairly poorly since it also calls binary tools provided in the build repository (see build/mk-image.sh). Those scripts have been modified by ayufan (see linux-build).

The script to build U-Boot issues a number of commands. The first command calls loaderimage, a Rockchip binary, with u-boot-dtb.bin, uboot.img and 0x200000. The former two arguments can be built using Buildroot. The help indicates that the DTB binary is an input file, the uboot.img is an output file and 0x200000 is a load_addr. Using build artifacts from Buildroot and calling the command increases uboot.img from 913K to 4M. The compiled device tree ends up at 0x800, but only accounts for 876K. 0x200000 in the output binary starts with the string “LOADER”. The original uboot.img started with 0xd00dfeed, which is located in the output binary at 0x1d8580, 0x2d8580, and 0x3d8580. LOADER is found at 0x0, 0x100000, 0x200000, and 0x300000.

The scripts generate an image with the following layout:

Name Filesystem Start (hex) End Size
idbloader 64 0x40 8063 8 kB
Reserved 1 8064 8191 128 bytes
Reserved 2 8192 16383 8 KiB
U-Boot 16384 0x4000 24575 8 KiB
ATF 24576 0x6000 32767 8 KiB
boot.img FAT 32768 0x8000 262143 229376 bytes
Root FS EXT4 262144 0x40000 100%

Those partitions are defined using GPT. The partition containing boot.img is marked as bootable. The binary contains the Linux kernel (e.g. zImage) and initial ramdisk.

Note that ayufan’s pre-built images as of 0.7.11 do not match how the boot ROM selects a device to boot. With valid images on the eMMC and SDcard (without jumping SW4) the boot ROM will boot off the eMMC, but ayufan’s U-Boot will mount the rootfs off of the SDcard. It is easy to get around this by modifying the U-Boot environment or removing the SDcard and rebooting.


Interestingly, Rockchip seems to support the RK3399 in coreboot (see coreboot source), as well as Google for their Chromebooks. It includes a Python 2 script named make_idb.py to generate the idblock bootloader. It seems to be copied fairly literally from rkdeveloptool.

The IDB region is prefixed by a 4 byte cookie of RK30, RK31, RK32, RK33 or RK11 depending on the processor. The cookie is followed by data the script reads a file that is at most 4 MiB.

The IDB block starts with 55 AA F0 0F, which is meaningless when decoded as ASCII or Unicode. Oddly, in rkdeveloptool it is written as 0F F0 AA 55. Good ol’ endianness…

typedef struct {
    DWORD   dwTag; 
    BYTE    reserved[4];
    UINT    uiRc4Flag;
    USHORT  usBootCode1Offset;
    USHORT  usBootCode2Offset;
    BYTE    reserved1[490];
    USHORT  usBootDataSize;
    USHORT  usBootCodeSize;
    USHORT  usCrc;

Interestingly, 0xAA55 is defined as MSDOS_MBR_SIGNATURE in rkdeveloptool and is apparently the MBR “boot signature”.

Broadcom NetXtreme II

I purchased a NetXtreme II 4 port Ethernet PCIe card to allow the ROCKPro64 to function as a switch. When I booted using ayufan’s Debian based image the PCI the system failed to boot.




Data sheets