One interesting reason there's a been a bunch of progress in this space is that automotive systems are required to show the rear view camera in a certain amount of time. Progress driven by the oddest of things.
I'm impressed. I don't know of too much work that's going on upstream for optimizing boot times, other than some of the clear linux stuff: <a href="https://www.phoronix.com/scan.php?page=news_item&px=Clear-Linux-Ubuntu-Eoan-Boot" rel="nofollow">https://www.phoronix.com/scan.php?page=news_item&px=Clear-Li...</a><p>There are folks looking into improving boot times on Android; turns out init and kernel drivers are a tangly mess of {dependency} spaghetti. Loading kernel modules can induce delays in processing relocations.<p>The kernel patches disable a bunch of stuff, including ethernet it looks like? Most of the kernel changes comment out blocks of code, or trade long delays for shorter delays with more iterations.
> Networking takes by far the longest time to get ready. The main reason is that Ethernet auto-negotiation takes a significant amount of time, about 1 to 3 seconds.<p>Is this a fundamental limitation of how auto-negotiation works?
Is there a way to speed it up?
> A reboot is even faster, only 0.26 seconds from issuing the reboot to entering user space.<p>Curious; it doesn't say how that works. Could be kexec, but if it's a real reboot then I'd be interested to know why it's faster. Can you still skip some hardware initialization somehow?
> Start with MMC clock frequency at 52 MHz instaed of 400 kHz.<p>Whoa there!<p>Spec violation. Not guaranteed to work. Might work some days but not others.
Are super-quick boots vulnerable to having a (presumably?) lower entropy pool exploited or do the steps taken to mitigate low entropy across freshly minted cloud images also help here?
The hardware looks awesome! Looks like it hasn't been updated in 2 years though, has anyone produced these PCBs based on the Jiffy?<p>Is that an EMMC Socket on there?