How to manually deploy bootfs.tar.xz?

Technical Support
, ,
1

Hi,

I am using the verdin iMX8MP v1.1B SoMs on a custom carrierboard (very similar to the dev board).
As we are not able to use Torizon OS yet, I have been working on a way to build our Yocto image (based on the minimal reference image) with swupdate layer (as this was quickest to initially implement).

I have the tools and update process looks good with deploying everything needed (at least visually).

However, I am not getting any of the device-tree or kernel modules loading.
I am currently extracting a “bootfs.tar.gz” archive into the mounted vfat partition (mmcblk2p1).
It all looks like everything is there and I have no issues reading the files.
But I cannot get anything to load properly.

The biggest sign is the hwmon stuff which is not present at all when booting the new image (apparently everything is “waiting_for_supplier”, and thus not actually loaded.
My app requires these to display device dashboard for SoM temps and things, but everything is blank.

I was wondering if there was a special format or way to deploy this bootable image?
Maybe I am doing something wrong.

I tried using the “image” type in swupdate, but that fails to leave the partition configured as a FAT one.
I am currently using the “files” definition that allows me to mount the existing partition as FAT and extract the archive into the partition.

Any help or pointers would be greatly appreciated as I am supposed to be delivering my first software update package on Monday morning and I am now out of ideas.

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:

Hello! Thank you for providing detailed information about your setup and deployment process.

Based on your description, the main issue is that device trees and kernel modules are not loading after updating your system with SWUpdate, even though the files appear to be present on the boot partition. This is a common challenge when manually managing the boot partition content. Below are some focused steps and considerations to help ensure your device tree and overlays are correctly deployed and loaded:

1. Boot Partition Layout

The Linux kernel and U-Boot expect a very specific structure for device tree binaries (.dtb) and overlays on the boot (VFAT) partition. If this structure is not respected, device tree and overlays will not load, leading to issues like missing hwmon interfaces and drivers reporting “waiting_for_supplier”.

Checklist:

  • Ensure your .dtb file for the SoM is present directly in the root of the boot partition.
  • Device tree overlays (.dtbo) should be inside an overlays/ subdirectory in the boot partition.

2. overlays.txt Configuration

  • There must be an overlays.txt file in the boot partition root.
  • overlays.txt should contain a valid entry referencing your required overlays, for example:
    fdt_overlays=verdin-imx8mp_my_overlay.dtbo another_overlay.dtbo
    (multiple overlays are listed space-separated)

Further info:

3. Ensure Proper Extraction and File Formats

When extracting your bootfs.tar.gz:

  • Preserve directory structure, especially ensuring .dtbo files end up in overlays/.
  • FAT32 is the correct format; make sure no hidden file system corruption occurs during the extraction.

4. Kernel and U-Boot Configuration

  • The kernel used must match the device tree (i.e., be built for the correct hardware revision/model).
  • Double-check your kernel and U-Boot version compatibility with your device tree files.

5. Yocto/Production Integration

For Yocto builds, use the variable TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT to ensure your custom overlays are included correctly and applied during boot time.

More info:

6. Compare with a Working Boot Partition

As a reference, you can take a look at the boot partition from a working Tezi or Reference Multimedia image for iMX8MP. Compare the structure, file names, and overlays.txt usage.

Quick Troubleshooting Tips

  • From U-Boot, check if it finds and loads the correct .dtb and overlays by reviewing boot log messages.
  • Ensure CONFIG_OF_OVERLAY is enabled in your kernel configuration for overlay support, if you use overlays.
  • If using swupdate, make certain that file permissions and names remain unchanged by the packaging/extraction process.

If you ensure the above aspects are in place, your system should properly load device tree, overlays, and kernel modules, restoring hwmon and other hardware features necessary for your application.

Best regards,
Toradex AI Assistant.

3

Hi @izzy_building!

The answer by the Toradex AI is reasonable and a good starting point.

I’m not familiar with SWUpdate, since it is a third-party tool and not supported by Toradex.
However, to deploy the Kernel, you should copy the zImage (Kernel image) to /boot. Regarding the Kernel modules, you should use the command make modules_install INSTALL_MOD_PATH=<path-to-install-modules>, which will create a folder with your modules within, then you might compress it (using tar command, for example) and copy it to the Verdin. After that, you can decompress it in the root folder of the SoM (the / folder).

Regarding the overlays, you can follow the steps given by the Toradex AI.

These steps should be enough to deploy all the content of the bootfs.tar.xz.

Best regards.

4

I forgot to mention that my build uses the meta-traded-security layer to add secure-boot and signed rootfs.

It turns out that the bootfs image can just be extracted into the relevant vfat partition. The problem I had needed up being caused do to sstate. I have to clean the sstate and everything built and worked without issues. I only discovered this because I eventually gave up and just flashed the tezi image directly to the board and found that the SoM failed in the same way.

Is there something in yocto that can mark related recipes? As I’m sure the kernel and device tree and config recipes should all cause all of them to be rebuilt.

For now note to self: Always clean sstate for the kernel connected recipes.

For future reference…
In the case of swupdate the bootfs archive should be put under the files group (not images) with the device, path and format specified. I was unable to get the bootfs.tar.xz to work even after adding support for xz. So I have added bootfs.tar.gz to ensure that gets built. You will probably want to add a preinstall script to format the partition first to make sure you copy files into a clean partition (I also had issues on random SoMs if I didn’t do this).

Also, for swupdate on a verdin imx8mp, it seems we need to put an offset of zero for the imx-boot file to one of the bootloader “reserved” partitions. I started with a value of 33K based on reading a lot of online examples.
As a note, you can check the image.json in the tezi image to check what values you need.

5

Hi @izzy_building and @izzycoding!

As far as I understood, you managed to solve the problem, right? If so, I’m glad to know that, and please mark your answer as a solution.

Besides, I’m not sure if there is a tool in Yocto to mark related recipes, but I’m pretty sure that if it exists, it is documented in their documentation.

Best regards.

6

Hi @lucas_az.tx ,

Indeed I have resolved this issue.

For swupdate always put the bootfs under files and have a preinstall script to format the partition first.

If using the meta-toradex-security layer with signed rootfs, then you also should ensure clean sstate before building as the sstate can cause the output image to be corrupt.

Regards,
Izzy

1 Like