Device tree overlay

Ivan_Gorchev · December 1, 2025, 8:02pm

Hello, all,

I’m a happy owner of a two brand new Verdin iMX8MP QL 1GB It modules. Today my custom boards arrived and the party started

The modules works perfect, the installation of custom Yocto build takes less than 2 minutes. I’m really impressed of the performance!

Now I’m trying to apply a device tree overlay and to set 3 pins as gpio outputs and output the Linux heartbeat and drive LEDs. The pins are SODIMM 42, SODIMM 44 and SODIMM 46.

verdin-imx8mp-frontpanel-leds.dts (1.5 KB)

I’ve checked the board, LEDs are properly connected and when the module is not placed I can drive them.

The overlay is added in the overlays.txt. I can see in boot log it is loaded:
Loading DeviceTree: imx8mp-verdin-nonwifi-dev.dtb
87336 bytes read in 3 ms (27.8 MiB/s)
153 bytes read in 2 ms (74.2 KiB/s)
Working FDT set to 50200000
Applying Overlay: verdin-imx8mp_hdmi_overlay.dtbo
2219 bytes read in 3 ms (721.7 KiB/s)
Applying Overlay: verdin-imx8mp_dsi-to-hdmi_overlay.dtbo
4099 bytes read in 2 ms (2 MiB/s)
Applying Overlay: verdin-imx8mp_spidev_overlay.dtbo
561 bytes read in 2 ms (273.4 KiB/s)
Applying Overlay: verdin-imx8mp-frontpanel-leds.dtbo
1460 bytes read in 2 ms (712.9 KiB/s)

Unfortunately gpioinfo says prints of the pins are inputs:
gpiochip3 - 32 lines:
line 31: “SODIMM_44” input
gpiochip4 - 32 lines:
line 0: “SODIMM_42” input
line 1: “SODIMM_46” input

I’m running out of ideas what to do. Please support me to resolve this issue.

With kind regards,
Ivan

Verdin iMX8MP QL 1GB
Custom Yocto build, BSP 7.5.0
Custom carrier board

ToradexAI · December 1, 2025, 8:03pm

Hi, I’m the Toradex AI Assistant.

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

GPIO Configuration Issue with Device Tree Overlay

Hello Ivan! I can help you resolve this GPIO configuration issue. Based on the available information sources, there are several key points to address when configuring GPIO outputs using device tree overlays on the Verdin iMX8MP.

Checking Applied Overlays

First, let’s verify that your overlay was applied successfully. You can check if the overlay was applied correctly by examining the device tree properties(1):

# ls /proc/device-tree/chosen/overlays/
# cat /proc/device-tree/chosen/overlays/verdin-imx8mp-frontpanel-leds.dtbo

If the overlay was applied successfully, this should return 0(1).

Common GPIO Configuration Issues

From the community discussions, there are several common issues when configuring GPIOs with device tree overlays on Verdin iMX8MP(2):

Pin Control Configuration: The pin control node must be correctly defined in your overlay with proper pin settings(2).
GPIO Node Structure: The GPIO node should include the gpio-hog property with correct gpios property and output-high or output-low directive(2).
Pin Control Reference: A critical requirement is that the pin control configuration must be properly referenced in the pinctrl-0 property of the iomuxc node(2).

Required Configuration Structure

Based on the community examples, your device tree overlay should include both the pin control configuration and proper referencing(2):

&iomuxc {
    pinctrl-0 = <&pinctrl_gpio1>, <&pinctrl_gpio2>,
                <&pinctrl_gpio3>, <&pinctrl_gpio4>,
                <&pinctrl_gpio7>, <&pinctrl_gpio8>,
                <&pinctrl_gpio_hog2>, <&pinctrl_gpio_hog3>, <&pinctrl_gpio_hog4>,
                <&pinctrl_hdmi_hog>, <&your_custom_pinctrl>;
};

Troubleshooting Steps

Verify Pin Assignments: Check the Verdin iMX8MP datasheet to confirm the correct GPIO mappings for SODIMM 42, 44, and 46.
Check for Conflicts: Ensure there are no conflicting overlays or pre-enabled overlays that might override your GPIO settings(2).
Reboot Process: After making changes to your overlay, ensure you reboot the system properly to apply the overlay correctly(2).
Pin Control Integration: Verify that your custom pin control configuration is properly added to the pinctrl-0 list in the iomuxc node(2).

Without seeing your specific overlay file, the most likely issue is that the pin control configuration isn’t properly referenced in the iomuxc node’s pinctrl-0 property, which is a common requirement for GPIO configuration on the Verdin iMX8MP(2).

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Ivan_Gorchev · December 2, 2025, 8:02am

Good morning!

Thank you for the quick reply!

The result of “Checking Applied Overlays”:
root@verdin-imx8mp-15315030:~# ls /proc/device-tree/chosen/overlays/
ls: cannot access ‘/proc/device-tree/chosen/overlays/’: No such file or directory
root@verdin-imx8mp-15315030:~# cat /proc/device-tree/chosen/overlays/verdin-imx8mp-frontpanel-leds.dtbo
cat: /proc/device-tree/chosen/overlays/verdin-imx8mp-frontpanel-leds.dtbo: No such file or directory
root@verdin-imx8mp-15315030:~# cat /proc/device-tree/chosen/overlays/verdin-imx8mm_spidev_overlay.dtbo
cat: /proc/device-tree/chosen/overlays/verdin-imx8mm_spidev_overlay.dtbo: No such file or directory
root@verdin-imx8mp-15315030:~#

Looks like my overlay is not applied, but verdin-imx8mm_spidev_overlay.dtbo is not applied too, even it is part of the pre-enabled overlays.

I’ve try the same commands on a module with fresh installation without any modifications - result is the same:
root@verdin-imx8mp-15315030:~# ls /proc/device-tree/chosen/overlays/
ls: cannot access ‘/proc/device-tree/chosen/overlays/’: No such file or directory
root@verdin-imx8mp-15315030:~#

I’ve check if skip_fdt_overlays is set to one, but skip_fdt_overlays is not defined.

Best regards,
Ivan

ToradexAI · December 2, 2025, 8:02am

Overlay Application Issue with BSP 7.5.0

Hello Ivan! The missing /proc/device-tree/chosen/overlays/ directory indicates that the overlays are not being applied at boot time, which explains why your GPIOs remain as inputs.

Checking Overlay Application Status

Since you’re using BSP 7.5.0 (Yocto-based), the overlay application method differs from Torizon OS. Let’s verify the overlay status using alternative methods (1):

Check if overlays are present in boot partition:

$ ls /boot/overlays

Verify overlays.txt content:

$ cat /boot/overlays.txt

Check U-Boot environment variables:

$ fw_printenv | grep overlay

BSP-Specific Overlay Configuration

For BSP 7.5.0, overlays are handled differently than in Torizon OS. The overlays need to be properly enabled through the TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT variable during the Yocto build process (1).

Enable/Disable Device Tree Overlays in BSP

To enable your overlay in BSP, you need to add it to the overlays.txt file and ensure it’s properly formatted (1):

# vi /boot/overlays.txt

The file should contain:

fdt_overlays=verdin-imx8mp-frontpanel-leds.dtbo

After editing, synchronize and reboot (1):

# sync
# reboot

Troubleshooting Steps

Verify overlay compilation: Ensure your .dts file compiles without errors to .dtbo
Check overlay compatibility: Verify your overlay has the correct compatible property for toradex,verdin-imx8mp (2)
Remove conflicting overlays: Temporarily disable other overlays to isolate the issue

Alternative Verification Method

Since the /proc/device-tree/chosen/overlays/ path doesn’t exist in your BSP version, check if your GPIO nodes are present in the device tree:

$ find /proc/device-tree -name "*gpio*" | grep -i led

