ASRock X79 Extreme6 ME Subsystem N/A

Hr_KaLeu · June 21, 2020, 1:53pm

I agree with you. No matter what road I go down, no matter what BIOS I hammer into the chip -> no change.
The idea with the older BIOS was already in my mind. I did manage to even find the first release. However, I have to go at least with version 2.40 since every release before wont support my CPU.
A first look into the details by using UEFI Toll tells me, that ME Version seems the same.

I also forgot to ask a question: is there a special procedure to prepare the BIOS file that I donwload from ASRock before program it into the chip by using the programmer? I tried forcing the programmer to use the file that comes from ASRock, I tried to rename the file extension to bin and I also tried the UEFI tool to extract the entire file that then creates either a *.rom or *.bin
The result was always the same as described many time above.
Anything else I overlooked or made wrong?

plutomaniac · June 21, 2020, 5:07pm

Ah you are using an IVB-E CPU then? This is why I mentioned v2.20, it was the last official BIOS with SNB-E support only (ME 7) and was wondering if ASRock made a mistake during the transition from ME 7 (SNB) to ME 8 (SNB/IVB), considering that FITC v8.1.40 is a bit broken while working on PBG platforms. But, honestly, I don’t think that would change anything because everyone with the same motherboard would have had that problem in such case. You can try asking ASRock but I doubt they’ll say anything for a ~10 year old platform. The BIOS that ASRock provides is a proper 8MB SPI image which can be used directly with your programmer so no, unfortunately you’re not making a mistake there.

Hr_KaLeu · June 21, 2020, 5:54pm

My CPU is a an i7-4960X. So, yes it is Ivy Bridge-E.
I figured that it does not make any difference what type of file I do program. Otherwise I would have seen other problems as well. I just asked to rule out a possible mistake.

At this point I am completely out of ideas. I also tend to say that both chips are ok. I tried another procedure to make sure that the chip is totally empty before programming a bios image. I did fill everything with 00 then with FF then erase then blank test. I assume that, if the chip itself has problems I would have seen some statement within the programmer software.

Maybe I try to get in touch with the ASRock folks and see where it goes. Otherwise I could get myself a Sandy Bridge and try again. However, this could be a waste of … something in the neighborhood of 30 - 50 Euros if the board itself has a problem somewhere inside.
Oh well, if only those parts would not have been so expensive back then when I did purchased them.

plutomaniac · June 21, 2020, 6:43pm

Nah, don’t get a SNB-E just for this. It’s not worth it. In fact, a replacement X79 board could be cheaper. It’s not the SPI chip either and it might be best to not write it more so that it doesn’t wear out completely. In the end, my guess is hardware issue like bad PCH/Chipset (where the ME co-processor is), capacitors, VRMs etc.

Vincent12 · June 23, 2020, 4:08am

@Hr_KaLeu

What about using UBU to update CPU microcodes, and/or using MMTool adding the missing CPU-microcode for your CPU in the older BIOS version?
—
[Edit]
My basic question was if it was risky, when flashing ME-updated firmware with external programmer, where I cannot run the “fpt.exe -greset” command at same boot phase
so easily when I want to avoid risking a shortcut on EEPROM when removing it from frunning system (so if better switching computer off in between and with external flashing), but if ithat would cause a permanent brick, because there I cannot run “fpt.exe -greset” command at same boot phase after BIOS-ME update, or if it could be restored with external flashing my my backup-dump (with last older ME), and if I needed an unlocked FD just for that.

Because I was unsure about if the “fpt.exe -greset” would have to be set directly after ME update (whether by FPT.exe or by external programmer with plugging EEPROM away from booted system, programming it, and replugging EEPROM back to the booted FreeDOS-system) or if it could be done also after a reboot,
so I tried safer thing, (mattering the ME-reinitialization thing), with doing it at same boot phase (with plugging EEPROM from booted system, programming chip, and replugging EEPROM back to the booted FreeDOS-system, and then directly the “fpt -greset” command)…
Before doing that, I remember, before trying updating ME and plugging off EEPROM from running system while in FreeDOS and flashing update SPI image with programmer etc…
I accidently ran “fpt.exe -greset” on the older ME-SPI image version already (on latest already flashed BIOS from Asrock). This wasn’t the reason for inteferring with later ME update procedure?

It appeared there was nothing harmful about running “fpt.exe -greset” on old registred ME firmware to Co-processor, no warnign message (last used older original ME firmware) standard “fpt.exe -greset” ME reinitialization messages system, without error warnings, rebooted normally…
…although FD and ME firmware locked in old and new modded firmware):

Then I tried updating ME in the EEPROM-chip for 1st time, (with plugging EEPROM from booted system, programming and replugging EEPROM back in booted FreeDOS-system)

