[U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing boot partitions

[Marek Vasut]

On 6/4/19 3:34 PM, Faiz Abbas wrote:
> Hi Marek,
> 
> On 04/06/19 6:56 PM, Marek Vasut wrote:
>> On 6/4/19 1:22 PM, Faiz Abbas wrote:
>>> Hi Marek, Peng,
>>
>> Hi,
>>
>>> On 03/06/19 12:04 PM, Peng Fan wrote:
>>>>
>>>>> Subject: [PATCH] mmc: Avoid HS400 mode when accessing boot partitions
>>>>>
>>>>> According to JEDEC JESD84-B51.pdf section 6.3.3 Boot operation ,
>>>>> HS200 & HS400 mode is not supported during boot operation. The U-Boot
>>>>> code currently only applies this restriction to HS200 mode, extend this to
>>>>> HS400 mode as well.
>>> The spec in section 6.3.3 (according to my understanding) is talking
>>> about "boot operation" which is a way of getting data from the the eMMC
>>> without going through the Device identification mode (Section 6.4.4)
>>> i.e. without sending any commands. All the host has to do is hold the
>>> command line low in Pre-Idle mode to automatically receive data at the
>>> preconfigured frequency and bus width.
>>>
>>> When U-boot is accessing the partition, it has already gone through the
>>> Device identification mode and is in data transfer mode (i.e. it needs
>>> to send commands for read/write to happen). In this case, we need to
>>> switch the partition in Extended CSD to access the boot partition
>>> (Section 6.2.5). The spec doesn't say anything about HS200 and HS400 not
>>> being supported here.
>>>
>>> Also, I don't see linux kernel switching down speed when trying to
>>> access a boot partition (unless its being very sneaky about it). So if
>>> you are seeing issues with accessing boot partitions at HS200/HS400 then
>>> you should probably look at how linux code is working instead.
>>
>> Did you practically verify this ? In my case, the boot partition access
>> fails in HS200/HS400 mode (samsung and sandisk emmc, but I'd have to
>> check the exact part number).
>>
>> commit 01298da31d92ecc46cf9130d8cff68bc51698197
>>     mmc: Change mode when switching to a boot partition
>> seems to confirm that too.
>>
> 
> I had tried to raise these concerns for that patch as well
> (https://www.spinics.net/lists/linux-mmc/msg50432.html) but it was
> missed at that time.
> 
> I did verify that kernel is not switching speeds on a dra7xx board. JJ
> and I have seen failures similar to yours in u-boot (which led to this
> patch) but not in kernel which makes me think that the fix was wrong.
> Have you verified with your setup in kernel?

No, but I'll add it to the list of things to look into.

In the meantime, this should go in anyway, to make the code consistent.

-- 
Best regards,
Marek Vasut