26 ms·
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
by megous 2y ago
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.
- deleted 2y ago[deleted]
- PhilipRoman 2y ago>On other platforms you can get bootloader to hand off to kernel in subsecond timeframes, sometimes as fast as in 0.3s. Any good resources about this? I absolutely loathe the pre-kernel boot times we get at $WORK, even when using a supposedly minimal bootloader. Just decompressing the kernel takes like 10 seconds.
- megous 2y agoFor 0.3s you need specialized bootloader, like eg. levinboot https://gitlab.com/DeltaGem/levinboot https://gitlab.com/DeltaGem/levinboot for Rockchip RK3399 or https://xnux.eu/p-boot/ https://xnux.eu/p-boot/ for Allwinner A64. Or make something similar for your chosen platform with U-Boot's falcon mode and making the kernel as small as possible, so that not much needs to be loaded for the initial UI (put in modules what can wait, like wifi driver, etc.). For around 1-2s you need a platform that has good SD or eMMC host implementation in U-Boot, and doesn't spend too much time initializing DRAM, or in U-Boot SPL code before MMU/CPU data cache is enabled. If the CPU is slow or not upclocked in U-Boot, not doing decompression in bootloader is also a tradeoff option that may end up being faster. Some newer Rockchip RK35xx SoCs have pretty fast boot times in this regard. (RK3399 interstingly doesn't) It's all necessarily SoC specific. On some platforms (RV1103/6) I've also experimented with using bootrom functions that normally load U-Boot to load the kernel directly, so with that approach, DTB, and kernel is being loaded right away, without re-initializing eMMC or SD card or having to load and execute a complicated DT driven bootloader like U-Boot at all. But that required quite bit of work and some reverse engineering of the Boot ROM code, so that's not just a optimization.