A verified build and boot baseline

Board chosen, now the boring but essential part: get a known-good build that boots, so that later "did my change break this" has an answer. There are two tracks here, QEMU-only and real board. Do the QEMU track first regardless, because it validates the toolchain and build before any hardware is involved.

Host and toolchain

On Fedora the cross toolchain and build deps are one dnf line, then a workspace:

sudo dnf install -y gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu \
    make flex bison bc openssl-devel elfutils-libelf-devel ncurses-devel \
    dwarves pahole dtc u-boot-tools qemu-system-aarch64

aarch64-linux-gnu-gcc --version     # confirm the cross compiler works
mkdir -p ~/rk3576/{kernel,uboot,firmware,images,rootfs}

Build from the Collabora tree

The Collabora kernel is where the RK3576 work lives. Clone it, get on the right branch, and confirm the device tree files exist (if they do not, you are on the wrong branch):

git clone https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux.git
cd linux
git checkout rockchip-devel
find arch/arm64/boot/dts/rockchip -name "*rk3576*" | sort

That should list rk3576.dtsi, rk3576-armsom-sige5.dts and rk3576-radxa-rock-4d.dts. Then build the Image, device trees and modules with the Rockchip multi-platform defconfig:

export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
export KBUILD_OUTPUT=~/rk3576/kernel/build-arm64

make O=$KBUILD_OUTPUT rockchip_linux_defconfig
make O=$KBUILD_OUTPUT -j$(nproc) Image dtbs modules 2>&1 | tee build.log

The artifacts to check for are arch/arm64/boot/Image and the two board .dtb files under arch/arm64/boot/dts/rockchip/.

What QEMU can and cannot do

This is the part to be honest about. QEMU has no -M rk3576 machine type and cannot emulate the SoC. What it is good for:

A generic ARM64 boot under -M virt proves the kernel reaches a shell and catches early-boot regressions. With a small busybox initramfs:

qemu-system-aarch64 -M virt -cpu cortex-a72 -m 4G -smp 4 -nographic \
    -kernel $KBUILD_OUTPUT/arch/arm64/boot/Image \
    -initrd ~/rk3576/rootfs/initramfs.cpio.gz \
    -append "console=ttyAMA0 earlycon rdinit=/init"

The thing to keep front of mind: a kernel that boots under -M virt is not the same as one that boots on RK3576 hardware. The virt machine has none of the RK3576 clocks, power domains, PHYs or peripherals, so driver failures that only happen on real silicon are invisible here. It validates the build, not the board.

The firmware stack

On real hardware the boot chain is BootROM, then DDR init (still a closed rkbin blob, and an open TODO), then U-Boot SPL, then BL31 from Trusted Firmware-A, then U-Boot proper, then the kernel. Worth noting OP-TEE (BL32) has no RK3576 support upstream yet, which is one of the bigger open tasks.

Verifying a real boot

Once a board arrives, connect UART at 1500000 baud (Rockchip runs the debug serial fast) and watch for the kernel naming the machine, then sanity-check what probed:

picocom -b 1500000 /dev/ttyUSB0
# look for: Machine model: ArmSoM Sige5

dmesg | grep -i "probe\|error\|fail\|defer"   # any unexpected deferrals?
ip link show eth0                              # stmmac ethernet
ls /dev/dri/                                   # mali GPU
cat /sys/kernel/debug/devices_deferred         # should match only known-TODO subsystems

Cross-reference that against the mainlined-subsystems table from last week. Everything listed as mainlined should probe here. Anything deferred or errored that is not a known TODO is worth chasing. A common one on RK3576 is a device waiting on PWM, which is the v5 patch still in review.

The development loop

With a baseline that boots, the actual work loop is short: change the source, rebuild only Image, dtbs and modules, copy them to the boot partition, then generate and lint a patch before sending:

make O=$KBUILD_OUTPUT -j$(nproc) Image dtbs modules
git format-patch HEAD~1 --subject-prefix="PATCH" -o ~/rk3576/patches/
./scripts/checkpatch.pl ~/rk3576/patches/*.patch

And then it loops right back to the very first post: b4 and neomutt to send it to linux-rockchip@lists.infradead.org, in-reply-to the cover letter, plain text, one logical change per patch. That is the whole point of getting the mail setup working first. The pieces connect.

That closes out this run of weekly entries: the s390 landscape, ARM64 on the mainframe, Rust, and the RK3576 from board choice to a booting baseline. Plenty still to do. Watch this space.

Reference: the Collabora kernel repo and the Flipper One open tasks.

← picking an rk3576 board all posts