Download microcode proposals

Ballard, Curtis C (HP Storage) curtis.ballard at
Fri Jun 6 10:13:19 PDT 2014

Attachment #1: <a href="">nameless-3052-2-1.html</a>

It appears to me that the download 'modes' may be getting mixed up.  I don't
see anything in 14-150r0 that addresses use of the MODE SPECIFIC field, only
the MODE field.  It is possible that similar issues exist for the MODE
SPECIFIC field but those do not appear to be discussed in 14-150r0.
HP has products handle the MODE field similar to the way IBM describes their
handling of the MODE SPECIFIC field.  Only valid MODE field settings are
allowed in the initial command and any subsequent intermediate commands.  The
MODE field setting in the final command determines the activation method.
The explanation provided by one developer was that since they could find no
method in SPC for determining which segment was the final segment they chose
to begin the transfer with a mode that does not save the firmware and use a
mode that has a save and activate rule for the final segment to notify the
device server that it should now save and prepare for activation as
Curtis Ballard
Hewlett-Packard Company
+1 970 898 3013 / Tel
Curtis.Ballard at / Email
Fort Collins, CO
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of Kevin D Butt
Sent: Friday, June 6, 2014 10:44 AM
To: Gerry Houlder; Bill Martin-SSI
Cc: owner-t10 at; T10 Reflector
Subject: Re: Download microcode proposals
IBM has products that use the MODE SPECIFIC field setting on the last segment
and uses that regardless of what was set in previous segments (though  we do
reject invalid values at all times).  Therefore, using the value in the first
segment and forcing a reject for subsequent non-matching values would make
IBM devices non-compliant.
IBM votes for using the value in the last segment and not requiring
consistent values throughout all the segments.	In reality, only the last
segment causes an action, all the others are just sending portions of the
Kevin D. Butt
SCSI Architect, Tape Firmware, T10 Standards
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at
From:	     Gerry Houlder
<gerry.houlder at>
To:	   T10 Reflector <t10 at<mailto:t10 at>>,
Date:	     06/06/2014 08:21 AM
Subject:	Re: Download microcode proposals
Sent by:	<owner-t10 at<mailto:owner-t10 at>>
Hi Bill,
I reviewed 14-150r0 and 14-121r1 and have these comments:
(a) The text in 14-150r0 lumps download options 07h and 0Eh in with option
0Dh in describing the error case. This is incorrect. Options 07h and 0Eh
always requires the MODE SPECIFIC field to be zero (i.e., the field is
reserved) just like all of the other download options, so these cases should
always result in ILLEGAL REQUEST sense key with INVALID FIELD IN CDB
additional sense if that field is ever non-zero.
(b) I verified that Seagate products remember the MODE SPECIFIC field setting
(for option 0Dh) on the first download command in a sequence (i.e., when the
BUFFER OFFSET is zero) and expect further download commands in the same
sequence to match that MODE SPECIFIC setting. If a further command doesn't
match the MODE SPECIFIC setting, then the command is rejected with ILLEGAL
REQUEST sense key and INVALID FIELD IN CDB additional sense code.
Seagate prefers using ILLEGAL REQUEST sense data to indicate that the command
is being discarded but any previously accepted download segments are
preserved, meaning that a correct download command resuming the sequence is
all that is needed for recovery. In most of the cases when COMMAND SEQUENCE
ERROR is reported, Seagate drives discard any previously received download
segments and expect the initiator to start over again from the beginning.
(c) Since the error situation described in 14-150 should only occur in
download option 0Dh (all other cases are covered by our existing rule about
reserved fields), then i prefer  error code response description to be in the
location indicated in proposal 14-121r1, not in the location indicated in
On Thu, Jun 5, 2014 at 4:10 PM, Bill Martin-SSI
<bill.martin at> wrote:
As you may remember, I presented a proposed clarification of download
microcode at the last T10 plenary meeting week. This was 14-121r1. There was
agreement to review what products are currently doing in the case described.
I have posted another proposal 14-150r0 with some additional clarifications
to the download microcode operation. Please review this proposal to determine
what your products currently do, so that we may complete these actions at the
T10 plenary meeting in July in Colorado Springs.
Bill Martin
SSD I/O Standards
Samsung Semiconductor, Inc.
Cell (408) 499-1839

More information about the T10 mailing list