| Message ID | 20190214132655.26211-1-marek.vasut+renesas@gmail.com |
|---|---|
| State | Accepted |
| Commit | fceea9926804c8e72bdcde27bf64bebedcf0a754 |
| Delegated to: | Marek Vasut |
| Headers | show |
| Series | [U-Boot] mmc: Downgrade SD/MMC from UHS/HS200/HS400 modes before boot | expand |
Hi, On 14/02/19 6:56 PM, Marek Vasut wrote: > Older kernel versions or systems which do not connect eMMC reset line > properly may not be able to handle situations where either the eMMC > is left in HS200/HS400 mode or SD card in UHS modes by the bootloader > and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card > to non-UHS mode before booting the kernel to allow such older kernels > to work with modern U-Boot. This broke boot on all dra7xx devices. The fallback to DDR52 doesn't go through and all following commands timeout. Log: U-Boot 2019.04-rc4-00018-ga00d15757d (Mar 20 2019 - 17:25:22 +0200) CPU : DRA752-GP ES2.0 Model: TI DRA742 Board: DRA74x EVM REV H.0 DRAM: 4 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Loading Environment from FAT... *** Warning - bad CRC, using default environment Loading Environment from MMC... OK Net: eth0: ethernet@48484000 Hit any key to stop autoboot: 0 => => boot Booting from network ... link up on port 0, speed 1000, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.1.52 (246 ms) link up on port 0, speed 1000, full duplex Using ethernet@48484000 device TFTP from server 192.168.1.36; our IP address is 192.168.1.52 Filename 'zImage'. Load address: 0x87000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################################# 3.3 MiB/s done Bytes transferred = 3556144 (364330 hex) link up on port 0, speed 1000, full duplex Using ethernet@48484000 device TFTP from server 192.168.1.36; our IP address is 192.168.1.52 Filename 'dra7-evm.dtb'. Load address: 0x88000000 Loading: ###################### 2.9 MiB/s done Bytes transferred = 108307 (1a713 hex) ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Device Tree to 8ffe2000, end 8ffff712 ... OK Using machid 0xfe6 from environment Starting kernel ... omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear Thanks, Faiz
On 5/2/19 9:57 AM, Faiz Abbas wrote: > Hi, Hi, > On 14/02/19 6:56 PM, Marek Vasut wrote: >> Older kernel versions or systems which do not connect eMMC reset line >> properly may not be able to handle situations where either the eMMC >> is left in HS200/HS400 mode or SD card in UHS modes by the bootloader >> and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card >> to non-UHS mode before booting the kernel to allow such older kernels >> to work with modern U-Boot. > > This broke boot on all dra7xx devices. The fallback to DDR52 doesn't go > through and all following commands timeout. > > Log: > > U-Boot 2019.04-rc4-00018-ga00d15757d (Mar 20 2019 - 17:25:22 +0200) > > CPU : DRA752-GP ES2.0 > Model: TI DRA742 > Board: DRA74x EVM REV H.0 > DRAM: 4 GiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > Loading Environment from MMC... OK > Net: eth0: ethernet@48484000 > Hit any key to stop autoboot: 0 > => > => boot > Booting from network ... > link up on port 0, speed 1000, full duplex > BOOTP broadcast 1 > DHCP client bound to address 192.168.1.52 (246 ms) > link up on port 0, speed 1000, full duplex > Using ethernet@48484000 device > TFTP from server 192.168.1.36; our IP address is 192.168.1.52 > Filename 'zImage'. > Load address: 0x87000000 > Loading: ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ################################################################# > ############################################# > 3.3 MiB/s > done > Bytes transferred = 3556144 (364330 hex) > link up on port 0, speed 1000, full duplex > Using ethernet@48484000 device > TFTP from server 192.168.1.36; our IP address is 192.168.1.52 > Filename 'dra7-evm.dtb'. > Load address: 0x88000000 > Loading: ###################### > 2.9 MiB/s > done > Bytes transferred = 108307 (1a713 hex) > ## Flattened Device Tree blob at 88000000 > Booting using the fdt blob at 0x88000000 > Loading Device Tree to 8ffe2000, end 8ffff712 ... OK > Using machid 0xfe6 from environment > > Starting kernel ... > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear This seems to be a kernel bug ?
Hi Marek, On 02/05/19 3:39 PM, Marek Vasut wrote: > On 5/2/19 9:57 AM, Faiz Abbas wrote: >> Hi, > > Hi, > >> On 14/02/19 6:56 PM, Marek Vasut wrote: >>> Older kernel versions or systems which do not connect eMMC reset line >>> properly may not be able to handle situations where either the eMMC >>> is left in HS200/HS400 mode or SD card in UHS modes by the bootloader >>> and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card >>> to non-UHS mode before booting the kernel to allow such older kernels >>> to work with modern U-Boot. >> >> This broke boot on all dra7xx devices. The fallback to DDR52 doesn't go >> through and all following commands timeout. >> >> Log: >> >> U-Boot 2019.04-rc4-00018-ga00d15757d (Mar 20 2019 - 17:25:22 +0200) >> >> CPU : DRA752-GP ES2.0 >> Model: TI DRA742 >> Board: DRA74x EVM REV H.0 >> DRAM: 4 GiB >> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 >> Loading Environment from FAT... *** Warning - bad CRC, using default >> environment >> >> Loading Environment from MMC... OK >> Net: eth0: ethernet@48484000 >> Hit any key to stop autoboot: 0 >> => >> => boot >> Booting from network ... >> link up on port 0, speed 1000, full duplex >> BOOTP broadcast 1 >> DHCP client bound to address 192.168.1.52 (246 ms) >> link up on port 0, speed 1000, full duplex >> Using ethernet@48484000 device >> TFTP from server 192.168.1.36; our IP address is 192.168.1.52 >> Filename 'zImage'. >> Load address: 0x87000000 >> Loading: ################################################################# >> ################################################################# >> ################################################################# >> ################################################################# >> ################################################################# >> ################################################################# >> ################################################################# >> ################################################################# >> ################################################################# >> ################################################################# >> ############################################# >> 3.3 MiB/s >> done >> Bytes transferred = 3556144 (364330 hex) >> link up on port 0, speed 1000, full duplex >> Using ethernet@48484000 device >> TFTP from server 192.168.1.36; our IP address is 192.168.1.52 >> Filename 'dra7-evm.dtb'. >> Load address: 0x88000000 >> Loading: ###################### >> 2.9 MiB/s >> done >> Bytes transferred = 108307 (1a713 hex) >> ## Flattened Device Tree blob at 88000000 >> Booting using the fdt blob at 0x88000000 >> Loading Device Tree to 8ffe2000, end 8ffff712 ... OK >> Using machid 0xfe6 from environment >> >> Starting kernel ... >> >> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > This seems to be a kernel bug ? Kernel MMC hasn't even probed yet. This omap_hsmmc_send_cmd print is coming from drivers/mmc/omap_hsmmc.c:1066 Here's the Log with MMC_TRACE enabled:https://pastebin.ubuntu.com/p/M3W3DVjqn5/ Thanks, Faiz
On 5/2/19 12:24 PM, Faiz Abbas wrote: > Hi Marek, > > On 02/05/19 3:39 PM, Marek Vasut wrote: >> On 5/2/19 9:57 AM, Faiz Abbas wrote: >>> Hi, >> >> Hi, >> >>> On 14/02/19 6:56 PM, Marek Vasut wrote: >>>> Older kernel versions or systems which do not connect eMMC reset line >>>> properly may not be able to handle situations where either the eMMC >>>> is left in HS200/HS400 mode or SD card in UHS modes by the bootloader >>>> and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card >>>> to non-UHS mode before booting the kernel to allow such older kernels >>>> to work with modern U-Boot. >>> >>> This broke boot on all dra7xx devices. The fallback to DDR52 doesn't go >>> through and all following commands timeout. >>> >>> Log: >>> >>> U-Boot 2019.04-rc4-00018-ga00d15757d (Mar 20 2019 - 17:25:22 +0200) >>> >>> CPU : DRA752-GP ES2.0 >>> Model: TI DRA742 >>> Board: DRA74x EVM REV H.0 >>> DRAM: 4 GiB >>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 >>> Loading Environment from FAT... *** Warning - bad CRC, using default >>> environment >>> >>> Loading Environment from MMC... OK >>> Net: eth0: ethernet@48484000 >>> Hit any key to stop autoboot: 0 >>> => >>> => boot >>> Booting from network ... >>> link up on port 0, speed 1000, full duplex >>> BOOTP broadcast 1 >>> DHCP client bound to address 192.168.1.52 (246 ms) >>> link up on port 0, speed 1000, full duplex >>> Using ethernet@48484000 device >>> TFTP from server 192.168.1.36; our IP address is 192.168.1.52 >>> Filename 'zImage'. >>> Load address: 0x87000000 >>> Loading: ################################################################# >>> ################################################################# >>> ################################################################# >>> ################################################################# >>> ################################################################# >>> ################################################################# >>> ################################################################# >>> ################################################################# >>> ################################################################# >>> ################################################################# >>> ############################################# >>> 3.3 MiB/s >>> done >>> Bytes transferred = 3556144 (364330 hex) >>> link up on port 0, speed 1000, full duplex >>> Using ethernet@48484000 device >>> TFTP from server 192.168.1.36; our IP address is 192.168.1.52 >>> Filename 'dra7-evm.dtb'. >>> Load address: 0x88000000 >>> Loading: ###################### >>> 2.9 MiB/s >>> done >>> Bytes transferred = 108307 (1a713 hex) >>> ## Flattened Device Tree blob at 88000000 >>> Booting using the fdt blob at 0x88000000 >>> Loading Device Tree to 8ffe2000, end 8ffff712 ... OK >>> Using machid 0xfe6 from environment >>> >>> Starting kernel ... >>> >>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >> >> This seems to be a kernel bug ? > > Kernel MMC hasn't even probed yet. This omap_hsmmc_send_cmd print is > coming from drivers/mmc/omap_hsmmc.c:1066 > > Here's the Log with MMC_TRACE > enabled:https://pastebin.ubuntu.com/p/M3W3DVjqn5/ Oh, could it be the clock were disabled at this point already ? Or something along those lines. I don't have any omap board to test it on, can you debug it ?
Hi Marek, On 02/05/19 4:54 PM, Marek Vasut wrote: > On 5/2/19 12:24 PM, Faiz Abbas wrote: >> Hi Marek, >> >> On 02/05/19 3:39 PM, Marek Vasut wrote: >>> On 5/2/19 9:57 AM, Faiz Abbas wrote: >>>> Hi, >>> >>> Hi, >>> >>>> On 14/02/19 6:56 PM, Marek Vasut wrote: >>>>> Older kernel versions or systems which do not connect eMMC reset line >>>>> properly may not be able to handle situations where either the eMMC >>>>> is left in HS200/HS400 mode or SD card in UHS modes by the bootloader >>>>> and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card >>>>> to non-UHS mode before booting the kernel to allow such older kernels >>>>> to work with modern U-Boot. >>>> >>>> This broke boot on all dra7xx devices. The fallback to DDR52 doesn't go >>>> through and all following commands timeout. >>>> >>>> Log: >>>> >>>> U-Boot 2019.04-rc4-00018-ga00d15757d (Mar 20 2019 - 17:25:22 +0200) >>>> >>>> CPU : DRA752-GP ES2.0 >>>> Model: TI DRA742 >>>> Board: DRA74x EVM REV H.0 >>>> DRAM: 4 GiB >>>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 >>>> Loading Environment from FAT... *** Warning - bad CRC, using default >>>> environment >>>> >>>> Loading Environment from MMC... OK >>>> Net: eth0: ethernet@48484000 >>>> Hit any key to stop autoboot: 0 >>>> => >>>> => boot >>>> Booting from network ... >>>> link up on port 0, speed 1000, full duplex >>>> BOOTP broadcast 1 >>>> DHCP client bound to address 192.168.1.52 (246 ms) >>>> link up on port 0, speed 1000, full duplex >>>> Using ethernet@48484000 device >>>> TFTP from server 192.168.1.36; our IP address is 192.168.1.52 >>>> Filename 'zImage'. >>>> Load address: 0x87000000 >>>> Loading: ################################################################# >>>> ################################################################# >>>> ################################################################# >>>> ################################################################# >>>> ################################################################# >>>> ################################################################# >>>> ################################################################# >>>> ################################################################# >>>> ################################################################# >>>> ################################################################# >>>> ############################################# >>>> 3.3 MiB/s >>>> done >>>> Bytes transferred = 3556144 (364330 hex) >>>> link up on port 0, speed 1000, full duplex >>>> Using ethernet@48484000 device >>>> TFTP from server 192.168.1.36; our IP address is 192.168.1.52 >>>> Filename 'dra7-evm.dtb'. >>>> Load address: 0x88000000 >>>> Loading: ###################### >>>> 2.9 MiB/s >>>> done >>>> Bytes transferred = 108307 (1a713 hex) >>>> ## Flattened Device Tree blob at 88000000 >>>> Booting using the fdt blob at 0x88000000 >>>> Loading Device Tree to 8ffe2000, end 8ffff712 ... OK >>>> Using machid 0xfe6 from environment >>>> >>>> Starting kernel ... >>>> >>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>> >>> This seems to be a kernel bug ? >> >> Kernel MMC hasn't even probed yet. This omap_hsmmc_send_cmd print is >> coming from drivers/mmc/omap_hsmmc.c:1066 >> >> Here's the Log with MMC_TRACE >> enabled:https://pastebin.ubuntu.com/p/M3W3DVjqn5/ > > Oh, could it be the clock were disabled at this point already ? > Or something along those lines. I don't have any omap board to test it > on, can you debug it ? > I found that the real culprit is 6892550c4aea4 ("mmc: Do not poll using CMD13 when changing timing"). The issue also happens when I just do an mmc dev 1 1 (boot0 partition of eMMC) which also involves downgrade from HS200 to DDR52. It seems the CMD13 after switch down is required for this device. Any ideas why this could be happening? Thanks, Faiz
On 5/7/19 7:29 PM, Faiz Abbas wrote: > Hi Marek, > > On 02/05/19 4:54 PM, Marek Vasut wrote: >> On 5/2/19 12:24 PM, Faiz Abbas wrote: >>> Hi Marek, >>> >>> On 02/05/19 3:39 PM, Marek Vasut wrote: >>>> On 5/2/19 9:57 AM, Faiz Abbas wrote: >>>>> Hi, >>>> >>>> Hi, >>>> >>>>> On 14/02/19 6:56 PM, Marek Vasut wrote: >>>>>> Older kernel versions or systems which do not connect eMMC reset line >>>>>> properly may not be able to handle situations where either the eMMC >>>>>> is left in HS200/HS400 mode or SD card in UHS modes by the bootloader >>>>>> and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card >>>>>> to non-UHS mode before booting the kernel to allow such older kernels >>>>>> to work with modern U-Boot. >>>>> >>>>> This broke boot on all dra7xx devices. The fallback to DDR52 doesn't go >>>>> through and all following commands timeout. >>>>> >>>>> Log: >>>>> >>>>> U-Boot 2019.04-rc4-00018-ga00d15757d (Mar 20 2019 - 17:25:22 +0200) >>>>> >>>>> CPU : DRA752-GP ES2.0 >>>>> Model: TI DRA742 >>>>> Board: DRA74x EVM REV H.0 >>>>> DRAM: 4 GiB >>>>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 >>>>> Loading Environment from FAT... *** Warning - bad CRC, using default >>>>> environment >>>>> >>>>> Loading Environment from MMC... OK >>>>> Net: eth0: ethernet@48484000 >>>>> Hit any key to stop autoboot: 0 >>>>> => >>>>> => boot >>>>> Booting from network ... >>>>> link up on port 0, speed 1000, full duplex >>>>> BOOTP broadcast 1 >>>>> DHCP client bound to address 192.168.1.52 (246 ms) >>>>> link up on port 0, speed 1000, full duplex >>>>> Using ethernet@48484000 device >>>>> TFTP from server 192.168.1.36; our IP address is 192.168.1.52 >>>>> Filename 'zImage'. >>>>> Load address: 0x87000000 >>>>> Loading: ################################################################# >>>>> ################################################################# >>>>> ################################################################# >>>>> ################################################################# >>>>> ################################################################# >>>>> ################################################################# >>>>> ################################################################# >>>>> ################################################################# >>>>> ################################################################# >>>>> ################################################################# >>>>> ############################################# >>>>> 3.3 MiB/s >>>>> done >>>>> Bytes transferred = 3556144 (364330 hex) >>>>> link up on port 0, speed 1000, full duplex >>>>> Using ethernet@48484000 device >>>>> TFTP from server 192.168.1.36; our IP address is 192.168.1.52 >>>>> Filename 'dra7-evm.dtb'. >>>>> Load address: 0x88000000 >>>>> Loading: ###################### >>>>> 2.9 MiB/s >>>>> done >>>>> Bytes transferred = 108307 (1a713 hex) >>>>> ## Flattened Device Tree blob at 88000000 >>>>> Booting using the fdt blob at 0x88000000 >>>>> Loading Device Tree to 8ffe2000, end 8ffff712 ... OK >>>>> Using machid 0xfe6 from environment >>>>> >>>>> Starting kernel ... >>>>> >>>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>>> omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear >>>> >>>> This seems to be a kernel bug ? >>> >>> Kernel MMC hasn't even probed yet. This omap_hsmmc_send_cmd print is >>> coming from drivers/mmc/omap_hsmmc.c:1066 >>> >>> Here's the Log with MMC_TRACE >>> enabled:https://pastebin.ubuntu.com/p/M3W3DVjqn5/ >> >> Oh, could it be the clock were disabled at this point already ? >> Or something along those lines. I don't have any omap board to test it >> on, can you debug it ? >> > > I found that the real culprit is 6892550c4aea4 ("mmc: Do not poll using > CMD13 when changing timing"). The issue also happens when I just do an > mmc dev 1 1 (boot0 partition of eMMC) which also involves downgrade from > HS200 to DDR52. It seems the CMD13 after switch down is required for > this device. Any ideas why this could be happening? Could it rather be that degrading from HS200 to DDR52 is broken ? I think the board I use downgrades from HS200/HS400 to non-DDR mode. Try disabling the DDR52 mode support in DT and see what happens ... maybe that would be a useful pointer.
diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c index 76225b7939..a9c8f335c1 100644 --- a/drivers/mmc/mmc-uclass.c +++ b/drivers/mmc/mmc-uclass.c @@ -368,6 +368,19 @@ static int mmc_blk_probe(struct udevice *dev) return 0; } +#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \ + CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \ + CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) +static int mmc_blk_remove(struct udevice *dev) +{ + struct udevice *mmc_dev = dev_get_parent(dev); + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(mmc_dev); + struct mmc *mmc = upriv->mmc; + + return mmc_deinit(mmc); +} +#endif + static const struct blk_ops mmc_blk_ops = { .read = mmc_bread, #if CONFIG_IS_ENABLED(MMC_WRITE) @@ -382,6 +395,12 @@ U_BOOT_DRIVER(mmc_blk) = { .id = UCLASS_BLK, .ops = &mmc_blk_ops, .probe = mmc_blk_probe, +#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \ + CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \ + CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) + .remove = mmc_blk_remove, + .flags = DM_FLAG_OS_PREPARE, +#endif }; #endif /* CONFIG_BLK */ diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index b04345a1e1..1c1527cc74 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -2781,6 +2781,32 @@ int mmc_init(struct mmc *mmc) return err; } +#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \ + CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \ + CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) +int mmc_deinit(struct mmc *mmc) +{ + u32 caps_filtered; + + if (!mmc->has_init) + return 0; + + if (IS_SD(mmc)) { + caps_filtered = mmc->card_caps & + ~(MMC_CAP(UHS_SDR12) | MMC_CAP(UHS_SDR25) | + MMC_CAP(UHS_SDR50) | MMC_CAP(UHS_DDR50) | + MMC_CAP(UHS_SDR104)); + + return sd_select_mode_and_width(mmc, caps_filtered); + } else { + caps_filtered = mmc->card_caps & + ~(MMC_CAP(MMC_HS_200) | MMC_CAP(MMC_HS_400)); + + return mmc_select_mode_and_width(mmc, caps_filtered); + } +} +#endif + int mmc_set_dsr(struct mmc *mmc, u16 val) { mmc->dsr = val; diff --git a/include/mmc.h b/include/mmc.h index d84e4fca73..1f30f71d25 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -690,6 +690,12 @@ int mmc_initialize(bd_t *bis); int mmc_init(struct mmc *mmc); int mmc_send_tuning(struct mmc *mmc, u32 opcode, int *cmd_error); +#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \ + CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \ + CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) +int mmc_deinit(struct mmc *mmc); +#endif + /** * mmc_of_parse() - Parse the device tree to get the capabilities of the host *
Older kernel versions or systems which do not connect eMMC reset line properly may not be able to handle situations where either the eMMC is left in HS200/HS400 mode or SD card in UHS modes by the bootloader and may misbehave. Downgrade the eMMC to HS/HS52 mode and/or SD card to non-UHS mode before booting the kernel to allow such older kernels to work with modern U-Boot. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Tom Rini <trini@konsulko.com> --- drivers/mmc/mmc-uclass.c | 19 +++++++++++++++++++ drivers/mmc/mmc.c | 26 ++++++++++++++++++++++++++ include/mmc.h | 6 ++++++ 3 files changed, 51 insertions(+)