Complete ME disablement on X79 systems? #278
Comments
|
Do you mean WDT? My Rampage IV Gene has it(refer to picture). I successfully ran ME_Cleaner with the /S flag on it, and no 30 minute reboots. Everything works fine AFAIK. Did you wipe the ME region more completely than the ME_Cleaner script or something? I thought it is necessary for ME to initialize the CPU in the first place? |
I don't think so. I couldn't find those IO ports in the X79 datasheet, but I think they are part of the southbridge watchdog. The ME watchdog isn't exposed to the OS AFAIK. The only way to check whether it exists is to erase the ME region, boot the board, and wait 30 minutes.
Yes, I erased the entire ME region. Normally when you do this the ME will shut off the system after 30 minutes, but apparently that does not happen on some machines.
I heard this as well but it doesn't seem to be the case for X79/SandyBridge-E. Maybe it is true for more recent Intel systems or non-HEDT platforms? If you want to test this I can prepare a ROM for Gene or give instructions for creating one. You will need to be able to recover from a bad flash if it doesn't work. Gene seems to have USBFlashback so that shouldn't be a problem. |
|
I have a CH341a flasher, so I'm not worried about a bad flash. I don't mind testing it, but I can't deal with a broken LAN port, so I might need to switch back to my current image after testing. As for modding the BIOS, I already have a modified image(Microcode update(42E), NVMe mod, ME_Cleaner), so if you like me to test removing the Intel ME region entirely, I would prefer instructions for further modifications instead(I would still like to keep my current modifications in addition to any new modifications required). As for your first side-effect of rebooting after resetting BIOS, I can confirm I encountered the same after using ME_Cleaner with the /S flag.
Do we put this line somewhere in the UEFI or something? Or is this a Linux command? I'm currently using Windows, at least till my NVMe adapter comes (Well, not like I'm proficient with Linux in the first place). If there is an automatic way of resetting the LAN after a cold boot I don't mind using the modified BIOS on a long-term basis. PS Did you actually manage to flash the image with ME removed using BIOS flashback? I tried modifying the ME region and the flash seemed to pass (the button flashing and all), but the modifications were not actually reflected in the system (I did the NVMe mod+Microcode update(42C)+ME_Cleaner all at one go, and none were reflected). I know a simple Microcode update works however because I updated the microcode (to older 42A) using USB flashback. In the end I tried using FTK8 to flash but it only wiped the SPI chip and bricked my board. I only managed to get it back up and running after getting an SPI flasher, but lost the UUID permanently in the process(not like it matters however). |
In that case I assume you are already familiar with UEFITool? Here's what you need to do:
All of this assumes you have not used the -t flag of me_cleaner to truncate the ME region. In that case you will need a differently-sized file. You can create the file by extracting the ME region with UEFITool and overwriting the entire contents with 0xFF bytes in a hex editor. After this, if you boot up your board and it stays on for more than 30 minutes, Gene doesn't have an active ME watchdog timer either.
That's C pseudocode. I wrote a UEFI module that does this but it also takes over the BDS process and boots directly to GRUB (in firmware). I can see about isolating the GbE fix into a separate module to be inserted with UEFITool. The fix can also be done in GRUB or in Linux, but in the latter case you have to reload the e1000e module. I'm not sure about Windows.
Yes, USBFlashback behaves differently depending on the file name you use. The normal file names like "R4E.CAP" and "R4G.CAP" only flash the BIOS region. "ERALL.CAP" seems to flash the BIOS and ME regions at least. You can also use the ROM variants of all of these names if you don't have Capsule files. Thanks for testing this out |
|
Managed to remove the ME region entirely. Fingers crossed for the 1/2 hour mark! |
|
...and, it works! Interestingly, Intel ME completely disappears from device manager, instead of showing a power failure status. Does this, by any chance, hint at Libreboot potential?
|
|
Interesting findings from my side: 1: Not sure if it's fast boot or not using Windows Boot Manager(boots directly off SSD), but I don't experience the LAN port disablement upon cold boot. 2: Now, this shows up during boot: 3: Also, there is now an additional entry in the boot menu: Now, in contrast of using ME_Cleaner, this actually resulted in the motherboard to post very slowly each time it starts, instead of just the first one. Will update if and when new findings are spotted. Edit #1: Intel WDT is now gone and changed to "Motherboard Resources": |
I think so! If the hardware initialization bits can be reverse-engineered the only proprietary parts would be intel microcode & iROG (EC) firmware, both of which are already issues for libreboot-supported systems like the X200.
Interesting. That could be a side-effect of the PXE option rom, which seems to have been enabled on your system for some reason. It could also be that the Windows drivers are able to recover from the failure state while the Linux drivers can't.
That's unfortunate, but something I also noticed when testing this. I think it may be caused by the ME drivers needing to time out before the post continues. I'll need to look into this more.
I didn't expect this. Maybe those ports do have something to do with ME. |
|
Well, after finally shoving the motherboard into the PC case for general use, I have an update here. Intel ME intermittently(persistent until reboot) appears and disappears in Device Manager: I have confirmed that nothing has modified the BIOS to add the ME modules. I used FTK to dump the BIOS and used UEFITool to verify, and the ME Region is still empty: I noticed that sometimes, Windows load time is significantly faster(insanely fast (<5 seconds) probably due to Fast Startup, but is somewhat sluggish from Ctrl-Alt-Del prompt to password prompt). In this case, I noticed the ME appears but "cannot start". However, if Windows loads slowly(typically from restart/power loss)(the loading speed does not necessarily reflect the capabilities of a SATA SSD), ME disappears completely from the system as per normal. The long POST time is consistent. I suspect this is due to Fast Startup, as I just attempted to shutdown+power on and Windows load up fast due to a quasi-hibernation technique, and ME appears albeit broken. A restart from Windows got everything back to normal(ME disappears). In HWiNFO64, the Intel Watchdog still shows as "Motherboard Resources" consistently. I also have no problems with LAN at all as well. Not sure if this is normal/expected. Could there be hidden ME modules in other regions of the BIOS which caused this? Can ME even "load partially" if the ME region in the BIOS is empty? (Edited to remove/rectify inaccurate information) |
|
Another thing: Not sure if this is the watchdog shown in HWiNFO64, but this device is disconnected from the system after removing ME (Both completely and after ME_Cleaner). It never came back.
Interesting find: The LAN chip is now detected as the "enterprise" 82579LM instead of "Consumer" 82579V after removing ME completely(but not after ME_Cleaner).
Edit: Did ME_Cleaner and ME Removal on same day. Managed to trace back the time I did them by comparing time commented on GitHub and the Last Arrival Date in Device Manager. |
I don't think the ME is working at all. I was able to get the MEI device to come back on warm boots but it isn't functional - it returns garbage in lspci: I think this is just a sign of the BIOS taking different paths for cold vs. warm boots. I have an idea about preventing this but I will need to test it. RE: sluggishness, I don't experience it on Linux, and I don't know why it would happen on Windows. I would try uninstalling the Intel Watchdog Timer and Intel MEI drivers, if you have them installed. The long POST times are also not something I've been able to reproduce easily. They have happened to me but are rare and it's difficult to test fixes as a result. Can you give me an idea of how much longer your POSTs are without ME? Are there any POST codes that stand out? BTW, I found that I could get the "Intel Boot Agent" screen to appear by enabling "Intel LAN PXE OPROM" in the "Advanced->Onboard Devices Configuration" menu of the BIOS setup. Maybe check that? |
|
Here's the post code video(downscaled to 480p) of the mobo under "warm boot"--ME appears broken in Device Manager: During a warm boot, the POST code ends with "40". The uppermost LED is permanently lit after POST. Time taken from power on to successful POST is ~40 seconds. Here's the post code video under cold boot--ME is not present: During a cold boot, the POST code ends with "AA". The uppermost LED is also permanently lit after POST. Time taken from power on to successful POST is ~40 seconds. Approximate time (1 trial each, not average of n trials) taken from POST success to Windows Logon (Ctrl-Alt-Del prompt): Cold--2 minutes (~5 seconds ROG logo+IBA, 1 minute 53 seconds on Windows startup scroll, 2 seconds to lock screen) Warm--14 seconds (~5 seconds ROG logo+IBA, <1 second on startup scroll, 8-9 seconds to lock screen) Approximate total time taken from power on to Windows Logon (taken from separate singular trials): Cold-- 2 minutes 40 seconds Will try cold boot with ME/Motherboard Resources disabled in Task Manager, and investigate on the LAN PXE OPROM on next post. BTW, did enabling the OPROM fix your LAN issue during cold boot? Also, are you running on UEFI mode or Legacy? I'm currently running Legacy boot+MBR, but will need to switch to UEFI mode+GPT after the PCIe NVMe adapter comes in the mail. |
|
Uninstalled the ME drivers and rebooted. POST success to Logon Screen took merely 33 seconds, which is much faster for a cold boot. However, Intel ME is back in device manager!...for a short while. It disappears shortly after in device manager. Meanwhile when ME appeared briefly, the following still holds true: The briefly-shown ME in Device Management:
Another relevant screenshot, after it disappears: When I reboot again without uninstalling the drivers, the system took 2 minutes to boot again(sans POST). ME never appears in Device Manager at all, just like before. Therefore, I can conclude that uninstalling the driver does help(loading Windows, not solving the POST duration), although the drivers needs to be uninstalled before each cold boot. This could mean Windows is still detecting the Management Engine/whatever remains of it during boot even without the drivers. |
|
My times for comparison:
Original firmware, including ME: Firmware with ME removed: So it seems removing the ME increases warm boot times by ~12 seconds on my board. My guess is that this is caused by the broken MEI device reappearing and firmware MEI drivers failing to interact with it.
I boot in UEFI mode with the CSM disabled, though these tests were done with the CSM enabled. If you don't need the CSM after you get your NVMe adapter I recommend disabling it, as it drastically increases POST times.
No, so I'm thinking either the Windows drivers are able to work around the issue or it doesn't affect Gene. The former could explain your 82579LM "upgrade". |
|
As suspected, my fix for the MEI device reappearing also fixes the POST delays, with warm boots returning to their normal 25 seconds with CSM on. (9 seconds with it off) Hopefully it will prevent Windows from reinstalling the MEI drivers as well. I've patched the modules for Gene if you want to test the fix. You need: Open your ROM in UEFITool and replace the modules as shown:
|
|
More updates on my side: "Intel LAN PXE OPROM" is shown as disabled in BIOS. Yet, I see that IBA prompt during startup. I managed to take a retired SSD with Windows 10 1809(meaning released ~September 2018)(previously it was 1607, meaning released ~July 2016) and boot it up (UEFI mode). Initially it was reasonably fast to start up(sans POST), but after installing/re-configuring the drivers and a cold boot it detected the ME and again took ~2 minutes to load to the desktop(No password set on this install). I did not install the ME driver and all the drivers were installed from device manager itself. In this newer build of windows, the LAN is also detected as the Enterprise version. Gonna mod my BIOS right now, so fingers crossed. |
|
Changed the modules, flashed the new BIOS...and the motherboard stopped POSTing. It's the same symptom as the time I bricked the board with FTK, whereby it just cycles on and off repeatedly. After I replaced the first module with the recovery PEI file, I noticed the bottom 2 volumes(8C8CE...) were also labelled "Rebuild". After changing both all the bottom 4 volumes have "Rebuild" status on them. I have verified the flashing went correctly and also re-modded my BIOS to the same result. Could there be an issue with the 2 modules? |
|
Ouch. I'm sure you know how to recover.
Your ROM is based on 4901 right? Can you post screenshots of the Information panel in UEFITool with the PE32 section selected? Modded and unmodded preferably. EDIT: I was using an older version of UEFITool. I see the volume rebases now. Still investigating. |
|
Screenshots below:
While my motherboard underwent cycle-on-cycle-off process, there is still a flash of POST code on the top right instead of being blank (When I accidentally erased the boot block with FTK), which probably implies the BIOS image is partially working. |
|
Your MEPlatformPEI modules are at a different address than I expected. I like to avoid having UEFITool relocate PEIMs, as it always seems to cause problems. If you extract the original PE32 sections (Extract body) and upload them I can apply the patch. |
|
Extract body, just edited |
|
folder.zip |
|
...why am I using dropbox when I can just attach zips. Here you go: modules.zip |
|
And... It works like a charm! ME does not show up 'hidden' in cold boots anymore, and the system stopped taking so long to POST! ~48 seconds from power on to Windows on cold boot. As for POST, it takes approximately 10 seconds for a cold boot, which is a big improvement. LAN chip still detected as 82579LM, and I still don't experience LAN issues on cold boot. The IBA screen still appears with the PXE OPROM disabled. As for soft boot, it is also faster (~20 seconds from power on to lock screen) thanks to the reduced POST times. The ME is gone for good this time round. If you don't mind me asking, what did you modify on those modules? Not like I would understand much about how this works but... |
Great!
I changed them to OR the Function Disable 2 (FD2) register with 0x1E instead of 0x1C. Normally the MEPlatformPEI module only disables the second MEI device. I add bit 1, which disables the first MEI device as well. It's a simple one byte change:
And the relevant southbridge documentation: Without the MEI enabled the other modules (and Windows) don't slow things down by trying to talk to a broken ME. |
|
Mind blown
I don't even know where to begin lol. How do you find the correct module and the correct byte to replace? UEFITool/HxD surely doesn't show anything useful does it? |
|
Well, I knew I was looking for FD2, and the southbridge documentation tells me it's at RCBA + 0x3428. I know that RCBA on these boards is 0xfed1c000, which means FD2 is at 0xfed1f428. Searching for that address in UEFITool gives a bunch of results, but I wanted to put the fix in a PEI module so it would run as early as possible. That leaves SBPEI, HECIPEI and MEPlatformPEI, and opening the latter in radare2 revealed a great spot to make the change:
|
|
My NVMe adapter just came in the mail today, and I managed to install a fresh copy of Windows 10 (1809) onto the attached NVMe SSD. Even though it is a UEFI-based install, there is no apparent issues(except the SM2263XT-based "AliExpress" KingSpec SSD is having atrocious speeds all round, even with HMB enabled) and everything seems very stable. ME never appeared again since the latest modification of course. POST timings are still ~10 seconds but I'm not bothered by it. The boot times are not improved at all...but I blame it on the SSD for this one:
Honestly speaking, I'm not even sure whether this excuse of an NVMe drive is any faster as compared to my Samsung 840 SSD I used prior. The Random Reads/Writes are simply horrid. Fortunately, a 256GB PM981 is on the way to replace this thing, and I might be able to report some improved numbers lol. At this point, do you think it's a good idea to recruit more testers from other enthusiast/modding forums? This place is relatively quiet in comparison. Of course, there can be barriers by doing so, such as modding the PEI modules in DIY situations... While removing the ME region is simple, the modding of the PEI modules could be challenging though--I still have almost no idea of what's going on, or how to find the correct part to replace. Warning--Gore ahead What I kinda figured out, or what I think I figured out but in reality I didn't:
...and pretty much nothing else. Wow. What I still don't know:
Trying to use this to open and examine the PEI modules reminds me of the pain of trying to install an IME on an old Solus VM 3 years back--a mixture of despair, confusion and running all sorts random commands blindly while following a guide for an seemingly unrelated issue. I somehow managed to succeed on that one, but not this time round. What am I even looking at here(I think I know it's Assembly Language of some sorts)? ...I'm not a Linux guy. Sigh. |
Yes, I think so. I'm interested to know whether this is exclusive to Asus, exclusive to X79, or in the best case, affects other HEDT platforms as well. I'm not active on forums so I don't know where the best place to post it would be. I'll create a repository to organize this (one github issue per board) so as to not clutter me_cleaner's issues.
Agreed. I think UEFIPatch can help in automating this kind of thing. I'm not sure that all X79 boards use the same module though, so multiple patches may be needed.
Exactly. It's interesting that bit 3 is set here, as it's marked reserved in the datasheet. The usual practice for reserved bits is to not change them.
RCBA (Root Complex Base Address) is configured in a southbridge register. For X79, this is register 0xF0 of the LPC Bridge (Bus 0, Device 31, Function 0, or 00:1f.0). So we can find out the current RCBA by reading that register from the OS. In linux, this can be done with the setpci command: Bit 0 is not part of the address, it just enables decoding of the memory range, so RCBA is 0xfed1c000. If there is a Windows tool that lets you inspect PCI configuration space you could also use that.
x86 is little endian, so when you search for a memory address you need to reverse the order of the bytes. You need to search for 28f4d1fe.
r2 definitely has a steep learning curve. I would still consider myself a beginner. To edit in r2 you have to open the file in read/write mode, which you can do by starting radare like "r2 -w path_to_file". After that, in visual mode, you have to position the cursor on the byte you want to edit and use the 'wx' command to overwrite it. In this case you would use "wx 1e". That said, for a one byte change it may be easier to just use a hex editor.
Yes, it's x86 assembly language. More specifically IA32 assembly, as all of the PEIMs are 32-bit. |
|
The testing repo is https://github.com/nkht/me_removal If you know some good places to post it let me know, or feel free to post it yourself if you are already active in a forum. |
|
BTW guys, regarding the e1000e having troubles, it might not be Intel ME related at all. I've recently encountered an issue with my Intel GbE being totally unusable on Linux while it worked fine on Windows. https://bugs.archlinux.org/task/62699 |
|
@nkht Considering suitability posting on modding forums such as win-raid and bios-mods forums right now |
|
@Nowaker I think this is a separate issue. In my case when the NIC is broken e1000e fails during initialization and the device doesn't even appear in @weareanomalouswearearegion Thanks! |
|
@nkht Alright! Mine showed up but couldn't send any packets (e.g. to obtain an IP from DHCP). |
|
Posted on TPU & ycombinator forums as well. Unfortunately bios-mods and win-raid have relatively few people who wants to remove the Intel ME, and instead it's often the other way round (fixing a broken ME). Probably won't have much uptake there, but I might still post there anyway though. @nkht Also, I came across this discussion: https://forums.anandtech.com/threads/what-controls-turbo-core-in-xeons.2496647/page-86#post-39245371 Apparently on some X99 platforms, the Intel Microcode can also be removed from the BIOS after ME_Cleaner, with the consequence that S6 will be broken and require disablement. Does this imply that systems with removed Intel ME have the same capability? This could mean further compatibility with Libreboot, which requires/prefers the microcode be removed from the BIOS. I'm not sure about the actual benefits of removing the microcode however, since it is required for mitigations against speculative execution. |
|
I don't think the ME state is related to microcode updates on X79. I had actually been running my system without microcode updates for a while, but decided to install them to fix the speculative execution vulnerabilities. I didn't notice any issues when running without them, but that will depend heavily on your CPU model, stepping, and what features you need. Ultimately you will be running microcode either way. Removing the updates just downgrades the version. Unrelated - I wrote that UEFIPatch file to automate the MEPlatformPEI change. It's in my me_removal repo if you're interested. |
|
Well, I'm just curious of the forum post regarding the use of ME_Cleaner followed by removing the Microcode completely from the BIOS to obtain the “IntelRCSetup" tab in the BIOS of certain X99 boards. The complete removal of the Microcode in addition to the ME firmware in the SPI chip might interest Libreboot developers more, since they prefer the Microcode to be run from the CPU itself(as read-only). I would rather use the latest microcodes however, for protection against the various speculative execution attacks. Will fiddle around with the patch file on some BIOSes later. |
Sorry, the images don't work for me so I missed that. It's a menu to configure the Intel reference code blob. From searching, it seems it's visible by default on some boards, so my guess is the me_cleaner/microcode situation is just a quirk of whatever board that user has. There are some interesting ME settings in there but I don't know if changing them is any better than running me_cleaner with the -s flag. It's definitely something to look at if any X99 owners show up. Libreboot's microcode requirement should be fine - at least for some CPUs. |
|
I'm not exactly sure of Libreboot's interest in this at this point to be honest; there isn't much activity in that subreddit (There are 2 mods who are also devs there so I doubt they didn't see this) and naturally there isn't much replies there. One comment also mentioned that the team is tight in resources and manpower as well. I have tried your UEFIPatch file and it seems to work for the X79 motherboard firmwares I downloaded, including new Aptio 5 ones such as X79 Deluxe (Of course, I am not able to test whether the modded firmware are functional or not). However, trying to run it on an Asus C602 (Also patsburg PCH) (version 5802 for Asus Z9PE-D8 WS) motherboard firmware did not work (UEFIPatch gave the error along the lines of 'nothing to patch'). |
|
I believe that coreboot should be asked first for x79, even if you want Libreboot to support it. Since Libreboot is a downstream project of coreboot, I do not believe that Libreboot might want to add new board(s), or even accept new featured patch on their own. (I used to submit one for T400s, but it is ignored by Libreboot, so I eventually submitted it to coreboot and get it partially accepted. ) |
|
@weareanomalouswearearegion I couldn't find the MEPlatformPEI module in the Z9PE-D8 WS BIOS. That board will probably need a separate patch - if ME removal works. @persmule |
|
@nkht My bad, I think I opened a wrong BIOS file. Searched it again and found out there indeed isn't a MEPlatformPEI module. @persmule May I ask what exactly is a 'submission'? Is it just a request to the devs themselves or a 'you build partially/fully, they approve/enhance" situation? |
|
@weareanomalouswearearegion Mainly "you build partially/fully, they approve/enhance". I used to send patches containing enhancement ("featured patch" mentioned in the context of my last comment) to devs, asking them to review and merge. I hardly found any portal to contribute to Libreboot, so I has chosen emailing my patches to their mailing list, but Libreboot team ignored them. On the other hand, coreboot has their gerrit open for everyone to submit their patches to get reviewed and accepted. I mean, if even "you build partially/fully, they approve/enhance" get ignored by Libreboot, how can they accept mere requests for new boards not supported by coreboot at the time? I believe that the behavior above implies that Libreboot team have set their role as "deblobbing coreboot" only, so featured patches (including those adding new boards) as well as requests with similar goals should go to coreboot instead of Libreboot. You may try to mail your request for X79 to both mailing list of coreboot and Libreboot, seeing which team will reply. |
|
Well, giving up on an open source firmware for now, I have discovered another motherboard model that apparently does not have proper Intel ME modules/region in it. It is a thin Mini-ITX(not really, as it does not have the same power jack as Intel's specifications) motherboard sold at various sites such as eBay, Taobao and AliExpress under the name "HM65-988" without a manufacturer brand. Being 'new' boards, they are most likely made from salvaged 6 series mobile chipsets (and not necessarily HM65, contrary to what its name suggests). After obtaining one of these motherboards, which came with a QM67 chipset, I popped a dual core sandy bridge i7 in it, and discovered the following: Intel Management Engine is not present in Device Manager: HWiNFO64 does not show Intel ME component under the motherboard section: Intel MEInfo does not detect ME as well, throwing an error similar to X79: Using FTK8 to dump the BIOS, the structure of the firmware is unconventional. The motherboard is using an AMI UEFI implementation. Note the lack of ME region (and other regions): A random picture of the motherboard: There is only one module that has 'ME' in it, which is the MeInitPolicyPEI module. There is also a CpuInitPEI module present (maybe BUP is in here?). Is this conclusive evidence that ME is not actually present at all? If this is the case, could it be the case that all 6 series chipsets, and X79 (+all C200, C600 equivalent chipsets) have inactive Intel ME Watchdog timers? If anyone wants to investigate further, I can dump the BIOS files here. |
|
I've tested me_cleaner on a MSI X79A-GD45 (8D) somewhere in 2019 and it was kind of working; me was dead, boot time was ok, no lan issues, but the ime device was shown as defunc instead of completely disappeared as on the h61, z77, etc boards I own. I thought the device may be hardcoded in the pci routing table, but this thread gave me some hope. Maybe I'll mess with the board again as I own two of them and also an external flasher :) |
|
I have tested the procedure on a Asus P9X97E-WS. Everything is working fine |
|
Has there been successful attempts at Corebooting either of those two ME removable X79 motherboards? (ASUS Rampage IV Extreme, ASUS Rampage IV Gene). if not, could someone please attempt porting it please? It'd be beneficial to the community as these are the only boards we have to my knowledge with this support. also what are the proper instructions to follow for ME removal on these? thanks. |
|
@weareanomalouswearearegion Another thing I noticed is: ME behavior changed a bit with the 8th gen boards. I have a asus one with h81(?) and after disabling the ME, CPU-Z failed to report any CPU-Clockspeeds. Same for other software. But it seems to still perform well, though. |
|
I can report success! I have FF'd the ME region and applied the patch provided by @nkht Flashed my MSI X79A-GD45 (8D variant, bios rev 12.7) with it, and it just works. The boot time even improved.
Everything seems to work as expected and the MEI device disappeared without reappearance on cold/warm boots or after s3 resume. And no, I don't have the network boot agent issue. And the network card is still recognized as the correct model. Anything else to test? I may test the procedure on a ASUS P67 board, if anyone is interested :) |
|
hey, this link is dead: https://github.com/nkht/me_removal can you restore it? |
|
I'm told that there is an archive link: |
|
Yup, seems like the right revision as well. |
Hi all,
It seems that some chipsets (or mainboards?) do not have an active ME watchdog timer. I have an ASUS Rampage IV Extreme and was able to wipe the ME region (all 0xFF) with almost no ill effects:
AFAICT there are only two side-effects of removing the ME firmware:
When coming from a ROM with ME firmware, or when resetting CMOS, the first boot will fail after a second or two. The system resets itself, and then all subsequent boots succeed.
The onboard NIC doesn't work on a cold boot. This can be fixed by resetting the NIC:
*(volatile uint32_t*)GBE_BAR |= 0x84000000;If anyone else has this board, other X79 mainboards, or even more recent intel HEDT systems (X99 or X299), I think everyone would be interested in finding out whether they have active watchdog timers.
The text was updated successfully, but these errors were encountered: