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

Marek Vasut marek.vasut at gmail.com
Tue Jun 11 10:04:04 UTC 2019


On 6/11/19 10:12 AM, Faiz Abbas wrote:
> 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?

First of all, you established this is "wrong" without any real backing
except for your interpretation of the specification. I would still like
to hear from Jean the real reason why he added this filtering in the
first place.

That said, we're in rc4 , the release is just around the corner. I would
like to avoid big changes in the MMC subsystem , or any subsystem for
that matter. That's for next release , and if you have a patch for next,
please post it, I am happy to test it on the hardware I have available.

Also note that this patch does not have any impact on general use case,
the regular bulk of the eMMC can be accessed at HS200/HS400, it's just
the boot partitions which are accessed in HS52 or lower.

However, right now, the behavior is not consistent between HS200 and
HS400 modes, and I would very much like to have it consistent in the
upcoming release.

> 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.

Wrong, I want to debug this, I just don't want to do big changes in the
upcoming release this late in the release cycle. But if you propose a
patch for next, I am happy to test it on the hardware I have available.
Can you send such a patch ?

-- 
Best regards,
Marek Vasut


More information about the U-Boot mailing list