Issue on eMMC boot with iMX6ULL

[samuelrythm]

Hi all,

We are facing random (but frequent) failure on boot from eMMC with our iMX6ULL platform. We are using NXP official BSP release 4.1.15_2.0.0_ga.

However, if we include "imx6ul.dtsi" instead of "imx6ull.dtsi" on top of our custom *.dts file, then this problem disappears and the board boots successfully on each attempts.

We have looked into diffs between both *.dtsi files but nothing seems to deal with eMMC communication. However, we might have missed something obvious for specialists.

Here is log of the failure :

ALSA device list:

  #0: aic31xx-audio

Waiting for root device /dev/mmcblk1p2...

mmc1: MAN_BKOPS_EN bit is not set

sdhci: Tuning procedure failed, falling back to fixed sampling clock

mmc1: tuning execution failed

mmc1: error -5 whilst initialising MMC card

mmc1: MAN_BKOPS_EN bit is not set

sdhci: Tuning procedure failed, falling back to fixed sampling clock

mmc1: tuning execution failed

mmc1: error -5 whilst initialising MMC card

mmc1: MAN_BKOPS_EN bit is not set

sdhci: Tuning procedure failed, falling back to fixed sampling clock

mmc1: tuning execution failed

mmc1: error -5 whilst initialising MMC card

Thank you for your help,

Sam

[gusarambula · Accepted solution]

Hello Samuel Beaussier,

My apologies for the delay.

The tuning issue seems to be related to the usdh clock, which may explain the random nature of the symptoms. (Since the eMMC HW appears to work flawlessly).

I was checking both .dtsi files and did noticed that the usdhc2 (both usdhc definitions, for that matter) do present changes that may explain this scenario.

                                             usdhc2: usdhc@02194000 {

                                                            compatible = "fsl,imx6ull-usdhc", "fsl,imx6sx-usdhc";

                                                            reg = <0x02194000 0x4000>;

                                                            interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;

                                                            clocks = <&clks IMX6UL_CLK_USDHC2>,

                                                                            <&clks IMX6UL_CLK_USDHC2>,

                                                                            <&clks IMX6UL_CLK_USDHC2>;

                                                            clock-names = "ipg", "ahb", "per";

                                                            assigned-clocks = <&clks IMX6UL_CLK_USDHC2_SEL>, <&clks IMX6UL_CLK_USDHC2>;

                                                            assigned-clock-parents = <&clks IMX6UL_CLK_PLL2_PFD2>;

                                                            assigned-clock-rates = <0>, <132000000>;

                                                            bus-width = <4>;

                                                            fsl,tuning-step= <2>;

                                                            status = "disabled";

                                             };

The fsl,tuning-step is an optional feature that specify the increasing delay cell steps in tuning procedure. The default value for the uSDHC controller is one, but this feature is useful for some special boards or cards when the default tuning step can't find the proper delay window within limited tuning retries. Since the tuning is not executing properly, this line may be the culprit.

Another possible explanation would be a conflict between the clocks, but I would expect then more consistent failures.

Please try disabling the tuning-step line first and let us know if it works, if this was not the cause then it is most likely the assigned clock rates so you may leave those lines out as well. If the former is the case you would need to follow the whole Device Tree so see if there’s a conflict or an override to the required clock configuration in order to determine the root of the problem.

I hope this information helps!

Regards,

[samuelrythm]

Hello,

Thank you for your answer. My turn to apologize about the delay but we have missed time to run this test these last weeks. But finally we have been able to make it.

So far, it seems that your trick fixed it. However, disabling the tuning-step was not enough. We had to disable the clock configuration line as well to make it work properly.

Thank you again for your help.

Samuel

[penghaopenghao]

hi，Yes, I've met this question How did you solve this problem?