Torizon Cloud OTA update not applying dtb change with Yocto build

I’m trying out the Torizon Cloud OTA update feature with two paths, one of which isn’t correctly applying the device tree.

My setup is a verdin-imx8mp SOM on an IVY board.

In one path I use TorizonCore Builder to update the device tree using the following tcbuild.yaml:

input:
easy-installer:
local: torizon-docker-verdin-imx8mp-Tezi_7.3.0+build.18.tar

customization:
device-tree:
include-dirs:
- linux/include
- linux/arch/arm64/boot/dts/freescale
custom: linux/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-ivy.dts

output:
easy-installer:
local: torizon-docker-verdin-imx8mp-Tezi_7.3.0+build.CUSTOM

The other path I’m using Yocto to build the 7.3.0 version of toradex-torizon and adding a patch to set “fdtfile=imx8mp-verdin-nonwifi-ivy.dtb\0” in verdin-imx8mp.h

Using TEZI I can load the resulting images from both paths and they work as expected, using the desired device tree.

Then I push both images to the Torizon cloud. I start by re-flashing the eMMC to the base Torizon OS 7 found here then try to update to the modified image. When upgrading to the TorizonCore Builder version things work as expected and the correct device tree is loaded. However, when I try upgrading to the Yocto produced image the device tree from the base image is used.

Is this the expected OSTree behavior? Or am I missing something?

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? :+1: :-1:


This behavior is related to how OSTree handles filesystem updates and device tree management. Let me explain what’s happening with your two approaches.

Understanding OSTree Behavior

OSTree manages multiple bootable filesystem trees within a single partition and delivers updates atomically(1). When OSTree creates a “deployment” for a specific collection of objects that make up a bootable version of the filesystem, it uses a directory of hard links to the objects in the repository(1).

Your Two Approaches

TorizonCore Builder Approach

Your TorizonCore Builder configuration correctly applies the device tree customization:

customization:
  device-tree:
    include-dirs:
      - linux/include
      - linux/arch/arm64/boot/dts/freescale
    custom: linux/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-ivy.dts

This approach uses TorizonCore Builder’s device tree management system, which properly integrates the custom device tree into the OSTree commit(2)(3).

Yocto Approach Issue

When you modify the fdtfile variable in verdin-imx8mp.h through Yocto, you’re changing the U-Boot environment variable that tells U-Boot which device tree file to load. However, this approach may not properly integrate with OSTree’s filesystem management.

Root Cause Analysis

The issue you’re experiencing suggests that your Yocto-built image isn’t properly placing the device tree files in the OSTree-managed filesystem structure, or the U-Boot environment changes aren’t being preserved through the OSTree update process.

OSTree handles directories such as /var and /etc as special cases, providing persistent configuration and preservation of user data(1). However, device tree files and U-Boot environment variables need to be properly integrated into the OSTree commit structure.

Recommended Solutions

  1. Use TorizonCore Builder’s device tree commands: The dt command has subcommands to build and apply custom device trees to devices(2). This ensures proper OSTree integration.

  2. Verify device tree placement: Ensure your Yocto build places the device tree files in the correct location within the OSTree filesystem structure.

  3. Check U-Boot environment persistence: Verify that your U-Boot environment changes are being properly committed to the OSTree repository.

The TorizonCore Builder approach works because it’s specifically designed to handle device tree customizations within the OSTree framework, ensuring that both the device tree files and the necessary configuration changes are properly committed to the OSTree repository.

Best regards,
Toradex AI Assistant.

Greetings @CGFE,

The other path I’m using Yocto to build the 7.3.0 version of toradex-torizon and adding a patch to set “fdtfile=imx8mp-verdin-nonwifi-ivy.dtb\0” in verdin-imx8mp.h

Just to clarify, I assume you are patching the U-Boot source here correct?

If that is the case, then that is the reason for the behavior difference. Keep in mind you are updating the OS only when you perform such an update. You are not updating U-Boot.

The TorizonCore Builder method works by setting fdtfile in the boot script, not in U-Boot. The boot script is part of the OS therefore it gets picked up by OSTree and the subsequent OS update.

In your Yocto method you are patching/changing U-Boot (I assume). Therefore these kinds of changes are not picked up by OSTree which only tracks the OS/root filesystem.

We do have a way to do a bootloader update. But typically we don’t recommend bootloader updates unless there is no other option. Since updating the bootloader is inherently more risky than just updating the OS.

Now my question is, if you have this working with the TorizonCore Builder method, then why are you trying to do it in Yocto as well?

Best Regards,
Jeremias

Hi @jeremias.tx,

To answer your question - yes I’m patching the U-Boot source using a variation of the instructions located here.

I think that the concept of Torizon OS is fantastic and am hoping that in the end we can use it for production. Right now I’m acquainting myself with the concepts and mapping how we might transfer our custom distro meta-layer from previous projects over to Torizon.

Some areas of focus for me right now are how we might provision a production device using TEZI as well as other options. I’m working up to how we can sign the bootloader (and other artifacts) with key(s) stored in an external HSM. I glanced through the NXP HAB document and noticed a section specifically for this but haven’t got to how this integrates with Yocto or TorizonCore Builder for Torizon OS yet (something I’ve previously done for the AM62x on a past project in a custom distro layer).

In a different post it was suggested that to use the TPM functionality for the IVY board Yocto customization would be necessary. I have a feeling there may be other things we have to do in Yocto so I want to be prepared for both paths.

Can you point me to a way to have Yocto “set fdtfile in the boot script, not in U-Boot”?

Can you point me to a way to have Yocto “set fdtfile in the boot script, not in U-Boot”?

Basically you just need to set fdtfile=<device tree filename> here: meta-toradex-torizon/recipes-bsp/u-boot/u-boot-distro-boot/uEnv.txt.in at scarthgap-7.x.y · torizon/meta-toradex-torizon · GitHub

This is essentially what TorizonCore Builder does.

Best Regards,
Jeremias