Move `mainboard_gpio_map` declaration inside header and reorder some
function declarations. This is to align the header with Broadwell.
Change-Id: I436d7fdabf8d574e5dd2787fb6097f384cc8e453
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50065
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We deal with mb/lippert/frontrunner-af later since it currently
does not include <cimx/sb800/acpi/fch.asl>.
Change-Id: I30b611fc1fb01777223d7222adc96308a247a35c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50591
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix regression with commit aa969e887a ACPI: Move PICM declaration.
While mentioned in the commit message there already, the default
value for AMD boards changed from IOAPIC mode to PIC mode.
ACPI 6.3 spec has this text regarding _PIC method:
If the platform CPU architecture supports PIC mode and the method
is never called, the platform runtime firmware must assume PIC mode.
If MADT has IOAPIC entries, OS will want to change to APIC model. But
the method _PIC was not in the global scope so it could not be called
and therefore _PRT continued to report PIC model interrupt routing.
Already fixed for soc/amd/picasso in commit 839f668.
Change-Id: I7f3bb0d45946cec315694de1d540fea4d828348e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The only difference between ME7 and ME8 is the MKHI message handling.
Remove duplicated code, and also clean up includes.
Change-Id: Ia44eb29d3509eb4208ba2aed9e0cf7e8f8d2c41a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49992
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Evgeny Zinoviev <me@ch1p.io>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows dropping some preprocessor usage. The `mkhi_end_of_post`
static functions had to be renamed to avoid a name clash. A follow-up
will tidy up the code in me_smm.c to reduce some duplication.
Change-Id: I6357fed3540be87f42d1fd59534666b9092d0652
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49991
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Evgeny Zinoviev <me@ch1p.io>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows us to get rid of the `__unused` attributes. Subsequent
commits will separate ramstage and SMM code into separate files.
Tested with BUILD_TIMELESS=1, Asus P8Z77-V LX2 remains identical.
Change-Id: I1aaef5aa23561bee04f8dd9ddca66738bca91bb4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49990
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Evgeny Zinoviev <me@ch1p.io>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Platforms with bd82x6x do not initialise OSYS, so HPET is
always hidden.
The two boards lenovo/x201 and packardbell/ms2290 using
sb/intel/ibexpeak but still including <bd8x62x/acpi/lpc.asl>
initialised OSYS using _OSI() method and showed HPET selectively.
Change-Id: I02fffd439be2a5a9d22afd67e68abce888361214
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49486
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on the detected OS the HPET ACPI device needs to
be hidden sometimes.
Change-Id: I4c6f87f30ea0de5c073b1fcf57794bb9e19d4d91
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49483
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The southbridge common SPI support already does this.
Tested on Asrock B85M Pro4, internal flashing and MRC cache still work.
Change-Id: I7ce0ca584cd3d42a10cdb74f45742f1eadc01bfa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Not all TCO status bits have a corresponding enable bit. Masking out the
status register with the enable register causes these events to be lost.
Tested on Asrock B85M Pro4, BIOSWR_STS events are now detected.
Change-Id: I49abb5a4a99e943e57e0aaa6f06ff63bdf957cd3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Lynxpoint PCH-H does not have SerialIO, so do not generate its SSDT.
Change-Id: Ie816ebd470df93a45826498bf21be59ff0a813bf
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
IASL complains that creation of named objects within a method is highly
inefficient. Avoid this by moving these named objects out of the method.
Change-Id: Iabfb20dcb3f655658844d99ab7a3b479684d9d19
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Was copy-pasted from bd82x6x and no mainboard actually needs it.
The few globals moved outside the GNVS will be removed, relocated or
replaced with acpigen later.
Change-Id: I590a355f1bd1e54365b2e329cfdc62384446a15c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49280
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Was copy-pasted from i82801ix and no mainboard actually needs it.
Change-Id: I400424540b52dc5d43aba15720b18ad57ea2ebda
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49279
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Variable PICM was not inside GNVS region and can use a static
initialisation value.
For most AMD platforms PICM default changes from 1 to 0.
Fix comments about PICM==0 used to indicate use of i8259 PIC for
interrupt delivery.
Change-Id: I525ef8353514ec32941c4d0c37cab38aa320cb20
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49905
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The value should be set by OSPM using some combination of
_OSI() queris in the \_SB._INI() method.
To maintain previous behaviour with this commit, boards where
GNVS osys initialisation was removed now do the same in ASL.
Change-Id: Id4957b12a72fbf7fa988e7ff039e47abcc072e1c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49353
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Initialize variable to 1 to indicate AC power supply.
If platform has EC it will set this correctly based on
whether plugged on the charger or not.
Change-Id: I3f834cf7563b9e512fcab34cdb7a27a9f0fd31c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49352
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make it look more like the file under amd/pi/hudson.
Change-Id: I5b40dc5b6f54bf68113826e693ca5963fec83d38
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50461
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
It is already set in `src/arch/x86/acpi.c` function `arch_fill_fadt`.
Change-Id: Ica7e112ca253d1332ed2ea414948c8f1970d0a69
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
- 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>
