- 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>
Fix a typo and do some style improvements.
Change-Id: Ibc7e1869faa6b9ae12a51b1c3d209bbd8e54b0d2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49402
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Old archive is not available anymore. The tint sources inside the new
archive are the same (something changed in a debian subdirectory but
we aren't using it), so a libpayload_tint.patch is still valid.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: If556fac7d1d8379a022f59ed6aee1450b7bc5aa7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48616
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using MCHBAR32_AND_OR() in these two cases changes the order of
additions slightly. Originally, the MCHBAR offset and the base
register offset (0x5a4/0x5b4) were added first. Due to the added
parentheses in the register macros, now the complete register
offset is calculated first and then added to MCHBAR. Associativity
tells us that this doesn't change the result.
Changes in the resulting binary were verified manually on the
object file.
Change-Id: Id10882225c8e82b02583aa73e73d661c25abdef9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50355
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clean up cosmetics after refactoring the code. Reflow long lines and
align values in the tables, and also remove a now-unnecessary scope.
Tested with BUILD_TIMELESS=1, Asus P5QL PRO remains identical.
Change-Id: I2712c1ad5404d6968d18d762e6048c5da120ff78
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49400
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The first RCOMP group (data) is programmed differently, and has its own
tables. Remove the unused first index from the other tables, and adjust
the loop bound accordingly. Cosmetics are cleaned up in a follow-up.
Tested on Asus P5QL PRO (DDR2), still boots.
Change-Id: I3010acbd00f762c91aebeaf1625ed7543b14bf74
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49399
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The RCOMP data group is special and is programmed differently. Prepare
to simplify the code by programming it outside of the loop. Subsequent
commits will simplify the logic even further, then clean up cosmetics.
The special DDR3 case in the loop overwrites the command group strength
multiplier value. It doesn't need to be programmed for each RCOMP group.
Add a comment to justify not programming this register while programming
the settings for the RCOMP data group.
Tested on Asus P5QL PRO (DDR2), still boots.
Change-Id: I5c2484f48e3c07e8e787b1894932e342e8e8a75c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49398
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
These settings can be programmed with a single register write. Factor
the writes out into a single function to avoid some redundancy.
Tested on Asus P5QL PRO, still boots.
Change-Id: I3a08c255dd2b0deae650c7fe2ba4e1f4d1cef581
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
MRC uses an incorrect mask when programming this register, but the reset
default value is zero and it is only programmed once. As it makes no
difference, we can safely use the correct mask. Document this difference
in a comment to indicate the deviation from MRC behavior is intentional.
The default value for this register was dumped from Asus P5QL PRO.
Change-Id: I93b0c382f76e141b319414258e40a8bfe6c7848a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Consistently use commas after the last element of arrays, and also align
columns of values and comments. Remove `MHz` units from DDR speed values
to avoid confusion, as the memory's actual clock speed is half of these.
Tested with BUILD_TIMELESS=1, Asus P5QL PRO remains identical.
Change-Id: Id13022483c6221ce87d21dd21a5cfe4317a55ccd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Time has proven this statement to be unnecessary. Uncommenting it would
not have any effect on the existing code, thus remove it completely.
Change-Id: Iff4cdd71435e4fd69d4f3284e9fb2830fdd5b173
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Use gpio_keys driver to add ACPI node for pen eject event. Also
setting gpio wake pin for wake events.
BUG=b:176213181
TEST=emerge-volteer coreboot chromeos-bootimage
Signed-off-by: Pan Sheng-Liang <sheng-liang.pan@quanta.corp-partner.google.com>
Change-Id: If0959df5d0f069048777df81b0d4092ea90314eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49967
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Fix compilation on GCC 10.2.1 and address the underlying issue. The
printf format specifier for a size_t type is z.
Change-Id: Ieb1db6c0c3eb4947bd3617e418bac238b70ec08f
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Alderlake includes latest VBT (version 237 onwards),which has size of
8.5 KiB. This change is specific to alderlake so utilizing Kconfig option
to increase VBT size specifically for ADL platforms.
BUG=None
BRANCH=None
TEST=Include new VBT and boot the platform. Able to see firmware screen
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Change-Id: I438f4bce0a2dfa208e1cd59d1cd5dd1c5ad50833
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
These accessors can be reused for several other northbridges.
Tested with BUILD_TIMELESS=1, Roda RK9 remains identical.
Change-Id: Ia16ccc63dddebf938f4e9a7f5518e4d25d3e7e66
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49748
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No board in tree selects a different base address, so this can be
removed from Kconfig and be treated like the other base addresses in the
I/O space that are defines in iomap.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iec3d4476e3a6a5d2b226edef4c41f503a0c81f33
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50292
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Since I'm not sure if there are non-upstream boards that change the
default of the Kconfig value and the comment says that it needs to match
the binaryPI build, I'll do that change in a follow-up patch to allow
easy local reverts of that.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic0f08c6cb951994be6db19e10f73f0c621521c70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Drop casts to prevent pointer arithmetic and for consistency with other
platforms. These macros will be factored out in a subsequent commit.
Change-Id: I959e7378a8bf46fd1772192090a751d7a2f6f470
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49747
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Guarding the MCHBAR macro breaks reproducibility, but should not have
any functional impact.
Change-Id: I8be8d7b8a0f289d2be76d3dec43999f6b42e3265
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49746
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
smbios_type0_bios_version is only defined if HAVE_ACPI_TABLES is set.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I626ab954496833f46d6a785d92cc3b7e7d87e165
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Needed so we can reserve the memory.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8f5bb9d97932f75ca4ce22fbe9df4c0148acbea5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We need the same functionality for cezanne.
TEST=Boot ezknil
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I0800c662bb473eb571c74e76a8247298f534b53f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The sub-process calls break make's dependency tracking, hence we have
to always perform the calls if we want to allow automatic, incremental
builds.
We let each rule depend on a new, phony target `force-payload`. It has
roughly the same effect as tagging all the targets as phony, but doing
so would feel wrong as some of them are actual files.
Change-Id: I1bc2406db371e8dddbfdf71f68a6665a5b558f5e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The new `Makefile.payload` can be included by the Makefiles of pay-
loads for in-tree builds. The basic idea is to use libpayload's
build results without the `make install` step, and to ensure that
incremental builds work. For instance, if libpayload's code changes,
a `make` for the payload would automatically update the libpayload
build and rebuild the payload. But if there are no code changes in
libpayload, only updated files of the payload will be re-built.
The configuration of libpayload is supposed to be automatically
generated from a `defconfig` file. If this `defconfig` changes,
libpayload and the payload will be re-built.
Change-Id: If5319f1bf0bcd09964416237c5cf7f8e59f487a2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47633
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot's Makefile exports a lot of variables that influence make sub-
processes (e.g. for Kconfig). We don't want these variables leak into
sub-processes for (lib)payload builds, hence unexport them.
Change-Id: I8da2d8db6238d456723b9c22bee80c62e97027b0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48940
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot's Makefile exports a lot of variables that influence make sub-
processes (e.g. for Kconfig). We don't want these variables leak into
sub-processes for (lib)payload builds, hence unexport them.
Change-Id: I7d65c0aa6d4550bd6600c437e838339af69496da
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48939
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
FILO's Makefile will check for libpayload and might not even `clean`
if it's not found.
Change-Id: If5f8f4ecce317e54cd4b5688553cc38220f6e6df
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36461
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Mark TSEG as reserved, which is done on other platforms as well.
For some reason CorebootPayloadPkg crashes when using the region where
TSEG typically resides, which is basically RAM.
UefiPayloadPkg doesn't show this issue.
Change-Id: I3ae3659349d2a88bc3575fe9675433c054e28832
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50267
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Kyösti Mälkki