Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Hello! Thank you for your detailed description and questions about Secure Boot behavior with the Verdin iMX8MP. I’ll address each of your concerns based on the latest documentation and best practices:
1. Why does an image from a different build (with the same secure boot keys) sometimes fail to boot from the SD card initially?
Using the same keys ensures the basic signing process is consistent, but Yocto builds can still produce binaries with subtle differences between builds, even if no source or key changes are made. These differences may be due to build timestamps, metadata, or non-determinism in the build process. Secure Boot validates the signed binaries—including metadata—so any small difference might cause the verification to fail, leading to boot issues from the SD card (reference).
2. Does Secure Boot behave differently for booting from SD card vs internal storage?
Yes, there can be subtle differences. While Secure Boot is supported for both SD card and internal eMMC storage, the i.MX8MP SoC boot ROM and U-Boot process might handle image verification slightly differently depending on the boot source. For example, different storage paths can impact how devices are initialized and how the signature checkers are called. However, secure boot should operate reliably on both as long as the images are generated and signed consistently (reference).
3. Is this expected behavior when using different builds (same keys)?
Yes, this can unfortunately be expected, especially if the build system isn’t completely reproducible. Even minimal, undetected differences between builds (such as timestamps or build environment variations) can yield images that are not signed identically, leading to intermittent Secure Boot validation failures (reference).
4. How can we reliably boot new builds (using the same key) directly from SD card in the future?
To make this process as reliable as possible:
- Ensure a consistent build environment: Use deterministic building practices. Running Yocto in a container or well-managed VM (see Yocto container instructions) helps ensure build-reproducibility.
- Check for non-determinism: Examine your Yocto build configuration for variables that could make results change from build to build (e.g., timestamps, version strings).
- Test extensively before fusing keys: Before fusing the SRK hash to the SoC, try several builds and boot them from both SD and eMMC to catch inconsistencies.
- Always verify image signatures: Use tools like
hab_status on the board after flashing to ensure every signed image is accepted before using them for production (troubleshooting guide).
With a fully deterministic build and consistent deployment process, subsequent builds with the same keys should reliably boot from either storage source.
For more troubleshooting tips and details on secure boot scenarios, see the Torizon Secure Boot documentation.
If you have more questions or run into a specific error message, feel free to share the details!
Best regards,
Toradex AI Assistant.
