Raspberry Pi 3 Fastboot – Less Than 2 Seconds
furkantokac.com
furkantokac.com
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).
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.
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.
MacOS and Windows have figured out that showing a GUI ASAP satisfies the user. Even if in the background its still negotiating networks, initializing sub-systems, etc.
I wonder why Linux has not yet taken that approach? That is move GUI far up in the init-queue and let it initialize networks, avahi, resolved, firewalld, etc as GUI is showing login screen...
Does it though? Has this ever really satisfied you … that you get to login and then circle your mouse for a few minutes while you wait for things to kick off.
Na, all or nothing please I don’t want to be teased by an is-it-isn’t-it experience I want my boot to take its time, let me know what’s going on and when it’s all there let me enjoy a responsive experience.
It’s just a cheap trick and it probably doesn’t matter as much as they think it does.
On my C64 I'd start loading a game from cassette tape before dinner so I could play it afterwards.
Punched tape[0]: Hold my beer
The Altair launched with a cassette tape interface anyway.
In my mental model, the technology distinction is more between single user and multi-user systems. And arguably that is more a a software differentiator than a hardware difference.
On my 9 track tape I would be lucky if the thing loaded and was ready to use 72 hours later [1].
I had to type the games source code in from a magazine for my acorn electron.
Whenever a user interactable element will be ready in <~100ms, you can display it as ready now, because it is faster than the reaction speed of a human, which makes all interactions with the software faster, smoother and more responsive than if I used a loading indicator. It's a free win.
Whenever you know in advance you need to display something to the user and need to load/process something that takes much longer than 100ms, you can load in the background while displaying whatever needs to be displayed and if the time spent on the screen is slower than the loading time then the next interaction will be instant (common case), if the user is faster on the screen you can still go to a loading screen, but the time it is on screen for would still be much much shorter.
Knowing things in advance is not a cheap trick. I’m not talking about a well structured boot. I’m talking about the far more common approach of just showing a moving mouse pointer and a few icons and “pretending” the computer is ready to use, a notion that is quickly disabused as soon as you try to get to work. Then even, you will her no way to know when it “is” actually ready.
When is the last time you cold booted a modern Apple Macbook for example?... Minutes is an absolute exaggeration.
Because it boots faster than a Windows system in that scenario. I personally like to be able to use my system as soon as the desktop is visible.
Also this is the way. When your system boots, it boots.
Probably used fast boot and returned from an image. :)
With the added benefit of not having X11 setting modes 5 times in the mean time.
Starting with latest iterations CentOS 7 and Debian 10, booting Linux is almost instantaneous. We have quite a few VMs, and after restarting one (i.e.: reboot <enter>), I just need to sip a little coffee to be able to SSH into a fully booted system.
On the other hand some of the higher end servers we have can fit a meaningful chat to the booting process (in fast boot mode, no less).
This means that most of the overhead is hardware initialization waits, IO and GRUB.
BTW, X11 is not modesetting 5 times on me. Maybe the first modeset you see is kernel's terminal modeset?
It takes about 5 seconds to login anyways, so DHCP is usually done before my browser wants network
If you're using something else than yes, the start of network services are made during boot. But it can be argued that if you're not using NetworkManager, you are a server and wouldn't benefit from delayed connection.
What if the GUI bring-up required mounting filesystems that need a kernel module that hasn't loaded yet?
What if the filesystem is on a network?
What if the network isn't up yet?
What if someone's xinit script needs access to the bluetooth stack which isn't up yet?
And even if the all the "correct" assumptions were made for a default install... doing anything different from that would require unraveling a mess to fix.
You'll notice that after you install a new device driver it'll boot much slower. This is because it invalidates the hibernate image and does an actual boot next time.
It's also why it won't let you fiddle with the BIOS settings before it does a quick boot. Because the hibernate image presumes the exact same hardware configuration.
Linux updates also wreck bitlocker if the windows partition is on the same drive (which I have to use for work) so I left the whole dualboot thing behind.
Come to think of it, doesn't the SD card slot sit off of the USB bus?
It doesn't.
This can be done with (for instance) u-boot.
But honestly, if you're going to that length and really need good battery life, maybe consider a fast microcontroller ;)
ARM11 is what the raspberry pi 4 BCM module uses from what I could tell. Looks like your best bet is to set the cpu freq down. I didn't see anything useful in the Broadcom BCM2711 datasheet.
The Beaglebone is based on an SOC from TI that was designed for (at the time High End) Smartphones. Therefore it supports much lower power consumption and idle modes.
The BCM2763 and BCM2835 are the same silicon in a different package: https://raspberrypi.stackexchange.com/questions/840/why-is-t...
The trick/indicator about the design goal of primary Smartphone SOC usage for the OMAP SOCs and most mobile CPU is the existence of deep sleep, RAM retention modes. Additionally every GPIO pin is configurable for Pull-Up/Pull-Down to prevent current leakage.
I haven't looked extensively but I don't believe the Broadcom SOCs support this mode.
Actually after more extensive review - I think the story is probably that Broadcom attempted to make a smartphone processor from Alpamosaic's Video Coprocessor, but didn't adequately support the low power modes and didn't get any design wins for smart phone.
They then pivoted and found traction in the Over the Top TV space.
https://www.computer.org/publications/tech-news/chasing-pixe...
[0] https://www.anandtech.com/show/10716/roku-unveils-streaming-...
Roku Ultra: 900 MHz Broadcom BCM2836 CPU (quad-core)
[1] https://www.anandtech.com/show/4903/roku-2-xs-review-streami...
[2] https://www.reddit.com/r/raspberry_pi/comments/egwo6z/was_th...
Another idea is to use an open source "smartphone" like the PinePhone as a battery-powered, pocket-sized, general purpose computer, like the RPi. (Depite whatever usage the Pine64 folks and "app" contributors envisage.)
The PinePhone boots from SD card, like the RPi. It will run Linux. What remains is further OS support. It will boot NetBSD, which is a start. The RPi battery problem has been solved.
For the avoidance of doubt, "general purpose" means, among other things, "cellular calling" is not a prerequisite to usefuless. Similarly, "pocket-sized" does not imply that the computer is always operated by removing it from a pocket and holding it in the hand; it refers to the form factor, not the usage.
Further, I am not seeking to stimulate discussion of "average users". This is "Hacker News" not "Average User News". The idea has come up a few times on https://forum.osdev.org but I have not seen it discussed on HN.
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.
Yes, but glancing quickly at the article some solutions are not generally acceptable, such as moving filesystem processes to the application code. If you have a RPi project where you plan to run a single Qt app then you can do stuff like this, but that is generally speaking not the use case.
I’ll rather have slow boot and proper UEFI support so I can boot any vanilla ARM64 Linux distro (Debian proper), instead of images/distros which have been crafted to be device-specific (Raspbian).
I boot this thing once every second month at most. I honestly couldn’t care less about boot-times.
Luckily for me, there are solutions to my problem too ;)
Incidentally, I have used this for for the ESXi Fling for the Pi when benchmarking it against KVM performance (for those curious, KVM far outperformed ESXi), but I heard that it doesn't work as well for Linux distros (some hardware was broken last I heard [a few months ago]).
But yeah, I agree that getting UEFI support and standardising the ARM boot procedure is very useful for all of us.
Because these changes remove networking, USB support, sound, debugging support, and even the entire init system. It's useful if you need to boot into a single, simple app without networking or USB as fast as possible, but it's not useful for general purpose computing.
I’d rather my computer booted and then signalled when everything I want was ready, rather than hide the init time after claiming to be ready.
Virtualization systems like qemu-system or VMware support suspend/resume, which is essentially the same problem.
That said the internal state is a valid concern, you'd need the involvement of hardware drivers as it's essentially hibernation...
For most Linux use cases, it really comes down to distro (and especially init) choice.
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?
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.
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.
Is this possible? Has anyone done something like it before?
That's what small embedded systems basically are --- there's not bootloader or any other extraneous complexity, the MCU starts up from the reset vector directly into the "application code".
Using Linux or some other full-blown OS is why a lot of newer embedded stuff like "smart" TVs, set-top boxes, etc. need to "boot" before they're usable. Regardless of how much you try to optimise the process, it won't beat a simple MCU or the "old school" non-computerised systems from power-on until usable.
If you bundle some of the userspace into the kernel image, then you trade-off some security, and needing to have to rebuild this large image periodically, for much faster startup times, and (optionally) load times for some userspace applications - but you can still install and load other userspace tools, they'll just start up "normally".
So much of this is just tradition.
I have server machines that take minutes after power on before they even get to the kernel. I know they aren't designed to be rebooted often but this burns tons of time for no reason whenever they need to be serviced for whatever reason. Testing bios changes or doing network reconfiguration takes 30-60 minutes instead of 5, it sucks.
It takes a long time because we have simply accepted the tradition of "initialization takes a long time".
There are certain bottlenecks like loading boot images over relatively slow SPI, but the synchronization margins between components are like 10x bigger than they need to be simply out of poor engineering.
Booting a system goes beyond just the CPU. Most of the time isn't spent computing things. It's spent waiting for data transfers, initializing peripherals, and so on.
It's not just "tradition" to make it slow.