megi's PinePhone Development Log RSS


2023–07–06: Sneak peek of rk2aw – what's comming up soon

Rockchip SoCs' boot priority is really annoying. SPI NOR flash is a primary boot source where the SoC looks for the bootloader, and if the bootloader is messed up, or you simply don't want to run it, and instead you want to run a complete software stack from external storage (incl. a bootloader), you're in a very annoying situation, where all you can do on many Rockchip based devices is to erase your bootloader from internal SPI flash temporarily, and then somehow flash it again after you're done experimenting with software on external storage.

Even a simple update of a bootloader in SPI flash can go wrong very easily, because you can only have one copy of it in there. If you flash it incorrectly, if the flashing gets interrupted, or if you flash a broken build of the bootloader, you're out of luck, because the boot will most likely hang, and lower priority boot sources will not even get tried.

I've been writing a software tool, which I call rk2aw, to fix all these issues for good on several Rockchip SoCs, including RK3399, RK3566 and RK3588. It allows you to have multiple bootloaders in SPI NOR flash, it reverses boot order so that microSD card is tried first if present, it adds a single button/LED UI which is realizable on almost every Rockchip SBC in uniform way, and it adds some device specific improvements like preventing boot when powerup happens due to USB power insertion, and not a power button press.

I have also improved my patches for U-Boot that implement touch based boot UI, to make the menu extract boot entries from extlinux.conf file. The touch menu is now automatic and no longer depends on having to write U-Boot boot scripts manually. All you need is your pre-existing entries in extlinux.conf, now, and you'll get the menu.

As a companion to rk2aw, I wrote a flashing tool, that can safely update SPI NOR flash, and install U-Boot, rk2aw, and other bootloaders to it. There are bad ways to update the flash (via /dev/mtd0block), slightly better ways (using mtd-utils), and the best way is a hand-crafted algorithm tailored to understanding of the content being flashed, where the order of operations is designed specifically so that no interruption of the flashing process can lead to un-bootable system.

Preview of rk2aw: