DTS from THUD to KIRKSTONE conversion

Technical Support
, ,
1

Hi all,
I would like to ask you if anyone from you tried to pass dts file from thud to kirkstone.
I know there is bit different structure.
I do have old system fully operational with THUD on proprietary board but on KIRKSTONE, I cannot find how to enable second ethernet (eth1) and gpio37 (gpiochip1 pin5) from sysfs or gpiolibtool.
If anyone can help me or share direction would be nice.

Many thanks L

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 your question.

Migrating a device tree source (DTS) file from a Yocto “thud” (older LTS) to “kirkstone” (newer LTS) involves dealing with changes in the kernel and device tree structure. Here are some tailored steps and tips for what you want to achieve—enabling the second Ethernet interface and configuring a GPIO pin (gpio37):

1. Second Ethernet (eth1) on Kirkstone

  • Many Toradex System on Modules (SoMs) support a second Ethernet controller. To enable it in Kirkstone:
    • Ensure your carrier board has a second Ethernet PHY connected to the appropriate interface.
    • In your device tree, you must configure the node for the second Ethernet controller. Its structure/naming may have changed across kernel versions.
    • Reference: How to Add a Second Ethernet Port

Quick Steps:

  • Find the Ethernet controller node in your old DTS.
  • In Kirkstone, check for any changes in compatible strings or node organization for the Ethernet controllers.
  • Ensure your device tree overlays or modifications adhere to the new structure.

2. GPIO37 (gpiochip1, pin5) Handling in Kirkstone

  • The sysfs interface for GPIOs has been deprecated. It’s recommended to use the new character device interface with tools like gpiod.
  • Device tree handling for GPIOs remains similar, but you may need to adapt the pinctrl or GPIO controller nodes if the mainline kernel’s binding changed.
  • Reference: First Steps Modifying a Device Tree

Quick Steps:

  • In your device tree, set the pinmux/pinctrl for gpio37 as input or output, as needed.
  • Rebuild and deploy your updated device tree.
  • Use tools from the libgpiod package (e.g. gpiodetect, gpioinfo, gpioset, gpioget) instead of sysfs.
  • Example: To get the value of GPIO37 if it is on gpiochip1, you would run:
    gpioget gpiochip1 5

Device Tree Migration Tips:

  • Take your old DTS as a base, but compare each relevant section with the kernel reference DTS for Kirkstone.
  • Pay close attention to changes in compatible strings or the structure of nodes like ethernet, pinctrl, gpio, etc.
  • Customizations must be ported carefully—don’t just copy-paste wholesale. Adapt each node referencing the Kirkstone device tree sources.

Building and Deploying the Device Tree:

If you let me know your exact Toradex SoM model (e.g., Apalis iMX8, Colibri iMX6, etc.), I can offer precise device tree node examples for Ethernet and GPIO.

Best regards,
Toradex AI Assistant.

3

Thank a lot for your answer.
in first step I will concentrate on gpio37, yes I’m using libgpiod package and gpiodetect, gpioinfo, gpioset, gpioget functions.
gpiofind gets me for SODIMM30 gpiochip1 pin 5
gpioset gpiochip1 5=1 doesn’t return error but gpioget gpiochip1 5 returns 0 and osciloskop stays on high forever.
Could you be more specific what shall I share to find the problem?

4

It seems you are working on moving from thud to kirkstone and thus having issues with a however of the second ethernet (eth1) and gpio37 (gpiochip1 pin5 for the crunchboard) springfox. As the DT structure and config has changed between the two releases, you’ll have to update your DTS files to match the new structure. For the 2nd Ethernet port you will have to check a node in the DTS from the eth1 and make sure it’s correct and also modify the PHY settings to your liking. So, for gpio37, make sure it is defined correctly in the GPIO tree in the dts and also make sure the driver configuration (or overlay files) use the correct device definition in order to access the GPIO via sysfs or gpiolib. It might be helpful to consult the Kirkstone release notes and the Yocto meta layers documentation for any specific changes to GPIO or Ethernet handling. If you’re still stuck, reaching out to the community or checking for similar issues in Yocto’s mailing list or forums could provide additional insights.