Thanks for the report Hanson, sorry it didn't work but glad you recovered okay.

If after flashing the BIOS it did not try to reflash the ME Firmware then it is not using the backup as a reference but hard coded somewhere else as to what ME firmware should be installed. My guess would be after running the update it has tried to recover using the backup but as the backup also contains the newer version it fails the check on reboot so gets stuck in a loop of restoring the backup because it does not match the hard coded version number somewhere else in the BIOS.

It's also been a while since I've done these. Might need to do it the harder way of rebuilding the ME to the same settings as your board before replacing the backup ME firmware.

@hansonHere is another version for you to test, since you have ways of recovering. A small risk is still involved, however, because you never know what could happen to your board.I replaced both the actual ME and the backup with 8.1.51.1471, but I transferred the settings from the old ME by rebuilding. Reset BIOS to defaults, look if you don't have anything related to ME that might trigger the replacing, flash this, do a full shutdown for a couple of minutes, then test. If it still tries to recover, then try to contact the manufacturer, maybe they will release an updated version for you.

One particular setting in this ME is that Independent ME recovery is activated, which should only be true it the board has another chip to restore ME. If you are eager to do more testing, I could disable this setting and try to see where this leads.

@CodeRushYou where (almost) right about InsydeFlash backing up ME from another source. I redid all the tests and this was the result:

The BIOS has standard access for regions, so only the BIOS region could be accessed by FPT. The ME backup had been obtained by FWUpdLcl.

The BIOS packages with different ME have the same CRC for all files, except BIOS file. So I swapped the BIOS files and did a backup with InsydeFlash. It reads the ME from the BIOS file inside the package. Not sure if this is the safest way when downgrading or upgrading to a BIOS with different ME, if that ME is somehow unstable.

I tried your modded BIOS. Unfortunately I get the same result. After flashing the BIOS the ME stays at the old version. When I flash it to the latest firmware manually, the reboot/restoring loop starts and I have to recover with my other BIOS chip. There must be another place where the FW release version is read from...

@hansonA few steps before we move on:- You are using now BIOS version 2.80 with ME 8.1.40.1416? What ME driver (software) are you using?

- Have you left the USB flash drive connected after the flash and reboot, for the ME update to complete? This is an important step, as you can read here. (It is also recommended to read more later, as it contains some valuable information from users with same/similar boards. Although this step and the software was only needed the first time you used an Ivy compatible BIOS with an Ivy CPU, you never know what Asrock has coded as requirements)

- Do you get any debug code on Dr. Debug? Do you get any message on the screen while ME reflashes back? A screenshot would be useful.

- Do you get the same result with the BIOS posted bellow? I have patched AMITSE to expect 8.1.51.1471 as ME version, but not sure if this is enough. Don't know why Asrock would pull such a dumb move as hard-coding ME version.

@CPL0I have also determined AMITSE as the module that loads the backup, by invoking a MeReFlash.

But I don't know if it is that easy to patch, as it has 7 occurrences. Should all be patched?

If you have dissassembly knowledge, maybe you could guide me a little. I have only patched the version so far (28h to 33h, 588h to 5BFh), in the hope that it might be enough. If it works, I could just nop and jmp for future updates to work. Do you think that all branches with MeReFlash should be avoided, or only some of them?

first of all thanks a lot for helping me out!! So you're right it's the BIOS 2.80 with ME 8.1.40.1416. The Windows driver I use is 9.5.15.1730. I left the stick connected after the flash but the ME FW was not updated during the BIOS flash I think. After flashing my BIOS I checked the ME version inside the BIOS configuration and there was displayed the old version number. So I decided to make a ME flash by FWUpdlcl to 8.1.51.1471 afterwards. Then, after the reboot, the "backflashing-loop" started. Message on the screen then is just a progressbar and the information not to turn off the computer during UEFI update. The headline is "Intel ME Update". I'll have an eye on the dr. debug next time.

Hey you did a great job!! Finally I'm on ME 8.1.51.1471. Everything went fine, ME update came automatically after the reboot. Checked the version inside the BIOS - all good! Again: many many thanks for your time and courage!!

