U-boot iMX8MM eMMC 5.1 issue with custom device tree

xboborx — Thu, 01 Aug 2024 12:01:26 GMT

Hello,

we are working on developing a device using the SoM FETMX8MM from Forlinx, based on the iMX8MM SoC. For our project, we need a newer kernel (6+) than what the manufacturer provides, so we've been building a custom U-Boot.

Unfortunately, Forlinx has closed-source U-Boot, and we need kernel version 6+. We've had to create a custom DTS file by decompiling the DTB from the binary image since we don't have the original DTS. U-Boot was built from the GitHub repository uboot-imx (branch lf_v2022.04).

The issue we're facing is that the eMMC 5.1 (FORSEE FEMDRW008G-88A39) on the SoM isn't initializing. Power management is handled by the ROHM BD71847A. Our investigation shows that the eMMC is connected to the USDHC3 data bus.

When using the specified DT configurations

-----

&i2c1 {

clock-frequency = <400000>;

pinctrl-names = "default", "gpio";

pinctrl-0 = <&pinctrl_i2c1>;

pinctrl-1 = <&pinctrl_i2c1_gpio>;

scl-gpios = <&gpio5 14 GPIO_ACTIVE_HIGH>;

sda-gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>;

status = "okay";

pmic_rohm: pmic@4b {

compatible = "rohm,bd71847";

reg = <0x4b>;

pinctrl-0 = <&pinctrl_pmic>;

pinctrl-names = "default";

interrupt-parent = <&gpio1>;

interrupts = GPIO_ACTIVE_LOW>;

rohm,reset-snvs-powered;

#clock-cells = <0>;

clocks = <&osc_32k 0>;

clock-output-names = "clk-32k-out";

gpo {

rohm,drv = <0x0c>;

};

regulators {

#address-cells = <0x01>;

#size-cells = <0x00>;

bd71837,pmic-buck2-dvs-voltage = <0xf4240 0xdbba0 0x00>;

bd71837,pmic-buck2-uses-i2c-dvs;

buck1_reg: BUCK1 {

regulator-name = "BUCK1";

regulator-min-microvolt = <700000>;

regulator-max-microvolt = <1300000>;

regulator-boot-on;

regulator-always-on;

regulator-ramp-delay = <1250>;

};

buck2_reg: BUCK2 {

regulator-name = "BUCK2";

regulator-min-microvolt = <700000>;

regulator-max-microvolt = <1300000>;

regulator-boot-on;

regulator-always-on;

regulator-ramp-delay = <1250>;

rohm,dvs-run-voltage = <1000000>;

rohm,dvs-idle-voltage = <900000>;

};

buck3_reg: BUCK3 {

// BUCK5 in datasheet

regulator-name = "BUCK3";

regulator-min-microvolt = <700000>;

regulator-max-microvolt = <1350000>;

regulator-boot-on;

regulator-always-on;

};

buck4_reg: BUCK4 {

// BUCK6 in datasheet

regulator-name = "BUCK4";

regulator-min-microvolt = <3000000>;

regulator-max-microvolt = <3300000>;

regulator-boot-on;

regulator-always-on;

};

buck5_reg: BUCK5 {

// BUCK7 in datasheet

regulator-name = "BUCK5";

regulator-min-microvolt = <1605000>;

regulator-max-microvolt = <1995000>;

regulator-boot-on;

regulator-always-on;

};

buck6_reg: BUCK6 {

// BUCK8 in datasheet

regulator-name = "BUCK6";

regulator-min-microvolt = <800000>;

regulator-max-microvolt = <1400000>;

regulator-boot-on;

regulator-always-on;

};

ldo1_reg: LDO1 {

regulator-name = "LDO1";

regulator-min-microvolt = <3000000>;

regulator-max-microvolt = <3300000>;

regulator-boot-on;

regulator-always-on;

};

ldo2_reg: LDO2 {

regulator-name = "LDO2";

regulator-min-microvolt = <900000>;

regulator-max-microvolt = <900000>;

regulator-boot-on;

regulator-always-on;

};

ldo3_reg: LDO3 {

regulator-name = "LDO3";

regulator-min-microvolt = <1800000>;

regulator-max-microvolt = <3300000>;

regulator-boot-on;

regulator-always-on;

};

ldo4_reg: LDO4 {

regulator-name = "LDO4";

regulator-min-microvolt = <900000>;

regulator-max-microvolt = <1800000>;

regulator-boot-on;

regulator-always-on;

};

ldo6_reg: LDO6 {

regulator-name = "LDO6";

regulator-min-microvolt = <900000>;

regulator-max-microvolt = <1800000>;

regulator-boot-on;

regulator-always-on;

};

-----

/* EMMC */

&usdhc3 {

assigned-clocks = <0x04 0x1b5>;

clocks = <0x04 0x00 0x04 0x77 0x04 0x1b5>;

assigned-clocks = <&clk IMX8MM_CLK_USDHC3_ROOT>;

assigned-clock-rates = <400000000>;

bus-width = <8>;

keep-power-in-suspend;

pinctrl-names = "default", "state_100mhz", "state_200mhz";

pinctrl-0 = <&pinctrl_usdhc3>;

pinctrl-1 = <&pinctrl_usdhc3_100mhz>;

pinctrl-2 = <&pinctrl_usdhc3_200mhz>;

non-removable;

status = "okay";

};

-----

pinctrl_usdhc3: usdhc3grp {

fsl,pins = <

MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x40000190

MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d0

MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d0

MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d0

MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d0

MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d0

MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d0

MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d0

MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d0

MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d0

MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x190

};

pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {

fsl,pins = <

MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x40000194

MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d4

MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d4

MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d4

MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d4

MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d4

MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d4

MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d4

MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d4

MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d4

MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x194

};

pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {

fsl,pins = <

MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x40000196

MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d6

MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d6

MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d6

MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d6

MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d6

MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d6

MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d6

MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d6

MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d6

MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x196

};

-----

We'll see in cli:

u-boot=> mmc dev 2

CMD_SEND:0

ARG 0x00000000

MMC_RSP_NONE

CMD_SEND:8

ARG 0x000001aa

RET -110

CMD_SEND:55

ARG 0x00000000

RET -110

CMD_SEND:0

ARG 0x00000000

MMC_RSP_NONE

CMD_SEND:8

ARG 0x000001aa

RET -110

CMD_SEND:55

ARG 0x00000000

RET -110

CMD_SEND:0

ARG 0x00000000

MMC_RSP_NONE

CMD_SEND:1

ARG 0x00000000

MMC_RSP_R3,4 0x00ff8080

CMD_SEND:1

ARG 0x40360080

MMC_RSP_R3,4 0x00ff8080

CMD_SEND:1

ARG 0x40360080

MMC_RSP_R3,4 0x00ff8080

CMD_SEND:1

ARG 0x40360080

MMC_RSP_R3,4 0x00ff8080

CMD_SEND:1

ARG 0x40360080

MMC_RSP_R3,4 0x00ff8080

CMD_SEND:1

ARG 0x40360080

MMC_RSP_R3,4 0x00ff8080

CMD_SEND:1

ARG 0x40360080

MMC_RSP_R3,4 0x40ff8080

CMD_SEND:1

ARG 0x40360080

MMC_RSP_R3,4 0x40ff8080

CMD_SEND:1

ARG 0x40360080

MMC_RSP_R3,4 0xc0ff8080

CMD_SEND:2

ARG 0x00000000

MMC_RSP_R2 0xd6010338

0x38413339

0x3811bc91

0x7aa07900

DUMPING DATA

000 - d6 01 03 38

004 - 38 41 33 39

008 - 38 11 bc 91

012 - 7a a0 79 00

CMD_SEND:3

ARG 0x00010000

MMC_RSP_R1,5,6,7 0x00000500

CMD_SEND:9

ARG 0x00010000

MMC_RSP_R2 0xd0ffff32

0x9f5903ff

0xffffffe7

0x96400000

DUMPING DATA

000 - d0 ff ff 32

004 - 9f 59 03 ff

008 - ff ff ff e7

012 - 96 40 00 00

CMD_SEND:7

ARG 0x00010000

MMC_RSP_R1,5,6,7 0x00000700

CMD_SEND:8

ARG 0x00000000

MMC_RSP_R1,5,6,7 0x00000900

CMD_SEND:6

ARG 0x03b70200

MMC_RSP_R1b 0x00000900

CMD_SEND:13

ARG 0x00010000

MMC_RSP_R1,5,6,7 0x00000900

CURR STATE:4

CMD_SEND:6

ARG 0x03b90100

MMC_RSP_R1b 0x00000900

CMD_SEND:8

ARG 0x00000000

MMC_RSP_R1,5,6,7 0x00000900

CMD_SEND:6

ARG 0x03b78600

MMC_RSP_R1b 0x00000900

CMD_SEND:13

ARG 0x00010000

MMC_RSP_R1,5,6,7 0x00000900

CURR STATE:4

CMD_SEND:6

ARG 0x03b90300

MMC_RSP_R1b 0x00000900

CMD_SEND:13

ARG 0x00010000

MMC_RSP_R1,5,6,7 0x00000900

CURR STATE:4

CMD_SEND:8

ARG 0x00000000

RET -110

CMD_SEND:6

ARG 0x03b70000

RET -110

CMD_SEND:6

ARG 0x03b70000

RET -110

CMD_SEND:6

ARG 0x03b70000

RET -110

CMD_SEND:6

ARG 0x03b70000

RET -110

CMD_SEND:6

ARG 0x03b70200

RET -110

CMD_SEND:6

ARG 0x03b70200

RET -110

CMD_SEND:6

ARG 0x03b70200

RET -110

CMD_SEND:6

ARG 0x03b70200

RET -110

CMD_SEND:6

ARG 0x03b70000

RET -110

it gets stuck in a loop. Initially, the ERR -100 on CMD8 and CMD55 seems suspicious, but soon after another CMD0, we receive a CMD1 response of 0x00ff8080, regardless of the argument. According to the JEDEC standard for previous versions, this response could mean that the device is busy or the voltage range is not valid.

Could you please suggest us what might be causing this behavior?

Unfortunately, we don't have access to the SoM schematic, so we're relying on intuition here.

P.S. The responses to CMD9 and CMD2 seem valid, according to the eMMC datasheet.

Thanks a lot in advance.

Best regards

Re: U-boot iMX8MM eMMC 5.1 issue with custom device tree

JorgeCas — Thu, 01 Aug 2024 17:07:53 GMT

Hello,

I suggest you try to check the connection of eMMC with the processor to configure the device tree according to your design.

Also, I suggest you take a look on our reference device tree used in U-boot.

imx8mm.dtsi

imx8mm-evk.dts

Best regards.

Re: U-boot iMX8MM eMMC 5.1 issue with custom device tree

xboborx — Sun, 04 Aug 2024 21:00:30 GMT

Hi, JorgeCas.

Thanks for your response. To create a custom device tree, I used a modified imx8mm-evk.dtsi (with the main properties specified at the top), which includes the unchanged imx8mm.dtsi.

Is it possible to pinpoint the issue (clock, power, etc.) from the eMMC logs? Are there any alternative debugging methods available in U-Boot?

Re: U-boot iMX8MM eMMC 5.1 issue with custom device tree

JorgeCas — Mon, 05 Aug 2024 21:55:38 GMT

Hello,

As you mentioned, the issue is related to power or device is busy. I think you should try changing regulators definitions in device tree. Since there is no documentation about your board you should experiment with these values.

Best regards.

topic U-boot iMX8MM eMMC 5.1 issue with custom device tree in i.MX Processors

U-boot iMX8MM eMMC 5.1 issue with custom device tree

Re: U-boot iMX8MM eMMC 5.1 issue with custom device tree

Re: U-boot iMX8MM eMMC 5.1 issue with custom device tree

Re: U-boot iMX8MM eMMC 5.1 issue with custom device tree