Typical time to boot to display with Secure Boot enabled

Hi,

What is the typical/expected boot time from cold boot until being able to display something custom on a built in display.
Lets just assume one optimizes their setup in a way where displaying something on screen as early as possible has high priority. Mabye by building plymouth and display drivers into initramfs or similar, you get the point.
But in order to comply with EU CRA and similar then secure boot is implemented.
Lets say the hardware is something like an imx8mp or even some imx95 if that makes significant difference.
Im just fishing for rough numbers for a best case and a typical case. Im only interested in cases where Secure Boot is implemented and enabled.
If there are some ways to speed it up significantly by integrating some kind of hardware modules etc. i’m also interested.

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


Based on the available documentation, I can provide some insights about boot times and display initialization, though specific timing data for secure boot scenarios with iMX8MP/iMX95 is limited in the sources.

Boot Time Reference Points

The documentation mentions that Toradex has achieved impressive boot performance in the past. For context, the Windows Embedded Compact operating system for the Colibri T20 module was able to cold boot in 480 milliseconds(1). This demonstrates Toradex’s focus on boot optimization through techniques like cache performance improvements and concurrent driver loading(1).

Display Initialization Challenges

From community discussions, there are known challenges with early display initialization. One user reported that with a MIPI display using a custom driver on iMX8MM, the display driver probe occurred at 6.49 seconds into boot, but driver enable didn’t happen until 40 seconds when containers started(2). This suggests that without optimization, display initialization can be significantly delayed.

Secure Boot Implementation

The documentation shows that Toradex supports secure boot implementation on iMX8MP using the tdx-signed inherit class and various HAB (High Assurance Boot) configuration parameters(3):

INHERIT += "tdx-signed"
TDX_IMX_HAB_ENABLE = "1"
UBOOT_SIGN_ENABLE = "1"

(3)

The secure boot process involves signing the U-Boot bootloader binary, and enforcement only occurs after fuses are set on the device(3).

Optimization Approaches

For early display output, the documentation suggests:

  1. Initramfs Customization: Using tools like ostree-customize-plymouth.sh to add splash screens to the initramfs for very early boot display(2)

  2. TorizonCore Builder: Creating custom images with optimized boot sequences and driver initialization(2)

  3. Plymouth Integration: TorizonCore uses Plymouth for splash screen management, which is initiated from initramfs early during boot(2)

Current Limitations

The available sources don’t provide specific boot time benchmarks for iMX8MP or iMX95 with secure boot enabled. The timing will depend on factors like:

  • Secure boot verification overhead
  • Display driver complexity
  • Initramfs size and content
  • Hardware-specific initialization requirements

For precise timing data and hardware-specific optimizations for your use case, you may need to conduct testing with your specific configuration.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Greetings @depressed_wizard,

Just to clarify. When you say “secure boot”, are you just referring to having NXP’s high assurance boot (HAB) enabled? Or do you you mean something else?

I’m just asking since “secure boot” can be a very loaded term with many definitions.

If you are just referring to HAB then I imagine the boot time difference is negligible if even noticeable at all compared to not having HAB. The verification that HAB does is very quick, not including the setup steps to program the efuses of course.

In fact on Torizon OS, we already do what you suggest and have a splash screen via Plymouth start as early as the initramfs. With just HAB enabled there’s not really a noticeable difference in the time it takes for the splash screen to be visible.

I don’t have exact numbers at the moment, but it’s comparable to normal boot time without HAB.

Best Regards,
Jeremias

Hi @jeremias.tx and thanks for the fast reply.

When i say secure boot in this specific context i guess what i actually mean is the power-on process from the root of trust to the kernel/initramfs in secure boot context. So verifying each stage is signed and trusted. Im not concerned about boot time measuring in secure boot attestation context and such. Just the chain of trust from root of trust to kernel/initramfs by verifying signatures.

The main reason for asking is that i want to compare some numbers that i currently have from an existing system without dedicated crypto accelerator (non-toradex SoM) against what i could expect from an imx8mp or something similar in that product range-ish.

I get you dont have exact numbers but ballpark estimates would be very helpful.

Or we could turn the question around a bit.

How long time does it take from cold boot power on to splash screen visible in your setup with the described secure boot chain of trust enabled up to and including initramfs image (e.g. initramfs image is also signed and verified) - is it less than 5seconds? Less than 10 seconds? Less than 15 seconds?

Thanks in advance!

Okay so for rough numbers on our Verdin i.MX8MP from a complete powered-off state to seeing the splash screen was in the range of 5-6 seconds.

On the i.MX95 the times are longer like 8-10 seconds. However, I want to note that you should take the i.MX95 numbers right now not too seriously. This hardware platform is still relatively new for us and is still undergoing much optimizations and changes that could greatly affect this number.

Back to the Verdi i.MX8MP there are some considerations and assumptions regarding the value I gave:

  • First of all I tested this with our Torizon OS software. I did this because by default this software configuration from us uses a Plymouth based splash screen that starts from the initramfs. So it was easy to test.
    • That said, Torizon OS is a prebuilt Linux distribution made by us for general use. It is not optimized specifically for boot speed. So in theory this number could be lower.
  • The method of kernel/initramfs security we use is FIT image verification as described here: meta-toradex-security/docs/README-secure-boot.md at scarthgap-7.x.y · toradex/meta-toradex-security · GitHub
    • This method has a very minor effect on this boot time in my observation. If you use a different method to sign/verify the kernel/initramfs then this assumption will likely be different for you of course.
  • The display I used was an HDMI display to show the splash screen, since it was readily available. Some displays like HDMI displays have to be “woken up” when they receive a video signal. This means it’s likely the 5-6s I cited above is actually longer because it took a second or two for my HDMI display to wake up and actually show the splash screen. So your experience may vary depending on the display interface and actual display used.

Best Regards,
Jeremias

Alright that answers my questions, thanks a lot

1 Like

Glad i was able to help.

Best Regards,
Jeremias

This is perhaps a bit stale, but I’d like to add that Michael Olbrich from Pengutronix had a talk on this topic at the recent Open Source Summit in Amsterdam, and the recording is available: https://osseu2025.sched.com/event/25Vso/the-cost-of-security-measuring-and-reducing-boot-time-impact-michael-olbrich-pengutronix

His tests were not on Toradex hardware, but it was a board with an i.MX8M Plus SoC, so it should be pretty comparable.

One really important note: the crypto “accelerator” on the i.MX8 modules is the CAAM, which in actual fact is significantly slower than the hardware-optimized software implementations for most algorithms. The CAAM is still useful for various things, but if you’re optimizing for speed you generally want to look elsewhere.