We’re having some issues in u-boot with the pin SODIMM_99 (GPIO1 14) which acts as an LED (Output).
The pin is nor set nor clearable using the u-boot CLI:
gpio set GPIO1_14
gpio: pin GPIO1_14 (gpio 14) value is 1
Warning: value of pin is still 0
gpio clear GPIO1_14
gpio: pin GPIO1_14 (gpio 14) value is 0
I can always measure a steady ~1.66V to GND, regardless of what I try to set, which causes the LED to glow lightely.
The LED is connected directly from GND to the PIN (using a series resistor).
We have further, similar LEDs on other pins (SODIMM 101,103,105) which don’t have that problem and are set/clearable.
As soon as the OS is running, I can set all the pins using sysfs (/sys/class/leds/) without an issue, including Pin99, so this shouldn’t be a hardware issue.
It seems that something else is using this pin in u-boot, but I checked the devicetree and couldn’t find anything:
For verification I tested with the default BSP 6.7.0, installed from web using TEZI, but got the same result in u-boot.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Simon,
It seems like you’re experiencing an issue with controlling the GPIO1_14 (SODIMM_99) pin in U-Boot on the Colibri iMX6ULL module. Given that the pin works correctly under the Linux OS, it suggests that the hardware is functioning properly and the issue is likely related to U-Boot configuration or initialization.
Here are a few steps you can take to troubleshoot and potentially resolve the issue:
Check Pin Multiplexing in U-Boot:
Ensure that the pin is correctly configured as a GPIO in U-Boot. You can check the pin multiplexing settings in the U-Boot device tree files (imx6ull-colibri.dtsi, imx6ull-colibri-u-boot.dtsi, etc.). Look for the pin configuration and ensure it is set as a GPIO and not being used by another peripheral.
Check U-Boot GPIO Initialization:
Verify that the GPIO subsystem is properly initialized in U-Boot. Sometimes, GPIOs might not be correctly initialized, leading to issues in setting or clearing them.
Check for Conflicting Configurations:
Ensure that there are no conflicting configurations in the U-Boot device tree or board-specific files that might be affecting the GPIO1_14 pin.
Test with a Minimal U-Boot Configuration:
Try testing with a minimal U-Boot configuration to isolate the issue. Disable any unnecessary peripherals or configurations that might be interfering with the GPIO.
Check U-Boot Version:
Ensure you are using a stable and supported version of U-Boot. Sometimes, upgrading or downgrading U-Boot can resolve such issues.
Debugging:
Add debug prints in the U-Boot GPIO driver code to trace the execution and see where it might be failing to set or clear the pin.
Compare with Working Pins:
Compare the configuration and initialization of the problematic pin (GPIO1_14) with the other working pins (SODIMM 101, 103, 105). Look for any differences that might explain the issue.
If after these steps the issue persists, you might want to reach out to Toradex technical support for further assistance. They can provide more specific guidance and help you debug the issue in detail.
Best regards,
[Your Name]
Please, also check if these links can help you solve your problem:
Checking the device tree, SODIMM 99 is configured as a regular GPIO in u-boot for the Colibri iMX6ULL eMMC, not being used elsewhere.
I would also recommend that you check the source from DENX, which is where we get u-boot from.
That being said, it seems that, when using u-boot from the Toradex Reference Minimal Image 6.7.0, the pin is not configured with the alt mode 5 for GPIO:
Colibri iMX6ULL # gpio clear GPIO1_14
gpio: pin GPIO1_14 (gpio 14) value is 0
Colibri iMX6ULL # gpio set GPIO1_14
gpio: pin GPIO1_14 (gpio 14) value is 1
Warning: value of pin is still 0
Please note that the warning is still present when setting the pin value to 1, but I can measure it at 3.3V.
Thanks for your response.
I can reproduce your solution on my Hardware using the default Image and my custom BSP, the LED can be set/cleared as expected after these commands.
Would it be possible to setup the iomux properly in the Code/dtb already (preferrably dtb)? Where should this be done?
Upon further investigation, u-boot is not applying the pinctrl from the device tree.
This is likely due to the limited device tree support which is present in u-boot.
A way to guarantee this configuration would be to include it in the board initialization file, please see the attached patch, which does just that for this GPIO pin.
Most likely yes, however when this could be done is not clear.
We usually update the u-boot version with every major BSP release (5, 6, 7, etc.), so if there is an update to u-boot that allows for the gpios to be automatically configured according to the device tree this feature would eventually be available in a new BSP version.
We’re in the process of upgrading to the new BSP7. Unfortunately, the Pinmux still doesn’t work using the DT.
Further, setting the pin in the board.c file also doesn’t work the same as in BPS6: The pin is still configured as GPIO (Can be set and cleared) but without actively setting the Pin to low (gpio clear GPIO1_14) the LED is now yet again glowing lightely, with ~1.6V. Previously, just configuring with a Pulldown worked.
/* Workaround: Set Pin as output low */
#define SODIMM_99_PIN IMX_GPIO_NR(1, 14)
imx_iomux_v3_setup_multiple_pads(set_pin_mux_workaround, ARRAY_SIZE(set_pin_mux_workaround));
//BSP7 now requires to actively set the pin as output to have a properly defined state...
gpio_request(SODIMM_99_PIN, "led-level2-failure");
gpio_direction_output(SODIMM_99_PIN, 0);
In Linux, everything still seems to work alright, this only affects the bootloader.
Is this a known issue, or are there other steps required with the new BSP/U-Boot for proper setup?
