From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 11 Jun 2019 12:04:04 +0200 Subject: [U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing boot partitions In-Reply-To: <39df182a-dbc8-b688-fa5a-43907bffc5a3@ti.com> References: <20190531132244.29719-1-marek.vasut+renesas@gmail.com> <43c3efe1-55cf-91e3-34c3-c509d0a7207d@ti.com> <3e2e9363-bf4d-84db-867b-130c3709bbb3@gmail.com> <39df182a-dbc8-b688-fa5a-43907bffc5a3@ti.com> Message-ID: <722b00d2-f1d2-3382-9e6c-41d1e4aa5f20@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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