This is a guide for booting RockPro64 computer (https://www.pine64.org/rockpro64/) without using any proprietary blobs. RockPro64 is based on Rockchip’s rk3399 SoC, so if you have some other rk3399 board, you might still find this guide useful.

I’m using Gentoo GNU/Linux in this guide but steps should be quite similar on other distributions.

Overview of boot sequence

Before we proceed with detailed instructions, let us briefly describe how rk3399 boots.

rk3399 chip has two types of internal memory that is inside the chip itself:

32 KiB BootROM which is read only.

200 KiB SRAM (Static RAM).

When rk3399 is powered on, CPU loads BootROM code into SRAM (at this stage main system RAM is not yet initialized). BootROM is a fairly small program baked into hardware that is responsible for loading initial bootloader. It supports booting from SPI, eMMC, SD and supports downloading next bootloader over USB OTG interface. Since it is quite small and baked onto the chip itself, for the purposes of this guide we will consider it as hardware, not software.

So, BootROM loads U-Boot TPL into SRAM. Since SRAM is quite small, we cannot load the full U-Boot bootloader into it, so only a small part called TPL is loaded. Its main job is to initialize main system RAM (RockPro64 has up to 4 GiB of LPDDR4 based RAM).

Then U-Boot TPL hands control back to BootROM which then loads a slightly bigger part of U-Boot called U-Boot SPL. At this stage SPL loads ATF (Arm Trusted Firmware: https://github.com/ARM-software/arm-trusted-firmware) and U-Boot Proper into memory. Then ATF starts and finally runs U-Boot.

U-Boot can boot payloads from a variety of sources including, eMMC, SD, USB as well as do network boot. Also, U-Boot has support for UEFI booting specification, so it can boot EFI binaries located on ESP partitions. Even though U-Boot can load Linux kernel directly, I personally find it more convenient to first load Grub2 and then load Linux kernel.

Compiling required components

Toolchain

First of all you need to install required toolchain. If you are following this guide on RockPro64 itself or other ARM64 system, you can just use gcc . If you are not on ARM64, you can use crossdev (https://wiki.gentoo.org/wiki/Cross_build_environment) to install ARM64 cross-compiler (other distributions often ship cross compiler binaries too, e.g. on Debian GNU/Linux you can use https://packages.debian.org/sid/gcc-aarch64-linux-gnu).

In addition to ARM64 compiler, you also need ARM32 cross-compiler:

crossdev --target arm-none-eabi -s4

At the moment on my system I have cross-arm-none-eabi/gcc-8.3.0-r1 with USE="cxx graphite jit multilib pgo" .

Arm Trusted Firmware

As mentioned before, source code for ATF can be downloaded from https://github.com/ARM-software/arm-trusted-firmware.

Building ATF is quite easy but you might want to first remove some blobs (alternatively, removal of blobs is available in my git fork https://git.stikonas.eu/andrius/arm-trusted-firmware)

find . -name '*.bin' -exec rm -rf {} \; make PLAT=rk3399

This should produce build/rk3399/release/bl31/bl31.elf . Now, we can make the path to bl31.elf binary known to U-Boot build process

export BL31=path/to/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf

U-Boot

U-Boot only gained support for training LPDDR4 memory in v2019.10 which is not released yet , so for now we will get U-Boot from git:

git clone https://gitlab.denx.de/u-boot/u-boot.git/

Let’s use default configuration. I also tried tweaking configuration a bit to enable HDMI display inside U-Boot but so far I was not successful.

cd u-boot make rockpro64-rk3399_defconfig make

This should produce idbloader.img which contains U-Boot TPL and SPL and u-boot.itb which contains U-Boot Proper. We can install those with the following script

#!/bin/sh -e cd u-boot sudo dd if=idbloader.img of=/dev/mmcblk1 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk1 seek=16384

Optionally you might want to create two 4 MiB partitions that start at sectors 64 and 16384 and use those with dd without seek . Before running commands above, make sure that your eMMC or SD card is represented by /dev/mmcblk1 block device. I have only tested booting from eMMC and did not try SD card myself.

At this stage you can use any of the boot methods supported by U-Boot. In this guide I’ll be using UEFI boot to load GNU GRUB.

GNU GRUB

Let’s get GRUB2 from package manager:

emerge sys-boot/grub

On my eMMC card I have created EFI System Partition (which should be FAT32 formatted). Then add moutpoint /boot/efi to /etc/fstab . GRUB should then be installed to ESP:

#!/bin/sh # mount /boot/efi # you might needs this if /boot/efi is not mounted grub-install /dev/mmcblk1 --removable grub-mkconfig -o /boot/grub/grub.cfg

The script above should have created /boot/efi/EFI/BOOT/BOOTAA64.EFI

Compiling kernel

In this guide I’ll use mainline kernel with a few patches. Support for RockPro64 is not yet complete in the mainline kernel, so it is essential to use the latest kernel. At the time of writing this is 5.3.

Configuring kernel is out of scope for this blog post, there are other guides online. You can use my configuration from https://stikonas.eu/files/gentoo-sources/. Copy config file into your kernel source directory and rename it to .config . However, for UEFI boot as described in this blog, you need to enable CONFIG_EFI_STUB=y in your kernel config.

Let’s download kernel sources. First of al, we’ll apply a few patches. Download the patches from https://stikonas.eu/files/gentoo-sources/ and put them to /etc/portage/patches/gentoo-sources/ . Note that the last patch 0003-arm64-dts-rockchip-Add-PWM-fan-for-RockPro64.patch will be included in Linux 5.4. The other two patches fix booting from eMMC and terrible IPv6 performance.

emerge gentoo-sources

To achieve fully blobless boot we can deblob the kernel:

cd /usr/src/linux # assuming that is where you unpacked your kernel wget https://linux-libre.fsfla.org/pub/linux-libre/releases/5.3-gnu/deblob-5.3 wget https://linux-libre.fsfla.org/pub/linux-libre/releases/5.3-gnu/deblob-check wget https://linux-libre.fsfla.org/pub/linux-libre/releases/5.3-gnu/deblob-main chmod +x deblob-5.3 deblob-Pcheck PYTHON=python2.7 ./deblob-5.3

To compile the kernel, simply run

make -j$(nproc)

Then kernel can be installed with

make zinstall make modules_install make dtbs_install

The last command will install device tree files to /boot/dtbs/kernel_version/rockchip . In particular this directory should contain rk3399-rockpro64.dtb . Copy this file to ESP partition, so that it is available to U-Boot when it is loading Grub.

Copying this dtb file is in principle optional. If it is missing, then kernel will simply use dtb from U-Boot which is mostly good enough, but kernel usually has slightly more up to date device tree file. At the moment I was not able to get HDMI working if I skip this step. This is possibly related to my failure of getting screen to work in U-Boot itself

kernel_version=5.3.0-gentoo-gnu mkdir -p /boot/efi/dtb/rockchip cp /boot/dtbs/${kernel_version}/rockchip/rk3399-rockpro64.dtb /boot/efi/dtb/rockchip

Don’t forget to generate initramfs, for example you can use dracut

dracut --xz -H /boot/initramfs-${kernel_version}.img $kernel_version grub-mkconfig -o /boot/grub/grub.cfg

At this stage your can reboot and if everything goes fine, you’ll hopefully boot into fully free system.

If you grab latest mesa package with panfrost driver you can even use accelerated KDE Plasma desktop or play some 3D games.

Configuring fan with fancontrol

The last patch we applied to the kernel exposes fan interface to the kernel. At the moment this makes fan spin at full speed. You can control it with e.g. fancontrol from sys-apps/lm-sensors package. I use the following /etc/fancontrol configuration file:

INTERVAL=10 DEVPATH=hwmon0=devices/platform/pwm-fan DEVNAME=hwmon0=pwmfan FCTEMPS=hwmon0/device/pwm1=../thermal/thermal_zone0/temp MINTEMP=hwmon0/device/pwm1=35 MAXTEMP=hwmon0/device/pwm1=60 MINSTART=hwmon0/device/pwm1=100 MINSTOP=hwmon0/device/pwm1=70

fancontrol can be started with systemctl enable fancontrol; systemctl start fancontrol

Caveats

Unfortunately, on my system booting is not reliable yet. I’m not yet sure why. Sometimes U-Boot Proper fails to initialize eMMC card (typing boot until it succeeds usually fixes the problem), occasionally boot fails in other U-Boot stages.

Update: This seems to be specific to some eMMC cards. Maybe related to command queue support (see kernel patch that I applied to my kernel that was also disabling command queueing on eMMC cards).

Booting from SPI

U-Bootalso supports booting from on-board SPI flash. Version 2020.01 can boot U-Boot TPL and U-Boot SPL stages from SPI flash. In order to also boot U-Boot Proper, you need to patch boot order and use adjust U-Boot config (see provided defconfig in the following link)

https://github.com/u-boot/u-boot/commit/7db83e4dcaf2c987f6545ecdbe0eba35a05b9273

You can flash these stages with the following script:

#!/bin/sh -e cd u-boot image_name="spi_idbloader.img" combined_name="spi_combined.img" tools/mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin "${image_name}" padsize=$((0x60000 - 1)) image_size=$(wc -c < "${image_name}") [ $image_size -le $padsize ] || exit 1 dd if=/dev/zero of=${image_name} conv=notrunc bs=1 count=1 seek=${padsize} cat ${image_name} u-boot.itb > "${combined_name}" dd if="${combined_name}" of=/dev/mtdblock0

Binaries

If you prefer to run binaries but do not want to compile them yourself, you can get them from https://stikonas.eu/files/gentoo-sources/u-boot/