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

[Faiz Abbas]

Peng, Marek,

On 11/06/19 6:47 AM, Peng Fan wrote:
>> partitions
>>
>> On 6/10/19 7:59 AM, Peng Fan wrote:
>>>> Subject: Re: [U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing
>>>> boot partitions
>>>>
>>>> Hi Marek, Peng,
>>>>
>>>> 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.
>>>
>>> Yes, the spec does not mention this. It only mentions HS200/400 not
>>> supported during boot operation.
>>>
>>>>
>>>> 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.
>>>
>>> There might be bug in U-Boot code.
>>
>> So are we gonna leave this inconsistency in for current release or what's it
>> gonna be ? Like I said, we're in rc3, it's fine to do bigger changes in next
>> release, but we should at least fix this in current release.
> 
> I'll pick up your patch in this release.
> 

The issue that Marek is facing is not a regression, is it? Are we really
going to merge something that we know to be wrong just so we are
consistently wrong?

Marek, I understand you do not want to debug this right now but this
patch will 1) Mislead people into thinking that we know what we are
doing (two patches went in with pretty confident patch descriptions) and
2) Mask issues for people who could take the time to help debug this.

Thanks,
Faiz