The fact that both your custom overlay and the pre-enabled spidev overlay show the same behavior suggests this is a system-wide overlay application issue rather than a problem with your specific overlay file.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Ivan_Gorchev · December 2, 2025, 8:18am

Please find the result of checks below:

root@verdin-imx8mp-15315030:~# ls /boot/overlays
verdin-imx8mp-frontpanel-leds.dtbo verdin-imx8mp_mezzanine_ov5640-27mhz-default-jumpers_overlay.dtbo verdin-imx8mp_ov5640_overlay.dtbo
verdin-imx8mp_dsi-to-hdmi_overlay.dtbo verdin-imx8mp_mezzanine_ov5640-alt-jumpers_overlay.dtbo verdin-imx8mp_panel-cap-touch-10inch-dsi_overlay.dtbo
verdin-imx8mp_dsi-to-lvds_panel-cap-touch-10inch-lvds_overlay.dtbo verdin-imx8mp_mezzanine_ov5640-default-jumpers_overlay.dtbo verdin-imx8mp_panel-cap-touch-10inch-lvds_overlay.dtbo
verdin-imx8mp_dsi-to-lvds_panel-lvds-dual-channel-1080p_overlay.dtbo verdin-imx8mp_mezzanine_panel-cap-touch-10inch-lvds_overlay.dtbo verdin-imx8mp_panel-cap-touch-7inch-dsi_overlay.dtbo
verdin-imx8mp_hdmi_overlay.dtbo verdin-imx8mp_mezzanine_panel-lvds-dual-channel-1080p_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo
verdin-imx8mp_hmp_overlay.dtbo verdin-imx8mp_nau8822-btl_overlay.dtbo
verdin-imx8mp_mezzanine_ov5640-27mhz-alt-jumpers_overlay.dtbo verdin-imx8mp_ov5640-27mhz_overlay.dtbo
root@verdin-imx8mp-15315030:~# cat /boot/overlays.txt
fdt_overlays=verdin-imx8mp_hdmi_overlay.dtbo verdin-imx8mp_dsi-to-hdmi_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo verdin-imx8mp-frontpanel-leds.dtbo
root@verdin-imx8mp-15315030:~#

Hit any key to stop autoboot: 0
Verdin iMX8MP # fw_printenv | grep overlay
syntax error
Verdin iMX8MP # fw_printenv
Unknown command ‘fw_printenv’ - try ‘help’

The verdin-imx8mp-frontpanel-leds.dtbo is in /boot/overlays.

The verdin-imx8mp-frontpanel-leds.dtbo is added in /boot/overlays.txt

TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT is defined in verdin-imx8mp.conf:
TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT = “verdin-imx8mp_hdmi_overlay.dtbo verdin-imx8mp_dsi-to-hdmi_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo”
TEZI_EXTERNAL_KERNEL_DEVICETREE_BOOT:use-mainline-bsp = “verdin-imx8mp_dsi-to-hdmi_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo”

Best regards,
Ivan

Crede · December 2, 2025, 9:25am

Hey, just a quick drop in. Here is my working overlay for IMX8MP on the Verdin developer board. The LED is connected to GPIO5. Maybe you find something.

This is what gpioinfo reports:
verdin-imx8mp:~# gpioinfo | grep 216
line 7: “SODIMM_216” “heartbeat_led_sodimm_216” output active-high [used]

crede-heartbeat-overlay.dts (736 Bytes)

Ivan_Gorchev · December 2, 2025, 9:52am

Thank you so much! I will test it immediately and will share the results.

Meanwhile I’ve tested the LEDs with gpioset. All of them works fine. There are no hardware issues.

Ivan_Gorchev · December 2, 2025, 12:19pm

Hello,

I’m one step ahead.

@Crede Thank you very much for the shared code! I modified my dts respect to the syntax used in yours.

separated and placed the “compatible” section before includes
added &{/} before { leds {…} }
rest of the code is the same

