DTB_PREFIX bleeds into FIT config names when using secure boot on scarthgap

Technical Support
1

Hello everyone, I encountered an odd boot problem on the Colibri iMX6DL with Scarthgap when I enabled secure boot (UBOOT_SIGN_ENABLE = “1”).

Boot always failed with “Could not find configuration node” because the boot script was searching for conf-nxp_imx_imx6dl-colibri-eval-v3.dtb in the FIT image, but the FIT image only contained conf-imx6dl-colibri-eval-v3.dtb.

After some research, I discovered that KERNEL_DTB_PREFIX = “nxp/imx’” (set in colibri-imx6.inc) is changed to nxp_imx_ and then replaced into KERNEL_DTB_PREFIX in boot.cmd.in via DTB_PREFIX. The FIT image configuration names never contain the prefix, even though the boot script expects them to since the deployed DTBs do not maintain the subdirectory path.

Setting DTB_PREFIX = " in local.conf is a solution that adjusts the boot script without interfering with kernel DTB compilation.

Only with secure boot does this appear. The mismatch is never hit without it.

Affected: Scarthgap-7.x.y, Colibri iMX6DL, secure boot enabled
DTB_PREFIX = ““ in local.conf is a workaround.

2

Hi, I’m the Toradex AI Assistant.

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

I can help troubleshoot this secure boot issue with the DTB prefix mismatch on Colibri iMX6DL. To provide the most accurate guidance, could you specify:

  • Which exact version of Torizon OS or BSP are you running?
  • Are you using Yocto BSP or Torizon OS for your build?

This information will help me provide platform-specific guidance for resolving the DTB_PREFIX configuration issue you’re experiencing with secure boot.

You can get this information by running the tdx-info command on your device. For more details about this command, see: Getting Device Information with Tdx-Info | Toradex Developer Center

Common Platforms:

  • Hardware: Verdin i.MX8M Plus, Verdin AM62, Aquila AM69, Apalis i.MX8QP, Colibri i.MX8X, Ivy Carrier Board, Ixora Carrier Board, Mallow Carrier Board, IMX95
  • OS: Yocto 7.2.0, Torizon 6.8.2, Torizon OS 6, BSP 7, BSP 6, Torizon OS 7.2.0-build.13
  • Integration: Device tree, gpio, spi, can, hdmi, display, camera, recovery mode, device driver, kernel patch, ethernet, rpmsg, lvds

Once I have your platform details, I can provide specific guidance on configuring secure boot properly for your Colibri iMX6DL setup and address the DTB_PREFIX bleeding issue you’ve identified.

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.

3

Greetings @ruben_m123,

Are you using our security-based meta-layer to enable this?: GitHub - toradex/meta-toradex-security · GitHub

The images built with this do have conf-nxp_imx_imx6dl-colibri-eval-v3.dtb in the final FIT image. Perhaps you changed something in your meta-layer to affect the naming of the FIT image nodes?

Best Regards,
Jeremias

4

Hi Jeremias,

Yes, we are using meta-toradex-security. Despite that, our FIT image is still producing conf-imx6dl-colibri-eval-v3.dtb instead of conf-nxp_imx_imx6dl-colibri-eval-v3.dtb.

We include colibri-imx6.inc, which sets KERNEL_DTB_PREFIX = “nxp/imx/”. One thing that might be interfering is how we prune the device tree list. We are currently using:
KERNEL_DEVICETREE:remove = "imx6dl-colibri-cam-eval-v3.dtb imx6dl-colibri-aster.dtb imx6dl-colibri-v1.2-aster.dtb imx6dl-colibri-v1.2-eval-v3.dtb imx6dl-colibri-v1.2-iris.dtb imx6dl-colibri-v1.2-iris-v2.dtb"

I noticed that our remove list lacks the “nxp/imx/” prefix defined in the include file. Could this mismatch in the KERNEL_DEVICETREE variable be causing something to strip the prefixes from the remaining entries during the build process? I’ll test adding the prefix to the remove list and report back when possible.

Best regards,
Ruben

5

Do let us know if you figure out what change or customization on your end is causing this behavior. Right now I can’t think of a clear cause at the moment.

It might help to do a completely default unmodified build just to make sure the behavior is consistent with what we observe on our end. At least as a sanity-check of sorts.

Best Regards,
Jeremias