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

[Max Merchel]

Am 08.01.26 um 11:33 schrieb 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);
> 

Hi Pan,

the change prevents the function from being carried out on the iMX6.
Settings of max-frequency in dt are ignored because cfg->f_max has 
already been set initially.

-- 
Best regards,
Max

TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/