Re: [PATCH 1/1] Production State Awareness support in host side

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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




[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux