Thank you very much, I found the entry. Do you know which tool to use for? MM Tool says invalid ffs file when I try to replace it. Also renaming the .bin to .ffs had no success. Should I use a hex editor?
Many thanks hanson
As posted above, I would be very wary of replacing the whole part of the GUID. Try updating with FWUpdLCL and before rebooting back it up with FWUpdLCL. If you used the full 1.5MB SKU for updating you might find it only uses a part of that image for updating which should be apparent by the size of the backup and the size of the 1.5MB SKU. Or you can skip the update and just do the backup to check.
Iāll try to make a better explanation later in half an hour or so.
The ME Firmware contains data for your computer such as clock setups. Looking at the 1.5MB SKU 8.1.51.1471 linked on this board and your existing ME Firmware they are incompatible. Using the whole image would very likely leave your board bricked. Using it with FWUpdLCL is okay as this just takes the section from the 1.5MB SKU that is needed and leaves the ME Firmware settings such as clocks alone.
For you to update the GUID in the file you need to keep the ME Firmware settings in the first part of the image and only update the section after that.
If you look at the 1.5MB SKU 8.1.51.1471 in a hex editor you need to remove the section from 0x0 to 0x4cfff and replace it with the section from your BIOS (not including the EFI header).
Thanks a lot, Iāll try that. Luckily I have a spare BIOS chip ASRock sent me recently. If something goes wrong I should be on the safe side.
Regards hanson
Here is an example you can check against, untested. I donāt know if it is also necessary to update the ME Firmware section if you are using an AsR flasher but the BIOS side is updated.
File deleted.
Sorry, no downloadlink appeared
You donāt se MeAsrBIOS.zip ???
No unfortunately not
now itās ok
Hey CPOL,
thanks so far for your work. Unfortunately I had no success. I flashed your modified BIOS without problems. After that I updated ME FW by using FWUpdLCL. After the reboot my board tried to restore the original firmware. But maybe due to the changes you made it rebootet again and again and again, always updating the ME FW after restart. I interupted this loop finally and restored original settings by booting with my second chip, then changing the chip during running system and flashing back the original BIOS.
Regards hanson
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.
@hanson
Here 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.
@CodeRush
You 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.
Hey man,
thanks a lot for your work, Iāll try it out asap (backinā up right now) and let you know the result.
Best regards!!
Hey,
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ā¦
AMITSE
Two options,
1. Include the update that lordkag was kind enough to supply in the BIOS and code new version number in AMITSE.
2. Modify AMITSE to bypass the hard code and update ME as a normal update without the BIOS trying to revert back to the backed up ME in BIOS.
With option 2 you can update any later ME versions as normal without further BIOS modding.
@hanson
A 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.
@CPL0
I have also determined AMITSE as the module that loads the backup, by invoking a MeReFlash.
[[File:load.png|none|auto]]
But I donāt know if it is that easy to patch, as it has 7 occurrences. Should all be patched?
[[File:Occurrences.png|none|auto]]
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?
[[File:Ver.png|none|auto]]
Hi,
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.
Iāl give the new version a try now and inform you later.
Best regards hanson
@lordkag
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!!
Best regards hanson
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.
Ok so I checked it twice now, even with a clear CMOS. The "loop" is gone and the new version stays. Great job Mr.!!
I have now seen your reply. So it was enough. If ever a new ME becomes available, just post a reply and I would make it to either ignore the version, or to wait for that specific version.
You can now use UBU to do a couple more updates, if you want more. This is the first thing to do, but if you can wait a few minutes, I will write more about Asmedia and microcodes.
[[File:UBU.png|none|auto]]
Use UBU only for RSTe, as your board has 3 version of SataDriver/OROM, 3.x + 11.6.x + 12.7.x, probably all available to be used. If they would have added 11.2.x, it would have been the full set.