Subject: Issues After Migrating Yocto/BitBake Build to Scarthgap (Boot2Qt/Qt 6.8.4 / Toradex Apalis iMX8)

Romain.Donze · July 15, 2025, 2:52pm

Hi everyone,

We’re currently working on a custom embedded Linux setup based on Yocto and BitBake for our Toradex Apalis iMX8QP-based project, and we’ve hit a few bumps during our recent migration. I’d like to share the details here in case anyone else has encountered similar issues or can provide guidance.

Background

We’ve been maintaining a custom Yocto meta-layer, which includes RTC, GPIO power-off support and other things. This setup has been working reliably on earlier versions — including Boot2Qt 6.8 and the Kirkstone Yocto release.

We’ve now updated our system to Boot2Qt 6.8.4 LTS, which brings in the Scarthgap Yocto release and Linux kernel 6.6.84 from Toradex BSP 7. I updated our meta-layer accordingly, and while the build process completes without errors, we’re experiencing several issues at runtime on our hardware.

Hardware In Use

Apalis iMX8QP WB V1.0B on Ixora V1.2A
Apalis iMX8QP V1.1D on Ixora V1.2A

Issues Observed

1. U-Boot: Device Tree Selection Fails (V1.0B board)

The boot process halts in U-Boot with: Failed to load 'imx8qp-apalis-eval.dtb'
I have to manually run: setenv fdtfile imx8qm-apalis-ixora-v1.1.dtb
to continue booting.

2. U-Boot: Wrong Default Device Tree (V1.1D board)

The board boots with: Loading DeviceTree: imx8qp-apalis-v1.1-eval.dtb
This works, but to select the correct DT for our setup, I have to manually run: fw_setenv fdtfile imx8qp-apalis-v1.1-ixora-v1.2.dtb

3. Missing Device Trees in /boot (both boards)

Previously (on Kirkstone), /boot listed all available .dtb files. We relied on this to choose the correct DT during deployment via our gui application.
With Scarthgap, /boot no longer contains these files, making selection at runtime more difficult.

4. GPIO Power-Off Overlay Not Working

U-Boot prints: Applying Overlay: apalis-imx8_gpio-poweroff_overlay.dtbo
However, the actual GPIO power-off behavior doesn’t function anymore.

5. RTC Overlay Appears OK

U-Boot correctly applies: Applying Overlay: apalis-imx8_rtc-rv8803_overlay.dtbo
And dmesg | grep rtc shows the RTC driver is loaded: rtc-rv8803 4-0032: registered as rtc0

My Questions

Has anyone successfully dealt with similar U-Boot device tree loading issues when upgrading to Scarthgap?
Is it expected that /boot no longer lists DTB files in newer Boot2Qt/Scarthgap builds?
Has the handling of overlays — especially GPIO-related ones — changed significantly?
Do these symptoms suggest a minor misconfiguration or a more involved migration effort from Kirkstone to Scarthgap?

Any insights, tips, or examples would be greatly appreciated!

I am also joining the repo manifest used for this build and the recipes-kernel with the overlays.

Thanks in advance,
Romain

recipes-kernel.zip (7.5 KB)
v6.8.4-lts.xml (3.0 KB)

ToradexAI · July 15, 2025, 2:54pm

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 Romain,

Thank you for your detailed post outlining your current migration challenges from Yocto Kirkstone to Scarthgap on your Apalis iMX8QP platforms. This kind of comprehensive info makes troubleshooting much easier. I’ll address each of your main points and questions below:

1. U-Boot Device Tree Selection Issues

The U-Boot variable fdtfile determines which DTB file is loaded at boot and its value depends on SoM revision, carrier board, and EEPROM data. In your V1.0B board case, U-Boot tries to load imx8qp-apalis-eval.dtb, which does not exist; the manual override with imx8qm-apalis-ixora-v1.1.dtb works.

For V1.1D, the default is imx8qp-apalis-v1.1-eval.dtb, and you override it to imx8qp-apalis-v1.1-ixora-v1.2.dtb for your particular setup.

This DTB selection is based on logic in U-Boot that reads board/EEPROM information (U-Boot variables reference). If your hardware variant or carrier board is not fully auto-detected, or if the set of DTB files changed in the BSP, you may see these issues.

Tip: Running printenv fdtfile in U-Boot will show you exactly what is selected. You can persist your override using fw_setenv as you have done.

2. Missing Device Trees in /boot

