On 6/26/19 11:22 AM, Jean-Jacques Hiblot wrote: > > On 25/06/2019 21:47, Marek Vasut wrote: >> On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote: >>> On 25/06/2019 17:53, Marek Vasut wrote: >>>> On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote: >>>>> Hi Marek, >>>>> >>>>> On 06/02/2019 14:11, Marek Vasut wrote: >>>>>> When using CMD6 to switch eMMC card timing from HS200/HS400 to >>>>>> HS/legacy, >>>>>> do not poll for the completion status using CMD13, but rather wait >>>>>> 50mS. >>>>>> >>>>>> Once the card receives the CMD6 and starts executing it, the bus >>>>>> is in >>>>>> undefined state until both the card finishes executing the command >>>>>> and >>>>>> until the controller switches the bus to matching timing >>>>>> configuration. >>>>>> During this time, it is not possible to transport any commands or >>>>>> data >>>>>> across the bus, which includes the CMD13. >>>>> Is it something that affects all platforms ? >>>>> >>>>> I've been working on this on TI platforms lately and although I've >>>>> seen >>>>> the same kind of problems. But they mostly go away If the code >>>>> handling >>>>> the switch handles the SWITCH_ERROR bit. >>>> The error probably happens because you send the card a command, but the >>>> command hits the bus that's in some weird intermediate state. Either >>>> the >>>> card didn't finish switching the bus properties yet, or it did, or it's >>>> in the middle of it, but you cannot tell. >>> OK thanks for the response. >>> >>> If CMD13 can't be used because the bus is in an undefined state, >>> shouldn't send_cmd(CMD13) just fail ? >> So it would fail, but how do you guarantee the bus/card switched to the >> new state and is reliably ready ? You can't, because you cannot >> communicate with the card -- which is the entire problem here, you have >> no way to communicate with the card while the bus is switching. However, >> you can wait the maximum allowed time according to the spec, and then >> the bus/card must be ready. If not, all bets are off. >> >>> I'm asking because this is a 50ms delay in the hot path of the boot >>> process. >> I totally understand that, I have the same issue with HS200/HS400 on >> R-Car Gen3, all the calibration shenanigans and this indeed add quite a* >> bit to the boot time. But I don't have a good answer here. > > I'll post something using the existing wait_dat0() callback. If the > callback is implemented, we can forgo the 50ms delay and poll the dat0 > line.
We can ? Do you have some more details ? -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