However I got same warning messages as Hr_KaLeu (see [Edit} 2nd picture post #290), as here:
(I didn NOT clear CMOS in between when I accidently ran "FPT.exe -greset" (without doing any ME update) and on the old used ME firmware from Asrock newest installed BIOS, and then updating it, I just booted back to FreeDOS right away and attempted the update via programmer and running -greset.exe on swapped back EEPROM-chip) And here error message like Hr_KaLeu

As safety precaution, playing back directly the earlier modded image (with the last used older ME firmware version) with ext. programmer (letting system still running), then putting flash chip back in, WITHOUT ANY new PC start NOR ANY rebooting, and ran “fpt.exe -greset”. etc. No error message, system rebooting automicalln, then after successful PC restart, shutting of PC manually removing pwer cord and the CMOS battery and CLR-RTC-jumper set to 2-3 for few minutes.

Again doing 1), booting to FreeDOS. Removing chip from already booted system, programming it with newest SPI BIOS image with newest updated available ME, setting back in. Then I retried 2nd time the "fpt.exe -greset (during constant boot period), still error same message Hr_KaLeu gets , noticing I had a netqwork cable plugged in connected with 2nd computer, plugging LAN cable of Z77 Pro4. So attempted “fpt.exe -greset” comand again (without rebooting), and interestingly it suddenly worked with the new ME firmware SPI-image, no error warning any more rebootinmg automatically, not any error message with new ME image, and fpt -greset command, showing the standard-ME-insatll-initializiation messages

Though I haven’t tried me MEInfo Tool, if the new ME firmware was healty, but ME hardware VID 0x8086 ,PID 0x1EA3 listed in Device Manager under PCI-communication-controller.
But ME Update with cleaning the ME Region from Dump and transferring the setting and updating ME seems to be fine before.xml and after.xml and only very small settings different, plutomaniac recommended as guidline, to show up only with Beyond Compare:

—

In the meantime I had used ME_cleaner to remove ME firmware from SPI image,
[[File:intelmetool_-mod_MMTool_5.0.0.7_vbios-orom_replc.,UBU_1.79.1_RST_GOP_LAN_O.SATA_-(MMTool)612-Upd.&611_del.+nvme_insert_comprssd.-UBU-ucode_repl.,ME_Upd_Asrock_Z77_Pro4_P2.00(Upd)_Original-FW.png|none|auto]]

[[File:intelmetool_-mod_MMTool_5.0.0.7_vbios-orom_replc.,UBU_1.79.1_RST_GOP_LAN_O.SATA_-(MMTool)612-Upd.&611_del.+nvme_ins._cmprsd.-_UBU-ucode_repl.,ME_Upd,ME-Disbl_Z77_Pro4_P2.00Orig.png|none|auto]]

…And system appears to act quite much faster, withiout it, than with ME. The ME firmware update made system faster and it solved Asrock-BIOS-setup-bug, when "Discard Changes and Exit"did nothing, also fw-setup faster
and ME firmware cleaning did accelerate it a bit still more, still all bugs solved
LPC-controller (unknown device =>LPC no driver was installed) not longer shwoing up in Device-manager (only as old greyed out entry from shielded-out entries), after ME cleaning, but it still is listed in Linux under “lspci”.

Another serious bug that got solved, was when I hit/touched a had little bit a DVI-plug (e…g plugged with display with power supply) or an USB-connector that is connected SATA-HDD-USB-case-adapter (external power supply), hitting/touching its metal-shielding from 2nd-plug-side just a little bit only to the IO-shield and anywhere Mobo-connection-panel or near to an connector (where you can some small lightning on the metal sometimes (e.g. from “capacitive coupling” s.o. explained to me), the system suddenly freezes, and monitor was flickering around and showed only patterns and image inteferences, no Desktop visible any longer, computer freezing and after ca 30 seconds PC rebooting,
this got solved. The IO-blend when I put mainboard into PC case did minimized that beaviour a lttile bit, but still after ca. 3 times bug was still reprodcucible,
now with either ME update and/or it cleaner, hitting a few different conenctors a bit multiple times (tested about 50 contacts) against metal-brackets, etc, no longer causes anything from that at all,
I can’t say for sure what of the two solved, but the old ME version 8.1.0.1248 certainly had that issue. Suspected that, and is correct.

–
Next I’ll try if Wake-On-LAN works, but probably NOT without ME running.

intelmetool_-mod_MMTool_5.0.0.7_vbios-orom_replc.,UBU_1.79.1_RST_GOP_LAN_O.SATA_-(MMTool)612-Upd.&611_del.+nvme_insert_comprssd.-UBU-ucode_repl.,ME_Upd_Asrock_Z77_Pro4_P2.00(Upd)_Original-FW.png

intelmetool_-mod_MMTool_5.0.0.7_vbios-orom_replc.,UBU_1.79.1_RST_GOP_LAN_O.SATA_-(MMTool)612-Upd.&611_del.+nvme_ins._cmprsd.-_UBU-ucode_repl.,ME_Upd,ME-Disbl_Z77_Pro4_P2.00Orig.png