This just shows how proprietary boot flow of RPi is slow. On other platforms you can get bootloader to hand off to kernel in subsecond timeframes, sometimes as fast as in 0.3s.

Then kernel can be done in another 0.3s or faster, and then userspace can still be optimized more than what's described in the article, too. Instead of shell and executing programs, which requires filesystem access, loading them, loading shared libraries, etc. you can have a specialized, tiny statically built init binary which just does all initialization/mounts via syscalls and then runs your app (which should be built statically, too).

This way you can achieve ~1-2s boot to UI on even way slower platforms than Rpi4. I did something like this on Pinephone a few years ago and recently again on Luckfox Pico Mini, which is a slow Cortex-A7 with DDR2 memory.

There's no justification for Rpi to be booting for 12s. Even unoptimized standard U-Boot on common platforms often runs for just ~1s before handing off to the kernel.

"Instead of finding and optimizing tasks, we just turned systemd off". Okay.

The folks at Bootlin have way more interesting approaches and techniques to review. I'd look to them.

https://bootlin.com/blog/tag/boot-time/

Even if your userspace is pretty fast, some necessary initialization happening before the kernel is even loaded means the you probably never get lower than 6-8 seconds. There is a lengthy EEPROM issue thread about that for the Pi4: https://github.com/raspberrypi/firmware/issues/1375

I wonder how this even works, as PID 1 should exit right away, no? And I thought this would lead to an immediate kernel panic?