Slow Raspberry Pi 4 boot time

[timoteicampian]

Creating a feature request

Is your feature request related to a problem? Please describe:

• The boot time of dietpi over our raspberry pi 4b is a little bit too much - about 15 seconds

Describe the solution you'd like:

• Raspberry Pi 4b boot time under 3 seconds

Describe alternatives you've considered:

• This tutorial https://www.furkantokac.com/rpi3-fast-boot-less-than-2-seconds claims under 2 sec boot time. Only that it's for RPI 3, not RPI 4.

Additional context

• If dietpi-config can provide a menu option for recompiling start.elf & other speed fixes, or just some alternative start.elf. Or however you deem it right :)
  I really believe this would better the DietPi mission of creating a swift OS

[MichaIng]

Well, the major part of the boot time is not the bootloader, kernel and device tree stage, but the init system which sets up the userland and starts the services which drive your OS and applications.

The tutorial is an experiment how to boot fastest into a limited busybox "shell" (ah not even that), no real OS, no service management, no multi user system/authentication, not package manager, nothing. It boots fast, but you cannot do anything. If you want to run a single script or process on that machine (like the Qt application mentioned in the tutorial, manually compiled and copied to the RPi, some sort of status monitor it seems), that's fine, but an RPi 4 is wasted hardware for this.

We use the official, tested and capable RPi kernel, bootloader, dtb and firmware stack and won't offer a feature to compile a custom kernel, given how much can go wrong when someone without any experience with kernel compiling starts doing it. There are guides and instructions how to compile a custom kernel, but I do not see a reason to do so, as long as you do not need additional kernel features/modules which are not enabled in the official kernel. As said the major boot time comes from the init system userland part, not from the kernel.

DietPi is a minimised OS, but still Debian based, with the intention to have the power and flexibility of systemd service management, APT package manager with Debian's ~60,000 available software packages, a proper UNIX user management with authentication systems, network management, and a capable shell with the basic command-line utilities. Only with this, we are able to provide the system configuration options we do, and the options to install from a larger number of server software options and stacks, which do require some sorts of underlying OS like this.

If you want to make a fair comparison, check out Raspberry Pi OS Lite, Ubuntu Server or other distributions server/lite images which do have a package manager, init system with service management, shell, multi user system etc. With what we did compare with, DietPi boots fastest 😉.

[timoteicampian]

Thank you for your detailed and very prompt reply.
We measured the boot time in a controlled "pre-systemd" (initrd) environment:

• a custom bash init script and changed the cmdline.txt to point to it (and to enable network there we used
  ip=192.168.1.200::192.168.1.1:255.255.255.0:rpi:eth0:off )
• rebooted into that custom (and small) bash init script;
• synced the time with an internet time server;
• saved /etc/fake-hwclock.data onto the /boot partition and immediately after /etc/init.d/reboot stop
• before doing anything, the script did cp /boot/fake-hwclock.data /etc/fake-hwclock.data && /usr/sbin/fake-hwclock load
• the difference ntpdate reported against the internet time server was about 15 seconds almost every time.
  This way, only the "cold reboot" time difference was accounted for, before loading any services/binaries loaded, almost completely outside "the init system" (and completely out of the "systemd" system).

We may be wrong, but our little experiment so far seems to locate the culprit somewhere within the bootloader, kernel and/or device tree stage, outside of "systemd" (we never booted into the systemd during the test).
Could you, please, also try to reproduce this measurement in your environment?

PS:
We are using a RPI 4b with 4GB RAM with a fast microsd card: https://www.samsung.com/us/computing/memory-storage/memory-cards/evo-plus-microsdxc-memory-card-64gb-mb-mc64ha-am/

[Joulinar]

Whole bootloader and kernel is not provided by DietPi. It's the original one directly delivered by RPi foundation.

[MichaIng]

Did you check systemd-analyze when booting into regular multi user system including init? This should be around 15 seconds, and pre-init is then a little fraction of this.

Not sure how your /etc/init.d/reboot stop works, but it sounds like you measure the reboot time, not the boot time, hence including shutdown phase and possible delay until (re)boot starts after shutdown has completed.

The question also is what you actually want to measure and want to do with the system. If you really want to boot into a custom script and don't want to load any init system, then this may be interesting and you may be able to improve this boot time (sacrificing mentioned full server capabilities). But if you actually want to boot into a multi user init system, then what you measure has not really much relevance, but systemd-analyze, dmesg timestamps or other complete boot time measurements are what is relevant.

Also if you suspect any suboptimal bootloader behaviour, I recommend to watch its output with a UART adapter. E.g. the EEPROM on RPi 4 can be configured, like the boot order so that the SD card is checked at first (should be the default, though) and other parameters. Also you can add boot_delay=0 to the config.txt to skip the 1 second wait time before the kernel is loaded: https://www.raspberrypi.com/documentation/computers/config_txt.html#boot_delay
In my case, it works well, but with other (likely older/slower) SD cards may fail.

If you really find an issue or possible optimisation without downsides, you should report it to the RPi devs: https://github.com/raspberrypi/firmware
As said, we use the unmodified official RPi kernel/bootloader/firmware and won't offer or ship custom ones and generally keep default compatibility settings like the 1 second boot_delay. But if there is an improvement possible, of course it is great to report upstream (ping me, I'm happy to test/verify), have it checked by RPi devs and then in case shipped for all RPi users, including DietPi ones.

[MichaIng]

I'll mark this as closed. Feel free to reopen if required.