Thank you for providing the tdx-info output. Based on your Torizon OS 7.2.0-devel configuration on the Verdin iMX8M Plus V1.1A, I can now provide more specific guidance for your GPIO3_IO16 (SODIMM_64) configuration issue.
Understanding the GPIO3_IO16 Configuration Issue
Your issue with GPIO3_IO16 (SODIMM_64) is actually a known configuration problem. Based on the community forum discussion, this pin has specific device tree configurations that can interfere with its use as a general-purpose GPIO (1).
Pin Configuration Analysis
GPIO3_IO16 (SODIMM_64) is configured in the pinctrl_flexspi0 node in the device tree, which assigns it to the FlexSPI interface (1). This configuration can cause the pin to have specific pull settings that interfere with your analog strap input requirements.
Solutions for Your Use Case
1. Device Tree Modification
To properly configure GPIO3_IO16 as a floating input for your analog strap, you need to remove its assignment from the FlexSPI configuration. The pin is currently configured in the device tree as (1):
pinctrl_flexspi0: flexspi0grp {
fsl,pins =
<MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16 0x82>; /* SODIMM 64 */
};
2. Creating a Device Tree Overlay
You can create a device tree overlay using TorizonCore Builder to properly configure this pin. For production use, you should use TorizonCore Builder rather than direct file modification (2).
To apply device tree overlays with TorizonCore Builder (2):
$ torizoncore-builder dto deploy --remote-host <your_board_ip> --remote-username torizon --remote-password torizon --force --reboot <your_overlay_file>.dts
3. GPIO Access Best Practices
For production applications, you should (3):
- Use SODIMM pin names rather than bank/line numbers for consistency
- Specify only the required GPIO devices in your container using
--device /dev/gpiochip0 - Configure the pin properly in the device tree to avoid conflicts
Alternative Pin Recommendations
Since GPIO3_IO16 has FlexSPI conflicts, consider using dedicated GPIO pins that are guaranteed to be available. You can check available GPIO pins by (3):
# gpiofind SODIMM_<pin_number>
For pins that don’t have peripheral function conflicts, you can use the libgpiod tools to test them (3):
# gpioset <bank> <line>=<logic_level>
Early Boot Configuration
For your specific requirement of keeping the pin floating during power-on, you may need to modify the U-Boot device tree configuration, as Linux device tree overlays only take effect after the kernel boots (2).
The issue you’re experiencing with the ~1.5V level during early boot suggests that the FlexSPI configuration is being applied by U-Boot before Linux takes over.
Next Steps
- Remove the GPIO3_IO16 assignment from the
pinctrl_flexspi0node if you’re not using FlexSPI - Create a proper device tree overlay that configures the pin as a floating input
- Test with a dedicated GPIO pin if the timing requirements are critical
- Consider hardware modifications if software timing cannot meet your analog strap requirements
The community discussion indicates this is a known issue with device tree pin assignments, and the solution involves proper device tree configuration to remove conflicts (1).
Best regards, Toradex AI Assistant.
**
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.