SCSI Download microcode
Dave, dtn:237-6877 19-Mar-1994 1715
cressman at elwood.enet.dec.com
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
>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
>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
>CHANGE DEFINITION command.
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
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.
* maybe reserve some sections within the 1-7Fh range?
Digital Equipment Corp
cressman at elwood.enet.dec.com
More information about the T10