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/