Now the dtbo is loaded. I can see the proper names of the LEDs in the gpioinfo.
Unfortunately I’m not able to output the Linux hearbeat.
When the file contains “default-state = “on”;” corresponding LED is on, even the linux,default-trigger = “heartbeat”;

Best regards,
Ivan

Crede · December 2, 2025, 1:00pm

This may be a silly question: is heartbeat enabled in the kernel of your custom build?

CONFIG_LEDS_TRIGGER_HEARTBEAT=y

Ivan_Gorchev · December 2, 2025, 1:36pm

@Crede Looks like this is THE QUESTION! I was reading about this flag till now. Currently heartbeat is not listed as possible option in /triggers. When I try to set manually the trigger to heartbeat, echo write fails.

cat /sys/class/leds/LED_5_FP_YELLOW/trigger
[none] kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock disk-activity disk-read disk-write panic mmc2 mmc1 rfkill-any rfkill-none usb-charger-0-online

root@verdin-imx8mp-15315030:~# echo heartbeat > /sys/class/leds/LED_5_FP_YELLOW/trigger
-sh: echo: write error: Invalid argument

I will continue digging in the configuration to find out if CONFIG_LEDS_TRIGGER_HEARTBEAT is enbled.

Update:
The heartbeat trigger is compiled, but as a kernel module and the module is not loaded automatically.
root@verdin-imx8mp-15315030:~# zcat /proc/config.gz | grep CONFIG_LEDS_TRIGGER_HEARTBEAT
CONFIG_LEDS_TRIGGER_HEARTBEAT=m

Once I load the module manually the heartbeat is output as expected.
modprobe ledtrig-heartbeat

Best regards,
Ivan

Ivan_Gorchev · December 3, 2025, 6:05am

Good morning!

@Crede Thank you very much for the help! The shared code was essential to makeing my overlay work.
I my current overlay I set one led in default-state = “on”; I can see this setting is applied, the LED is on, but this happens a lot of time after power up. I used similar settings on Apalis iMX.6 and all of them were applied immediately after u-boot start.

Do someone know at what moment in the boot process Device Tree overlays are applied? Is there a difference between putting a setting in the main Device Tree vs. in an overlay?

Best regards,
Ivan

leonardo.costa.tx · December 4, 2025, 6:06pm

Hey @Ivan_Gorchev, sorry for the delayed response.

The overlays are applied by U-Boot before the kernel boots. Since the kernel sees the resulting device tree with the overlays applied right before starting to boot, it shouldn’t make a difference in behavior from configuring the pins in and overlay, as opposed to configuring it directly in the device tree files.

There are several possible reasons for the LEDs to be toggled earlier in other modules. It may be that the LED driver is initialized earlier, or that they are just coincidentally toggled on by default on U-Boot.

I used similar settings on Apalis iMX.6 and all of them were applied immediately after u-boot start.

Do you mean that the LEDs are turned on while U-Boot is running, before the kernel boots? If that is the case, then it’s not caused by the overlay, and it’s just that either the SoC or U-Boot drives these pins on by default, and that is not something you can modify either with the kernel device trees or with overlays.

Thank you very much for the help! The shared code was essential to makeing my overlay work.

Just to confirm it, is your setup working correctly now? If it is, just as a friendly reminder, please mark the response that solved your issue as the solution to make it easier for other users to find it . Let me know if you find any other issues.

Best regards,

Ivan_Gorchev · December 5, 2025, 11:02am

Hello, Leonardo,

Thank you joining the loop.
The Crede comments helped me a lot to fix the syntax of my overlay and resolve the issue with missing heartbeat.

Currently I’m investigating why the overlay is applied so late at boot. I tested several times. My red LED is set ON around 10 seconds after power up or reboot. This for sure is during the boot of the Kernel.

