Hi all, here is yet another help request in fixing a corrupted BIOS. My Asus Zenbook UX31a (non-touch version) got bricked while upgrading the BIOS due to a power drop: quite an uncomfortable situation being it my main working machine. The laptop doesn’t respond to any attempt to turn it on: no noise of mechanical parts spinning, no lights, no display. Short story: I’d need some kind help in reconstructiong a working BIOS file. In case it may help, I’m writing below all what I tried and observed.
I ordered a CH341A SPI Programmer and a SOIC8 Test Clip and started experimenting. I installed flashrom on a second GNU/Linux laptop, wired and connected the programmer to the chip and I backed up my original corrupted BIOS (sudo flashrom --programmer ch341a_spi -r backup.bin).
I then tried to merge the original corrupted BIOS with the updates Asus provides on its website, following the successful experience of another user:
For doing so, I used the Bless hex editor on the second GNU/Linux laptop.
I tried to merge each of the updates provided on the Asus website (Version 204, 206, 212, 216, 218, 219) with the original corrupted bios, and then tried to see if flashing any of these single merged files would solve the situation. None of them worked, except the merged file original BIOS+Update version 204. After I flashed this, and after I tried multiple times to turn on the laptop, I was able to power up the machine and access the BIOS config screen. The keyboard was not working though, so this was of no use for doing anything in the settings screen. I had to power off the machine. Moreover, further attempts to power up the laptop with that same file flashed on the EEPROM are not working: again no lights or parts spinning. Mistery.
Just for giving a complete picture, I also tried to flash some other ready .bin files I found on the internet (taken from here and from here - in this second case the ones called "ux31a non touch.zip" and "asus_fixed.zip"), but with no success.
So, at the moment I flashed back the only working merged file (original corrupted BIOS+Update version 204), but the laptop carries on giving no sign of life if I try to power it on.
Could someone kindly help me understanding what I could do to save the laptop?
I’m attaching the original corrupted BIOS (backup.bin) and the original corrupted BIOS merged with the update version 204 (new_204.bin); of course I could provide you with any of the other .bin files I worked on.
@Caigo - If you ME FW in the bricked BIOS is OK, which is “Seems” to be, then all those merges should have been bootable and working. As should the laboneinside BIOS, the other from here possibly not, since it’s for a touch system. Even if the ME was messed up it should still be bootable, so I don’t think ME messed up or not has anything do with current failures. So it’s possible, and I’m thinking, that your write process is failing and flashrom isn’t writing properly and then failing to verify the write failed. I’d prefer you do the writes from windows using CH341A software or ASProgrammer software, once you tell me your chip ID I’ll give more direct advise about that.
What is your BIOS chip ID? Read if off the chip yourself, don’t rely on software to tell you. Good news is all your board specific info I can salvage from your dump, so that’s a plus!
You’re bricked BIOS is 218, but do you know what it was before you started the BIOS update?
Hi @Lost_N_BIOS , first of all thank you for your help and sorry for the delay.
I have access to a couple of Windows 10 computers: of course I can try to flash using them. The chip is a Winbond 25Q64FVSIG1232.
Here I think I messed up the thing a little, since I don’t remember precisely which version of the BIOS I was previously running. I think it was 206 or 212, but I’m not sure. I’m really sorry, this may cause more trouble than expected.
For W25Q64FV in window we have to use other than exact ID for some software, so that may mean Flashrom is failing to write properly too. YOu can write, then dump without turning the system on, then compare in hex with what you wrote and see if it’s 100% match or not, that is only way to truly verify the write I’d suggest you do this, so you can confirm or not if flashrom is failing you. Or, you can move right to a windows test if you want, if your merged BIOS files there too, and or the laboneinside, then it may have something to do with EC FW not matching BIOS (or is blank etc)
Don’t worry, I am used to helping people with this all the time, so if you are not sure it’s OK (about the previous BIOS version) I only asked in case you knew because if you knew for sure then I’d fix a BIOS with that exact version in case EC FW is still old version and required that BIOS to match
So, I just tried doing this. I flashed one of my merged files (new_204.bin) using flashrom, then moved to the Windows 10 laptop and - using CH341A software 1.34 - I read and saved the file. I then compared the saved file with the original one (new_204.bin) with an hex editor, and they are actually the same. I tried also with new_212.bin, and the result was the same (the file flashed with flashrom and extracted from the BIOS chip through CH341A software is the same as the original).
Probably I didn’t need to do this at that point, but I tried anyway to flash other different merged files (new_204, new_206, plus the laboneinside one) using the CH341A software 1.34 on Windows 10, and choosing as suggested the chip ID W25Q64BV. Of course - having verified with the previous step that they are not different than the ones I was previously flashing with flashrom - I had no success (the laptop still seems totally dead).
Any other idea I could try? Thank you really much.
At least now you know flashrom is writing properly. Can you find other BIOS sized chip on the board? If yes, dump it and send me the contents, you may need to put in new or old EC FW, some have to have BIOS Matching EC FW. If you find there is Data on there, if you find another chip, it may have been flashed with whatever 218 uses, so it may be worth a shot to see if it’s properly written by trying 218 BIOS (I would try that with the labeoneinside FD/ME + 218 BIOS region from Asus.) IF that fails too, let me know, I will make you an updated FD/ME + 218
OK, then it may not be an EC FW thing. ** Edit, I do see at 206 (FW Change), then 212 and 216 EC FW update, but this board may simply use EC FW in BIOS itself.
Maybe something in the FD or ME is messed up in all source BIOS files we’ve been looking at, usually if ME is messed up it will just make the ME fail, so if anything it’s possibly a faulty FD region (hard to believe this with the labone BIOS though)
Let me see if I can find other known good dump from this model. I found several, and compared your FD, all is 100% match and OK, and compared with UX31A2 only one byte difference for it’s different LAN config (So summary = FD is OK) Please wait, I will make you 204 and 206 BIOS to try
* Edit @Caigo - what CPU do you have, in case some BIOS not compatible (this could be part of the issue too, I just noticed Ivy Bridge mentioned in the BIOS change logs)
Well, it’s not that, BIOS 204 even supports that CPU, so it’s not a microcode issue. I will make you some BIOS to try with updated ME FW, maybe that will sort the issue out, hopefully nothing will be carried over from a broken ME source.
I tried the firmware attached by LittleSnail, but both the Windows program and flashrom fail to verify it once flashed.
I’m having a few problems with my test clip (it was really low quality and is not able anymore to make proper contact with the 8 EEPROM soldered points): I ordered a new one and should receive it in a few days. I’ll then be able to experiment a little more with other .bin files.
I just tried: this time it is verifying correctly, but the computer is still showing no sign of life after having flashed the .bin file that @LittleSnail provided.
@Caigo - First, lets manually confirm your writes. And you have to redo it, since you tried to start system it may be changed now, or you can do it with the laboneinside BIOS
Erase chip, blank check, then open BIOS and write to chip. Once done do not try to start system. Close application. Open application, read chip, verify buffer, save file. Open that file and the one you wrote to chip in hex editor compare function, if they match write is OK If they do not match then you found the issue (failed write + false verification) <<This happens if wrong software version for the chip, or wrong ID used etc (For W25Q64FV be sure you are using 1.30 or 1.34 and W25Q64BV ID
If they match, and laboneinside BIOS does not start the system you may have other issues, something shorted previously (or currently, in place live short) or something blown out at previous short, may have fried something when the power went out on you (ie surge through the line etc) If no reaction at all to power on button attempts, then this may very likely be the issue
@Lost_N_BIOS - I tried to do as you suggested (erase, blank check, BIOS write; close and re-open application; read chip, verify, save). I did it all with 1.34, selecting W25Q64BV ID.
Unfortunately, checking the files (flashed with read and saved) with HxD (https://mh-nexus.de/en/hxd/) I saw they are the same. I tried both with the file provided by @LittleSnail and with the laboneinside one. Same result.
I guess I should start searching for a new computer then, no?
Thank you so much for your help, it was really much appreciated.
@Caigo - Yes, it does sound like it’s not the BIOS that is the issue then, sorry to say Maybe you can find board on ebay. * edit - Yes, I see board with w/ i5-3317U is only $68, I would go this route instead of a whole new system, it will be much cheaper.
Maybe you can find board on ebay.