[REGRESSION] mmc: "unable to select a mode: -5" on i.MX8M/AM62 platforms

[Peng Fan]

Hi All,

> Subject: Re: [REGRESSION] mmc: "unable to select a mode: -5" on
> i.MX8M/AM62 platforms
> 
> On Thu, Jan 08, 2026 at 01:37:57PM +0530, Tanmay Kathpalia wrote:
> > On 1/8/2026 12:32 PM, Max Merchel wrote:
> > > Am 08.01.26 um 00:15 schrieb Vitor Soares:
> > > > U-Boot 2026.01 fails to initialize MMC devices on multiple
> > > > platforms with "unable to select a mode: -5" during
> mmc_select_mode().
> > > >
> > > > Affected platforms:
> > > > - Verdin iMX8M Mini (SPL boot failure - cannot boot at all)
> > > > - Verdin iMX8M Plus (MMC init fails in U-Boot proper - cannot
> > > > boot)
> > > > - SMARC iMX8M Plus (MMC init fails in U-Boot proper)
> > > > - Verdin AM62 (boot failure, no output)
> > > >
> > > > All platforms use eMMC and worked correctly prior to this
> regression.
> > > >
> > > > Bisect results:
> > > > - Last known good commit: 228810d0bac3
> > > > - Known bad commit: 36aeeb591b0d
> > > >
> > > > Between these commits, several MMC-related changes were
> merged.
> > > > These seem particularly relevant:
> > > > commit aebb523a2381 ("mmc: mmc-uclass: Use max-frequency
> from
> > > > device tree with default handling") commit 1e40e419aeb2 ("mmc:
> > > > sdhci-cadence: Use max-frequency property from device
> > > > tree")
> > > > commit fa7e82127fad ("mmc: sdhci-cadence: Set controller and
> PHY
> > > > speed modes for SD and eMMC cards")
> 
> ...
> 
> > Thanks for the detailed report and bisect results. I've looked into
> > the issue, and it appears the regression is introduced by commit
> > aebb523a2381
> > ("mmc: mmc-uclass: Use max-frequency from device tree with
> default
> > handling").
> > The problem stems from the probe function in the FSL eSDHC driver
> > (fsl_esdhc_probe). Here's a breakdown:
> >
> > First, fsl_esdhc_init is called, which sets cfg->f_max to the minimum
> > of the controller's sdhc_clk and a hardcoded 200 MHz limit:
> > cfg->f_max = min(priv->sdhc_clk, (u32)200000000);
> > Subsequently, mmc_of_parse is invoked, where in the commit if the
> > "max-frequency" property is not specified in the device tree node for
> > the MMC controller, this function overrides cfg->f_max to 0.
> >
> > This results in f_max being set to 0, which prevents proper mode
> > selection during MMC initialization and leads to the "unable to select
> a mode: -5"
> > error you're seeing across those platforms.
> >
> > A potential fix could involve either:
> >
> > Adding the "max-frequency" property to the relevant device tree
> nodes
> > (e.g., setting it to 200000000 or the appropriate value based on the
> hardware).
> 
> In general solving a regression in code, adjusting the DT is not ok in
> Linux, not sure if the same reasoning would apply in the U-Boot use
> case (considering that both U-Boot and DT are firmware).

Please see whether below changes could work on your platforms or not.
It works on i.MX93.

diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index bf0bea93853..a32cd25ba85 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -249,7 +249,8 @@ int mmc_of_parse(struct udevice *dev, struct mmc_config *cfg)
         * will set the MMC configuration maximum frequency to the host controller's
         * maximum base clock frequency from capabilities register.
         */
-       cfg->f_max = dev_read_u32_default(dev, "max-frequency", 0);
+       if (!cfg->f_max)
+               cfg->f_max = dev_read_u32_default(dev, "max-frequency", 0);
 
        if (dev_read_bool(dev, "cap-sd-highspeed"))
                cfg->host_caps |= MMC_CAP(SD_HS);

> 
> Francesco