Secure boot increases the boot time

[Hubix9]

Board used: CM5 32GB 4GB Ram
Operating system images used: dietpi and Raspberry Pi OS for RPi5/CM5

Hello,

I have observed an interesting behavior that does not seem to be documented. I'm using the rpi-sb-provisioner to secure a CM5 based device, I have noted that before starting to boot the kernel the CM5 takes around 9 seconds to initialize it's hardware (as mentioned in this link on RPi forum ). After provisioning exactly the same boards with secure boot, the time it takes from starting the device to linux booting is almost twice as long (around 17 - 18 seconds). I am measuring the startup from plugging in the power, until the solid green light of CM5 IO expansion board stops shining. The issue occurs both when CM5 is plugged into the official CM5 IO expansion board as well as in the target device. Same boot time slowdown occurs no matter if I use a dietpi based system image or Raspberry Pi OS one (issue seems to be system image unrelated but checked just in case).

I use the following provisioner configuration options:
PROVISIONING_STYLE: secure-boot
RPI_DEVICE_BOOTLOADER_CONFIG_FILE: blank
RPI_DEVICE_EEPROM_WP_SET: Enabled
RPI_DEVICE_FAMILY: 5
RPI_DEVICE_FIRMWARE_FILE: {...}/pieeprom-2025-05-08.bin
RPI_DEVICE_LOCK_JTAG: Enabled
RPI_DEVICE_STORAGE_CIPHER: aes-xts-plain64
RPI_DEVICE_STORAGE_TYPE: emmc

I would like to ask if this behavior is expected and is it possible to decrease the boot time slow down?

[stu-spp]

Yes, this is expected.

1. boot.img needs to be verified. (5 seconds?)
2. initramfs must decrypt the rootfs prior to mounting it. (10 seconds?)

I'm not aware of any techniques that can speed up these two items.

[JamesH65]

You can speed this up by making sure your image is as small as possible - create a custom image with only the drivers and applications etc you need to try and reduce the de-compress/de-encrypt times.

[tdewey-rpi]

So, there are a handful of additional tractable steps you can take, but be aware every step takes you further from the well-trodden path:

To speed up the pre-Linux phase:

1. Build a custom kernel with the minimum of drivers & configs set for your device
2. Reduce the number, if any, of dtb overlays & similar files in the boot.img
3. Further audit the boot.img for unnecessary start files
4. Anything you can reasonably do to drive the on-disk size of boot.img to 0

Linux itself:

• Audit your systemd start-up sequence with systemd-analyze
• Use perfetto and friends to study your daemons & programs

[Hubix9]

Hi, thank you very much for the responses.

I've tried decreasing the image size. Went from 6.7 GB to 2.99 GB, the speedup increase was in order of around 1 second. An important note is that I focused on rootfs modifications so I mostly removed unused applications and didn't touch the boot.img at all, nor modified the kernel. Thus probably the rootfs verification only got sped up. The Linux phase is sorted out and system is already usable after around 3 seconds (mostly thanks to the stuff done by dietpi, I didn't really need to do much there).

Will look further into the kernel and boot.img trimming you suggested to drive the boot time down some more.

Thank you very much for the help, if I encounter some issues or have some new findings to share I will post them here.

[tdewey-rpi]

Hi, thank you very much for the responses.

I've tried decreasing the image size. Went from 6.7 GB to 2.99 GB, the speedup increase was in order of around 1 second. An important note is that I focused on rootfs modifications so I mostly removed unused applications and didn't touch the boot.img at all, nor modified the kernel. Thus probably the rootfs verification only got sped up. The Linux phase is sorted out and system is already usable after around 3 seconds (mostly thanks to the stuff done by dietpi, I didn't really need to do much there).

Will look further into the kernel and boot.img trimming you suggested to drive the boot time down some more.

Thank you very much for the help, if I encounter some issues or have some new findings to share I will post them here.

That's about what I'd expect. The size of the rootfs will matter most for provisioning time, but at runtime it's decrypted on-demand (and so is really a function of your cipher & cipher support).

The boot.img, however, is read into RAM from the storage device by a secondary on-chip processor - and while we've tuned this as best we can to make it performant, it's not equivalent to the ARM processors in terms of throughput. Spending your effort in this direction will have a much more tangible impact on time to first draw.