aboutsummaryrefslogtreecommitdiff
path: root/src/mainboard/lenovo/l520/cmos.default
diff options
context:
space:
mode:
authorEvgeny Zinoviev <me@ch1p.io>2019-11-21 21:47:31 +0300
committerEvgeny Zinoviev <me@ch1p.io>2021-02-07 01:46:54 +0300
commitb01b13866a6049ac81bd11861a29c3f4e591f951 (patch)
treeaab52e1fcdf6633020fda8081f16499c3cd46c20 /src/mainboard/lenovo/l520/cmos.default
parentdc413403cfebf233d9cd03fa629744fc4fc1b563 (diff)
sb/intel/bd82x6x: Support ME Soft Temporary Disable Mode
- Add support for ME Soft Temporary Disable Mode. In this mode, ME doesn't load its kernel and freezes at Bring UP (BUP) phase. This mode is saved in ME NVRAM (and thus will remain for next reboots and poweroffs). - Add support of new CMOS option for Sandy Bridge and Ivy Bridge ThinkPads. HOW TO USE To disable ME: 1. nvramtool -w me_state=Disabled 2. reboot To enable it back: 1. nvramtool -w me_state=Normal 2. reboot To check current status: intelmetool -m Tested on ThinkPad X230 and ThinkPad X220. BACKGROUND There's no Intel documentation that would explain how this should be implemented, in public. Working binary sequence for MKHI command to put ME in Soft Temporary Disable Mode, as well as a way to bring ME out of it (by writing to H_GS register), was found and published by researchers from PT Security: 1. To disable ME, BIOS issues the disable command (before End of Post) and reboots. ME is supposed to be disabled on the next boot after DID (DRAM Init Done). My numerous tests show that issuing the command and rebooting is not enough. If we reboot too early, ME will not be disabled. Apparently, it is doing something in background after receiving the command. It works with a delay of 500-1000 ms. I also tried to dump all known (documented) registers, such as GMES and HFS, before and during the next 2 seconds after execution of the disable command to find a possible indication that something's changed in ME and we're ready to reboot. Found nothing unfortunately. 2. To enable ME back, host writes value 0x20000000 to H_GS. PT slides don't contain any more information on it, but my tests show, that after writing this value, GMES[31:28] is changing from 0x01 (BUP phase) to 0x03 (Policy Module) to 0x06 (Host Communication). Then, after some more time, fw_init_complete bit of HFS becomes 1. This means that ME starts loading its kernel immediately, without reboot. On the other hand, Lenovo BIOS clearly perform a reboot after enabling it (one reboot after saving the settings, then ThinkPad logo appears, and then one more reboot). I'm assuming we have to reset too. Change-Id: Ic01526c9731cbef4e8552bbc352133a2415787c2 Signed-off-by: Evgeny Zinoviev <me@ch1p.io>
Diffstat (limited to 'src/mainboard/lenovo/l520/cmos.default')
-rw-r--r--src/mainboard/lenovo/l520/cmos.default1
1 files changed, 1 insertions, 0 deletions
diff --git a/src/mainboard/lenovo/l520/cmos.default b/src/mainboard/lenovo/l520/cmos.default
index 979f132863..681c40e78b 100644
--- a/src/mainboard/lenovo/l520/cmos.default
+++ b/src/mainboard/lenovo/l520/cmos.default
@@ -14,3 +14,4 @@ sticky_fn=Disable
trackpoint=Enable
backlight=Both
usb_always_on=Disable
+me_state=Normal