Because we need to use the LAN9303 eth switch we upgraded torizon from 5.7.6 to 6.7.0. We built a custom version with yocto because we needed to add another driver.
Using the custom 6.7.0 Yocto build i run torizoncore-builder with a custom device-tree, as i have done with 5.7.6. Here GPIO3_IO11 (SOM pin 196) from the “pinctrl_dap1_gpios” is used as an input with interrupt by the software in the operating system. It is one of 4 pins that need to be configured like this.
The issue is that this pin is not configured as it should be after flashing torizon to the SOM. The other 3 are correct.
I am configuring SOM pins
196 gpio3.io12
200 gpio3.io06
202 gpio3.io14
204 gpio3.io11
as input with interrupt low
running cat /sys/kernel/debug/gpio i get this
gpio-396 (MXM3_281 |sysfs ) in hi IRQ
gpio-390 (MXM3_87 |sysfs ) in hi IRQ
gpio-398 (MXM3_126 |sysfs ) in lo IRQ
gpio-395 ( |PHY reset ) out hi ACTIVE LOW
My issue is with gpio-395, it should be the same as the other ones.
I am not sure who is configuring this gpio. If i use the base dts(imx8qm-apalis-eval.dts) from which i started the modifications it still gets set up as PHY reset.
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
To address the issue of GPIO3_IO11 (SOM pin 196) not being configured as expected in your custom TorizonCore 6.7.0 build, you should follow a systematic approach to identify and correct the configuration. Given that the other pins are correctly configured, the focus should be on what differentiates the configuration of GPIO3_IO11 from the others.
Review Device Tree Overlays: Start by closely examining the device tree overlay (DTO) you’ve created for your custom configuration. Ensure that the pin definition for GPIO3_IO11 is correctly specified, matching the configuration of the other GPIOs that are working as intended. The pin should be defined within a pin control group (pinctrl) in your device tree source (DTS) file, with the correct settings for input with an interrupt on a low level.
Check for Conflicting Configurations: It’s possible that GPIO3_IO11 is being configured elsewhere in the device tree sources (DTS or DTSI files) or in another overlay that gets applied at boot time. Use grep or a similar tool to search through the device tree sources for any instance of GPIO3_IO11 or its corresponding pin name as defined in the SoC’s documentation to ensure there’s no conflicting configuration.
Verify Pin Muxing: Ensure that the pin muxing for GPIO3_IO11 is set correctly to function as a GPIO. The pin might be multiplexed for a different function by default, and you need to explicitly configure it as a GPIO in your device tree overlay.
Inspect U-Boot Configuration: Since the bootloader (U-Boot) can also configure pins, verify that U-Boot is not setting up GPIO3_IO11 in a way that conflicts with your desired configuration. Look into the U-Boot environment variables and the board-specific U-Boot configuration files for any pin setup related to GPIO3_IO11.
Runtime Configuration Check: After booting, check the pin configuration at runtime using the Linux sysfs interface or tools like devmem2 to directly read the hardware registers related to pin configuration. This can help confirm if the pin is being set up as expected after boot and might help identify when the configuration changes if it does.
Kernel Log Analysis: Review the kernel boot log (dmesg) for any messages related to GPIO or pin configuration that might indicate why GPIO3_IO11 is being configured differently. Look for any errors or warnings that might suggest
Please, also check if these links can help you solve your problem:
Let’s focus on just pin 204/gpio3.io11. Here you believe that this pin corresponds to gpio-395 in the kernel. This is true back in the kernel used in our 5.X versions:
gpio-393 (MXM3_229 )
gpio-394 (MXM3_233 |fsl_lpspi ) in lo
gpio-395 (MXM3_204 )
gpio-396 (MXM3_196 )
Notice here that gpio-395 has the label MXM3_204. These labels come from the device tree. Now in our 6.X OS version notice how gpio-395 no longer as the same label:
gpio-395 ( |PHY reset ) out hi ACTIVE LOW
But if you look at the output of cat /sys/kernel/debug/gpio in 6.X you’ll notice the label of MXM3_204 is instead here:
gpio-329 (MXM3_229 )
gpio-330 (MXM3_233 |spi1 CS0 ) out hi ACTIVE LOW
gpio-331 (MXM3_204 )
gpio-332 (MXM3_196 )
In the new kernel it seems the numbering has shifted for all the pins and pin 204 is now instead gpio-331. It is due to this numbering change that you’re seeing issues since now the GPIO numbers you used in 5.X are not the same as 6.X. Therefore, you’re confusing which pin you’re manipulating now.
Cause of this changes and instabilities like what you witnessed here with the numbering changing can happen. This is why typically we advise to not use sysfs for GPIO manipulation these days. Instead we recommend libgpiod: How to Use GPIO on Torizon OS | Toradex Developer Center
This method does not rely on these kernel gpio numberings and instead rely on the actual gpio enumerations (gpio3.11 for example). Making them more consistent across kernel versions.
