Switch Voltage from 3.3V to 1.8V at SD1 Pins (USDHC2)


I am doing the bring-up of a custom carrier board for the VERDIN-IMX8MM-v1.0B (BSP 5.1.0).
In our design we use the pins of the SD 1 interface as GPIO.

With the simple overlay attached below we are able to control the SD_1_[D0,D1,D2,D3,CMD,CD#] pins with gpioinfo, gpioset, gpioget etc. (tested with a multimeter)

However our design expects this pins to be working at 1.8V, by default the interface is working at 3.3V.

Reading the Verdin iMX8M Mini Datasheet:

The IO voltage of the SDIO power block can be changed independently from the other IO blocks,
but all signals of the SDIO block change their voltages together. The IO voltage of the Verdin
“Always Compatible” interface (i.MX 8MM USDHC2) is provided by the MUXSW_VOUT output of
the power management IC (PMIC). The voltage level is controlled by the dedicated VSELECT output
of the USDHC2 interface which is located on the GPIO1_IO04 ball of the SoC.

As seen in the DTS below we configure the iomux so that GPIO1_IO04 is VSELECT.
However, toggling GPIO1_IO04 high/low has no effect on the voltage measured on the SD_1_[D0,D1,D2,D3,CMD,CLK,CD#] SODIMM pins

Could you please offer some gidance as to what we are missing to switch the voltage to 1.8V?

Thanks in advance :slight_smile:

#include "dt-bindings/gpio/gpio.h"

#include <imx8mm-pinfunc.h>

/ {
    compatible = "toradex,verdin-imx8mm";

&usdhc2 {
    status = "disabled";

&iomuxc {
    pinctrl-0 = <&pinctrl_gpio2>;
    pinctrl_gpio2: gpio2grp {
        fsl,pins = <
            MX8MM_IOMUXC_SD2_DATA0_GPIO2_IO15       0x41
            MX8MM_IOMUXC_SD2_DATA1_GPIO2_IO16       0x41
            MX8MM_IOMUXC_SD2_DATA2_GPIO2_IO17       0x41
            MX8MM_IOMUXC_SD2_DATA3_GPIO2_IO18       0x41
            MX8MM_IOMUXC_SD2_CMD_GPIO2_IO14         0x41
            MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12        0x41
            MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT      0x1d0



You muxed the pin GPIO1_IO04 to the function USDHC2_VSELECT. So using the function GPIO1_IO04 will not have any effect on the pin state.

Changing the pinmuxing to MX8MM_IOMUXC_GPIO1_IO04_GPIO1_IO04 might solve the riddle.

However, I would solve your use case by directly controlling LDO5 [1] by setting regulator-max-microvolt also to 1.8V plus adding the property regulator-always-on;.


[1] imx8mm-verdin.dtsi « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

Hi Max,

Thanks for feedback :slight_smile:

I have modified the overlay with the changes you suggested:

&ldo5_reg {
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;

I have also properly configured


Unfortunately, this does not solve the issue, I am still reading 3.3V when I measure the multimeter.

Aditionally dmesg shows this:

verdin-imx8mm-06612187:~$ dmesg | grep "LDO"
[    1.618267] LDO5: Bringing 3300000uV into 1800000-1800000uV
[    1.620054] LDO5: supplied by regulator-dummy
[    1.622502] LDO6: supplied by regulator-dummy

Any other suggestions I could try ?

I have also tried this, but didn’t make a difference either:

&reg_usdhc2_vmmc {
	regulator-max-microvolt = <1800000>;
	regulator-min-microvolt = <1800000>;
	status = "okay";


Hi Jaume

I will have to try that out on HW when I’m back in the office next week.

Note that reg_usdhc2_vmmc represents the SD card power switch on the carrier board, i.e. it is not related to what you are trying to do.


Hi Max,

I was thinking about it and realized that I am using
‘imx8mm-verdin-wifi-dahlia.dts’ and not ‘imx8mm-verdin-wifi-v1.1-dahlia.dts’.
Please let me know if I should use the v1.1, from the name it felt I should’t use it since I am currently using a v1.0B verdin-imx8mm.

Comparing the dts I can see there is a major difference in the regulators:

&i2c1 {
	clock-frequency = <400000>;
	pinctrl-names = "default", "gpio";
	pinctrl-0 = <&pinctrl_i2c1>;
	pinctrl-1 = <&pinctrl_i2c1_gpio>;
	scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
	sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
	status = "okay";

	pmic: pca9450@25 {
		reg = <0x25>;
		compatible = "nxp,pca9450";
		/* PMIC PCA9450 PMIC_nINT GPIO1_IO3 */
		pinctrl-0 = <&pinctrl_pmic>;
		gpio_intr = <&gpio1 3 GPIO_ACTIVE_LOW>;
		i2c-lt-en = <0x101>;

		regulators {
			#address-cells = <1>;
			#size-cells = <0>;

			/* Run/Standby voltage */
			pca9450,pmic-buck2-dvs-voltage = <950000>, <850000>;


			ldo5_reg: regulator@10 {
				reg = <10>;
				regulator-compatible = "ldo5";
				regulator-min-microvolt = <1800000>;
				regulator-max-microvolt = <3300000>;




&i2c1 {
	/delete-node/ pca9450@25;

	pmic_v10: bd71837@4b {
		compatible = "rohm,bd71837";
		interrupt-parent = <&gpio1>;
		/* PMIC BD71837 PMIC_nINT GPIO1_IO3 */
		interrupts = <3 GPIO_ACTIVE_LOW>;
		pinctrl-0 = <&pinctrl_pmic>;
		reg = <0x4b>;

		gpo {
			rohm,drv = <0x0C>;	/* 0b0000_1100 all gpos with cmos output mode */

		regulators {


			ldo5_reg: LDO5 {
				regulator-max-microvolt = <3300000>;
				regulator-min-microvolt = <3300000>;
				regulator-name = "LDO5";



The PMIC is different and from the looks of it, it seems that LDO5 was never meant to switch from 1.8V to 3.3V to begin with ? (in 1.0)


On the V1.0 hardware another PMIC is used, there is no dedicated regulator for the SD card communication voltage. GPIO1_IO04 controls a switch between 1.8V and 3.3V.

For me an overlay which sets the pin GPIO1_IO04 to the function GPIO1_IO04 allows me to later control the voltage. (with gpioset 0 4=1 I do get 1.8V).

  • Are you sure you recompiled and deployed the device tree overlay?
  • What is the output of devmem2 0x30330038


P.S. I recommend to move to V1.1 hardware as soon as possible. There have been a lot of incompatible changes, among others also additional pullups on the SD interface.

Hi Max,

Thanks, that did it !
I mistakenly jumped to the conclusion that MX8MM_IOMUXC_GPIO1_IO04_VSELECT should be used to select the voltage level.
In my defence I will say that the v1.0 documentation was not very clear on the topic :frowning:.

We plan to switch v1.1 ASAP, we have a pending order with you guys, but in the meantime the only thing I can work with is an old v1.0 board we had lying around.

Thanks for the excellent support !