With Scarthgap and Boot2Qt 6.8.4, it is normal to see /boot not containing all DTB files. This is a change both in Toradex’s BSP 7 (Linux kernel 6.6.84) and commonly in new Boot2Qt packaging. Typically, only the device tree(s) for the current hardware and overlays are installed to save space and reduce confusion.

If your runtime application requires the full set of DTBs in /boot, you will need to modify your Yocto recipes to package and install more DTBs in that location. This is usually done by appending to the do_install task in the kernel or a custom recipe.

3. Handling of Overlays (Especially GPIO-Related)

Overlay handling has evolved from Kirkstone to Scarthgap. It’s crucial to update your overlays for compatibility with the BSP’s new kernel version (device-tree-overlays reference). Even small differences in the base trees or driver bindings can break legacy overlays. GPIO handling, in particular, sometimes changes between kernel versions.

A few checks:

Make sure your .dtbo is built against Linux 6.6.84’s device tree sources.
Validate the overlay syntax and update any deprecated properties.
Compare your overlay with current examples from Toradex’s device-tree-overlays repository (examples).
Test disabling faulty overlays temporarily by setting skip_fdt_overlays=1 in U-Boot to confirm if overlay loading is the only cause (skip_fdt_overlays).

4. Migration Scope: Minor or Major?

Your described issues are common when experiencing a BSP, kernel, and Yocto branch bump simultaneously. While some device tree naming/packaging issues are minor (solved by adjusting fdtfile and kernel recipes), overlay breakage can sometimes require deeper investigation, especially around GPIO, as kernel APIs may have changed, requiring you to adapt the overlay itself.

So the migration effort could range from updating a few recipes to reworking your overlays for the new kernel (and checking for renamed/added/removed device tree nodes/properties).

Recommendations

U-Boot device tree issues: Adjust your deployment scripts or persistent U-Boot environment (fw_setenv fdtfile ...) for your hardware setup. Double-check which DTBs are actually installed in /boot.
Missing DTB files in /boot: Update your recipe(s) to install any required DTBs alongside the expected one.
Review and rebuild overlays: Confirm overlay sources match kernel version and base device tree changes. Rebuild if needed, referencing official overlay examples.
Test with overlays skipped: To isolate overlay issues, set skip_fdt_overlays=1 in U-Boot.

If you provide your overlay source file(s) and Yocto recipe snippets, I could suggest specific changes to bring your GPIO power-off overlay up to date.

Feel free to share additional details if you’d like more tailored suggestions!

Best regards,
Toradex AI Assistant.

(U-Boot variables reference)
(Device tree overlays reference & examples)

Romain.Donze · July 15, 2025, 5:19pm

@ToradexAI
/boot is not empty because of missing installed package. it is empty because the boot bartition is simply not mounted there. It appears to be mounted in /run/media/BOOT-mmcblk0p1 instead. The same place where any usb key will be mounted automatically

leonardo.costa.tx · July 15, 2025, 7:12pm

Hey, @Romain.Donze!

About the device tree selection for the Apalis iMX8QP V1.0B: We are actually aware of the booting failure for this specific board version, and we’re investigating it currently.
About the wrong device tree for the Ixora: There is no way for the SoM to check which carrier board it’s connected to, thus we make our images utilize the SoMs’ evaluation board device tree by default. You can add a .bbappend to the u-boot recipe on our BSP to load Ixora device tree instead, such as shown in this page.
From what I understood, the /boot directory is not present, and the boot partition is mounted to /run/media/BOOT-mmcblk0p1. I don’t think this is expected, our BSP and Boot2Qt images contain the /boot directory with the device trees. How exactly are you building your Yocto images? Can you provide more details on how you are implementing our BSP?
The overlay not working could be due to an incompatibility with the Ixora device tree that was not present when you used the evaluation board device tree. Can you provide more details on your overlay?

Let me know if any of this info was helpful. If you can provide more details on your Yocto build, I’ll try investigating further.

Best regards,

Romain.Donze · July 15, 2025, 7:54pm

Hi @leonardo.costa.tx, thanks for the answer

For the missing device tree issue, I think I might have find a workaround for now, I am simply adding two dts file (imx8qp-apalis-eval.dts and imx8qp-apalis-ixora-v1.1.dts) wich are plain copy of imx8qm-apalis-eval.dts and imx8qm-apalis-ixora-v1.1.dts. I think the root issue is uboot not being able to find any imx8qp device tree (since it should be redirected to imx8qm when the version is v1.0)
The fact that eval board is choosen by default is not a real problem for me since we are setting it later manually with fw_setenv (hence the need of /boot)
In fact, yes, /boot is present. It is simply not used in any way. Absolutely your Boot2Qt image here, Qt for Device Creation (Boot to Qt) | Toradex Developer Center have a correct mount in /boot. but those images are built with kirkstone branch. And as said in my OP we had no issue with kirkstone (up to Qt 6.8.3). I also tested with the Boot2Qt 6.8.4-lts image provided by the Qt online-installer. But I still have this issue where /boot is not mounted properly, so the issue seems to come from scarthgap.

