I've got an Acer Predator Helios 300 notebook model PH317-51 that suddenly won't initialize, just the keyboard lights up. I had read that some of these (or similar) machines would tank out on firmware updates pushed from Microsoft via Windows 10 update. After troubleshooting other aspects of the machine I'm now officially grasping at straws and want to try reprogramming the BIOS chip before throwing in the towel. It's a Winbond 25Q64JVS10 (64m-bit, 8MB). I've pulled it and dumped it. It contains data that looks appropriate but I have no way of knowing it's it's corrupt. I figured that I could download the BIOS from Acer's site, extract the binary, program the chip, and put it back in the machine to test... no dice. I can't seem to find the data in Acer's BIOS download or the executables within it. So, here I am... I would appreciate suggestions on either confirming that my BIOS dump is okay or where to obtain the 8MB raw binary that I can use to reprogram my chip. Googling has turned up many sites that seem rather sketchy so I'm hesitant to trust them and decided to join here... since I have some other projects happening for which this looks like a good place to be. Thank you.

UPDATE - I ran the Acer BIOS update executable and found that it generated a binary file iflash.bin of almost 9MB in appdata\local\temp\7zXXXXX. The file contained the BIOS but also had other stuff before and after. I was able to strip out the unwanted data and isolate just the 8MB of BIOS data. I programmed it, soldered back in to laptop, and still no go... but at least I tried and won't have to wonder about it.

In case anyone else is every trying to figure out where to get a raw BIOS image... the BIOS data inside iflash.bin ended at 0x9730F, so I stripped out everything after that. Then I stripped out everything from the beginning of the file until it was 8MB in size. Comparing against the beginning and end of the dump I made from the original chip... this was correct for the iflash.bin generated by BIOS_Acer_1.09_A_A.zip from Acer's site.

@Archipelago - Did you dump your written contents and compare them in hex to what you meant to be written? This should be done, to be 100% sure your write was as intended, you can't always rely on program verification.
User in this thread use very different ID and had success, and I made suggestion to use BV too (not tested by anyone there, but for FV ID BV is what writes properly and FV fails) Version of the tool used matters too, or failed writes may verify or just always fail.
This why it's best to dump your written contents and then compare with source in hex editor
[HELP] ASUS s510ua-db71 WINBOND W25Q64JVSIQ BIOS read and write

EC/KBC FW may be messed up too, dump it's contents before you write anything. EC FW image starts at 0x8A3FF0h and ends at 0x8C3FEFh = 20000 (128KB)

The BIOS cut should be 0x97310h to 0x89730F = 800000h (8MB/8192KB). If that was not your exact cut, this may also be why it fails to boot. Just in case, or for anyone needing later, proper 8MB cut is attached

If you want, send me what you dumped from the chip before you wrote to it, and I can tell you if it's complete proper BIOS, what version etc (if you know what version was on there before, then we'll know if BIOS update messed it up)

I don't know what FV, ID, BV are but I have compared my 'cut' to yours and they are identical. I used the verification of my EPROM burning software/hardware which reads the bytes from the chip and compares against what's loaded into the buffer. Are you saying this shouldn't be trusted? To my knowledge it's never failed me after programming thousands of devices.

The dump from the original chip is attached. It is unknown if it's good or bad, this was just something to try. I still have the original chip intact, I wrote the new BIOS to a donor chip that I yanked from some HP in the recycle heap. At this point I'm thinking it wasn't a BIOS issue, but perhaps you could confirm the integrity of the original. Thanks.

Great, you cut BIOS correctly then Sorry, for FV I meant the end of the chip ID, like W25Q64FV, or W25Q64BV etc.

