There are no other microcode databases, just some containers from Intel and AMD which can be extracted via MCE with -cont parameter. That's all MCE does, extraction. And yes it does support extraction of Intel/AMD containers in text or binary form.
As the name indicates, MCE only extracts. It does not update and will not update in the future either. Obviously it extracts 5 files because the list you showed has only 5 unique lines (microcodes), everything else are duplicates.
Ah, right! You accidentally did a manual "fptw -greset" which is what I had suggested in the first place but was erroring out if I remember properly. Shutting down the system and removing power (cord + psu switch ideally) for 1 minute will have the same effect. Apparently I forgot to suggest that before. It's great that such a reset was all your system needed. Thank you for the followup report, enjoy!
Obviously it is flashed at the SPI chip. The only viable explanation is that the second chip was already updated to the same firmware version.
As long as you can read, dump & flash the SPI chip, the other stuff are trivial. You can use the cleanup guide at the full SPI dump. With such programmers, you always flash back the entire SPI image, not just a section. I suggest this: if you manage to dump the full SPI image, compress and attach it here and I'll clean it for you. There is a chance that such cleaning is the only thing your HP needs (hope for the best, expect the worse like HP provisioning gone rogue as previously discussed) so at least lets make sure it's done properly.
Zitat von KotTHECat im Beitrag #2645Yes, i have a Consumer PCH-H system, but i couldn't find the v18.104.22.1686 (PCH-H; need it for another system) at the first page. Is it for a reason?
If you are talking about firmware, 11.6.10 is older than 11.6.13 so obviously it cannot be found at the first post. Older firmware can be found at the Firmware Repositories thread. If you meant the message at MEA, that refers to FWUpdate tool's version 22.214.171.1246 which as of now is the latest we have and can be found at the first post.
Zitat von KotTHECat im Beitrag #2645Also, is it safe to downgrade firmware using FWUpdater under DOS?
Yes, EFI and DOS are safer than Windows but less convenient sometimes. The choice is yours.
Ah, FTK. Not the same as FPT of course. As you can see it uses FWUpdate so you are good. If you have a Consumer PCH-H system them 11.6 is just fine, nothing has changed from what's written at the first post. Also, FTK is not updated anymore. It's best if you use the tools from the System Tools packages directly.
I haven't updated MEA and the DB yet, that's why you get the "not in db" message and the Warning is different. I'll wait for some results before releasing.
Never flash ME firmware (that is not your own dump or not produced via the cleanup guide) with FPT. FPT doesn't preserve system specific settings, FWUpdate does. You now use the ME dumped from another system which could very possibly have a different configuration. Use only FWUpdate for simple updating from one version to another. If you flashed with FPT, download the latest BIOS from your OEM, flash it and then update the ME via FWUpdate.
Actually, I do. I have a laptop which has the lowest end i3-2310M and wanted to upgrade the cpu to an i7 and the 2760QM is on my list. No joke! Send me a pm if you want to sell it and we'll see if it works out.
I answered at the MEA thread here. As for me_cleaner, it's not something new. As for risks, check the Introduction here to learn what won't work and also this discussion. Everything else is up to each individual's choices.
I haven't tested the file but I know MEA is correct. If you load the FITC "ME Region.bin" at MEA you'll see a Warning about possible data loss. FITC v2 to v10 used to cut all the padding from extracted ME images even if that violated region boundaries. Before reinserting the file back to the BIOS/SPI image, FITC would just readd the padding. Stupid but that's how it worked. MEA detects the size intelligently from what the actual firmware reports. At bare Engine regions it can check for extra (useless) padding, less (possible data loss) padding and at full SPI images it can check if there are extra/unknown data after the ME firmware size but before the ME region actually ends as described at the Flash Descriptor.
The Platform Controller Hub (PCH or chipset traditionally) is a chip which is soldered to the motherboard and has nothing to do with what BIOS/SPI chip you buy, reflash etc. The HM70 PCH supports only Pentium and Celeron processors and the restriction is hardware coded/enforced at the PCH itself. Nothing you do at the cpu, SPI chip or the latter's firmware will change that fact. So the SPI image regions and/or ME firmware in those have nothing to do with this restriction. The other laptop you mentioned uses HM76 chipset which can work with Core i-series cpus. Intel has a website with all their products and list the specifications, datasheets, what is compatible etc. Here is the page of the HM70 PCH cpu compatibility. To improve the performance of that particular system, pick the strongest of those Celeron or Pentium processors mentioned at the HM70 ark page.
Yes, I expected the i7 to be there during the MEInfo test especially. But it doesn't matter. The ME firmware itself is healthy. The 30 minute shutdown is caused by the fact that Intel does not allow anything other than Celeron and Pentium processors work at the HM70 chipset. Basically the cpu you replaced is not "compatible" (intentional hard-coded limitation imposed by Intel) with the cheap HM70 chipset.
Such picture method won't be helpful. Download the file I have attached. Since you have Windows 10, just go to any tool folder and then File > Open command promt > administrator and run these commands:
You need to open a command prompt (cmd.exe) and then run the tools. For example if you extract the System Tools folder at C:\ directory then:
1) Search for cmd.exe and run it as Administrator (right click on the result) 2) Type cd "C:\ME System Tools v8\MEInfo\Windows64\" (or Windows folder if the OS is 32-bit) 3) Type MEInfoWin64 -verbose (or MEInfoWin if OS is 32-bit)
Same for Flash Programming Tool. A picture will do but if you want to redirect/save the output to a file and then compress and upload it here, then you can add a ">" at the end of each command (example: MEInfoWin64 -verbose > result.txt).
I was now able to find the model at Toshiba support. Lets see what the tools report first though.
From the ME thread, download ME System Tools v8. Run MEInfo tool and show the report here. Also run Flash Programming Tool with the command "fptw -d spi.bin". Does it show any error? The model you mentioned is not enough. The full model after PSCBWE is required for me to see that firmware it has.
Zitat von Ataemonus im Beitrag #2637Strange thing is that by flashing my chip via the hardware programmer with the .cap file from the ASUS site did not fix anything, it's the first thing I tried. Board would not POST, booted up, reset after 3 seconds, and so on, nothing on screen.
Obviously. As I said above, you must remove the AMI Capsule from .cap files before flashing the SPI image via a hardware programmer or flashers such as FPT. You do that easily via CodeRush's UEFITool. If you flash the .cap file from ASUS website as it is via a programmer or FPT (if FD allows write access everywhere for the latter) you will end up with a bricked system. ASUS specific flashers (USB FlashBack, EZ Flash, bupdater etc) should remove the AMI Capsule automatically and in fact expect it to be there to verify SPI image integrity. But when using a programmer, FPT and maybe AFU, the capsule must be removed first.
Your case (desktop with no special info, full SPI image provided by ASUS) and tool availability (programmer) make this problem easy to fix. Just download the latest SPI/BIOS .cap from ASUS and either:
1) Use EZ Flasher with the .cap file (check board manual on what EZ Flash expects as input) 2) Use programmer with the AMI Capsule removed first by UEFITool (exact size 0x1000000)
If option 1 does not work because for some reason EZ Flash deals only with the BIOS region of the SPI image (I don't think so, otherwise its almost the same as USB FlashBack), then go for option 2.
If you want, you can unlock the FD read/write access at the SPI image before EZ/programmer reflash in order to be able to service the locked regions down the road. They are normally locked for security purposes and if you always have a programmer, you don't really need to unlock it. It's your choice.
You don't understand correctly. The SPI chip in your system is 16MB. The SPI chip image consists of firmware regions. Flash Descriptor (FD), GbE, ME, BIOS and EC. The FD controls, among other functionality, what regions you can read and write from via software methods. Your FD is locked and allows only reading all the regions but writing only at the BIOS. So no matter what tool you use at an operating system (AFU, ASUS, FPT etc), it cannot write and thus repair locked regions such as the ME. These BIOS options or jumper I mentioned, have the ability to disable the FD lock to allow both read/write access for servicing purposes. If you don't have these, you cannot fix the ME region firmware with any software tools. What might work is the in-BIOS (EZ Flash or whatever) flasher which in some cases (OEM dependent) can flash the entire SPI image (even locked regions) because the FD lock is set after the BIOS has completed its operations. Maybe ASUS has set their in-BIOS flasher to reflash only the BIOS region and not the entire 16MB SPI image which is downloadable from their website. I know that this is what the ASUS USB BIOS Flashback does which is NOT the same as the in-BIOS ASUS flasher. Try EZ Flash, not ASUS USB BIOS Flashback as the latter only reflahes the BIOS region whereas maybe the former can reflash the entire SPI chip. With those chip hotswaps, you were just flashing back and forth the BIOS region of the chips only, which is useless as the problem is not there but at the ME.
Long story short, since you have a locked FD and no way to unlock it by jumper or BIOS option (try EZ Flash if you haven't already and confused it with USB BIOS Flashback), you need to use a hardware programmer to reflash the removable SPI chip manually. Otherwise, claim the warranty and a get a replacement board. If none of these suit you, you can leave things as they are even though it's not recommended.