> -----Original Message----- > From: linux-mmc-owner@xxxxxxxxxxxxxxx [mailto:linux-mmc- > owner@xxxxxxxxxxxxxxx] On Behalf Of Ulf Hansson > Sent: Wednesday, December 03, 2014 2:29 PM > To: Alex Lemberg > Cc: linux-mmc; Chris Ball; Avi Shchislowski > Subject: Re: [PATCH 1/1] Production State Awareness support in host side > > On 3 December 2014 at 12:39, Alex Lemberg <Alex.Lemberg@xxxxxxxxxxx> > wrote: > > Hi Ulf, > > > >> -----Original Message----- > >> From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxx] > >> Sent: Tuesday, December 02, 2014 11:31 AM > >> To: Alex Lemberg > >> Cc: linux-mmc; Chris Ball; Avi Shchislowski > >> Subject: Re: [PATCH 1/1] Production State Awareness support in host > >> side > >> > >> On 25 November 2014 at 15:55, Alex Lemberg > <Alex.Lemberg@xxxxxxxxxxx> > >> wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxx] > >> >> Sent: Tuesday, November 25, 2014 12:57 PM > >> >> To: Alex Lemberg > >> >> Cc: linux-mmc; Chris Ball; Avi Shchislowski > >> >> Subject: Re: [PATCH 1/1] Production State Awareness support in > >> >> host side > >> >> > >> >> On 25 November 2014 at 10:17, Alex Lemberg > >> <Alex.Lemberg@xxxxxxxxxxx> > >> >> wrote: > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxx] > >> >> >> Sent: Monday, November 24, 2014 2:24 PM > >> >> >> To: Alex Lemberg > >> >> >> Cc: linux-mmc; Chris Ball; Avi Shchislowski > >> >> >> Subject: Re: [PATCH 1/1] Production State Awareness support in > >> >> >> host side > >> >> >> > >> >> >> [...] > >> >> >> > >> >> >> >> >> > >> >> >> >> >> I am not so sure we should finalize the production phase > >> >> >> >> >> while initializing the eMMC card like this. > >> >> >> >> >> > >> >> >> >> >> Certainly we should check the PSA state, but I think we > >> >> >> >> >> should return an error if we think the device hasn’t > >> >> >> >> >> completed production. It should be the responsibility for > >> >> >> >> >> the "programming tools" to finalize the > >> >> >> >> production, right!? > >> >> >> >> > > >> >> >> >> > According to eMMC spec, the switch to NORMAL should be > >> >> >> >> > done after device > >> >> >> >> soldering to final host (not programmer). > >> >> >> >> > Please refer to "Figure 32 — Recommended Soldering > procedure" > >> >> >> >> > in > >> >> >> >> eMMC5.0 specification document. > >> >> >> >> > Also, since we are dealing with only "field" host here, we > >> >> >> >> > are not > >> >> >> >> touching/switching any other modes of PSA, but only Normal > (field). > >> >> >> >> > This code should run only once - in the beginning of device life > cycle. > >> >> >> >> > >> >> >> >> I get your point, but I am not so sure. > >> >> >> >> > >> >> >> >> To me, I wouldn't trust that the platform binaries has been > >> >> >> >> successfully programmed to the device, unless the programmer > >> >> >> >> tool takes care of switching the device to "normal". > >> >> >> >> > >> >> >> > > >> >> >> > Thanks Ulf! > >> >> >> > Also, please note - PSA PRE_SOLDERING_POST_WRITES mode intent > >> >> >> > to save device pre-loaded content during the soldering process. > >> >> >> > Flash data can be corrupted due to soldering procedure high > >> >> >> > temperature. So switching to Normal cannot be done by > >> >> >> > external > >> >> >> programmer. > >> >> >> > >> >> >> So, if flash data will be corrupted due to for example high > >> >> >> temperatures during soldering, how will that be detected when > >> >> >> using the > >> >> "manual mode"? > >> >> >> > >> >> >> If that's the job for the platform software I fail to > >> >> >> understand why the PRE_SOLDERING_POST_WRITES state needs to > exists at all!? > >> >> > > >> >> > The flow of "Manual Mode" is: > >> >> > >> >> Thanks for clarifying. > >> >> > >> >> > > >> >> > [skipping few common steps] > >> >> > ... > >> >> > Host (Programmer) sets PRODUCTION_STATE_AWARENESS to 0x1 > >> >> > (PRE_SOLDERING_WRITES) > >> >> > > >> >> > Host (Programmer) perform pre-soldering data loading and/or > >> >> > device configuration > >> >> > > >> >> > Host (Programmer) sets PRODUCTION_STATE_AWARENESS To 0x2 > >> >> > (PRE_SOLDERING_POST_WRITES). > >> >> > No writes past this point > >> >> > >> >> To repeat my question: > >> >> > >> >> _Unless_ there are no validation of the device soldering performed > >> >> by the "programmer tool" past this point, why couldn't the host > >> >> set PRODUCTION_STATE_AWARENESS to 0x0 (NORMAL) at this point > instead? > >> >> > >> > > >> > If programmer set to NORMAL at this point, the programmed data can > >> > be corrupted during the soldering process. > >> > eMMC device will protect programmed data during the soldering > >> > process in PRE_SOLDERING_POST_WRITES (0x2) mode. > >> > >> Exactly how will that be done? > >> > >> During the soldering process the eMMC card isn't powered. So how > >> could it protect itself better, just because the state is > PRE_SOLDERING_POST_WRITES? > > > > The device will use "special" internal operations for saving content > > prior to device soldering, and will switch to "regular" after the soldering and > getting "NORMAL" mode. > > Huh, this is a seriously hard question to get some answer to. I still don't get it. > > Are you saying the card are able to protect itself during the soldering phase? I > assume soldiering is done without powering the card, thus I find it hard to > understand that your statement can be true. > > Anyway, to convenience me, you need to give at least one example of what > these protective operations could be during soldering. > Please let me try to clarify. The risk in soldering is that data which was loaded into the flash would be corrupted due to the heat of soldering the device to the host. To mitigate the risk the production tools (programmer) and host platform specify to the device its current state. Basically there are 2 types of states: pre-soldering state and post-soldering state (“Normal”). When the device controller identifies that it is in pre-soldering state it would use “special” flash programming manner in order to write to the flash. This “special” flash programming makes the data, which was previously written, immune to the risky soldering procedure and the data will not be corrupted at soldering. (However, “special” flash programming comes with a cost, which depends on the vendor proprietary solution). As you can see, the data protection is done while programming the data using the “special” method before the soldering and not during soldering. To reduce the cost to minimum, and allow proper operation of the storage device, the device should NOT use the “special” flash programming when it does not have to. To make sure that the device stops the “special” flash programming and resumes regular flash programming the device must know that it is in post-soldering state. This indication comes from the host when it sets PRODUCTION_STATE_AWARENESS back to NORMAL state. Therefore, the host platform needs to send this indication to the device AFTER device soldering to the platform. I hope that this clarifies the procedure and the need for sending the post-soldering indication to the device by the host platform. > Kind regards > Uffe > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body > of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at > http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
