3 ms·

Raspberry Pi 3 fastboot in less than 2 seconds (2020)

61 points by fanf2 2y ago

harvie 2y ago
Too bad you need to ditch USB and Ethernet or other peripherals... It would be nice if there was a way to defer the initialization of those subsystems after userspace has started. Eg.: Unless i boot from USB, i probably don't need my USB mouse nor ethernet before X server and Firefox had started. So why not start initializing those peripherals later in parallel while userspace already works on starting browser? Obviously this does not fit all imaginable usecases, but would be nice to be configurable.
- guerrilla 2y ago
  > It would be nice if there was a way to defer the initialization of those subsystems after userspace has started. Why couldn't you? I didn't read the whole thing but there's a note at the top saying they're working on getting USB and Ethernet working. That's probably how.
  - harvie 2y ago
    If i understood it correctly... Initializing things as USB, which are inherently plug-n-play peripherals do need to wait for some protocol-defined time before we can say all peripherals on that bus were initialized. (Eg. i beleive USB devices have 0.5 second to enumerate, so if you wait for USB before you continue booting, it's automaticaly 0.5 second delay. But if you find USB hub, which is rather common, it's another 0.5 second delay to enumerate devices behind it.).
    - zokier 2y ago
      I'm pretty sure Linux does usb device enumeration/initialization already asynchronously and does not block booting
- fulafel 2y ago
  Is there reason to think there's some obstacle for later loading them? At least on x86 you can compile the usb stuff as modules and load as late as you like.
