@Lost_N_BIOS the complete chip ID is XMC QH64AHIG (XM25QH64AHIG), the motherboard has the inscription:
MOCKINGBIRD-L 19746-1 YJCJD$CA
https://www.dell.com/support/home/en-ca/…-laptop/drivers
That’s the DELL webpage containing everything for the laptop.
@lfb6 , I unfortunately cannot open the other machine, since it’s not mine. Can I do those steps without having to plug the programmer?
@lfb6 , I’ll get it done tomorrow for sure. I’ll also look for the aforementioned jumper but I don’t remember seeing anything like it anywhere on the board, I’m attaching a picture of the MB for reference.
For XMC QH64AHIG / XM25QH64AHIG try using ID GD25Q64 and Colibri or ASprogrammer - Make dump using this, if it matches what you used before, then read is OK, but for write back, I would use one of these as this is confirmed working.
Thanks for the board ID, I asked because I am talking to a guy at badcaps forum, maybe he can find us a good dump to use for comparison, fixing etc.
Thanks, that is the BIOS page I downloaded from, but I grabbed an older version is all (1.3.0)
Yes, FPT stuff is all software 
FPTw.exe -me -d me.bin << needs added to the list above
EC dump will fail, I just noticed FD has read/write = NO on EC 
llfb6 >> ME FW not covered by boot guard, only 8C8CE578-8A3D-4F1C-9935-896185C32DD3 + Last BIOS volume (8C8CE578-8A3D-4F1C-9935-896185C32DD3)
* Edit - @lfb6
foulou0238 over at badcaps forum said he will send dump from working system in a few days
Regarding BootGuard I know/ can see which regions are covered. But mechanisms for controlling are in ME so it’s not clear what a corrupted ME / corrupted MFS would cause in this case- and FVME profile 5 means ‘stop booting’.
Regarding bios dump- that’s good news
Yes, but ME Settings do not matter/apply, measured or verified boot would be set at the chipset level in the FPF fuses. Yes >> FVME = Verified + Measured Boot enabled, if violated = immediate shut down. This is set at chipset level
You could set No boot guard in ME FW and it would still be enabled due to key burned into chipset, so really, in systems where it’s active like these Dells or HP etc, it’s a waste if time for anything to be set in the ME FW
I would wait to do anything here, until you have a working ME FW dump, to clean/UPD/transfer over, then you only have to sort BIOS after that. ME FW from this dump cannot be used or fixed, ignore it as if it does not exist 
I’ll post the dump once he send it over
@lfb6 , @Lost_N_BIOS , I executed the commands:
-d fails,
Reading HSFSTS register… Flash Descriptor: Valid
— Flash Devices Found —
ID:0x207017 Size: 8192KB (65536Kb)
ID:0xEF4018 Size: 16384KB (131072Kb)
- Reading Flash [0x0000040] 0KB of 24576KB - 0 percent complete.
Error 185: FCERR is set. Hardware sequencing failed. Make sure that you have access to target flash area.
FPT Operation Failed.
-fd works
-ec fails with same error as above (Error 185: FCERR is set. Hardware sequencing failed. Make sure that you have access to target flash area.
)
-biosreg works
-me works
Files are here
https://drive.google.com/file/d/1Ct0jHS8…iew?usp=sharing
@lfb6 , it succeeded, I understand. At least the command didn’t result in any immediate errors. These are all coming from the fully working system, exact same specs.
Files are here:
https://drive.google.com/file/d/1Ct0jHS8…iew?usp=sharing
@jacoghi Easiest fix will be replacing the ME region with the working one from your colleagues system and try. Since the dumprd bios from the working system is identical except for NVRAM (expected) we continue with your old bios. Flash descriptor is identical, too, and EC firmware we don’t have, but in your good read are 3 copies of Dell EC firmware in perfect order, so there’s a good chance that the last piece in this area is OK, too.
Flash the file in 8MB.zip into the 8 MB chip. You can use the verify option of the flash- program, but in any case do in addition a separate read, store the file under a different name and compare it to the orginal file, they should be bitwise identical.
Since I left the bios unchanged I don’t add the 16MB file.
If this does work, fine.
If not there’s
- a slight chance for something in your EC firmware being wrong (we can’t be 100% sure that it’s OK at least) or
- maybe something in the NVRAM filesystem of the bios region being corrupted or
- there’s a fault that’s completely independant of the UEFI firmware…
(Even if Dell warranty will accept your case later this flash won’t possibly damage the machine any further, if you work carefully. You opened it already and had the clip on that chips several times anyway.)
8MB.zip (2.24 MB)
I didn’t follow these details since Lost_N_Bios had much more detailed knowledge regarding chip- flasher incompatibilities. I’d say same software Lost_N_BIOS recommended for reading the chip?
@lfb6 , yeah, he suggested me using “ID GD25Q64 and Colibri or ASprogrammer”. I just did a read using those suggestions and the MD5 matches exactly what I got with the software suggested by him previously as well, so I’m going with ASProgrammer.
@lfb6 , no luck, man. I wrote to the IC, verified straight from the IC, good to go. Then, I did another read and compared the md5 to the original file, they matched perfectly. At first, the battery LED didn’t even blink with the new 8MB file. After I plugged in the charger, the same behavior as before started happening, two quick blinks, in white.
@jacoghi Sorry to hear that.
How far did you disassemble this machine? In the picture you send I can see some connectors that look suspicous, like as not completely pushed in?
And did you really put together everything? Did you checkk all connectors? One of my notebooks plays dead with harddisk missig, for example, so it’s not always predictable what’s needed for boot and what can be omitted.
@jacoghi - you need to say what exact full commands fail at post #27, saying -d fails tells us nothing. If you mean -d of entire BIOS (FPTw.exe -d filename.bin), this would be expected as well
EC dump fail was expected, I mentioned that
Read OK with programmer and certain software/version does not = write will be OK with that same software/version always. Use what I suggested for each chip
Sounds like you compared after write, without powering on, and it was a match, so OK/successful write
If worse comes to worse here, dump both chips from the working system, write to the failed system. If that does not work, then there is some other hardware issue, or something not connected etc
You can fix the system details later
@lfb6 , I only disconnected the battery and cmos battery, nothing else. Those connectors you pointed to are the battery and the speakers, they are fully pushed in. Everything is good, M2 is connected, RAM is there. So I guess when I read the bios something else got damaged, somehow. Voltages or not, residual current on capacitors, or something. Nevertheless I appreciate very much all the effort you put into this.
@Lost_N_BIOS , those are the two commands that failed, entire bios and ec, everything else was “successfully” dumped, meaning no error during the creation of the files.
And I’m still waiting for DELL’s response, they said they are looking into making an exception in my case, but definite response no only by next week.
@jacoghi , @Lost_N_BIOS We were on a wrong track with the “corrupted” ME, Plutomaniac double checked and the ME is perfectly fine. See
Intel Management Engine: Drivers, Firmware & System Tools (349)
So it turns out that you didn’t do anything wrong to your UEFI firmware and that it has to be somthing else. I consider the chance of a corruption in NVRAM /bios region) or a fault in the EC firmware extremely slim. Complete bios is identical to the dump from the working machine, and EC firmware contains 3 perfect copies of of the EC firmware 1.01 and 1.03 from the Dell update package.
I’m sorry, but I’m pretty sure the UEFI firmware is in perfect order and I don’t see anything meaningful left I could do here
(Flashing the 8 MB chip with the copied ME from the other machine didn’t do any harm to your machine)
@jacoghi - Hopefully they allow you to RMA then!! I would fully break it down, then reconnect everything again, just to be sure it’s not some bad connection, also give it a good shake, to be sure there’s not a loose screw somewhere causing a short.
@lfb6 - BIOS should not match 100% identical match, NVRAM would for sure be diff between the two machines, and system details (if in padding, not just NVRAM would differ too) unless he wrote in good to bad and then dumped again.
But yes, if everything else is 100% match, then this is not a BIOS issue 
@lfb6 Thanks once again, man, I appreciate all the effort you put into this. Regarding the NVRAM, is it possible to fully clear it and eliminate that possibility? What’s the likelihood of that specific area being damaged during a read, or worst case scenario, touching pins?
@Lost_N_BIOS I’ll take it completely apart once I get a negative response from Dell, just to play it safe and not have the technician complaining about this or that not looking like it comes from the factory. Once again, my fingers are crossed and the wait is killing me.