I purchased a PINE64 ROCKPro64 with 4GB of RAM.

Serial

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.

rock64@rockpro64:~$ 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.

alt.fedoraproject.org/alt hosts aarch64/armv8 images, while arm.fedoraproject.org hosts armv7 images. arm-image-installer does not support any Rockchip-based PINE64 boards, but does list them in a board directory. Confusingly, it also seems to require uboot-images-armv7 or uboot-images-armv8, but those packages are not listed as dependencies. The U-Boot images packages appear to be built from the uboot-tools package as defined by the corresponding spec file. The arm-image-installer also has no error handling and numerous lint warnings.

Booting

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 SPI flash, eMMC, and then a SD card. The RockPro64 includes a header labeled SW4, which when jumped will boot the SD card (see boot jumper configuration. It does this by enabling or disabling the clock to the eMMC.

Firmware

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.

coreboot

Interestingly, Rockchip seems to support the RK3399 in coreboot (see /src/soc/rockchip/rk3399/Kconfig), 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;
} RK28_IDB_SEC0, *PRK28_IDB_SEC0;

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.

Buildroot

I built the mainline rockpro64_defconfig and booted of the output sdcard.img. At first the boot stopped after MMC messages that included a GPT warning. Expanding the root filesystem caused the warning to go away, but the boot still did not progress. I noticed then that MMC1 was regonized, but the default boot paramter specified the root filesystem would be on MMC0 so I modified extlinux.conf, which booted to a prompt.

Next I noticed that the Ethernet interface was not created and only lo was listed under /sys/class/net. The device tree includes an alias of ethernet0 for node ethernet@fe300000.

The transciever is a Realtek RTL8211F, but that doesn’t seem to appear in the device tree. The Ethernet controller in the RK3399 is a Gigabit Media Access Controller (GMAC), which is mapped to 0xfe300000.

I thought that it could be related to udev and tried enabling mdev, which is part of BusyBox, but that didn’t change anything. I ran into a bunch of errors trying to build systemd, since that required a toolchain change. Unfortuantely, eudev also required a toolchain change.

The Ayufan boot log includes ethernet@fe300000.

Resources

Rockchip

PINE64

Data sheets

Other