SCSI-3 Download Microcode

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 
reserved bits.

I am willing to devise a detailed proposal based on feedback on this concept.

More information about the T10 mailing list