T Cloud update overwrites overlays.txt

Technical Support
, ,
1

I’m looking into updating our application to Torizon OS from a Yocto-based build.

Our application uses DSI-HDMI and RPMSG each of which requires an overlays in the overlays.txt file.

However it seems the the Torizon Cloud OS update also updates the overlays.txt file, and resets it to fdt_overlays=colibri-imx8x_vga-640x480_overlay.dtbo.

Actually it’s a bit of a disaster, since the M4 runs firmware to start the RPMSG, but without the overlay, it causes Linux to reboot.

This might be okay if it were only for the new OS, but the previously running OS has it’s overlays.txt replaced too! When the new OS fails to launch, and we roll back to the old OS, it also fails to launch and is left in a continuous reboot cycle.

How should these overlays be specified, so that they remain intact when the OS is updated ? IIUC they are loaded by U-Boot, so I guess they could be specified in that environment. But then, would this be overridden by the overlays.txt ? Or can that be nixed from U-Boot ?

TIA

2

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:

Device Tree Overlay Persistence with Torizon OS Updates

You’ve identified a critical issue with device tree overlays being reset during OTA updates. The solution is to use TorizonCore Builder for production deployments rather than manually modifying the overlays.txt file.

The Problem with Manual overlays.txt Modifications

The approach of manually editing overlays.txt is intended for evaluation and prototyping only (1). When you manually modify this file, OTA updates will reset it because the file is part of the OS image being updated.

Recommended Production Solution: TorizonCore Builder

For development and production, you should use TorizonCore Builder to build custom Torizon OS images with your required overlays pre-configured (2).

Step 1: Install TorizonCore Builder

Follow the installation steps for TorizonCore Builder (2).

Step 2: Create a Configuration File

Create a tcbuild.yaml file that specifies your required overlays (2):

input:
  easy-installer:
    local: torizon-core-docker-colibri-imx8x-Tezi_X.X.X+build.X.tar

customization:
  device-tree:
    include-dirs:
      - device-trees/include/
    overlays:
      add:
        - device-trees/overlays/colibri-imx8x_dsihdmi_overlay.dts
        - device-trees/overlays/colibri-imx8x_hmp_overlay.dts

output:
  easy-installer:
    local: torizon-core-docker-colibri-imx8x-Tezi_CUSTOM

(2)

Step 3: Clone Required Repositories

Get the device tree source files (2):

$ git clone -b toradex_6.6-2.2.x-imx git://git.toradex.com/linux-toradex.git linux
$ git clone -b toradex_6.6-2.2.x-imx git://git.toradex.com/device-tree-overlays.git device-trees

(2)

Step 4: Build Your Custom Image

$ torizoncore-builder build

(2)

Available Pre-enabled Overlays

For Colibri iMX8X, the following overlays are pre-enabled by default (3):

Module Supported Peripherals Overlays
Colibri iMX8X VGA colibri-imx8x_vga-640x480_overlay.dtbo

Available Overlays for Your Use Case

Based on your requirements, these overlays are available (3):

  • DSI to HDMI: colibri-imx8x_dsihdmi_overlay.dtbo (3)
  • HMP (RPMSG): colibri-imx8x_hmp_overlay.dtbo (3)

Why This Approach Works

When you build a custom image with TorizonCore Builder:

  1. The overlays are permanently integrated into the custom OS image
  2. OTA updates using your custom image will maintain the overlay configuration
  3. Rollbacks will work correctly because both old and new images have the same overlay configuration
  4. You avoid the continuous reboot cycle you’re experiencing

Emergency Recovery

If you need to disable overlays temporarily (for recovery), you can set the U-Boot environment variable skip_fdt_overlays to 1 (1):

setenv skip_fdt_overlays 1
boot

(1)

This approach ensures your critical overlays (DSI-HDMI and RPMSG) remain intact through OTA updates and rollbacks, preventing the reboot cycle you’re experiencing.

Best regards, Toradex AI Assistant.

1 Like
3

Greetings @Timo,

I see you marked the AI’s response as the solution. Did the AI resolve all your questions/concerns, or did you have further questions?

Just to add, the AI’s response seems fairly accurate. Device tree overlay information is part of the metadata of the OS update. When you do an OS update it uses the overlays for that specific OS package.

Therefore if you want the overlays to remain the same throughout OS updates, you need to make sure the OS package you are updating to has the same overlays set in it’s metadata.

Best Regards,
Jeremias

4

Hi @jeremias.tx,

I see you marked the AI’s response as the solution. Did the AI resolve all your questions/concerns…?

Yes – I think it was very polite saying RTFM :smiley: I was in the mindset of independent docker updates…

Device tree overlay information is part of the metadata of the OS update

Of course this makes perfect sense – indeed we need to distribute a custom device tree in any case, so we should just add the overlays to that.

We will almost certainly proceed using full system images for remote updates, since they will need to be tested as such in any case.

All the best,

Tim

5

Glad you were able to get some clarification on this topic then.

Best Regards,
Jeremias