The reason for reflashing and boot-loop is that it is hardcoded to have 8.1.40.1416 as ME version, if not, it just flashes the backup. If the backup is not 8.1.40.1416, then you have boot-loop. I think it updates the ME only after the reboot, so you still need to have the USB flash connected. Also, the new ME becomes fully operational only after a shutdown, so that's why (I think) you still had the old version in BIOS after flashing. If it didn't updated ME, then it would have no reason to restore and boot-loop.

So, these are important steps: leave the USB stick connected after the flash is done and PC reboots to complete the update, enter BIOS (ignore ME version), do a full shutdown. Only after this you can check if the boot-loop is gone and if the ME is updated.

This tool looks quite interesting. Where can I download it? By the way SATA OROM's and Driver Modules are already updated by Aptio tool. I also did it with the BIOS provided by you before flashing. (I have the OROM's and SATA driver for TRIM support on X79 chipset inside).At the moment I do CSM disabled ultra fast boot with a modded 12.7.x driver module instad of the 3.5.x module. The Broadcom module is also already replaced, just the AsMedia 106x controller is difficult. When I use the offered ROM for both devices (611 and 612) I can no longer boot from them while "in Windows use" is ok, that means they're not in full function any more (I have XP on an extra disc and boot it from the 106x if I need to)

I don't know the options that your BIOS has to offer, but I think it would be very useful to have all 3 versions in BIOS and just switch to whatever you need. The 3.x RST(e) version has a different DevID (8086-2826) and it can be switched from BIOS, so I see no reason to remove it. Only you can decide.

The 11.6.x and 12.7.x have the same DevID (8086-2822), but have a different GUID (for SataDriver) and different anchor in CSMCORE (8086-2822 for 11.6.x and 8086-55AA for 12.7.x). If you can choose between them from BIOS, it would be awesome to keep them both. If not, just update the one with the same DevID as your board (most likely 8086-2822, look in Device Manager) and leave 8086-55AA as it is. To conclude: 8086-2826 is 3.x version and can be updated to latest 3.x and kept as an alternative for RST; 8086-2822 is 11.6.x version and is the one used for booting, update to your needs; 8086-55AA is 12.7.x and, if not available as an option in original BIOS, just update for the sake of updating. All the above have in mind the original BIOS and only OROMs as seen from MMTool. The SataDriver GUID is different for each one, which makes me think that they can be used and switched from BIOS, thus having 3 SataDriver/OROM to choose from. You must check yourself, if you ever feel the need to test. If you have 3 options in BIOS, update each one to latest 3.x, 11.6.x and 12.x (or 13.x). If you have only 2 options in BIOS, update RST and RST(e) to your needs. All TRIM-enabled modules can be found here.

You can use UBU to update Asmedia, you have 2 identical copies for the same DevID (1B21-0612), only the anchor is different (1B21-0612 and 1B21-0611). If you update only one using MMTool, always go for 1B21-0612. UBU offers version 0.954 as firmware, so maybe the bug is solved?

You can use UBU to update Broadcom from OROM 16.0.1 and UNDI 15.2.2 to OROM 16.2.1 and UNDI 16.2.2.

You can use UBU to update the microcodes or you can use the module bellow, but it is not needed. Your i7 3930K has 206D7 CPUID, so it already has the latest version 710. The difference between UBU and the module bellow is that UBU only keeps 5 out of 10 microcodes, adds one and updates one (only retail CPUs, yours included) and the module keeps them all and updates CPUID 206D6 from rev. 16 to rev. 19, CPUID 206D5 from rev. 12 to rev. 13. Use with MMTool or UEFITool and only replace the second 17088572-377F-44EF-8F4E-B09FFF46A070 module, the first one is empty.

The topic of this thread is the Intel Management Engine and not the update of ROM modules. Since hanson's problems to get the Intel ME firmware updated fortunately have been solved with lordkag's and CPL0's help, I ask you to continue your just beginning discussion within >this< section of the Forum.The best would be, if hanson starts there a new thread. If you agree, I will move the last posts beginning at #86 into the new one.