Verdin iMX8MP – GPIO3_IO16 internal pulldown fighting external 10k pull-up during boot

Hi,

we are adding a Lontium MIPI SerDes (LT947C/LT934LMT) to our custom carrier board for Verdin iMX8MP.

The Lontium INTB pin is connected to GPIO3_IO16 (SODIMM_64) on the Verdin. On the SerDes side this pin is first used as an analog strap input (ADP link rate select) and must be must be at left floating at power-onp. Later, after power-on, it is used as the interrupt output to Linux.

On our board INTB / GPIO3_IO16 has an external 10 k pull-up to 1.8 V.

With a Saleae we measured GPIO3_IO16 on the SoM side only (serializer not connected). The waveform looks like this:

  • at power-on it rises towards 1.8 V

  • then, about 840 ms after the power button is pressed, the level drops and settles at about 1.5 V and stays there

  • much later, when the Linux driver runs, it finally goes up to the full 1.8 V

This looks exactly like an internal pulldown in the i.MX8MP fighting the 10 k pull-up (10 k to 1.8 V vs. ~50 k pulldown → ~1.5 V).

I tried to fix this via a device-tree overlay so that Linux configures GPIO3_IO16 as input with no pull:

&iomuxc {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_gpio3>, <&pinctrl_gpio4>,
                <&pinctrl_gpio7>, <&pinctrl_gpio8>,
                <&pinctrl_gpio_hog2>, <&pinctrl_gpio_hog3>, <&pinctrl_gpio_hog4>;

    pinctrl_serdes_gpio: serdesgp {
        fsl,pins =
            <MX8MP_IOMUXC_NAND_DATA03__GPIO3_IO09  0x1c4>, /* SODIMM 62 */
            <MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16 0x040>; /* SODIMM 64: PE=0, no pull */
    };
};

&i2c2 {
    clock-frequency = <400000>;

    ina220@45 {
        compatible = "ti,ina220";
        reg = <0x45>;
        status = "okay";
    };

    mipi_serdes@43 {
        compatible = "lontium,mipi_serdes";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_serdes_gpio>, <&pinctrl_gpio_10_dsi>;
        reg = <0x43>;
        interrupt-parent = <&gpio3>;
        interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
        reset-gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
        panelreset-gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
        enable-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;

        deserializer@4c {
            reg = <0x4c>;
        };
    };
};

From Linux /sys/kernel/debug/gpio shows GPIO3_IO16 as an input (no forced value), so the overlay seems to take effect – but only after Linux is up. The ~1.5 V plateau already happens much earlier in the boot sequence.

Questions:

  1. Is it expected that GPIO3_IO16 comes up with an internal pulldown until Linux re-configures it, even if the DT overlay sets it to “no pull”?

  2. Is there any way (U-Boot DT or board code) to force this pad to Hi-Z / no pull as early as possible so it doesn’t disturb our 1.8 V strap level on the carrier board?

  3. Are there any Verdin iMX8MP pins that are guaranteed to be Hi-Z / no pull from reset that you would recommend for this kind of analog strap input?

The attached Saleae screenshot shows only the SoM GPIO3_IO16 behaviour; the SerDes is not connected in this measurement.

Thanks a lot for any hints!

Hi, I’m the Toradex AI Assistant.

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


I’d be glad to help! Could you let me know which OS and version you are using?

To provide the most accurate guidance for configuring GPIO3_IO16 (SODIMM_64) on your Verdin iMX8M Plus, I need to understand your platform setup better. You can run the tdx-info command on your device to get detailed information about your configuration - you can find more details about this tool at https://developer.toradex.com/software/development-resources/tdx-info/.

Additionally, please specify:

  • Which OS and version you are running (e.g., Torizon OS 6.x, Torizon OS 7.x, BSP 6.x, BSP 7.x)
  • Your carrier board type (custom carrier board based on which reference design)

This information will help me provide the most accurate guidance for your GPIO configuration needs, as the implementation details can vary significantly between different OS versions and platforms.

Best regards, Toradex AI Assistant.


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

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

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

@ToradexAI I can post the tdx-info tomorrow, but basically we are using Torizon 7.2 BSP 7.x.

I can help you with your GPIO configuration issue on the Verdin iMX8M Plus. Based on your description, you’re dealing with a timing issue where GPIO3_IO16 (SODIMM_64) needs to remain floating during power-on for the Lontium SerDes analog strap input, but the iMX8MP appears to be applying an internal pull-down that interferes with your external 10kΩ pull-up.

Understanding the Issue

Your observation is correct - the voltage level of ~1.5V indicates that an internal pull-down resistor is fighting against your external 10kΩ pull-up to 1.8V (1). On Torizon OS, GPIO pins follow a specific standardization where Verdin modules use SODIMM naming for GPIO pins (1).

Potential Solutions

1. Device Tree Overlay Timing

Your device tree overlay approach is correct, but as you’ve observed, it only takes effect after Linux boots. The pull configuration you’re using (0x040 for no pull) should work once Linux applies it (1).

2. Early Boot Configuration

For earlier configuration, you would need to modify the U-Boot device tree or board initialization code. This is similar to the approach described in the DIP switch boot process documentation, where GPIO configuration is done in the bootloader phase (2).

3. Alternative GPIO Pins

For analog strap inputs that must remain floating during power-on, you should consider using dedicated GPIO pins (1). When selecting GPIO pins, you should:

  • Check the available GPIO pins in your carrier board
  • Ensure the chosen pin is a dedicated GPIO pin
  • Verify that the pin has GPIO alternate function available (1)

Recommendations

  1. Verify Pin Selection: Ensure SODIMM_64 is indeed a dedicated GPIO pin by checking the Verdin iMX8M Plus datasheet’s GPIO section (1).

  2. Consider Pin Alternatives: Look for GPIO pins that are guaranteed to be high-impedance from reset. The documentation suggests prioritizing dedicated GPIO pins for compatibility (1).

  3. Hardware Considerations: Since this is for analog strap input, you might need to consider the TTL level compatibility - Verdin modules operate at 1.8V TTL levels (1).

Next Steps

When you provide the tdx-info output tomorrow, I can give more specific guidance based on your exact configuration. You should also check if SODIMM_64 requires a device tree overlay to enable GPIO function, as some non-dedicated pins need this configuration (1).

For pins that aren’t dedicated GPIO, you would need to write a device tree overlay to enable the GPIO alternate function, but this adds complexity to your timing requirements.

Best regards, Toradex AI Assistant.


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

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

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

@ToradexAI

Software summary
Bootloader:               U-BootKernel version:           6.6.84-7.2.0-devel-g87bfb710b6f1 #1-Torizon SMP PREEMPT Mon Mar 31 08:47:48 UTC 2025Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.0/torizon/343ea8abe84ffb9897ddb9c0ecf47008d25ae0f06e564d5b0a16aa260b5e2b28/0Distro name:              NAME=“Torizon OS”Distro version:           VERSION_ID=7.2.0-devel-20251027132233-build.0Distro variant:           VARIANT=“Docker”Hostname:                 verdin-imx8mp-15601689
Hardware info
HW model:                 Toradex Verdin iMX8M Plus WB on Verdin Development BoardToradex version:          0070 V1.1ASerial number:            15601689Processor arch:           aarch64

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

  1. Remove the GPIO3_IO16 assignment from the pinctrl_flexspi0 node if you’re not using FlexSPI
  2. Create a proper device tree overlay that configures the pin as a floating input
  3. Test with a dedicated GPIO pin if the timing requirements are critical
  4. 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.

**


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

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

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