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

[Marek Vasut]

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

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.

-- 
Best regards,
Marek Vasut