RK3399 Boot Modes and Partition Design in Embedded Linux Drivers

1. Analysis of RK3399 Boot Modes

The boot process of RK3399 is divided into hardware initialization and software boot stages, with the core logic consisting of BootROM, SPL/U-Boot, and the kernel.

1. BootROM Stage (Hardware Initialization)

Firmware: The unmodifiable code stored in the chip’s internal ROM, responsible for:

Initializing the CPU core clock and DDR memory controller
Scanning storage media (eMMC/SD/UART) to find the boot program
Loading SPL (Secondary Program Loader) into SRAM

Why is it firmware? Similar to the BIOS on a computer motherboard, it ensures that even if external storage is damaged, the system can still be restored via USB/UART.

2. SPL/U-Boot Stage (Boot Loading)

SPL (Primary Loader):

Closed-source solution: ddr.bin + Miniloader (provided by the manufacturer)
Open-source solution: TPL + SPL (community-developed, more flexible)

Function: Initialize DDR timing and load U-Boot into memory
Two implementation methods:

Core Tasks of U-Boot:

Load the kernel image (vmlinuz/Image)
Pass the device tree (dtb) and boot parameters (cmdline)
Support FIT packaging: Integrate the kernel, dtb, and ramdisk into a single image (*.itb), enhancing security verification8

3. Kernel Boot Stage

Process: Unpack image → Initialize scheduler/interrupts → Mount rootfs → Start systemd/init
Key Driver Loading:

Display driver (DRM/VOP): Initialize the display controller and load EDID information7
Storage driver: Identify eMMC/SATA/NVMe devices
Power management: Configure DVFS dynamic frequency scaling

2. Partition Design and Function

The partition structure of RK3399 directly affects the firmware storage layout and boot reliability. Typical partitions are as follows:

Partition Name	Content	Function Description	Recommended Size
idbloader	Initial code loaded by BootROM	Contains the boot header for SPL and U-Boot	2MB
uboot	Main program of U-Boot	Provides an interactive command line and kernel loading	4MB
trust	Security monitoring firmware	Implements Secure Boot and cryptographic verification	4MB
kernel	Linux kernel image	Contains the compressed vmlinuz and device tree	16-64MB
rootfs	Root file system	Contains system libraries, applications, and configuration files	Expandable based on needs

Why is the trust partition needed?

This is a security design unique to the RK platform, similar to the TrustZone technology in mobile phones. It operates independently of the main system and is responsible for:

Verifying the digital signatures of U-Boot and the kernel
Managing encryption keys (e.g., disk encryption)
Preventing unauthorized firmware flashing

Advantages of FIT Packaging

Traditional methods require separate handling of kernel, dtb, and other files, while FIT (Flattened Image Tree) describes the image relationships using DTS syntax:

images {     kernel {         description = "Linux Kernel";         data = /incbin/("./zImage");         type = "kernel";         arch = "arm64";         os = "linux";         compression = "gzip";     };     fdt {         description = "Device Tree";         data = /incbin/("./rk3399.dtb");         type = "flat_dt";     }; };

Advantages:

Single file management for multiple images, reducing upgrade risks
Supports hash verification and signatures, enhancing security
Compatible with U-Boot’s flexible configuration

3. Key Points in Driver Development

1. Device Tree Configuration

Hardware Description: Defined in arch/arm64/boot/dts/rockchip/rk3399.dtsi:

&amp;vopb {     status = "okay";     assigned-clocks = &lt;&amp;cru DCLK_VOP0_DIV&gt;;     assigned-clock-parents = &lt;&amp;cru PLL_VPLL&gt;; };

Function: Informs the kernel that “the display controller uses the PLL_VPLL clock source,” avoiding hard-coded register addresses.

2. Driver Loading Order

The display driver must be initialized in order:

DRM Framework: Register drm_driver
Component Binding: VOP (Display Processor), HDMI/DP interfaces, EDID parsing
Mode Setting: Configure resolution and refresh rate via drm_mode_config_init

3. Debugging Techniques

U-Boot Command Line: Modify CONFIG_BOOTDELAY to extend the wait time, making it easier to interrupt the automatic startup

Kernel Logs: dmesg | grep -i "drm" to check the display driver initialization status
Device Tree Debugging: fdtdump /sys/firmware/devicetree/base to verify the actual loaded dtb

4. Plain Language: Why is the Design So Complex?

Security Layering: BootROM only performs the most basic initialization, with subsequent steps verifying each stage, similar to needing multiple card swipes to enter a building (BootROM→SPL→U-Boot→Kernel), preventing a single point of failure from causing a total collapse.
Hardware Compatibility: Different manufacturers’ memory chip timings vary, and SPL needs to dynamically adjust DDR parameters, similar to performing “compatibility training” for different brands of memory sticks.
Flexible Expansion: FIT packaging allows dynamic addition or removal of components, akin to categorizing clothes in a suitcase (kernel, drivers) for faster and safer access.
Error Isolation: The independent partition design ensures that if one partition is damaged (e.g., U-Boot crashes), recovery can still be performed via SD card, similar to a computer’s “system recovery partition.”

5. Practical Suggestions

Setting Up the Development Environment

bash

export PATH=/usr/gcc-linaro-7.3.1/bin:$PATH

Compiler Choice: gcc-linaro-7.3.1-2018.05 (officially validated version)
Environment Variable Configuration: Add the toolchain path to ~/.bashrc

Troubleshooting Common Issues

Stuck at U-Boot: Check if the bootcmd environment variable correctly points to the kernel address
Display Anomalies: Confirm that the VOP clock configuration matches the screen’s EDID
Missing Partitions: Use the gdisk tool to rebuild the GPT table