This is a common technique in embedded products, but I should point out that it's not useful for general purpose Raspberry Pi work.<p>The author disables several important kernel features to boot faster, including network support and USB support. Obviously, if you plan to use network or USB then it's not an option to disable those. You can disable some of the other debugging features and little extras for a slight boost, but it's going to be negligible (<1s, in my experience).<p>The biggest change comes from removing the init system entirely and replacing it with the user-facing app. This is the fastest way to get your app started, but now you're responsible for doing everything that was previously handled by the init system. The author can do this because they don't have any network, timekeeping, or other system functions normally handled by the init system. They only needs to mount filesystems, which is easy to replicate inside of the app.<p>Anyone planning to ship a Raspberry Pi based product should read this article carefully as a great starting point. Anyone who wants to use their Raspberry Pi for general purpose use or even with network connectivity or USB devices will be disappointed if they try these techniques. Great article, but it's a narrow use case.
Talking about optimizations for raspberry pi, does anyone knows if there is any low power mode configuration available ? I've always been fascinated by how smartphones can stay like one/two days in idle while a raspberry pi can't stand 10 hours with a similar battery.
Great job! I am building a CNC router in my spare time and I ended up using a raspberry pi 3 since I want to cram in a ton of features and esp32s and stm32s are simply not cutting it. And cutting the boot time is something I spend stupid amounts of time on. The best I was able to achieve was just under 8 seconds. I'll have to dig into this and see if there is something more I could do.
Interesting. I given up using Raspberry Pi 4 on a project because their crap proprietary bootloader took something like 4 seconds to start the kernel. Maybe it was faster on Pi 3. I ended up buying board with Allwinner that works with U-Boot.
I used to work for an automotive manufacturer, and one of the challengers that we faced while exploring system design was startup time to get from 0 to a backup camera.<p>It was this kind of thing we considered (this was all POC) but it comes with the cost of having to get the rest of the system up.
This is a great write up and was really interesting to read.
My question is why would the proposed changes are not already included upstream?
Isn't a faster boot what everybody wants?
If you have an immutable system partition I wonder if you could boot, and then take a snapshot of memory (excluding caches etc) and save that to disk. On a reboot you would 'simply' load your RAM image from disk and everything would be immediately at steady state?
I've been booting Void Linux on a raspberry pi 2 and it comes up in like 5s. If you really need to shave boot time down, like you're cutting power to the machine except when it's necessary and need it to come up instantly, something like this may be helpful though you might be in the realm of wanting an RTOS rather than Linux.<p>For most Linux use cases, it really comes down to distro (and especially init) choice.
So, it seems like the main speedups were from removing a ton of kernel modules, replacing the init system with the target application, and then some optimization of the target application. That's pretty neat!<p>But let's go further - while we're trading flexibility for performance, why couldn't the entire kernel and userspace be precompiled+loaded into a single image file - like a Smalltalk/Lisp image - and loaded directly into memory, modulo some really-truly-has-to-be-done-upon-power-up initialization?<p>Sure, there's hardware that has to be brought up - so, right after initializing basic access to the SD card and RAM, this hypothetical bootloader could initialize another core and use that to bring up the random SoC subsystems while the kernel image is being copied into RAM.<p>And, yes, this would mean that you would need to re-compile that image every time you updated the kernel (or any of the userspace stuff inside) - but, again, we're sacrificing flexibility for performance.<p>Is this possible? Has anyone done something like it before?
"bootcode.bin: This is the 2nd Stage Bootloader, which is run by the 1st Stage Bootloader which is embedded into the RPI by the manufacturer. Runs on the GPU. Activates the RAM. Its purpose is to run start.elf (3rd Stage Bootloader)."
That is Fastboot w/o network support (and a plethora of other features disabled). The trade-of appears to be worth for this particular application, but is hardly a general solution.
Did I read that the initialisation of entropy for random boot sequence (which needs time to get enough unrelated external asynchronous events to cause it to be 'unlike' another boot) was one of the things he disabled?
Can't seem to get ahold of _any_ embedded SBC these days. RPI 4s are being sold 3x their normal price, and alternatives like the RockPi are nowhere to be found :/