summaryrefslogtreecommitdiff
path: root/src/mainboard/lenovo/t420
diff options
context:
space:
mode:
authorEvgeny Zinoviev <me@ch1p.io>2019-11-21 21:47:31 +0300
committerAngel Pons <th3fanbus@gmail.com>2021-02-07 23:06:52 +0000
commit833e9bad4762e0dca6c867d3a18dbaf6d5166be8 (patch)
tree3e5ad211109146671cfd1efae96e64989d901727 /src/mainboard/lenovo/t420
parent20a609f0f77ef84ef7f4f5e487000347c361a29e (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> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37115 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de>
Diffstat (limited to 'src/mainboard/lenovo/t420')
-rw-r--r--src/mainboard/lenovo/t420/cmos.default1
-rw-r--r--src/mainboard/lenovo/t420/cmos.layout6
2 files changed, 6 insertions, 1 deletions
diff --git a/src/mainboard/lenovo/t420/cmos.default b/src/mainboard/lenovo/t420/cmos.default
index 467f965829..8244071b8a 100644
--- a/src/mainboard/lenovo/t420/cmos.default
+++ b/src/mainboard/lenovo/t420/cmos.default
@@ -14,3 +14,4 @@ sticky_fn=Disable
trackpoint=Enable
hybrid_graphics_mode=Integrated Only
usb_always_on=Disable
+me_state=Normal
diff --git a/src/mainboard/lenovo/t420/cmos.layout b/src/mainboard/lenovo/t420/cmos.layout
index e1d15be56b..daf569c0af 100644
--- a/src/mainboard/lenovo/t420/cmos.layout
+++ b/src/mainboard/lenovo/t420/cmos.layout
@@ -34,7 +34,9 @@ entries
421 1 e 9 sata_mode
422 2 e 13 usb_always_on
-# coreboot config options: cpu
+# coreboot config options: ME
+424 1 e 14 me_state
+425 2 h 0 me_state_prev
# coreboot config options: northbridge
432 3 e 11 gfx_uma_size
@@ -97,6 +99,8 @@ enumerations
13 0 Disable
13 1 AC and battery
13 2 AC only
+14 0 Normal
+14 1 Disabled
# -----------------------------------------------------------------
checksums