- Dumped ME region with fpt -me -d me.bin, which resulted in ~4MB dump file - Loaded it into fit - Already at this point decomposed image was only ~1.5MB - Modified settings to enable overclocking - Build
I used following guide Guide-Clean-Dumped-Intel-Engine-CS-ME-CS-TXE-Regions-with-Data-Initialization as a reference, except for the part with an empty reference image, which was not needed in my case. If I now try to flash new ME region back to SPI it says that the file size is less than the destination and it will result intruncated write operation. I declined that, but can’t figure out what went wrong.
I expected dumped file to be equal to the decompressed one, otherwise it probably means that either dump contains extra data (like padding or smth.) or the dump command went wrong. Not sure since rnig which pears befoe start flashing confuses me.
The dumped ME is in fact an 1.5Mb SKU for Intel 9, so no surprise here, the guide is well elaborated and explicit (for doing wot the tittle suggest) but users have to focus and read point by point all details, ur task only. Now ME Analyzer in fact reports: "Note: File has harmless unneeded Firmware end padding! So no surprise here also.
As already said: The guide does cover this problem, see last paragraph. Why do you work on a region? It’s easier to work on a complete image and extraxt the me region when ready… Be aware changes made in FIT for the descriptor are stored in the Flash descriptor, not in ME, so if you changed somthing in PCH straps for examle you’d have to flas FD, too, to make them effective.
First of all thanks for replying and helping me moving further. Very appreciated!
I decided to work on a region because my SPI is locked and I found “Me FW Image Re-Flash” option in the Setup section, as mentioned in “Guide-Unlock-Intel-Flash-Descriptor-Read-Write-Access-Permissions-for-SPI-Servicing”. So I have managed to unlock this single region by using setup_var and make a dump of it. I verified this dump, and it does contain FFFFs at the end, so it looks like I did dump only a single unlocked ME region and the rest was filled with dummies, resulting in 4MB size instead of an actual 1.5MB payload. You’re pointing to the last sestion, and yes, I saw it, but the me_output.bin file, which I built using FTI, was a little bit bigger that the decomposed one, so I decided that this instuction isn’t applicable in my case, and if I flash back with “fpt -me -f me_output.bin”, it will simply write the payload, leaving rest of the rom untouched, and since now payload became some KBs bigger it’s not an issue.
No, I haven’t changed anything there.
The only thing I did in addition to the overclocking settings change, was setting
. I also verified "Boot Guard Profile Configuration" and "Default Lock Enables Mask", which appeared to be already set approprietly, so there was no need to modify them.
I finally decided to flash it with "fpt -me -f me_output.bin" as stated above, ignoring "Warning: The file does not contain enough data to completely fill the target write area. Continuing will truncate the write length to file length. File length: 1560576, Write Length: 4190208", and did a "fpt -greset" afterwards.
Now my PC is bricked FAN starts spinning and it turns off. This happens in a loop. So I believe I corrupted my SPI. But Why? What I did wrong?
Is now reflashing with CH341A the only option I left with? I orderered this HW and will get it today afternoon. I also have original DELL BIOS.CAP file. Can I extract ROM from it and flsh with aforementioned hardware? Are there any pitfalls that I need to be aware of?
If I will manage to restore my SPI, what shall I change in the process above to get the ME sucessfully flashed?
- I would need to write from a specific offset, right? How can I find it out? - By the original ME you mean decomposed one which is 1.5MB? Because writing back dumped 4MB will essentially overwrite everything else with padding.
Well, I hope so My goal was to unlock Reference Clock for Intel XTU. So I changed the OC options and also increased ranges for frequencies, leaving their default values unchanged. So the plan was to do this later from the XTU SW.
Generally speaking: If this had been the bios chip you wouldn’t have the chance to brick your machine by fpt if this chip was in fparts.txt, yes. Since it’s not the bios chips and you’re anyway going to use a programmer …
UEFIToolNE for structure, UEFITool for exchangng regiosn, volumes… in an easy way.