how-to block ads
Mountain View, CA
|reply to koitsu |
Re: Corrupted SSD S/N After BIOS Update
said by koitsu:The serial number of the Intel SSD in the screenshot is displayed as follows:
I'll expand on the the drive ID/serial number "ordeal" in a later post, when I feel like explaining it / have the desire.
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 220.127.116.117 -- 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:
quote: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.
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.
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.
Thank you for explaining the inner workings of how this string is read and reported. Based on that information, I can understand why it's of no concern.
Let me explain a bit about the history of this PC, as it may lend some light on what happened here.
I assembled it in 2007. Original config was Gigaby GA P35-DQ1 rev 1 motherboard, 4GB Mushkin enhanced 4-4-4-12 timings memory, GeForce 8800GTS graphics card and Turtle Beach Montego DDL-II audio card. CPU is an Intel Core2 Quad 6600 (normal clock 2.4GHz)
Back in late 2007 or early 2008, I needed more rendering speed for video projects that were taking overnight to render. So I investigated overclocking options. The stress wasn't on the motherboard so much as the CPU, as the board was designed to go past 4GHz with faster CPUs and was also designed to be overclocked.
I'd managed to achieve a 3.8GHz overclock, but backed it off to 3.5GHz just for long-term stability. My testing tools were Prime 95 and Memtest86. Up to now, that configuration ran beautifully. Recently, I upgraded to Windows 7 64-bit, and a friend of mine kept pressuring me to add more RAM, although I was finding that 4GB was enough to run all my Adobe CS3 apps without any problems or strain whatsoever. But I figured, there's two empty slots, so I'll buy a kit of 8GB and replace the two 2GB Mushkin with four G-Skill sticks. However, the G-Skill, though it also specs as 4-4-4-12 timing, failed Memtest86 at the current voltage settings that the Mushkin were happy at. So I upped the memory voltage +.05V and that seemed okay. Booted Windows and ran WEI. Scored LOWER with this RAM than with the old RAM, so I assumed I needed to do some tweaking of the timings to get the speeds back to what I was getting with the Mushkin sticks. As it turns out, a number of timings were too aggressive and the motherboard is designed to restart and kick back to default safe settings. If it reboots too many times, as in me hitting hardware reset during POST on 3 successive restarts, DualBIOS will assume I flashed the BIOS with a bad / corrupted flash and switch over to the backup BIOS. Now this BIOS was at F8, while the current BIOS version is F9. As a result, I decided to update this BIOS so that BOTH BIOS copies in ROM would be the latest version. Once that happened, my SSD drive began to display those junk characters after the s/n, not before the BIOS update. That's what my original question was about, actually.
Before the experiments with adjusting the new RAM to higher timings, the drives' s/n was not displaying those >127 ASCII symbols. But at least now I understand there's no reason to be concerned. Certainly, the system has never run this nicely in the 5 years I've been using it. SSD, coupled with a 64-bit OS, added speed and stability I have not seen since my days with the SPARCStation II running Sun OS 4.1 (1987). Even when I got my Mac Quadra 950 in the early 1990s, I didn't enjoy that kind of stability, nor with Windows 95, NT, 2K or XP (though XP was coming close). So far, I have been doing ridiculous things on purpose, in an attempt to crash my editing apps, or see if the OS will crash. With Photoshop, Premiere, AfterEffects, Maya, Illustrator, InDesign, SoundForge and Remote Desktop all loaded, the system doesn't break a sweat switching from one to the other, nor do the apps themselves complain. Under this absurd environment, they run better than if they had the whole system to themselves, one app at a time, under XP. I'm actually VERY pleased with the system's operational stability now and would not change a thing.