Verdin IMX8MP + Ivy board LEDs

Technical Support
,
6

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

Did you like my answer? :+1: :-1:

Hello mvo,

You’re absolutely correct: the device tree files you referenced already contain LED definitions for SODIMM 30, 32, 34, 36, 44, 46, 48, and 54. Under normal circumstances, if you are using the standard Torizon image (or any image that includes these device tree files without modifications or conflicting overlays), the LEDs should just work—no extra overlay should be needed.

However, there are a couple of reasons why the LEDs might not be operable from userspace (e.g., missing in /sys/class/leds/ or gpioinfo):

  1. Pin Multiplexing (IOMUXC) Not Matching GPIO Use
    For a GPIO pin to function as intended, its pad must be set to GPIO mode via pinctrl (i.e., proper configuration in the device tree in sections like pinctrl_ivy_leds). If another peripheral (like PWM, I2C, etc.) is assigned to the same pin in another device tree or overlay, there may be a conflict.
    Pin multiplexing configuration details

  2. Conflicting Overlays/Customizations
    If your build includes overlays or modifications that reassign those pins elsewhere or disable them, the base configuration could be overridden.
    Conflicts in device tree overlays

  3. System Not Using Your Expected Device Tree
    If you boot an image but the device tree in use (as reported in /proc/device-tree/model or kernel logs) isn’t your custom or intended one, changes won’t take effect. This can happen due to naming mismatches or misconfigurations in your build system.

What to Check

  • Ensure You Are Booting the Correct Device Tree

    • After booting, check what device tree is actually loaded:
      cat /proc/device-tree/model
      or
      dmesg | grep -i dtb

  • Verify Pinctrl Configuration

    • Make sure that pinctrl_ivy_leds is defined and sets the correct pinmux for all the LED GPIOs.
      Example of pinctrl node

  • Look for Pin Conflicts

    • Check that there is no other peripheral (e.g., UART, PWM) assigned to these SODIMM pins in the device tree and overlays in your build.

  • LED Device Nodes Should Show Up

    • After boot, check for entries in /sys/class/leds/ corresponding to your status LEDs.
    • LEDs configured in the device tree with gpio-leds should show up here.

  • Check gpioinfo Again

    • The gpioinfo utility shows kernel-exported GPIOs, but the names/lines depend on the pinconf and controller mapping. If the device tree is correct, the corresponding GPIO lines should still show (but maybe under generic names if no label is given).

Summary

If you are using the provided device trees and have not added overlays that conflict, you should not need another overlay to use the Ivy board LEDs—they are already set up.

If you are still not seeing the GPIOs or LEDs as expected, it’s very likely to be a pinmux conflict, overlay ordering issue, or the image is not using the device tree you intended. Pin multiplexing, not the lack of a node, is usually the cause.

If you’d like, you can share the pinctrl_ivy_leds definition from your device tree for further review, or I can help you with steps to debug which device tree and pin settings are active at runtime.

Best regards,
Toradex AI Assistant.

Useful resources: