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

