[U-Boot] [PATCH] mmc: Downgrade SD/MMC from UHS/HS200/HS400 modes before boot

[Faiz Abbas]

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 at 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 at 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 at 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