RK3576 boot flow

this page describes the cold boot sequence of the rockchip rk3576 soc used in flipper one from the on chip boot rom through ddr initialization, spl, the fit packaged main bootloader (u boot + arm trusted firmware a), and finally the operating system it also documents the on flash layout that the boot rom and spl rely on the legacy rockchip boot option wiki https //opensource rock chips com/wiki boot option covers older socs (rk33xx and earlier) and uses obsolete terminology ( miniloader , idbloader ) that is not part of the current rk3576 stack boot sequence the rk3576 boot chain is built from several stages each stage has a narrow responsibility and prepares the system for the next one flowchart td a\[power on / reset] > b\[on chip boot rom] b >|enumerate boot sources\<br/>per saradc vin0 strapping| c{valid rkns at\<br/>byte offset 0x8000?} c no on any device > m\[maskrom mode\<br/>for usb upload] c yes > d\[run binaries from rkns image\<br/>boost bin → ddr bin → spl] d >|ddr trained,\<br/>spl running in dram| e\[fit image\<br/>default offset 0x800000] e > f\[bl31 / tf a] f > g\[u boot proper] g >|standard boot\<br/>extlinux conf / efi / pxe| h\[linux kernel + rootfs] stage 1 on chip boot rom the boot rom is mask programmed silicon that cannot be modified it begins executing as soon as power is applied to the rk3576 it is responsible for reading the voltage on the saradc vin0 boot strapping pin to determine the boot priority list typical orderings are emmc → sd → maskrom or ufs → sd → maskrom , depending on the board design walking the boot source list and, for each device, looking for a valid rkns image signature at byte offset 0x8000 entering maskrom mode if no bootable device is found it allows access to the boot storages via usb for details on using maskrom mode and available boot priority lists, see rockchip maskrom mode docid\ w759nknwjvtc3clzhvqxv stage 2 early bootloader (rkns image) the rkns (rockchip boot image) container includes a set of binaries that are loaded into on chip sram by the boot rom and executed sequentially, normally returning control to the boot rom after each stage until the spl locates the main bootloader image and jumps to it binaries included in the rkns image binary purpose boost bin patches parts of the boot rom code already loaded into sram and configures power mode parameters for ufs flash optional on boards that do not boot from ufs ddr bin initializes the ddr memory controller and runs ram training (timing calibration) after this stage, dram is usable spl u boot secondary program loader runs from dram, re discovers the boot device to load the main bootloader's fit image from on rk3576 the ddr bin produced by rockchip is a closed source binary blob — there is currently no open source replacement this is tracked in flipperone linux build scripts#56 https //github com/flipperdevices/flipperone linux build scripts/issues/56 stage 3 main bootloader (fit image) once spl is running in dram, it loads the main bootloader fit image from a fixed offset on the boot device the default byte offset is 0x800000 the exact offset is hard coded in the spl build configuration and can be changed at compile time the fit image is a flattened image tree container ( u boot itb ) that may include any combination of component role dtb device tree blob describing on board peripherals to u boot and (later) linux bl31 part of arm trusted firmware a it runs at el3 https //developer arm com/documentation/102412/0103/privilege and exception levels/exception levels and provides secure monitor functionality and el3 runtime services bl31 handles operations such as cpu power state transitions, psci services, suspend/resume support, and other platform specific secure monitor calls issued by software running in the non secure os bl32 optional trusted execution environment (op tee) used when the platform requires a secure os for trusted applications tracked for rk3576 in flipperone linux build scripts#57 https //github com/flipperdevices/flipperone linux build scripts/issues/57 u boot proper the main bootloader binary that runs after bl31 hands off control runs at el2 https //developer arm com/documentation/102412/0103/privilege and exception levels/exception levels the fit image also includes a configuration node, that determines which images where must be loaded and in what order in a normal boot bl31 runs first and takes care of further steps stage 4 u boot proper u boot is feature rich enough to load almost anything from almost anywhere, so the flow becomes board and image specific from this point on rockchip vendor u boot (based on a 2017 codebase) boots via hard coded commands used in rockchip's bsp / sdk images current mainline u boot uses standard boot, which enumerates the available storage devices, looks for "bootable" partitions on each, and for each partition considers a variety of boot methods such as extlinux conf , plain efi bootable binaries, pxelinux boot scripts etc current flipper test images use extlinux conf , but that may change in the future flash layout only two on flash offsets are fixed by the boot chain; everything else is determined by the partition table and the spl build configuration region byte offset notes early bootloader (rkns image) 0x8000 sector 64 on 512 byte sector media (sd, emmc); sector 8 on 4096 byte sector media (ufs) searched by boot rom main bootloader (fit image) 0x800000 (default) loaded by spl the actual offset is set in the spl build config and can be changed partition table (gpt or rockchip parameter) varies read by u boot proper; not consulted by boot rom or spl bootable partition(s) — kernel, rootfs, extlinux conf , efi binaries, … per partition table discovered by u boot standard boot modern packaging upstream u boot produces a single combined bootloader image, u boot rockchip bin , in which the rkns part and the fit part are already placed at the correct offsets with the necessary padding between them, so for most users the particular structure of those images shouldn't matter much the combined image is normally written with dd , e g dd if=u boot rockchip bin of=/dev/\<target> bs=512 seek=64 conv=fsync verify the target device with lsblk before running — dd overwrites the target unconditionally, and pointing it at the wrong disk will destroy data on the host system references comment by alchark https //github com/flipperdevices/flipperone docs/issues/52#issuecomment 4509109037 in the flipperone docs#52 issue u boot rockchip documentation https //docs u boot org/en/latest/board/rockchip/rockchip html u boot rockchip readme https //github com/u boot/u boot/blob/master/doc/readme rockchip in the official repo firmware design documentation https //trustedfirmware a readthedocs io/en/latest/design/firmware design html in arm trusted firmware a