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. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
