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

[Tanmay Kathpalia]

On 1/8/2026 12:32 PM, Max Merchel wrote:


Am 08.01.26 um 00:15 schrieb Vitor Soares:
Hi,

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")

Could someone familiar with these recent changes help identify what 
might have
changed in the mode selection logic?

=== Example logs ===

Verdin iMX8M Mini (SPL failure):

U-Boot SPL 2026.01-0.0.0-devel+git.53c0d5b38795 (Jan 06 2026 - 
20:44:27 +0000)
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s 
timeout)
SEC0:  RNG instantiated
Trying to boot from MMC1
unable to select a mode: -5
spl: mmc init failed with error: -524
Error: -524
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

---

Verdin iMX8M Plus (U-Boot proper failure):

U-Boot SPL 2026.01-0.0.0-devel+git.53c0d5b38795 (Jan 06 2026 - 
20:44:27 +0000)
DDR configured as dual rank
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s 
timeout)
SEC0:  RNG instantiated
Normal Boot
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x?, size 1208151552
Need continue download 1024
load_simple_fit: Skip load 'tee': image size is 0!
NOTICE:  Do not release JR0 to NS as it can be used by HAB
NOTICE:  BL31: v2.12.0(release):lf-6.12.20-2.0.0-dirty
NOTICE:  BL31: Built : 08:15:07, May  9 2025

U-Boot 2026.01-0.0.0-devel+git.53c0d5b38795 (Jan 06 2026 - 20:44:27 
+0000)

CPU:   NXP i.MX8MP[8] Rev1.1 A53 at 1200 MHz
CPU:   Industrial temperature grade (-40C to 105C) at 23C
DRAM:  8 GiB
Core:  309 devices, 31 uclasses, devicetree: separate
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s 
timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... unable to select a mode: -5

Verdin iMX8MP # saveenv
Saving Environment to MMC... unable to select a mode: -5
No block device
Failed (1)

---

SMARC iMX8M Plus:

U-Boot SPL 2026.01-0.0.0-devel+git.53c0d5b38795 (Jan 06 2026 - 
20:44:27 +0000)
Training FAILED
DDR configured as single rank
SEC0:  RNG instantiated
Normal Boot
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x?, size 1208152064
Need continue download 1024
load_simple_fit: Skip load 'tee': image size is 0!
NOTICE:  Do not release JR0 to NS as it can be used by HAB
NOTICE:  BL31: v2.12.0(release):lf-6.12.20-2.0.0-dirty
NOTICE:  BL31: Built : 08:15:07, May  9 2025

U-Boot 2026.01-0.0.0-devel+git.53c0d5b38795 (Jan 06 2026 - 20:44:27 
+0000)

CPU:   NXP i.MX8MP[8] Rev1.1 A53 at 1200 MHz
CPU:   Industrial temperature grade (-40C to 105C) at 23C
DRAM:  4 GiB
Core:  317 devices, 32 uclasses, devicetree: separate
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s 
timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC... unable to select a mode: -5
*** Warning - No block device, using default environment
unable to select a mode: -5
MMC init failed
---

I'm available to test patches or provide additional debug output if 
needed.

Best regards,
Vitor Soares

Hi Victor,

what frequencies are output when you enable DEBUG output in mmc.c?

I'm currently trying to find a solution for why the SD card and MMC in 
U-Boot (they work fine in SPL) are only running at a minimum frequency 
on the TQMa6 (iMX6) and TQMa6UL (iMX6UL).

My problem comes from commit aebb523a2381 ("mmc: mmc-uclass: Use max- 
frequency from device tree with.


=== Example logs ===

U-Boot SPL 2026.01+g6955caf8885+p13111 (Jan 07 2026 - 15:26:17 +0100)
SD
Trying to boot from MMC2
clock is disabled (0Hz)
clock is enabled (400000Hz)
clock is enabled (50000000Hz)
Device tree: imx6q-mba6a


U-Boot 2026.01+g6955caf8885+p13111 (Jan 07 2026 - 15:26:17 +0100)

CPU:   Freescale i.MX6D rev1.3 at 792MHz
CPU:   Industrial temperature grade (-40C to 105C) at 20C
Reset cause: POR
Model: TQ TQMa6Q on MBa6x
Board: TQMa6D on a MBa6x
Enet workaround: Unknown
DRAM:  1 GiB
Core:  104 devices, 27 uclasses, devicetree: separate
WDT:   Started watchdog@20bc000 with servicing every 1000ms (128s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC... clock is disabled (0Hz)
clock is enabled (400000Hz)
clock is enabled (400000Hz)
Reading from redundant MMC(1)... OK
In:    serial@21e8000
Out:   serial@21e8000
Err:   serial@21e8000
clock is disabled (0Hz)
clock is enabled (400000Hz)
clock is enabled (400000Hz)
switch to partitions #0, OK
mmc1 is current device


Hi Vitor,

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).
Or Revert the commit aebb523a2381, since platform data from 
dev_get_plat() is calloc-allocated (zeroed), so prior behavior left 
f_max at 0 until the driver set it—restoring the hardcoded limit.

Let me know if this aligns with what you're observing.

Regards,
Tanmay