Lewis' Blog Tales from the trenches of information technology

How not to update the BIOS on a newer (post 2009) Intel desktop board

Still in the thick of the system migration involving the virtualization of the previous W2K install. I procured the hardware to build the new workstation, which is based on an Intel DZ77GAL-70K desktop board and an i5-3570K CPU. (I won't go into detail here concerning my choice of the K series CPU and the matched desktop board, but I will provide some references below ¹.)

I'd read some anecdotal posts concerning the installation of Windows 7 64-bit on earlier firmware revisions of this board, so I had planned to update to the latest available BIOS. Unfortunately, as with so much anecdotal evidence - particularly posted by kids with too much time on their hands and not enough experience - , the record was somewhat incomplete, and I was not fully aware of the ramifications of the BIOS update process itself (and even though I've had years of experience flashing EPROMs ² and EEPROMs, the ability for manufacturers to quickly bring to market hardware and related technology which is not quite ready for prime time never ceases to amaze me).

And so it was that I assembled the hardware, fired up the machine, and was immediately stunned by the new graphical BIOS interface (including the ability to use the mouse for navigation) ³. The BIOS revision shipped on the board was 0039, and checking the Intel site, I saw that the latest was 0064. So, I quickly downloaded the 9+MB .BIO file and copied it to a USB stick.

Post-2009 Intel desktop boards typically have the ability to flash from an F7 keypress during POST. Even nicer is that there is no longer a requirement to create a bootable USB stick or bootable CD; as long as the file is present on the medium, one is presented with a text mode file browsing interface, making it possible to store it in a subdirectory.

I went through the flashing procedure to move the board quickly from 0039 to 0064, which was my fatal mistake. At the end of the procedure, the screen went black, and that was the end of that. The machine did not prompt for a reboot, nor did it reboot fully on its own. It seemed that nothing I did could get me to a POST display.

Another handy feature on these newer boards is the inclusioin of a 2-digit LED display mounted on the board itself, which reports port 80h POST codes as the system is booting ⁴. After the flash, the board would simply not move beyond a POST code of 12, which is CPU inititialization.

Had the machine not booted in in the first place, I might have suspected the processor. However, the fact that it did boot led me to believe that something had gone wrong with the flash. So, once again relying on my experience, I pulled the BIOS recovery jumper, downloaded the (original) 0039 firmware .BIO file, copied that to the root directory of a blank 2GB USB stick with no partition (i.e., formatted as large floppy), inserted the stick in one of the rear panel USB 2.0 ports, and powered up the machine, expecting the BIOS recovery procedure to work as it has for me in the past.

No dice this time. Nothing. POST code 12 after a long pause at code 21 while taking notice of the connected stick, and then nothing.

Pulled he RAM (two Corsair 4GB modules, installed in slots 1 & 2), and shuffled the one farthest from the CPOU (slot 2) into the slot closest (slot 1), leaving the other module out. Disconnected DVD and HDD. Applied power. Same thing. Pulled the CMOS battery for several minutes, and disconnected AC (I did not just rely on the power switch - even the physical rocker on the PC Power & Cooling 750W supply). Same thing. I even tried burning the .BIO file to a CD (again, these need not be made bootable any longer), reconnecting the DVD drive, and trying the recoverey procedure from there, but to no avail.

Because nothing around here ever happens in a vacuum, I was under the gun to get the system built and delivered to my client. So, I notified him of the difficulty (he was most understanding), and then I opened a chat session with Intel support.

Fred (the technician at Intel) walked me through doing pretty much what I'd already done (I wanted to make sure that I hadn't had a senior moment and forgotten something basic). In the course of the conversation, while waiting for the CMOS to drain, I think, we got to discussing how I ended up in this predicament. Fred suggested that I probably should not have jumped ahead that many BIOS revs, and instead should have moved up incrementally.

Had I not been in the middle of the current mess, and had we just met on the street, I probably would have dismissed what he said with a wave of my hand. After all, anyone who understands how EEPROMs work knows that a block is erased, new data is written, the next bock erased, data written, etc. What possible difference could it make whether the code in a particular register was one thing or another, as long as the firmware file itself was valid? (Unless, perhaps, the erase procedure doesn't fully erase the chip, due to either poor design or lower than necessary voltage?)

However, all things not being equal, I thanked him for the tip, and took his recommendation quite seriously. He advised that the board was most likely bricked, and that I should return it through my supplier. Again, I thanked him for his time, and we ended the session. I ordered up a replacement board and made preparations to return the one I'd managed to lock up.

When the replacement arrived two days later, I installed it and booted. It, too, was running revision 0039. This time, however, I was ready. I'd downloaded several intervening revisions, and after each successive flash, I went back into BIOS setup, pressed F9 to load firmware defaults, F10 to save, and then F7 at the next POST to update to the next revision. In all, I went through no less than eight revisions between 0045 and 0064. After the last flash, I started about first testing eComStation 2.2 (of course!), and then did the Windows 7 Ultimate 64-bit installation.

Last Updated on May 17th, 2013 by LewisR