Yes, exactly as mentioned, verification of programmer software cannot always be relied on, and should always be double checked how I mentioned when you are not 100% sure /should be booting etc. (such as this instance)
You are lucky then, I know what you mean and yes it can usually/generally be trusted, but I have seen verified completely blank BIOS all FF or 00 and chip/buffer matches (yet that's not true). This generally only happens if device or software version is not 100% compatible with chip ID you are reading/writing at the time.
Best to check to be sure

I will check that dump tonight, thanks. Donor chip may also be the issue, now that you mention this.
Not alll BIOS are compatible with all chips, BIOS and or ME FW have compatibility lists in them and some are programmed in certain ways that they wont work with certain chips (some dual operation chips, some quad etc, and it needs to match how it's currently set.
I would program the 8MB cut BIOS onto the original chip and put it back in place. Unless replacement chip is exact same ID, then it would be no issue.

Since verification is for the purpose of comparing data I'm inclined to blame failures on poor software or user error such as selecting wrong device, settings, etc. as you mentioned. And you're right... the EPROM's are both Winbond SPI 64mbit SOIC8 of very similar part numbers but it was neglectful of me not to confirm full compatibility... there could certainly be differences. If you can't confirm the integrity of the dump then I'll reprogram the original chip and swap it in place. Thank you for your help.

Verification failure can happen in odd situations, as I mentioned, when something isn't working that you expect should (like this), I always dump to compare in hex to be 100% sure.
If you don't feel such things are ever necessary then I can't help you learn this is possible anymore than I've tried
I used to think, and always had your immediate first comment on this too, until I learned otherwise can and does happen from time to time under proper usage.
But yes often due to unknown chip/software oddities which I do not consider poor software or user error, just unknown issues, I guess bugged software yes but you never know until you run into that or check for it and find etc.
If you don't check, you will never know, and will always just assume it's failed for other reasons and possibly toss something out or waste hours days longer for no reason.

Your attached dump looks OK (no immediately visible issues that stick out as a super badly messed up BIOS). Serial and board specific info is still in tact in there too if you get this working and you need to re-insert into BIOS later
This is BIOS 1.10 vs 1.21 stock we're looking at. ME FW looks OK at a glance, but I can't tell for sure without running system MEInfoWin report.
I would suspect EC FW chip may be corrupted, or some other hardware issue on this system, especially after your first BIOS write test failed to boot.
However, seeing this is 1.10 version now, I would also test writing a stock 8MB cut of that BIOS to the chip, in case it needs to be that BIOS for that EC FW currently on chip if there is a separate EC FW chip which there often is and sometimes BIOS only works with certain EC FW

These are the currently compatible BIOS chips for the latest 8MB BIOS cut, original dump same minus last entry
Flash chips in VSCC table:
1F4700 (Atmel AT25DF321)
EF4017 (Winbond W25Q64)
C84017 (GigaDevice GD25x64)
C22017 (Macronix MX25L64)
1C7017 (EON EN25QH64)
20BA17 (Micron N25Q064)
207017 (Unknown) << I found >> xm25qh64a (Wuhan Xinxin Semiconductor)

Dual & Quad I/O Read both disabled, but Dual & Quad Output Read enabled

I downloaded BIOS 1.10 from Acer since it's the same version that I dumped from the original chip. Comparing the fresh cut vs dump reveals many differences. Much is the same but there are some pretty big segments where the dump has data but the stock cut is blank. There are also some areas where the data differs (besides the serial number.machine ID area). I suspect it might just be where the machine has stored information, logs, certificates, etc. Anyhow, I moved the machine ID section into the fresh cut 1.10 and flashed it into the original 25Q64JVS1Q chip, soldered it in, and same problem. I think I'm done putting time into this unless you feel there is anything apparent I've done wrong. FYI the donor chip I tried previously was a 25Q64FVS1Q, which I think would be compatible.

Thanks.

---------------------

Follow up... after comparing sump vs fresh cut and having read the Asus thread you linked above I think that this method of trying to manually flash the chip with a fresh cut will not work. I get the impression that the fresh cut lacks much information that needs to be populated prior to flashing, or something along those lines.

@Archipelago - I showed you above the compatible chips, and yes W25Q64FV would work, but for that you need to use software 1.30 or 1.34 and ID W25Q64BV or writes will fail every time. - http://s000.tinyupload.com/index.php?fil...695330485827902
For W25Q64JV I would also try BV ID, but you may need to use ASProgrammer 1.41 - https://github.com/nofeletru/UsbAsp-flash/releases/

Yes, BIOS Dump and stock BIOS will always be VERY different when compared in hex, and you shouldn't just cut, blank out, or copy/paste anything unless you know what you are doing, you can break the BIOS with a single byte change if not done correctly.

Board specific info aside, you can program in the stock BIOS cut (untouched) and it should boot, once you get a proper write. Then you can fix board specific info later, once you confirm system is now booting and working with that BIOS.
With the above info, after you write to the chip, you can dump it without turning the system on yet, and then compare in hex what you wrote with what you gave as source, to ensure 100% verification

Zitat von Lost_N_BIOS im Beitrag #9

---

...you need to use software 1.30 or 1.34 and ID W25Q64BV or writes will fail every time.

---