Download microcode proposals

James C Hatfield james.c.hatfield at seagate.com
Tue Jun 24 14:16:17 PDT 2014


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1406241_f.htm">HTML-formatted message</a>

Bill (and others),
I should point out that ACS-3 defines different behaviour for one case.
ACS-3 requires that (if a a new download is started from the beginning, but
with a different mode) the previous download in process is cancelled and
the new download mode begins as if nothing bad happened. This is not a
reported error.
Note, that if the mode changes and the buffer offset is non-zero (and
consecutive from the previous segment), this is an error for ATA also.
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....: 720-684-2711
   cell...: 720-771-8914
On Tue, Jun 24, 2014 at 3:06 PM, Bill Martin-SSI <
bill.martin at ssi.samsung.com> wrote:
>  There were a number of comments on 14-121r1 and 14-150r0. This email
> attempts to summarize the responses and is an attempt to gain consensus
> prior to the next T10 meeting.
>
>
>
> 1)	  On the changing the MODE field in subsequent downloads:
>
> a.	   Seagate – declare an error if the MODE field changes from what
> was sent in the first segment, with an ASC of INVALID FIELD IN CDB;
>
> b.	  HP – MODE field changes for the last download for a download
> sequence and this MODE determines the activation method – no error
> generated for changes in the MODE field between segments; and
>
> c.	   IBM – would be acceptable with “may terminate” with an ASC
of COMMAND
> SEQUENCE ERROR;
>
> 2)	  On the MODE SPECIFIC field in different segments:
>
> a.	   Seagate – Capture the MODE SPECIFIC on the first download with
> MODE 0Dh and error if it changes;
>
> b.	  HP – did not address this issue; and
>
> c.	   IBM – use the value in the last segment and ignore the value in
> other segments with no error generated.
>
>
>
> There are some significant differences in this list where one
> implementation generates an error where another would have problems with an
> error being generated. Is there some middle ground that would allow
> application clients to know how a device server will respond?
>
>
>
> Thanks for any input,
>
>
>
> Bill Martin
>
> SSD I/O Standards
>
> Samsung Semiconductor, Inc.
>
> Cell (408) 499-1839
>
>
>
>
>



More information about the T10 mailing list