4.I don’t think the issue with the overlay not working comes from the device-tree issue since once I set it with fw_setenv, it should work in that case.
The goal of this overlay is to configure a gpio to work as poweroff output to be able to shutdown properly the system. The overlay can be found in the recipes-kernel I joined in my OP

apalis-imx8_gpio-poweroff_overlay.dts

// SPDX-License-Identifier: GPL-2.0-or-later OR MIT

// GPIO power off handling
#include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;

/ {
	compatible = "toradex,apalis-imx8", "toradex,apalis-imx8-v1.1";
};

&{/} {
	gpio_poweroff: gpio-poweroff {
		compatible = "gpio-poweroff";
		gpios = <&lsio_gpio4 2 GPIO_ACTIVE_LOW>;
		timeout-ms = <3000>;
		priority = <1>;
	};
};

Regards,
Romain

Romain.Donze · July 16, 2025, 7:19am

About the gpio-poweroff issue, I found out that from kirkstone to scarthgap libgpiod has gone from v1.6 to v2.1 and when doing ‘gpioinfo’ on my two distro I don’t have the same output

In kirkstone I have this output:

root@b2qt-apalis-imx8:~# gpioinfo gpiochip6
gpiochip6 - 32 lines:
	line   0:    "MXM3_18"       unused   input  active-high 
	line   1: "MXM3_11/GPIO5" "interrupt" input active-high [used]
	line   2: "MXM3_13/GPIO6" "gpio-poweroff" output active-low [used]
	line   3:   "MXM3_274"       unused   input  active-high 
	line   4:    "MXM3_84" "regulator-usb-host-vbus" output active-high [used]
	line   5:   "MXM3_262"       unused   input  active-high 
	line   6:    "MXM3_96"       unused   input  active-high 
	line   7:      unnamed       unused   input  active-high 
	line   8:      unnamed       unused   input  active-high 
	line   9:      unnamed       unused   input  active-high 
	line  10:      unnamed       unused   input  active-high 
	line  11:      unnamed       unused  output  active-high 
	line  12:   "MXM3_190"       unused   input  active-high 
	line  13:      unnamed       unused   input  active-high 
	line  14:      unnamed       unused   input  active-high 
	line  15:      unnamed       unused   input  active-high 
	line  16:   "MXM3_269"       unused   input  active-high 
	line  17:   "MXM3_251"       unused   input  active-high 
	line  18:   "MXM3_253"       unused   input  active-high 
	line  19:   "MXM3_295"       unused   input  active-high 
	line  20:   "MXM3_299"       unused   input  active-high 
	line  21:   "MXM3_301"       unused   input  active-high 
	line  22:   "MXM3_297"       unused   input  active-high 
	line  23:   "MXM3_293"       unused   input  active-high 
	line  24:   "MXM3_291"       unused   input  active-high 
	line  25:   "MXM3_289"       unused   input  active-high 
	line  26:   "MXM3_287"       unused   input  active-high 
	line  27:      unnamed     "enable"  output  active-high [used]
	line  28:      unnamed       unused   input  active-high 
	line  29:      unnamed       unused   input  active-high 
	line  30:      unnamed       unused   input  active-high 
	line  31:      unnamed       unused   input  active-high

And in scarthgap I have this output:

gpiochip4 - 32 lines:
	line   0:	"MXM3_18"       	input
	line   1:	"MXM3_11/GPIO5" 	input
	line   2:	"MXM3_13/GPIO6" 	output active-low consumer="gpio-poweroff"
	line   3:	"MXM3_274"      	output
	line   4:	"MXM3_84"       	output consumer="regulator-usb-host-vbus"
	line   5:	"MXM3_262"      	input
	line   6:	"MXM3_96"       	input
	line   7:	unnamed         	input
	line   8:	unnamed         	input
	line   9:	unnamed         	input
	line  10:	unnamed         	input
	line  11:	unnamed         	input
	line  12:	"MXM3_190"      	input
	line  13:	unnamed         	input
	line  14:	unnamed         	input
	line  15:	unnamed         	input
	line  16:	"MXM3_269"      	input
	line  17:	"MXM3_251"      	input
	line  18:	"MXM3_253"      	input
	line  19:	"MXM3_295"      	input
	line  20:	"MXM3_299"      	input
	line  21:	"MXM3_301"      	input
	line  22:	"MXM3_297"      	input
	line  23:	"MXM3_293"      	input
	line  24:	"MXM3_291"      	input
	line  25:	"MXM3_289"      	input
	line  26:	"MXM3_287"      	input
	line  27:	unnamed         	output consumer=enable
	line  28:	unnamed         	input
	line  29:	unnamed         	input
	line  30:	unnamed         	input
	line  31:	unnamed         	input

It looks like the gpiochip went from 6 to 4. It is also strange that my overlay works on lsio_gpio4 even though gpioinfo list it under gpiochip6 for the kirkstone release. But even like that it was working fine on the kirkstone release but not the scarthgap one

Has there bin any changes within the device-tree concerning gpios?

Romain.Donze · July 16, 2025, 7:23am

Concerning the /boot issue, here the the output of some ls and df command in both kirkstone and scarthgap image

kirkstone: Boot2Qt_6.8.3.txt (4.1 KB)
scarthgap: Boot2Qt_6.8.4-lts.txt (3.0 KB)

Edit: After further inspection, I think the problem is due to the bootpart-automount.rules not firing correctly despite it being present in /etc/udev/rules.d/ and /etc/udev/scripts/toradex-mount-bootpart.sh is also present. So I don’t know why this doesn’t work

I also try to list the udev logs with journalctl -b -u systemd-udevdand it gives me:
Jul 16 14:34:15 b2qt-apalis-imx8 (udev-worker)[249]: mmcblk0p1: Process '/etc/udev/scripts/toradex-mount-bootpart.sh' failed with exit code 1.

So I added some logs in toradex-mount-boot.sh to find out what is going on:
Here is the updated sh file:
toradex-mount-bootpart.sh (2.3 KB)

And here is the output it gives:

=== Wed Jul 16 15:13:35 CEST 2025 ===
UID: 0
User: root
Groups: root
Effective capabilities:
CapInh:	0000000000000000
CapPrm:	000001f7fdffffff
CapEff:	000001f7fdffffff
CapBnd:	000001f7fdffffff
CapAmb:	0000000000000000
SELinux context (if any):
N/A
Extracted BASEUUID: eeecaa21
Resolved BOOTPART: /dev/mmcblk0p1
Current DEVNAME: /dev/mmcblk0p1
DEVNAME matches BOOTPART – proceeding with mount setup
Computed MOUNTNAME: BOOT-mmcblk0p1
Final MOUNTPOINT: /run/media/BOOT-mmcblk0p1
BASE_INIT: 
Using legacy mount
Automount flag file exists. Mounting...
/bin/mount -o bind /run/media/BOOT-mmcblk0p1 /boot
mount: /boot: permission denied.
       dmesg(1) may have more information after failed mount system call.
Mount command executed with status 32

So I tried to manually run:
/bin/mount -o bind /run/media/BOOT-mmcblk0p1 /boot as it is done in the scripts and it works fine. So I don’t understand why the scripts fails to do it

leonardo.costa.tx · July 16, 2025, 1:15pm

Hey, @Romain.Donze,

From what I understood, you are building a Boot2Qt using only our BSP kernel. I investigated a bit further, and we do not follow strictly the Boot2Qt updates in our BSPs. Thus, some incompatibility issues can arise when upgrading to a new version of Boot2Qt, I suspect that might be the reason for both the /boot directory and device tree overlays. As a sidenote, I built our BSP Reference Minimal Image for confirmation, and the /boot directory and device trees are present.

While we’re glad to assist where we can, this particular setup goes beyond our usual support resources, and it could take too much time for us to investigate it, possibly delaying your project. For your use-case, our Qt Partners can offer hands-on assistance tailored to your application.

We can also point you to a partner that fits your project, so let me know in case you need it.

Best regards,

Romain.Donze · July 16, 2025, 1:18pm

Hi @leonardo.costa.tx

Could you please just have a look at my last message (edited) because the /boot issue might be linked to toradex more than Qt

Romain.Donze · July 16, 2025, 2:36pm

Also about my gpio-poweroff overlay the issue might be due to some changes in device trees between kirkstone and scarthgap branches (I don’t see any reason for this issue to be Boot2Qt related).

Do you think those changes could affect my overlay as you can see it in my previous posts?

I would be happy enough for now if we can come up with a fix for this bug as the other problems can be worked around more easily.

