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.
Hello Andrew,
Thank you for your detailed explanation! Your approach and documentation are great, and you’re definitely on the right track. The issue likely comes from a few places in your device tree configuration and the process for ensuring the pins are functioning purely as GPIOs.
Points to Address
-
Pin Ownership / Peripheral Conflict
- The SPDIF_TX pin is assigned by default to the CAN1 peripheral as
CAN1_TX
. Even if you change just the pinctrl values, the flexcan1 driver may still claim the pin. - Solution: Explicitly disable the
flexcan1
node in your overlay or device tree.
This will prevent the kernel from attaching the CAN1 function to those pins.&flexcan1 { status = "disabled"; };
(Reference)
- The SPDIF_TX pin is assigned by default to the CAN1 peripheral as
-
Pinctrl Pad Value
- The value
0x104
configures the pad with “pull-down” and “SION” (software input). While this should work for a pulled-down GPIO, for output use a more typical value:0x184
(output, pull-down) or0x1c4
(output, pull-up), depending on your needs (Reference).
- The value
-
Pin Assignment to GPIO
- Ensure the pins are placed into a hog configuration so they are exported and set as outputs with initial state:
This will make the pins available as /dev/gpiochip devices and keep them low on boot.&gpio5 { gpio5_io3: gpio5_io3_output { gpio-hog; gpios = <3 GPIO_ACTIVE_HIGH>; output-low; line-name = "gpio5_io3_output"; status = "okay"; }; gpio5_io4: gpio5_io4_output { gpio-hog; gpios = <4 GPIO_ACTIVE_HIGH>; output-low; line-name = "gpio5_io4_output"; status = "okay"; }; };
(Reference: Customizing Device Trees)
- Ensure the pins are placed into a hog configuration so they are exported and set as outputs with initial state:
-
Correct Header Pin Mapping
- Double-check that your pad assignments match the physical X19 pins, as some may be shared with default boot or debug functions (Reference: First Steps With Device Trees).
Recommended Device Tree Overlay Example
/dts-v1/;
/plugin/;
/ {
compatible = "toradex,verdin-imx8mp";
fragment@0 {
target = <&flexcan1>;
__overlay__ {
status = "disabled";
};
};
fragment@1 {
target = <&iomuxc>;
__overlay__ {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_flexcan1_gpio>;
};
};
fragment@2 {
target = <&gpio5>;
__overlay__ {
gpio5_io3: gpio5_io3_output {
gpio-hog;
gpios = <3 GPIO_ACTIVE_HIGH>;
output-low;
line-name = "gpio5_io3_output";
};
gpio5_io4: gpio5_io4_output {
gpio-hog;
gpios = <4 GPIO_ACTIVE_HIGH>;
output-low;
line-name = "gpio5_io4_output";
};
};
};
fragment@3 {
target-path = "/bus@30800000/iomuxc@30330000";
__overlay__ {
pinctrl_flexcan1_gpio: pinctrl_flexcan1_gpio {
fsl,pins = <
MX8MP_IOMUXC_SPDIF_TX__GPIO5_IO3 0x184
MX8MP_IOMUXC_SPDIF_RX__GPIO5_IO4 0x184
>;
};
};
};
};
- Use
0x184
pad control for stable, output-low GPIO. - Expand the above for all pins on X19 as needed.
How to Apply and Test
- Build the overlay and apply with TorizonCore Builder.
- Reboot your device and run:
gpioinfo
- Confirm your pins are correctly configured as output and low.
Further Guidance
- Make sure only overlays (not direct .dtsi edits) are used when possible, to ease migrations and updates.
- If you continue to see unexpected voltages, re-verify the physical header mapping and check for other conflicting definitions in other overlays or base trees.
References
- First Steps With Device Trees
- How to Customize Device Trees
- Changing GPIO Behaviour Using Device Tree Overlay
Please let me know if you need help adapting this for the rest of the X19 header or if you encounter further issues!
Best regards,
Toradex AI Assistant.