Trying to repair my ASUS N76VZ laptop after it decided upon a restart for chkdsk purposes to fail to get beyond a blank screen. If I recall correctly, this was after I was playing in the BIOS, in particular, I was looking at AHCI vs IDE for a newly installed SSD. In short, I was able to clone the existing HDD to the new SSD, put it in the laptop, and viola, it worked. Inside windows it had a bit of trouble–hanging/freezing, a couple reboots later (and I believe that’s when I was in the BIOS, not really playing around, though I can’t recall if I changed much, if anything) it seemed better. I ran a SFC /scannow which was good on the SSD, and then chkdsk requiring restart. Then no boot.
Now, I figure its BIOS related and unlikely GPU failure (or other component failure) because the timing of it is suspicious. Now, what is also weird, is that I have been able to power on the laptop and some time later I arrive to see the laptop in Windows. Both of these times, I recall the date was the same as the initial failure date, which has prompted me to consider if the CMOS battery is an issue? I recently checked the voltage with my ad hoc Arduino VoltMeter and found it was 2.5V (unreliable…), which may be a bit low and since I need some 2032’s for other devices, I’m going to be throwing a new one in, but doubt this may be the issue? I actually tried it with a different battery, with no change, but haven’t been able to find it to check its voltage level.
As for the BIOS, and why I’m posting for help here is as follows. I’ve attached a raspberry pi + SOIC clip to the the W25Q64FVSSIG flash chip and have a 8MB dump that was identical multiple times. I’m trying to figure out if the BIOS region is messed up and if a flash can fix it, and do so without losing much information in the DMI tables (if not mistaken). Or, if using my raspberry pi + SOIC clip, I can use a N76VZ dump that I believe to be working that I downloaded on another site which has the ME Region/FD Unlocked. This downloaded BIOS version is 213 versus my original factory version of 207. And I believe version 213, ASUS states ME FW is updated (again, this BIOS not from ASUS but third party as I know ASUS only packages BIOS region). When I analyzed my flash chip (ME analyzer), it seems pretty clear the FD/ME region is locked, but would I get around that with my current raspberry pi + SOIC + in system programming? or is a desolder required for that? I reckon if I could boot the laptop and flash without the pi, bringing it up to the current 214 version would be possible (and given what I’ve learned recently about ME, it would also be updated). (I guess I bring this up, hoping the ME Region isn’t corrupted, and looking through the hex editor, it is noticeably different than the repository of same version, but perhaps due to specific settings?)
Furthermore, the UEFITool indicates the Intel Image of my 8MB dump has a bunch of Invalid and Invalid links of type NVAR entry, but when I analyze the other BIOS, it looks a bit cleaner. Could that be the problem? Recall, the laptop has successfully booted, but took some completely random and long period of time (ie, wasn’t like I only have to wait 2 hours, but that I can’t get it to consistently boot at all–seems effectively bricked!)
Lastly, I found mention online of someone with a very similar problem with the N76VZ model and I sought out a reply from this fellow since he does repairs to boards. He desolder, flashed, and viola it worked again. I am hoping that if it is not possible, using the rasp-pi + soic + in system programming, to flash the BIOS including ME region (that is I’m worried if I flash that I’ll further brick the ME/BIOS Region), than it is at least possible to just flash the BIOS region and that likely is the issue, which I hope very much I have access to through the in system programming via Rasp-Pi.
Just to recap:
1) Since having trouble finding DMI table stuff, how to extract this info? FD44Editor doesn’t seem to open any Bios Bin for example
2) Can I successfully flash the 8MB chip, despite the locks, through rasp-pi + soic + in-system programming?
3) Can I at least flash BIOS region and likely fix issue?
4) Trying to go about this the most cautious way vs just erasing/flashing chip contents risking further damage!
I want to avoid desolder as that seems like hassle!
Hope the explanation is helpful. Thanks for any help! It is much appreciated.
So I wanted to provide an update for anyone that might come across a similar problem with a similar notebook, Asus N76VZ.
I went ahead with my Raspberry Pi using the GPIO pins, SOIC clip, Flashrom, some jumper wires as per the many guides available and had no problems clipping onto the flash chip, W25Q64FVSSIG, reading, erasing, writing, and verifying the content on the flash chip. After assembling a bit of the laptop, and exchanging a new CR2032 battery for the CMOS, the power was turned on and the laptop posted, then straight into windows. Laptop is completely fine without any issues with the MAC ID, UUID, or even windows activation. Somewhat of a small chance it was due to a new battery, however, it was tested with a different battery without luck. The only other change was the updated/reflashed Bios.
I thought I would have problems flashing via this hardware method because of warnings in Flashrom about laptops in general, and with the SMBIOS/DMI tables that contained hardware specific information about the laptop. It seems neither of this were really issues in my case. If I had my choice between desoldering a chip and using a SOIC clip, I’d choose the latter.
So to answer my own questions:
1) Wasn’t able to use FD44 Editor to extract any useful information, but I have a copy of the oldbios content. I spent time with other tools, but in the end relied on a dump that I found elsewhere for this model.
2) Successfully flashed via ISP despite any locks that probably would have prevented changes through software flash.
3) Flashed the entire chip without a problem, 8MB and all regions. Seems to have fixed the issue!
4) Turned out a lot easier than what I worried about as described. (I’ve flashed stuff before, but never through low level ISP like method)