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.
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)
regards hanson
Here’s the modded BIOS I actually use now if you’re interested
UBU is present right here, from our dear member Sonix.
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.
Here is UBU before and after:
[[File:UBUmc.png|none|auto]]
Here is with module before and after:
[[File:modulemc.png|none|auto]]
@ lordkag and hanson:
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.
Nice work lordkag. I only have the free version of IDA which is 32-bit so can not show it in IDA format but this is basically it in objconv format.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
?_00593:cmp bx, di ; 800063B4 _ 66: 3B. DF ; ME 7.x.x.x check if ME7
jz ?_00594 ; 800063B7 _ 74, 0A ;
cmp bx, r14w ; 800063B9 _ 66 41: 3B. DE ; ME 8.x.x.x check if ME8
jne ?_00597 ; 800063BD _ 0F 85, 0000008A ; If not ME7 or ME8 then skip reflash
?_00594:cmp bx, r14w ; 800063C3 _ 66 41: 3B. DE ; ME 8.x.x.x check major ver is 8
jnz ?_00595 ; 800063C7 _ 75, 17 ; If ME7 (major ver 7) then reflash
cmp si, r13w ; 800063C9 _ 66 41: 3B. F5 ; ME x.1.x.x check minor ver is 1
jnz ?_00595 ; 800063CD _ 75, 11 ; Not 1 then reflash
cmp r12w, 40 ; 800063CF _ 66 41: 83. FC, 28 ; ME x.x.28.x check hotfix is 28h
jnz ?_00595 ; 800063D4 _ 75, 0A ; Not 28h (40) then reflash
mov eax, 1416 ; 800063D6 _ B8, 00000588 ; ME x.x.x.588
cmp bp, ax ; 800063DB _ 66: 3B. E8 ; Check build
jz ?_00597 ; 800063DE _ 74, 6D ; If 588h (1416) then skip reflash
?_00595: ; Set up for ME reflash
I don't know AsRock's reason for doing this, maybe it's just their way of doing ME updates, but perhaps skipping it would involve less work for users updating ME Firmware themselves while adding the new version in AMITSE would give users a new ME Firmware once the BIOS is flashed. Perhaps AsRock is worried the ME update is not always successful so make sure it's checked each time.
@CPL0
I hope Fernando won’t mind if I continue here a discussion related to the ME problem, I also hope you won’t mind being poked again. I’ve only read the basic of the basics when it comes to disassembly. Here is what I have in mind for removing the check completely. First problem is that there are two possible starting point. I’ve uploaded the whole picture of the flow bellow.
[[File:me-patch.png|none|auto]]
The second problem is with that last jnz to patch. The hex is 0F 85 8A 00 00 00 and I thought of replacing it with 90 E9 8A 00 00 00. It works by jumping right to the last instruction and skipping MeReFlash, but if this is not the right way, I could always ignore it and pass the other nodes, like bellow. What is your recommendation?
[[File:me-patch2.png|none|auto]]
There are many numerous ways of doing it, all that matters in the end is that it works. For example in your second example instead of changing the jnz to "jmp short" you could change the cmp bp,ax to cmp ax,ax or cmp bp,bp and so on. When jumping over code check to make sure values that are set in it are not used later on. Usually good practice to try and preserve as much as you can.
@lordkag
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.
Hello again… Today ASRock released a new BIOS for my board and i wanted to ask if you could be so kind to insert the ME 8.1.51.x for me please. Here`s the original file.
Best regards hanson
Image attached. The X79E6_3.00_ME.rom is the BIOS to flash, which already has the 8.1.51.1471 ME and it is locked to this particularly version. Flashing any other ME firmware will trigger the backup to be restored.
The amitse300mod2.ffs is a module patched to give a little more freedom. Use it as this: open original 3.00 BIOS with MMTool and replace AMITSE module with this amitse300mod2.ffs, save image. Flash this new BIOS and you will still have 8.1.40.1416 as ME version, but you will be able to flash any 7.xx or 8.xx version from Windows. Flash 8.1.51.1471 from Windows, reboot to see if the ME is reflashed (ignore the version for now), shutdown for a couple of minutes, boot and check ME version. The limits of this method is that it only works with BIOS 3.00, any new release will require a new patched AMITSE. Use this second method only if you like testing. The first method is already tested and a lot safer.