How to optimize boot time in user space on a Raspberry Pi 4 / Boot2Qt
qt.io
qt.io
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.
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.
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.
The folks at Bootlin have way more interesting approaches and techniques to review. I'd look to them.
But in practical terms if you really need boot speed, you need a Pi 5 that only takes a few seconds at worst, not a Pi 4 which uses its slow ass GPU to run the boot process for absolute maximum sluggishness possible.
A few seconds is still very long - in automotive you’re dealing with a few hundred milliseconds from power is applied till the system is presenting an interactive GUI.
[Timer]
OnBootSec=2min
Edit: set delay to one minure, working just fine!
Not really. The result is kind of a letdown and that was too be expected, going after a single memcpy is low ROI because memcpy performance is probably what processor and library makers look at first.
What wins big is to remove useless stuff entirely. The demo boards I have seen often come with a standard Debian with all the services one might want for a workstation. The kernel is usually the same, with drivers such as PS/2 mouse enabled - thankfully just as a module, but disabling the useless drivers wins big in kernel compilation time. Which makes optimizing the rest a bit more comfortable (some options such as hardening and debugging can nearly full recompilation).
While there, one can also build the drivers one always want inside the kernel (not as module). A module inside a compressed kernel is loaded faster than from somewhere in a filesystem.
That said, Bootlin has indeed a lot of good stuff.
As for turning off systemd, it is not a bad idea if one replaces it with an init system that can start stuff in parallel (to mask the waiting times). I get that desktop users and admins like it a lot, but for an embedded system with a specific mission and a static configuration, it can overkill. There are a bit more caveats than what they say, though.
This. And there's even a project (targeting mainly RasPi) that does just that: https://gokrazy.org
(And yes, you can also deploy code that wasn't written in Go, although it's quite clunky.)
There's not a lot of good information about attacking it from the other way: Start with a bootloader, firmware, and a kernel, and add only the stuff that you need. I mean, it's probably out there on the web somewhere, but I've found it tough to find among all the "just strip down Debian" blog posts. If anyone has experience doing this and could point me to a few resources, I'd be grateful!
From there, get gcc and make for your platform, so you can carry on with compilation on-target, if possible; cross-compilation can be tricky. It should be ok if you don't want the heavier GUI stuff like X11/Wayland, browser etc.