said by koitsu:
I'll expand on the the drive ID/serial number "ordeal" in a later post, when I feel like explaining it / have the desire.
The serial number of the Intel SSD in the screenshot
There are a total of 20 bytes (characters) shown here -- the first 16 are the serial number, and there are four (4) trailing "garbage characters". To get them to display here in the forum I used Unicode, but on PCs -- particularly at that point in the boot phase -- you're limited to the character set defined per code page 437
(what most of us older folks call "ANSI" or "PC ANSI" (stemming from BBS days), also referred to as "IBM PC font", "the Windows System font", "extended ASCII", or "8-bit ASCII" -- not going to get into a history lesson here).
The character encoding is a single byte per character, so if we break the string down into its raw bytes, we get:
0x4b = K
0x49 = I
0x32 = 2
0x34 = 4
0x35 = 5
0x35 = 5
0x30 = 0
0x30 = 0
0x55 = U
0x44 = D
0x32 = 2
0x34 = 4
0x30 = 0
0x44 = D
0x47 = G
0x4e = N
0x44 = D
This is the serial number string which the actual SSD returns when requested via an ATA IDENTIFY DEVICE command (0xec). We'll get to that in a moment.
The Intel option ROM for your motherboard -- version 18.104.22.1687 -- is provided as part of your PC BIOS (yes, the same BIOS images you download from the manufacturer's website). Intel provides the motherboard manufacturer with this option ROM when they request it. I can tell you right now there are newer version of the option ROM than what your motherboard manufacturer is using in that PC BIOS release, but good luck getting them to update it -- the motherboard manufacturers don't always run "the latest and greatest" stuff, and that's often intentional.
Option ROMs contain standard x86 code like anything else (I'll get to why that matters in a moment too). These option ROMs, given what they do, have to probe the ATA bus for all attached devices -- and in doing so/finding a device during enumeration, they submit the ATA IDENTIFY DEVICE command to the underlying disk (or if CD/DVD, the relevant ATAPI command equivalent).
Per T13/1699-D revision 4a spec (circa May 2007) section 7.16.2, the ATA IDENTIFY DEVICE command response block is 256 word (512 bytes); normal for ATA. Word offsets 10 through 19 (which equates to 20 bytes) contain the serial number of the device, as an ASCII string. The length of the field is static/fixed, not variable. See attached screenshot of section 7.16.7 for that fact.
Section 7.16.2 clearly states, quote:
Some parameters are defined as ASCII strings. ASCII strings are a list of values that range from 20h to 7Eh which the host should interpret ASCII Characters. Values 00h-1Fh and values 7Fh-FFh shall not appear in ASCII strings.
So at a glance it appears that Intel, with that firmware version on that SSD, is not complying with the aforementioned revision of the ATA specification. However, which specification they're complying with matters -- earlier revisions of ATA8-ACS actually define the permitted characters in this field slightly differently. You're not going to get a straight answer out of anyone at Intel Technical Support about this -- this is straight up an engineering-oriented question/issue.
You see, a lot of option ROMs, BIOSes, utilities, or any other thing, often have code in them that treats these regions (serial number, model number, etc.) in a special way. The specification clearly states 10 words (20 bytes); however earlier specifications stated that vendors are supposed to "pad out" the strings with spaces, i.e. the string "HELLO BOB" would need to contain 11 spaces at the end.
To enforce this, a lot of code tends to do things like strip trailing spaces off the end of the model/serial/firmware strings from ATA IDENTIFY DEVICE, stop processing the string if they encounter a NULL (0x00) (i.e. treat it as end-of-string), or stop processing the string if they encounter a byte that is outside of the permitted range (permitted: 0x20 to 0x7e). This is done solely to keep "garbage characters" from showing up.
In turn, what this has done is create a problem -- engineers/developers writing the firmware code for these disks/devices then begin trying to make use of the extra "crap" at the end of the strings. Sometimes they stick some non-ASCII data at the end to represent something internal -- it could be a checksum value, it could be the build date of the firmware, it could be the score the programmer got at Pac-Man last week. (They shouldn't be doing this, but many do -- bad assumptions and not following specification...) Others do the same but actually pad out the string with spaces and ensure their "special data" is within the permitted range -- for example, my LiteOn DVD drive returns "iHAS524____B" (although that means "revision B", and the underscores are spaces). I'm sure you've seen some hard disks in the Device Manager show up as things like "FUJ9391______CB" (again, underscores=spaces) before. A different revision of ATA specification actually demands that you space-pad your strings. However, like I said, some option ROMs and code do things like cease printing after the first NULL (0x00), so the programmers think: oh okay, I can use the string "BOB", followed by a NULL, then I have 16 bytes left over for whatever I want! Wrong
-- but they do it anyway.
Now back to the option ROM. The Intel option ROM, rather than try to avoid printing the gobbledegook, is choosing to display all 20 bytes. They're assuming
that all underlying devices are complying with the ATA specification that the bytes contained within the serial number area must be between 0x20-0x7e. And that's perfectly fine for them to do -- the "crux" of the issue is that Intel, on that model of SSD, did not properly follow ATA specification by using only bytes 0x20-0x7e in the string. There may be an SSD firmware update that addresses this, but at the same time, I can assure you that there is a newer version of the Intel option ROM (and no you cannot get it :P) for the ICH9R that stops display of the string once it encounters a byte in a non-permitted range.
I told you it was technical, and I told you it washarmless/cosmetic. --
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.