SCSI-3 Download Microcode
/G=Jim/S=McGrath/O=QMAILGW/PRMD=QUANTUM/ADMD=MCI/C=US/ at qntm.com
Tue Jan 11 17:28:55 PST 1994
Subject: Time: 4:50 PM
OFFICE MEMO SCSI-3 Download Microcode Date: 1/9/94
I have been receiving feedback on download microcode in SCSI-2 and would like to
offer some proposals for improvement in SCSI-3.
First, some customers have system limitations that have prevented them from
downloading more than a certain amount of code (typically 64K bytes) during a
single command. While it would appear that the WRITE BUFFER command has a
readily available solution at hand in the BUFFER OFFSET field, that is not the
case. For the download microcode modes, the BUFFER ID and BUFFER OFFSET fields
are designated as don't cares - any valid is legal, and should be ignored.
I would suggest revising the standard language to allow the use of these fields.
In this case I would suggest the recommended practice be to use a buffer ID
other than 0, and to download code into that buffer in strictly increasing
addresses. The procedure should be terminated by either sending down a 0 length
piece of code , or by using one of the existing reserved bits to indicate the
termination of the procedure.
To make backward compatibility cleaner, we may with to use some newly defined
MODES. But given the existing shortage of unused MODE values, that is not the
procedure I am currently recommending.
Second, as with my existing ATA proposal, I think there should be a procedure
whereby multiple code revisions can be stored in the device and selected for
activation by the host. This would allow the system manufacturer to easily
configure the device to use the proper version of code without requiring the
user to actually have that code available to them. By allowing them this option
we allow the shipment of one device to the manufacturer, simplifying inventory
The suggested mechanism is to associate each BUFFER ID with a code revision. By
downloading to the BUFFER ID, a new code revision can be installed without
destroying previous revisions. To identify the existing revisions of firmware
in the device and to allow for their ultimate deletion, I suggest we use the
READ BUFFER command with the same MODEs as in WRITE BUFFER. The returned data
will be an indicator of whether the revision exists, what device manufacturer
unique ID is associated with it, whether is the currently executing code set,
and whether it is the default code set. A revision of code can be activated
(made the currently executing code), activated and designated the default code,
or deleted by setting a bit in the CDB. This control feature can be
incorporated into either the WRITE BUFFER or READ BUFFER command by reclaiming 3
I am willing to devise a detailed proposal based on feedback on this concept.
More information about the T10