13 ms·
Raspberry Pi 3 Fastboot – Less Than 2 Seconds
- bpye 5y agoIf 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?
- kijiki 5y agoCaches aren't a problem, you can just persist memory. The problem is the non-RAM internal state of everything. You can preserve CPU register state and various operating modes, but persisting the state of every hardware device you use is a big, undocumented challenge. Virtualization systems like qemu-system or VMware support suspend/resume, which is essentially the same problem.
- bpye 5y agoI only mentioned caches to reduce the amount of storage that would be read as storage isn't always very fast. That said the internal state is a valid concern, you'd need the involvement of hardware drivers as it's essentially hibernation...
- joezydeco 5y agoWith what mass storage driver?
- inChargeOfIT 5y agoLearned a lot, thanks for the write up!
- bitwize 5y agoI'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. For most Linux use cases, it really comes down to distro (and especially init) choice.
- johnvega 5y ago"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)."
- axegon_ 5y agoGreat 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.
- donquichotte 5y agoAre you using the PREEPMT_RT kernel? Driving steppers or servos directly from the Raspberry?
- wiml 5y agoIf you're driving steppers, especially on something like a mill, I'd think it'd make sense to use something like a Beagleboard with its PRUs, or an auxiliary hard-realtime microcontroller.
- deleted 5y ago[deleted]
- PragmaticPulp 5y agoYou might be able to shave a little bit of time off, but if you need network, USB, or an init system then be warned that this article removes all of those.
- GekkePrutser 5y agoReally nice effort and info. Thanks for sharing!
- goldbattle 5y agoThis 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?
- repomies69 5y ago> Isn't a faster boot what everybody wants? 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.
- josteink 5y ago> Isn't a faster boot what everybody wants? 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 ;) https://github.com/pftf/RPi3 https://github.com/pftf/RPi3
- kaladin-jasnah 5y agohttps://github.com/pftf/RPi4 https://github.com/pftf/RPi4 for Pi4 users. 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.
- PragmaticPulp 5y ago> My question is why would the proposed changes are not already included upstream? 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.
- lovelyviking 5y agoHow difficult it would be to make it work with RaspberryPI 400?
- garaetjjte 5y agoInteresting. 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.
- abainbridge 5y agoThat's interesting. I was thinking of going down the same route. Which Allwinner board? And how fast did it boot?
- garaetjjte 5y agoI went with Orange Pi 3. I would need measure exactly, but with U-Boot compiled without unnecessary things (USB etc.) it starts loading kernel pretty much immediately. In total boot to my graphical application which uses KMS/OpenGL was something around 2 seconds.
- whalesalad 5y agoFWIW my Pi4 running nerves/elixir boots to the full beam environment in less than ten seconds.
- sneak 5y agoThis is a quad core machine that can do billions of cycles per second. That seems unnecessary and wasteful by at least two, possibly 3 orders of magnitude. 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.
- gtirloni 5y agoThat's because of the POST procedure allowing time to initialize and run the ROMs in all PCIe devices. Also, HBAs take time to do staggered initialization of disk, etc. There are usually some tweaks you can do in the BIOS to skip certain things but unless you're seeing >5min boot times, I wouldn't bother.
- sneak 5y agoI understand the excuses, but the "time to initialize" thing is also just outdated tradition. These things (even the HBA stuff) are modern chips that can do zillions of operations per second. 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.
- withinboredom 5y agoAren’t most initializations done with the CPUs in real-time mode? In that case, they are probably only able to run in MHz and not ghz
- up6w6 5y agoTalking 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.
- opencl 5y agoThere aren't a whole lot of power management features available in the hardware, the SoC just wasn't designed for mobile/battery use. About all you can do is disable USB/ethernet/HDMI if not needed for your use case, or drop the CPU/GPU clocks.
- harlanji 5y agoIt is relatively low power, in the ballpark of a mobile phone. Running headless the Pi3 consumes 4-5W with an out of the box Ubuntu install, about 9W with the 7" screen, and after shutdown it remains on at about 2W. The iPhone SE takes about 9W while charging and 4W fully charged with the screen on. Numbers aren't exact, read out from a Jackery display and it's been a few months. I think the Pi4 8GB was about 1W more than the Pi3.
- PeterisP 5y agoDo you know why does it still consume half of the power (2w out of the 4-5w) after shutdown?
- geerlingguy 5y agoThe power circuit in the Pi isn't super-efficient.
- bfrog 5y agoMy Lenovo t460 draws 4-5w while idle with Wi-Fi and lcd goin… 4-5w is a decent draw for headless
- GeorgeTirebiter 5y ago
- guenthert 5y agoThat 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.
- abc_lisper 5y agoDoes anyone know how to get hold of a couple of raspberry pies. It is always a drag to get hold of
- grayhatter 5y agoI usually search for suppliers using Google. Did you try that yet?
- II2II 5y agoGo to the Raspberry Pi website, find the page for the product you want, the scroll down to the bottom to find a list of dealers. Availability probably varies by country, but I was able to find several configurations of the Pi 4B in stock in my country and pricing was in line with their recent price increase (sigh).
- PragmaticPulp 5y agoThis is a common technique in embedded products, but I should point out that it's not useful for general purpose Raspberry Pi work. 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.
- _red 5y agoGreat points, a tangential thought: 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...
- rusk 5y ago> satisfies the user 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.
- oolonthegreat 5y agoneat! I had no idea that rpi used a closed bootloader SoC? are there no open source hardware alternatives ?
- fouric 5y agoSo, 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! 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?
- fanf2 5y agoSounds like installing the application as init inside the kernel’s initramfs.
- yissp 5y agoI'm not super familiar with the concept, but isn't this sort-of what a "unikernel" is?
- userbinator 5y agoAt that point, why not just get rid of the OS? 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.
- fouric 5y agoBecause the thing I described is still more flexible than having no OS at all. 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".
- sircastor 5y agoI 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. 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.
- ggm 5y agoDid 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?
- eblanshey 5y agoAnyone know of something like this for a beaglebone black, with Qt/QML as well?
- exabrial 5y agoCan'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 :/
- EastOfTruth 5y agoESPs are still easy to get though and are surprisingly powerful enough for many tasks
- deleted 5y ago[deleted]