summaryrefslogtreecommitdiff
path: root/src/commonlib/Makefile.inc
diff options
context:
space:
mode:
authorEvgeny Zinoviev <me@ch1p.io>2019-11-21 21:47:31 +0300
committerEvgeny Zinoviev <me@ch1p.io>2021-02-05 23:29:17 +0300
commitcc5f7de34a857bc55e74e2d63093badd856919e8 (patch)
tree281767fdc81c778c5aac58a65245854b1d50a2af /src/commonlib/Makefile.inc
parentae1d122372c0c0393b8278ee6d7e6c61ebf364ce (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/commonlib/Makefile.inc')
0 files changed, 0 insertions, 0 deletions