@forceadmin Have you tried to set 0x2D4 to 0x1 only, then reboot and dump again? (Do not perform -greset). If still getting that CPU access error, try running the attached MESET utility from CLEVO, which may override the FD after auto reboot, then dump. (meset.exe is for DOS, meset.efi is for EFI Shell, and Wmeset.exe is for Windows)
I set 0x2D4 back to 0x1, rebooted, ran āfptw64 -d spi.binā, and received the same CPU error.
I then ran meset.exe from a DOS boot prompt and received error, This version of Meset.EXE is not compatible with the version of Windows youāre running. Check your computerās system information and then contact the software publisher. I am running Windows 10 Pro x64.
Thank you. I ran meset.efi from the EFI shell that Plutomaniac first sent. The message returned is ME Updated sequence, It will be auto-shutdown ,then power on.
However, it has done nothing since. I am unable to run any further commands. It has just been sitting there at that message for the last 10 minutes.
Edit: After waiting approximately 30 minutes with no activity, I pressed the power button and rebooted. I then ran "fptw64 -d spi.bin" and received the same CPU error.
I appreciate all of your attempts to help me. Unfortunately, I cannot afford to spend any more time on this issue. Iām very disappointed that a $3,000 laptop that is only 3 years old is in such condition.
Will it hurt anything to leave 0x2D4 at value 0x1? The laptop boots much quicker, runs much faster, & behaves as it should from a power management standpoint (sleep, dock/undock, etc.). Otherwise, it reboots every time it comes out of sleep (including when it docks & undocks). That is a very annoying and time-consuming activity.
Indeed you are out of software solutions. The only steps remaining relate to hardware. Either sort 2 pins at the audio chip, nothing to buy but laptop must be opened, or do soldering/desoldering (need to buy a cheap programmer and also requires wellā¦soldering). Personally I consider the last one extreme, especially at a laptop which makes thing harder. The 2-pin sorting is more doable without any expense or soldering. But if you donāt want any of that and you think the system behaves properly without a healthy ME firmware, then I suppose you can leave it at 0x1. It really depends on the OEM and laptop, the dependence to ME that is. Clearly your corrupted one is causing more trouble when enabled. The choice is yours.
@ vmanuelgm:
Thx for letting me know. Weāll wait for a fixed link then.
Thanks. I donāt have a problem opening the laptop as I have done it before. However, I donāt know how to āsort 2 pins at the audio chipā. Is there an instruction somewhere? My understanding is that doing this unlocks read/write access to the ME region at the BIOS/SPI chip. I would also need to know what software command(s) to run at the next boot. If the probability is high that this would resolve the issue, I would probably try it.
The pinmod unlocks the FD for read/write access until the next restart. Which 2 pins you need to short depends on your Audio chip. For Realtek it is usually pin 1 (3.3V) with pin 5 (HDA_SDO) but I recommend you detect what audio chip you have and check its datasheet which should have a pinout diagram. Once you know the pins and where theyāre located, you need to short them, start the laptop and stop shorting once the system boots. If everything went ok, you should be able to dump the full SPI image via FPT.
@Fernando Hi, Fernando, I face the same issue as harmoonia right now. Iām on a P8Z77-V Pro motherboard and wish to update my ME firmware to the recommended Intel ME Firmware v8.1.65.1586 (1.5MB) you provided here, but while following the steps, MEMANUF gives me the same errors (9331 and then 9296). Iām too fearful to proceed now. What do I do?
@plutomaniac Hi, Plutomaniac, it appears I addressed the wrong guru. Sorry Fernando for the mistake. Could you help me with this please, Plutomaniac?
EDIT:
Ok, crisis averted. I updated the driver to the recommended v11.0 drivers and ran the memanuf utility again. Passed. Proceeded to flash the ME firmware too. All good. Thank you!
Do you also get shutdowns after a certain period of time or are you just trying to update without any prior issues? Do you get the same error while running MEManuf with EOL parameter (MEManuf -eol)? Have your tried running Flash Programming Tool with command āfptw -gresetā to see if that changes anything at MEInfo, MEManuf or MEManuf -eol commands? Do you see a ācpu access errorā or similar when trying to run āfptw -d spi.binā command? Also, in advance, there is no need to tag me at my own threads as I monitor them regardless.
What laptop is that exactly? Did you update the drivers manually from somewhere? I donāt see it at the MS Update Catalog so itās probably not from them. Go to āC:\Windows\System32\DriverStore\FileRepositoryā and copy the folders which start with āheci.infā, one of them must hold the newer version.