I can see in the console log the reading of overlays:
Found U-Boot script /boot.scr
5389 bytes read in 3 ms (1.7 MiB/s)
Executing script at 50280000
Loading DeviceTree: imx8mp-verdin-nonwifi-dev.dtb
87336 bytes read in 3 ms (27.8 MiB/s)
153 bytes read in 2 ms (74.2 KiB/s)
Working FDT set to 50200000
Applying Overlay: verdin-imx8mp_hdmi_overlay.dtbo
2219 bytes read in 3 ms (721.7 KiB/s)
Applying Overlay: verdin-imx8mp_dsi-to-hdmi_overlay.dtbo
4099 bytes read in 2 ms (2 MiB/s)
Applying Overlay: verdin-imx8mp_spidev_overlay.dtbo
561 bytes read in 2 ms (273.4 KiB/s)
Applying Overlay: verdin-imx8mp-frontpanel-leds.dtbo
1694 bytes read in 2 ms (827.1 KiB/s)
8302103 bytes read in 51 ms (155.2 MiB/s)

Right after it the Kernel boots.

The pin I use for the red LED is I2S_2_D_OUT, SODIMM #46, GPIO5_IO1. The pin is an output and it is in low state. I confirmed it - in uboot and during the boot of the Kernel the level of the signal is low. I have a weak external pull-up resistor to 1.8V, so I’m sure this pin is an output and it is low level. I need a high level on this pin to enable my red LED. I cen see it enabled 6-7 seconds after u-boot, during the boot of the Kernel.

Best regards,
Ivan

leonardo.costa.tx · December 5, 2025, 5:48pm

Hey @Ivan_Gorchev,

Do you need the LED to follow the “heartbeat” pattern right at power up, or having it on is enough?

If you only need to toggle it on before the kernel boots, you could edit the U-Boot script in your recipe to control your GPIO pin, driving it high during the U-Boot operation. Would this solve the issue?

Best regards,

Ivan_Gorchev · December 5, 2025, 8:23pm

Hello @leonardo.costa.tx

I have to drive 3 leds - red, yellow and green.
The red one shall be on once the power is applied. Once the Kernel boot my autostart service turns off the red led.
The yellow one shall follow the heartbeat while the device is powered.
The green one is driven by my application.

This is how the led indication shall work. This is requirement from our previous design, based on Apalis i.MX6. Now we switched to Verdin i.MX8 due to the better performance, availability and price. It is mandatory to keep the device functionality as same as the previous design. In the previous design I used the device tree to set states of the leds and everything used to work perfectly. Now I’m trying to do the same, but may be there is a smarter way to do it.

I used to rebuild the kernel with several modifications. Integrated my overlay to be included into the build and set CONFIG_LEDS_TRIGGER_HEARTBEAT=y. Now when kernel boots I can clearly see the following:

uboot start, all leds are off
red led is turnerd on 6-7 seconds after kernel start to boot
yellow led start to follows the heartbeat in the same time

Now I’m completely sure the overlay takes effect 6-7 seconds after kernel start to boot. You can find what is printed on the console meanwhile.

boot_log.txt (3.5 KB)

Best regards,
Ivan

leonardo.costa.tx · January 8, 2026, 1:48pm

Hey @Ivan_Gorchev,

I’m sorry for the delay. Did you manage to fix the issue?

From what I understood, the problem is in the behavior of the red LED, right? It should be on right when the power is applied.

Unfortunately, it is not possible to apply the configuration on the kernel device tree (through an overlay or a device tree modification) and have it control the LED from the start. As you said, the overlay takes effect a few seconds after the kernel starts (the overlay is applied by u-boot before the kernel starts, but it will only take effect after the kernel and the LED controlling driver have been initialized).

I believe it was only a coincidence that the red LED turned on at power-up when you used the Apalis iMX6, that pin defaulted to high before the kernel initialized and drove it to low. As I said in the previous reply, I think the best alternative if you want the red LED to start working is to add a command in the U-Boot script so that U-Boot drives the pin high before the kernel starts.

One other thing, you said the yellow LED followed the heartbeat while the device was powered. Do you mean that when you used the Apalis iMX6, the yellow LED started to heartbeat right after power-up, before the kernel started? That would sound very strange to me.

Best regards,