Re: [t13] Checksum implementation issue

[Pat LaVarre]

This message is from the T13 list server.

The checksum I find in ATA/PI 7 op xEC Identify I quote in full far 
below.

Agreed, stuck hi/ stuck lo/ cut to float corruption of the lo data byte 
may destroy the xA5 signature.

Agreed, if when we lose the xA5, then the host won't know the device 
has implemented the "integrity word", so then the host may quietly 
neglect to check that "word", for the sake of interoperability.

The more or less widespread industry practice I remembering that 
allowed for this weakness was to write-read-compare the lo byte of data 
by access of the x1F5:1F4 Cylinder register.  Once we choose to trust 
the lo byte of data, then by definition we have chosen to trust whether 
the xA5 signature appears or not.

As yet I see no concrete value delivered by complicating this grown 
scheme further.  In this thread as in others, sorry if I've lost track 
of what problem we're solving.

I of course agree a crc probably tells us more than a checksum.  But to 
know how much more when, I need a model of failure.  Specifically what 
kind of likely failure will pass the read-write-compare register test, 
pass the xXXA5 checksum, and then still fail a crc?  Adding an option 
for the crc helps us significantly only in that case.

Pat LaVarre

--- d1532v1r4.pdf ATA/PI 7 vol 1 of 3 - 2003-12-23
...
6.16 IDENTIFY DEVICE
...
6.16.71 Word 255: Integrity word     The use of this word is optional. 
If bits (7:0) of this word contain the signature A5h, bits (15:8) 
contain the data structure checksum. The data structure checksum is the 
two’s complement of the sum of all bytes in words (254:0) and the byte 
consisting of bits (7:0) in word 255. Each byte shall be added with 
unsigned arithmetic, and overflow shall be ignored. The sum of all 512 
bytes is zero when the checksum is correct.
...