From: Elliott, Robert (Server Storage) [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 29, 2002 3:52 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Reif, Jim
Subject: ATA/ATAPI-7 byte order for IDENTIFY DEVICE/IDENTIFY PACKET DEVICE strings
While reviewing SAS endianness we noticed an oddity in ATA/ATAPI.
In ATA-5 and earlier, the IDENTIFY DEVICE and IDENTIFY PACKET DEVICE command descriptions noted that they transfer bytes in the model number, firmware revision, and serial number fields backwards. In ATA-6 and ATA-7, this was moved to the top of the document as a "convention." ATA-7 reads: "Some parameters are defined as a string of ASCII characters...When such fields are transferred, the order of transmission is:..."
IDENTIFY DEVICE lists them like this in its
table:
10-19 M F Serial number (20 ASCII
characters)
23-26 M F Firmware revision (8
ASCII characters)
27-46 M F Model number (40
ASCII characters)
Reviewing ATA driver code in a few different operating systems, I confirmed this requires weird byte swapping for those fields (only). The driver can't just convert the buffer into a char [] array and treat it as a string; it has to swap byte 0 with byte 1, byte 2 with byte 3, etc. before using the strings. All the other fields work as-is; a 32-bit number casts into a "unsigned long" correctly, a 16-bit number fits an "unsigned short", etc.
Searching on the web, I found some reports of CDROMs that didn't flip their string data for these fields, causing problems.
I'm not sure you should encourage this odd behavior in all future ATA commands that define strings. Early versions of "media serial number" proposal expressed it as an ASCII string, although the final version doesn't do so. Is it being implemented as an ASCII string today? If so, are the bytes swapped in this manner?
If the description remains tied to DD15:0 (parallel bus terminology), Serial ATA devices might not realize that they need to do the same byte swapping (software isn't going to expect Serial ATA devices to handle these fields correctly all the sudden).
I suggest you remove this text from the convention section and let the IDENTIFY DEVICE and IDENTIFY PACKET DEVICE command descriptions explain how those fields are formatted. They should describe the fields in protocol-independent terminology that will apply to both parallel and Serial ATA (no more DD[15:0] references). Future commands using strings need not follow the same convention (if they do, they should clearly state so).
Suggested changes:
6.16.8 Description
Table 15
IDENTIFY DEVICE information
...
10-19 M F Serial number (20 ASCII characters in a
byte-swapped string)
23-26 M F Firmware
revision (8 ASCII characters in a byte-swapped string)
27-46 M F Model number (40 ASCII characters in a byte-swapped
string)
..
6.16.17 Words (19:10): Serial number
This field contains the serial number of the device.
The contents of this field is an ASCII character string of
twenty bytes. The device shall pad the character string with
spaces (20h), if necessary, to ensure that the
string is the proper length. The combination of Serial number (words
(19:10)) and Model number (words (46:27))
shall be unique for a given manufacturer.
[add:]
This field
shall contain only ASCII graphic codes (i.e., code values 20h through
7Eh).
The ordering of the bytes in this field (e.g. for a
string of "Copyright") shall be:
Byte 0:
second character (e.g., 'o')
Byte 1:
first character (e.g., 'C')
Byte 2: fourth
character (e.g., 'y')
Byte 3: third character
(e.g., 'p')
Byte 4: sixth character (e.g.,
'i')
Byte 5: fifth character (e.g.,
'r')
Byte 6: eighth character (e.g.,
'h')
Byte 7: seventh character (e.g.,
'g')
Byte 8: tenth character (e.g. 'space',
used as the fill character)
Byte 9: ninth
character (e.g. 't')
Bytes 10-19: eleventh
through twentieth characters (e.g. 'space' fill characters)
--
Rob Elliott,
[EMAIL PROTECTED]
Industry Standard Server
Storage Advanced Technology
Hewlett-Packard
