-
firmware
This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware. (by raspberrypi)
Even if your userspace is pretty fast, some necessary initialization happening before the kernel is even loaded means the you probably never get lower than 6-8 seconds. There is a lengthy EEPROM issue thread about that for the Pi4: https://github.com/raspberrypi/firmware/issues/1375
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
gokrazy
turn your Go program(s) into an appliance running on the Raspberry Pi 3, Pi 4, Pi 5, Pi Zero 2 W, or PCs (x86_64 or ARM64)!
> What wins big is to remove useless stuff entirely.
This. And there's even a project (targeting mainly RasPi) that does just that: https://gokrazy.org
(And yes, you can also deploy code that wasn't written in Go, although it's quite clunky.)
-
For 0.3s you need specialized bootloader, like eg. levinboot https://gitlab.com/DeltaGem/levinboot for Rockchip RK3399 or https://xnux.eu/p-boot/ for Allwinner A64. Or make something similar for your chosen platform with U-Boot's falcon mode and making the kernel as small as possible, so that not much needs to be loaded for the initial UI (put in modules what can wait, like wifi driver, etc.).
For around 1-2s you need a platform that has good SD or eMMC host implementation in U-Boot, and doesn't spend too much time initializing DRAM, or in U-Boot SPL code before MMU/CPU data cache is enabled. If the CPU is slow or not upclocked in U-Boot, not doing decompression in bootloader is also a tradeoff option that may end up being faster. Some newer Rockchip RK35xx SoCs have pretty fast boot times in this regard. (RK3399 interstingly doesn't)
It's all necessarily SoC specific.
On some platforms (RV1103/6) I've also experimented with using bootrom functions that normally load U-Boot to load the kernel directly, so with that approach, DTB, and kernel is being loaded right away, without re-initializing eMMC or SD card or having to load and execute a complicated DT driven bootloader like U-Boot at all. But that required quite bit of work and some reverse engineering of the Boot ROM code, so that's not just a optimization.
