kcummings at vnet.ibm.com
kcummings at vnet.ibm.com
Tue Apr 26 16:03:43 PDT 1994
DOWNLOAD MICROCODE using WRITE BUFFER
I wish to thank Gerry Houlder for his comments on the multi-command
download proposal. I would like to respond to them.
> 1) He has included wording that requires the last command in a
> sequence to have a zero value for transfer length. This is
> undesirable. At all other times for this command, a zero length means
> that the target should transfer zero bytes. This meaning should be
> retained! The initiator should always indicate the correct number of
> bytes to be transferred in the transfer length field. The target will
> know that all bytes have been transferred by noticing that the Buffer
> Offset + Parameter List Length for a command adds up to the maximum
> number of bytes that the target is expecting. If this isn't good
> enough, we could define a particular Buffer ID value (0xFF ?) for the
> last piece.
I agree that the zero length means that the target should transfer zero
bytes! Your suggestion that a particular Buffer ID value like 0xFF
could serve as the ending flag would work just fine for me, providing
that there is no data sent with it (what buffer id?) and that it is
guaranteed to be the last command in the sequence. We could even define
a "Transfer Complete" flag in a spare bit in the WRITE BUFFER command,
again assuming that it is always the last command in the sequence.
What I am trying to accomplish here, and perhaps you folks can help me
to accomplish it, is to very explicitly separate the initiator's action
(transfer of the data), from the target's actions (code verification).
The method chosen must be at worst a no-op to any existing target that
does things differently. Additionally, it must not produce excessive
burden on the initiator or the target.
The initiator wants only to know that it has transferred all of the
microcode data it has to the target successfully and that the target has
acknowledged receipt of that data. The target wants to know that it has
received all of the data so that it can begin data verification. I
realize that this can be done implicitly with self describing data or if
the microcode will always have a fixed number of bytes. But an explicit
command sequence takes away any doubt.
That was the intent of that very-special-zero-length-no-op-WRITE-BUFFER
command. A Transfer Complete flag would work just as well, as long it
is always the last command in the sequence. A Transfer Complete flag
may bother existing targets though, while that very-special-etc. command
would be a no-op to existing targets, but could be the 'trigger' to
SCSI-3 targets that need it.
However, this is least important part of the proposal (the most
important part being the definition of the buffer id field, the transfer
length field, and the buffer offset field, for the download microcode
sequences). If the committee prefers not to have an explicit
end-of-transfer command, I will rewrite the proposal without it,
essentially dropping Section 126.96.36.199 in its entirety.
> 2) He includes a requirement that the new firmware doesn't take effect
> until a Reset occurs. This requirement is clearly unacceptable for the
> Download mode (as opposed to the Download & Save mode) because a reset
> would revert to the old firmware again. I prefer having the new
> firmware always take effect as soon as GOOD status has been reported
> for the last WRITE BUFFER command.
I stand corrected. Gerry is correct. Mode 101 (download and save)
specifically states "The downloaded code shall then be effective after
each power-cycle and reset ..."; mode 100 says that "After a power-cycle
or reset, the device operation shall revert to a vendor-unique
condition". I will correct the proposal to reflect this.
My thanks to Gerry Houlder for his comments.
I cannot verify my internet address: it is either
kcummings at vnet.ibm.com or kenc at tucvm2.vnet.ibm.com.
I think the former, but they both seem to work.
More information about the T10