itomato 2y ago
Buildroot is key here. Glad to see it.
hggh 2y ago
(2021)
dijit 2y ago
buildroot is a fantastic project. I built a IRC bouncer in a box using a OrangePi Zero, buildroot, ZNC and "The Lounge" - and sold them at the CCC 2017. The buildroot part was actually much nicer than I expected; if I was doing the same today I might try to adapt Oasis userland to it, but for a small "embedded" immutable little box it was excellent. Here's the code: https://git.drk.sc/Derecho/irc-sbc-buildroot https://git.drk.sc/Derecho/irc-sbc-buildroot
numpad0 2y ago
Isn't this range of quick booting usually done with "hibernate once resume many" setup?
- oneplane 2y ago
  At some point the time to resume is going to make no difference if you still need to load and start a kernel and loading state into RAM is just as fast as loading the OS (which is generally what you get with an immutable OS -- you don't have to spend time on dynamic stuff like loading/probing as much as you would normally). For most operating systems, time tends to be spent in two areas: 1. What-ifs, to mitigate hardware changes, software changes and environmental changes 2. Actually loading and starting the stuff you need That second part can be pretty fast and optimised, and if you eliminate the first part, what you'd do when resuming tends to be the same as loading/starting, but you're going to get bottlenecked by storage-to-RAM if you need to restore the entire memory at once. At that point, if loading/starting programs is fast enough, you might as well do just that. As a bonus, you now get to use events and parallel processing which can give you significant performance gains. But, if we go back a bunch of years and make it a bit more generic (not just focus on Linux); there was indeed a very long time where having a pre-loaded image (essentially the entire machine state) was the fastest you could get since the time spent on individual tasks was so much slower than it is now. The biggest difficulty was making sure that a restored state was stacked on top of pre-initialised hardware. In a way, this is still how many IPL processes for mainframes still work; the entire system is brought out of reset and initialised using a separate system, which then dumps the OS on top of an already-running system.
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
yjftsjthsd-h 2y ago
I'm curious why start.elf is looking at the device tree file; I thought that was purely for Linux's benefit
fulafel 2y ago
> In the system where UART is running, “8250.nr_uarts = 1” parameter is passed to the Kernel. We put this parameter into the cmdline.txt file of the problematic Kernel and it works like a charm. Lets move on the other problem. This is funny. I'm sure there's a intresting reason why there's a driver for a 1978 UART chip involved. (ref: https://en.wikipedia.org/wiki/8250_UART https://en.wikipedia.org/wiki/8250_UART)

61 points by fanf2 2y ago

Too bad you need to ditch USB and Ethernet or other peripherals... It would be nice if there was a way to defer the initialization of those subsystems after userspace has started. Eg.: Unless i boot from USB, i probably don't need my USB mouse nor ethernet before X server and Firefox had started. So why not start initializing those peripherals later in parallel while userspace already works on starting browser? Obviously this does not fit all imaginable usecases, but would be nice to be configurable.

guerrilla 2y ago
> It would be nice if there was a way to defer the initialization of those subsystems after userspace has started. Why couldn't you? I didn't read the whole thing but there's a note at the top saying they're working on getting USB and Ethernet working. That's probably how.
- harvie 2y ago
  If i understood it correctly... Initializing things as USB, which are inherently plug-n-play peripherals do need to wait for some protocol-defined time before we can say all peripherals on that bus were initialized. (Eg. i beleive USB devices have 0.5 second to enumerate, so if you wait for USB before you continue booting, it's automaticaly 0.5 second delay. But if you find USB hub, which is rather common, it's another 0.5 second delay to enumerate devices behind it.).
  - zokier 2y ago
    I'm pretty sure Linux does usb device enumeration/initialization already asynchronously and does not block booting
fulafel 2y ago
Is there reason to think there's some obstacle for later loading them? At least on x86 you can compile the usb stuff as modules and load as late as you like.

itomato 2y ago

Buildroot is key here. Glad to see it.

hggh 2y ago

(2021)

dijit 2y ago

buildroot is a fantastic project. I built a IRC bouncer in a box using a OrangePi Zero, buildroot, ZNC and "The Lounge" - and sold them at the CCC 2017. The buildroot part was actually much nicer than I expected; if I was doing the same today I might try to adapt Oasis userland to it, but for a small "embedded" immutable little box it was excellent. Here's the code: https://git.drk.sc/Derecho/irc-sbc-buildroot https://git.drk.sc/Derecho/irc-sbc-buildroot

numpad0 2y ago

Isn't this range of quick booting usually done with "hibernate once resume many" setup?

oneplane 2y ago
At some point the time to resume is going to make no difference if you still need to load and start a kernel and loading state into RAM is just as fast as loading the OS (which is generally what you get with an immutable OS -- you don't have to spend time on dynamic stuff like loading/probing as much as you would normally). For most operating systems, time tends to be spent in two areas: 1. What-ifs, to mitigate hardware changes, software changes and environmental changes 2. Actually loading and starting the stuff you need That second part can be pretty fast and optimised, and if you eliminate the first part, what you'd do when resuming tends to be the same as loading/starting, but you're going to get bottlenecked by storage-to-RAM if you need to restore the entire memory at once. At that point, if loading/starting programs is fast enough, you might as well do just that. As a bonus, you now get to use events and parallel processing which can give you significant performance gains. But, if we go back a bunch of years and make it a bit more generic (not just focus on Linux); there was indeed a very long time where having a pre-loaded image (essentially the entire machine state) was the fastest you could get since the time spent on individual tasks was so much slower than it is now. The biggest difficulty was making sure that a restored state was stacked on top of pre-initialised hardware. In a way, this is still how many IPL processes for mainframes still work; the entire system is brought out of reset and initialised using a separate system, which then dumps the OS on top of an already-running system.

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

yjftsjthsd-h 2y ago

I'm curious why start.elf is looking at the device tree file; I thought that was purely for Linux's benefit

fulafel 2y ago

> In the system where UART is running, “8250.nr_uarts = 1” parameter is passed to the Kernel. We put this parameter into the cmdline.txt file of the problematic Kernel and it works like a charm. Lets move on the other problem. This is funny. I'm sure there's a intresting reason why there's a driver for a 1978 UART chip involved. (ref: https://en.wikipedia.org/wiki/8250_UART https://en.wikipedia.org/wiki/8250_UART)