HxD

Unfortunately even my original dump was corrupted. I labeled it as bad one so if I try comparing them they will definitely be different from each other. Are these two files you uploaded combinations of both the good and the bad dump (good dump being one I found online) or both from the good one?

The files are put together one complete UEFI firmware, let's call it "file1"

You flash this file, and thereafter you read the content of the SPI chip again with the CH341A programmer and save it with a new name, let's say "file2".

Then you compare file1 and file2. If they anre not bitwise identical you didn't flash correctly.

Your bad dump won't be used.

Excellent, will try this as soon as I get home, thank you so much for your help with this, both of you. One last question before I flash tonight, since I originally did this with the intent of disabling intel me, will this .bin file be cleaned? It doesn’t need to be, at this point I’m content with just having a working bios again and I can always clean it now that I have a good bios again. If it is cleaned, is there a way to re-enable intel me that you know of? I only ask because I believe if I upgrade the bios in the future using the .exe from dell’s site I believe that will re-brick my bios unless it’s 100% stock. I know this thread wasn’t posted under that forum so if you can’t answer that’s ok, too. By the way, did you use my old bios dump to compile these files or the clean dump? If it was the clean dump, do I need to insert my service tag into the file or has that been done already?

ME is cleaned following this guide [Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization which means it's set back to a machine type specific configuration state but without machine specific data. So that's not what you mean by clean.

Reenabling ME would mean flashing a new ME region, unclear if fpt would suffice or if it's be necessary to use a programmer.

I used the parts of your old dump which seemed machine specific, it's the NVRAM and a padding in the beginning of the bios region. It might be that these are corrupt, too, and this image won't boot. Then we'll have to go back to emptied NVRAM and leave the machine specific data out.

But first thing is a flash that's verifiable a 100% good!

Considering the chip it is, should flash descriptors be unlocked prior to either read or write?

Got files combined, flashed new .bin and compared the read I got from that in HxD. Files are almost identical but at offset 0001C800 down to 0001C8F0 they do not match, in fact the HEX values on the read I got from the chip after programming it just show as FF's. Have gotten same exact results across multiple reads. Have not tried booting up. However, I don't have my cmos battery plugged in and I'm wondering if that could be why. What do you think? Attached are the combined file I made from the two you sent me and the file I got from the read after flashing it. Files are labeled pre-flash and post-flash (same link as earlier)

Drive link: https://drive.google.com/drive/folders/1...CmwLimEpHS4pxlZ


*edit*: sorry making multiple posts, will make sure to edit posts with new information as I get it from now on

Edit: verify also fails, again not sure if battery has anything to do with it or if that’s irrelevant. Tried unlocking flash descriptors in asprogrsmmer but then after erasing, writing, reading and verifying the dump is even worse. I don’t understand, asprogrsmmer 1.41 is supposed to be able to read and write properly on this chip, I’ve even seen evidence in other posts of it working. Not sure if it’s just user error and I’m not properly disabling or enabling flash descriptors or something else

Combined file is OK. Please zip files, this way one has at least a check that the content is unchanged.

That's a bad read from start to end, see pictures in spoiler. You got complete blocks not written, but also flipped single words.

Good idea, will zip from now on. Yeah using asprogrsmmer 1.41, some posts said colobri works. I can’t help but think I’m overlooking something simple. Like you said, it could possibly be a bad connection. I’m using a Pomona clip, really good as far as test clips go and I’ve tried re-clipping a few times with same results. The ch341a came with one of the cheaper test clips which I didn’t use since I had one already. When I ordered the clip I made sure to get 2 just in case(Pomona’s). I’ll try using the other clip and replacing all of the jumper cables connected to it.

Edit: yeah, light is on verifying connection (bright not dim) and activity light turns on when in use. Do you think it could be a driver error? I know this is grasping at straws and without you having it in front of you it’s hard to say for sure. Also for context, I have main battery and cmos battery disconnected, so maybe a voltage issue? I just didn’t want to fry the chip but now I’m worried the bios is simply perma-bricked

Edit: oh, sorry I overlooked your response on voltage. If it were the wrong voltage would we be getting different results than what we’re seeing?

Edit: default ch341a software sees it as being W25Q128BV, however writing on chip shows FV. I assume this is just an error as it doesn’t recognize it but maybe I should try it as that model instead

Can you make a sharp picture of the chip on the board in high resolution?

Otherwise I'd stay with ASprogrammer 1.41 and selected the correct chip (FV) from the list.

I can't think of a driver error.

To get a fix on this: Just try to read the chip and get two or three reads that are identical. If you got two, three consecutive a 100% identical reads by ASprogrammer 1.41 try 1.18 version CH341A- if this read still is identical, too, you should have a good connected clip and try writing with ASprogrammer again.

Do it manually: Erase, Blank check (one down in "="), Write, Verify, Read again, save to new file

Yeah, here’s a pic I took a couple of days ago. Am not with the laptop right now but will give that a go

Voltage- not wrong voltage, it's a 3V chip, but voltage drop since there are other chips on the 3V line that normally would feed the SPI. Those chips may draw too much current from the programmer, so that the voltage could drop below ~2.7V. But the CH341 will in hard cases normally shut down, disappear from programming software ("not connected") and LED 1 will be off.

But you might check the 3V on pin 8 if you have a multimeter...
https://www.winbond.com/resource-files/w...32016%20kms.pdf

Ok, I just realized I’m an idiot. Remember how I said the activity light is on when in use, bright not dim? That is true, but only while the programmer software is actively reading/writing. HOWEVER, when I first hook the clip up to the chip, at first the activity light is on, then dims and strobes a little bit before finally shutting off. Windows then gives the usb disconnected sound which I didn’t realize before because I had my speakers muted. I think it may be a voltage issue, considering what you said about it shutting down, however the power light on the programmer stays solid red the whole time. Does that sound like I need to supply power to the motherboard to you? I spent almost 45 minutes making sure the clip was properly seated and got the same results every time. If I do need to supply power to the motherboard, should the main battery be enough or should I plug it in too or is there anyway to know for sure without just trying?

Connect chip, check 3V line with multimeter- does the voltage drop?

And you possibly don't need all pins, I could cut out pins 3, 4 and 7 without anything happening on a 25Q128FV, might be worth trying if this will help already?
[GUIDE] The Beginners Guide to Using a CH341A SPI Programmer/Flasher (With Pictures!) (4)

From [GUIDE] The Beginners Guide to Using a CH341A SPI Programmer/Flasher (With Pictures!) (3)

Hmm, still no luck. I have clipped and reclipped so, so many times. With the battery connected, battery and power supply connected, only power supply connected, no dice. In fact, when I add any power at all, the run light is totally off and ch341a software cannot even detect the chip. At this point I am going to try ordering a couple of new chips and dip8 programmer so I can do this with no interference, then solder it to the board. It’s the only thing I can think of working at this point. Lost_n_bios didn’t seem to think I bricked the chip beyond flashing, but I’m starting to think I must have. That or there’s just too much interference with the clip/not a solid enough connection

I have a question about unlocking the flash descriptors though, if flashing the bios image back onto the bios chip, will they automatically re-lock because the image says they should be locked, or will I have to re-lock if I’ve ever unlocked them at any point, regardless of whether or not I flashed an image where the descriptors are supposed to be locked?

Will them being unlocked make intel boot guard angry and force the computer to turn off after 30 minutes?

In asprogrsmmer, when I select the drop-down next to unprotected, what should I edit the values to in order to make sure the proper ones are locked again?

If I desolder the chips and connect it to the adapter, would I need a 3.3v adapter? Does this chip even require one? I’m so confused as to when one of those adapters are and are not needed.

Lastly, does the software know how to properly unlock the flash descriptors based on the chip chosen or do I need to manually edit Sreg to stay on the safe side like when locking them