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

Thu Jan 8 09:07:57 CET 2026

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 at 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 at 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 at 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 at 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 at 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 at 21e8000
> Out:   serial at 21e8000
> Err:   serial at 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