imsolidstate

Alienware M17x BIOS / EC corrupted flash fix

I recently bricked my M17x trying to update the EC firmware for the PS2 scan rate fix. I created a USB Crisis rescue disk from the Dell package and booted from it. The Phoenix Phlash utility then informed me that it couldn’t flash when memory managers were present, and that I could press any key to exit. So I pressed a key. Instead of exiting however the program started trying to program the BIOS flash. It quickly locked up, and after I cycled power I got no response at all from the computer.

I found out once I tore down the machine that I had an original Dell (a.k.a. R1) motherboard. The incomplete BIOS load for the R2 completely confused it, as the embedded controller wasn’t recognizing the power button or keyboard for Crisis rescue (FN+B). It wouldn’t do anything at all. Time to find the flash memory that stores the configuration information.
A little examination revealed that the low level functions on this motherboard are managed by an ITE IT8512E embedded controller. This device controls typical BIOS functions like ACPI, fan PWM, keyboard controller/scanner, PS2 input from the touchpad, etc. The controller consists of two domains, the host processor (BIOS) and an 8032 microcontroller (EC). It is not entirely clear from the datasheet how the two domains are integrated; I’m not sure if it’s a logical separation or if there is actually two processors on the device. At any rate the two domains share a common internal flash memory that is mapped from the external flash ROM. On my board this external memory was an SST 25VF016B which is an SPI flash.
I bought a few of these from Mouser for this project. Evidently Microchip obtained the rights to manufacture these from SST because they said they were manufactured by Microchip but came labeled SST25VF016B, and even had SST on the chip instead of Microchip’s logo. Programming the chip was accomplished by an SPI programmer I made which I will cover in another post.
Using my SPI programmer, I read out the contents of the corrupted flash. There is a nice Linux program called dhex that allows you to compare two hex files. Using dhex I saw that the image was pretty messed up.

Once I programmed and verified a new EEPROM, I soldered it onto the motherboard. I put the computer back together thinking all was well but when I tried to turn it on I still got nothing. This started a rabbit trail where I tried to get the ISP programming software for the IT8512E from ITE, thinking that the EC code on it’s internal flash had gone so bad that it wasn’t finding the external flash interface or any of the other external I/O like a power button or keyboard. The datasheet doesn’t really talk about how the processor interfaces with external flash on reset, they use “flash” somewhat ambiguously.
However what I figured out was that with the motherboard out on the bench and plugged into the AC adapter, there was no VSTBY or VCC supplied to the chip. That means the chip wasn’t even getting a chance to try and load the code, assuming that it maps from external flash on reset (I was hoping). So I disconnected the AC adapter and tried plugging in the battery. Once I did that I found VBAT at the chip and shortly after the chip also had valid VSTBY. The flash had power as well. At that point I plugged in the media board with the power button and successfully got a lit alien head. Evidently powering from the battery woke up the chip and allowed it to load from the SPI flash. I have no idea why the AC adapter’s supply to the EC was disabled. Finally I put it all back together and after some initial configuration I was presented with a BIOS screen showing A07.
**update** I figured out that the motherboard won’t accept power from the AC adapter unless the keyboard is plugged in. That sucks because the keyboard is completely in the way when you are troubleshooting on the motherboard.

Tags: Alienware, Electronics