This message is from the T13 list server.

Thanks Pat. I appreciate your responses on this one.
I was thinking the same SCSI lines for the FW update and the descriptions
for the READ BUFFER and WRITE BUFFER commands were not adequate enough to
clarify whether they are intended for holding the FW code before flashing.

There are lots of things that make me worry about the drive FW update:

1. How do I verify whether the FW update was successful ? Is there a way to
read the FW contents ?
I understand, if the FW revision of the new FW is different, it will show up
in the IDENTIFY DEVICE data. But, are there anyother means ?

2. Is there an error recovery mechanism if the FW update fails in the middle
(due to power off or anyother conditions) ?

Have anyone have faced a problem of incomplete FW update using the drive
manufacturer's utilty ?

----- Original Message -----
From: "Pat LaVarre" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 08, 2003 10:47 AM
Subject: RE: [t13] ATA Drive firmware update.


> This message is from the T13 list server.
>
>
> I'm sure I can't point you directly to an answer, but I can comment ...
>
> I imagine the least vendor-specific choice of Scsi op for firmware update
is op x3B WriteBuffer, optional cdb1 & x1F Mode = x05 "Download microcode
and save".
>
> I'm guessing there is no analogue in the Ata standards?  I'm reasonably
confident that there was none in the beginning:
> http://www.t13.org/project/d0791r4c.pdf
>
> Personally I find it difficult to read the last block of any ATA HDD.  How
I do manage this in certain limited circumstances is recorded at:
> http://members.aol.com/plscsi/
>
> Given how difficult expressing a supposedly standard Ata operation like
reading the last block is, I think you may find it difficult to update the
f/w of ATA HDD's.  I also know the cheapest drives have f/w in ROM that
can't be altered, or OTP that can only be progressively more zeroed, rather
than flash that can be rewritten a few times.  And I've seen vendors design
commands that can't be sent with a standard pass thru, for example requiring
writes of an i/o port to occur in a certain order, or be repeated more than
normal, or ...
>
> I did enjoy `grep`ing
> http://www.t13.org/docs2002/d1532v1r1a.pdf
> for "firmware", thank you.  I saw, new to me, the surprising claim:
> 6.14.7 SMART device error log reporting
> ... If a device receives a firmware modification, all error log data shall
be discarded and the device error count for the life of the device shall be
reset to zero.
>
> Curious to appreciate, to be forced to notice, that firmware update, in
BIOS and devices both, still has no standard, here now in 2003.  I remember
seeing USB devices have a firmware update standard ... but I dunno how
widely adopted that is.  I remember hearing that mechanism was entirely
specific to USB, it wouldn't help you construct a Scsi or Ata command to
mean update firmware for ATAPI, FireWire, USB, whatever.
>
> Pat LaVarre
>
> -----Original Message-----
> From: Gana Pat [mailto:[EMAIL PROTECTED]]
> Sent: Wed 1/8/2003 10:56 AM
> To: [EMAIL PROTECTED]
> Cc:
> Subject: [t13] ATA Drive firmware update.
>
>
> Hi Folks,
>
> I want to write a drive firmware update utility for ATA HDDs. (There are
some rationale why I don't want to use Drive manufacturer's FW update util).
What command is used to update the drive firmware in the ATA drives ? Is
this standard across all the vendors ? Any hint in this area would be really
helpful to me.
>
> Thanks,
> Gana
>

Reply via email to