SCSI Download microcode

Dave, dtn:237-6877 19-Mar-1994 1715 cressman at
Sat Mar 19 16:46:17 PST 1994

    I read with interest your proposal and have some detailed feedback 
    which I placed in the context of your document:

    Jim McGrath wrote:

>                      Subject:                              Time:  11:30 AM
>  OFFICE MEMO         SCSI Download microcode               Date:  3/18/94
>Below is the content of 94-080r1 (in the next mailing).  I would
>appreciate feedback. --  Jim
>I have been receiving feedback on download microcode in SCSI-2 and
>would like to offer a proposal 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.

    We had the same concern about downloading "chunks" but put the Buffer 
    Offset field to good use.  I disagree with your comment here about
    "... and should be ignored."  The spec says, for both the Download
    microcode mode and Download & save mode: "The meanings of the buffer
    ID, buffer offset, and parameter list length fields are not specified
    by this International Standard and are not required to be zero-filled."

    This is not exactly the same as a "don't care" (more like Vendor Specific
    I think), so various devices (like my group's) are in fact free to make
    use of these fields in these modes, which I think was the intent.

    But, I agree we should define a reasonable use of these fields, rather
    than leave it to everyone's fertile imaginations.  I agree with parts
    of your proposal, but I think it can be simplified, and have a specific

>I would suggest revising the standard language to allow the use of
>these fields.  If the target receives a WRITE BUFFER command using
>the DOWNLOAD microcode mode, then it shall consider the BUFFER ID
>and BUFFER OFFSET fields valid.  They should be interpreted in the
>following manner:
>ID  Offset  Length  Action
> 0    0        m    Device receives m bytes of data and interprets it as
>                    bytes 0 through m-1 of downloaded microcode 0.
>                    This is the complete set of downloaded microcode.

    I disagree with this last line.  What is the purpose of this restriction?

    Our implementation is at odds with this, so perhaps it would help to
    explain it briefly, to illustrate what I think is a simpler approach
    that seems to allow the functions your proposal introduces.

    On our tape drives, we have implemented just ID 0.  The firmware image
    is quite large (~ 590 KB) and can be downloaded in chunks of any size
    (including the whole thing, as long as a minium granularity of 8KB is 
    kept), by setting the length and offset fields.

    Our current products have two code areas, for 2 different uP's, but we
    decided it was simplier for everyone to package it as one firmware image
    file to be downloaded to ID zero, rather than define another buffer ID.
    The tape drive takes care of the complication of separating the image 
    data, etc., so the host program can be quite simple and generic.

    (Our cache happens to be big enough to hold the whole thing, which
    was crutial for us to be able to make the above simplification. A target
    with scratch space on fixed media could use that, but our media is 
    removable so a giant image couldn't be squirreled away somewhere else 
    and processed later. However, this is getting into implementation concerns
    that I don't think are relevant to the proposal.)  

    Once all the microcode data has been downloaded, or on the last chunk,
    the Download & Save mode must be specified (length=0 if all data was
    downloaded by previous WriteBuffer cmds) so the tape unit knows to
    validate the image data and do the NV RAM updates.

> k    n        m    Device receives m bytes of data and interprets it as
>                    bytes n through n+m-1 of downloaded microcode k.
>                    This may or may not be the complete set of downloaded
>                    microcode.
>If a Buffer ID other than 0 is used, then each WRITE BUFFER command
>may transfer a portion of a downloaded microcode.  The target determines
>whether the complete data is transferred by receiving a WRITE BUFFER
>command with a transfer length of 0.  Note for this signaling mechanism
>to work the following sequence should be performed by the initiator:
>    RESERVE the device
>    send down one of more WRITE BUFFER commands with no intervening commands
>    RELEASE the device

    Again, I think different buffer IDs should be treated in a symetrical
    fashion.  It took some re-reading, especially of the last paragraph of
    your memo (below), but I see now what the intent is.  However, I still
    don't see a reason for another signalling mechanism.  It seems to me,
    the target has to know what is the expected size anyway.  Even if the 
    Save is not done, the target will know when a full image has been 
    downloaded and can automatically validate it, and return an error if 
    additional data (at higher offsets) is downloaded to the same buffer ID,
    and that sort of thing.  A separate signal doesn't tell the target anything
    new, however, I'm still open to this idea because it seems harmless
    (and maybe you have a good reason for requiring it.)
>If any command other than a WRITE BUFFER command is received between
>the RESERVE and the last WRITE BUFFER command, then the download
>sequence should be considered to be aborted.  The initiator should RELEASE
>the device, the device should not have been affected by the previous WRITE
>BUFFER commands, and the entire sequence should be started again.

    I suggest, that RESERVE and RELEASE, while a good idea, need not be 
    required in general (but would required in implementations where the 
    microcode image can't be strongly validated by the target.)

    However, we implemented a restriction very similiar to your "any other 
    cmd" rule above but somewhat weaker: if the download is done with 
    multiple commands, if any "complicated" command(s) are received in the 
    middle of things, the firmware update process is aborted by the target 
    and must be restarted from the beginning.  "Complicated" cmds, basically 
    means any cmd that cannot be handled "immediately" (at interrupt level 
    in our devices).  For example, Inquiry, Request Sense, TUR, most 
    Mode Sense cmds, are okay.

>When partial data is downloaded the initiator shall download the data in
>a contiguous address space in increasing order.

    I agree with this restriction!  We also impose a "non-overlapping" rule 
    for download commands, which is in the same spirit, so I suggest this 

>Note that by using the BUFFER ID, multiple versions of microcode may be
>downloaded and (optionally) saved.   If a single BUFFER ID is used, then
>the operating microcode shall be that associated with that ID.  If multiple
>BUFFER IDs are used, then the operating code is selected by using the

    I don't want to exclude the idea of different Buffer IDs being used to
    allow multiple versions of microcode to be downloaded, but it seems a
    little too VS to put in the standard.  I can't see our devices ever using
    this, but as long as a single buffer ID satisfies us there wouldn't be
    a conflict.

    How about defining a range of Buffer IDs that would have this attribute?
    I suggest 40h-7fh. 
    I feel that the standard should allow the WriteBuffer/Download uc [& save]
    options to have different Buffer IDs be implemented as mapping to the
    code areas for different uP's in the target, or sub-sections of the
    main uP's code space, or other things.  Maybe the standard should specify 
    that ID=0 be the "primary" updateable code area, and be a required minium
    Buffer ID definition for devices that implement the Download & Save modes:
      Buffer ID    Definition
      ---------    -----------------------------------------
         0          Required if D&S modes supported.  Maps to the whole of
                    the primary (and possibly only) updateable microcode 
                    space within the device.
         1-3Fh      Other updateable microcode areas, if any.
        40h-7Fh     Microcode areas for alternate flavors of operation, any
                    one of which can be made the operating microcode by use
                    of the Change Definition command.
        80h-FFh     VS

        * maybe reserve some sections within the 1-7Fh range?

    -Dave Cressman
    Digital Equipment Corp
    DLT development
    cressman at

More information about the T10 mailing list