The goal of this overlay, if not clear, is to use the gpio6 of the apalis module (mxm_13) to power off the ixora power supply through the force_off pin. (Yes this was working with kirkstone so it is not a hardware issue)

leonardo.costa.tx · July 16, 2025, 7:02pm

Hey @Romain.Donze,

I talked with the R&D team and we investigated further on the boot script you provided, and experimented with our BSP image. Take a look at this section from the script you provided:

	BASE_INIT="$(readlink -f "@base_sbindir@/init")"
	INIT_SYSTEMD="@systemd_unitdir@/systemd"

It seems that these variables were not substituted during your Yocto build. Switching the toradex-mount-bootpart.sh file in our reference image for yours gave out the same output as you described, and the /boot also came out empty. Try substituting your file for this one: toradex-mount-bootpart.sh (2.3 KB)

About the device tree overlay, it is possible that some change in the device tree affected your overlay. Since this thread is focused more on the issue with the boot directory, can you open another one regarding your device tree overlay? I’m already investigating and I’ll try helping you further there.

Let me know if the script I sent you works.

Best regards,

Romain.Donze · July 17, 2025, 5:37am

Hi @leonardo.costa.tx

Thanks for the reply, you are right about the base_sbindir and systemd_unitdir variables. those are correctly provided by the yocto build, I must have missed that part when adding messages to the script (I directly updated manually the script under /etc/udev/scripts on my device)

Now that I use your fix the result is different but still not working. The log output is

root@b2qt-apalis-imx8:~# cat /tmp/toradex-mount-debug.log
=== Thu Jul 17 07:31:38 CEST 2025 ===
UID: 0
User: root
Groups: root
Effective capabilities:
CapInh:	0000000000000000
CapPrm:	000001f7fdffffff
CapEff:	000001f7fdffffff
CapBnd:	000001f7fdffffff
CapAmb:	0000000000000000
SELinux context (if any):
N/A
Extracted BASEUUID: eeecaa21
Resolved BOOTPART: /dev/mmcblk0p1
Current DEVNAME: /dev/mmcblk0p2
DEVNAME does not match BOOTPART – skipping mount
=== Thu Jul 17 07:31:38 CEST 2025 ===
UID: 0
User: root
Groups: root
Effective capabilities:
CapInh:	0000000000000000
CapPrm:	000001f7fdffffff
CapEff:	000001f7fdffffff
CapBnd:	000001f7fdffffff
CapAmb:	0000000000000000
SELinux context (if any):
N/A
Extracted BASEUUID: eeecaa21
Resolved BOOTPART: /dev/mmcblk0p1
Current DEVNAME: /dev/mmcblk0p1
DEVNAME matches BOOTPART – proceeding with mount setup
Computed MOUNTNAME: BOOT-mmcblk0p1
Final MOUNTPOINT: /run/media/BOOT-mmcblk0p1
BASE_INIT: /usr/lib/systemd/systemd
Using systemd-mount
Automount flag file exists. Mounting...
/usr/bin/systemd-mount --no-block -o silent -o bind /run/media/BOOT-mmcblk0p1 /boot
Failed to start transient mount unit: Unit boot.mount was already loaded or has a fragment file.```

Romain.Donze · July 17, 2025, 6:15am

Got it !!!

Apparently something is interfering with the script (being boot.mount is already in use somewhere)

So I tried to find it with systemctl status boot.mount and it gave me this result:

root@b2qt-apalis-imx8:~# systemctl status boot.mount
○ boot.mount - /boot
     Loaded: loaded (/etc/fstab; generated)
     Active: inactive (dead)
      Where: /boot
       What: /dev/boot-part
       Docs: man:fstab(5)
             man:systemd-fstab-generator(8)

And indeed in /etc/fstab there is this line

/dev/boot-part       /boot                auto       noatime,noauto        0  0

This line is added by yocto/meta-boot2qt-toradex.git - Boot2Qt BSP layer for Toradex boards in recipes-core/base-files/base-files_%.bbappend

This bbappend file is present since a long time in this meta-layer and apparently it should be removed since it is not usefull (/dev/boot-part does not even exists). It can be disabled by adding this line in config file:

BBMASK += "meta-boot2qt-toradex/recipes-core/base-files"

Edit: concerning the gpio poweroff overlay, a new post has been created here: GPIO Power-Off Overlay Not Working After Migration to Scarthgap (Apalis iMX8QP)

leonardo.costa.tx · July 17, 2025, 11:53am

Hey, @Romain.Donze,

I’m glad you managed to solve the issue! I’ll be also looking into your GPIO overlay.

Best regards,