Simplify generation of GMA SSDT, using updated naming convention.
If acpi_fill_ssdt is being invoked, then we know the IGD device is
present and enabled, so we can skip those checks. And the SSDT
generator now checks that the gfx struct is populated, so we can
skip that too.
Change-Id: Icd9caf622dd4c46b13589ebb772138b25888752f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39948
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
NDID/DID entries are no longer used by the GMA SSDT generator, so
drop them. SSDT generation will be simplified in a subsequent commit.
Change-Id: Ibb7898ab4fbbbfcd29b6ba72367cc55a02cd4b1e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
NDID/DID entries are no longer used by the GMA SSDT generator, so
drop them. SSDT generation will be simplified in a subsequent commit.
Change-Id: Iecd8559f660cc748c417ec94b7a822e16603cbd8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
NDID/DID entries are no longer used by the GMA SSDT generator, so
drop them. SSDT generation will be simplified in a subsequent commit.
Remove direct setting of gnvs->ndid in qemu-q35 board since build
will otherwise break.
Change-Id: Ifbf08f43291c1fff7ccbc85272dc97334207983b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39954
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
NDID/DID entries are no longer used by the GMA SSDT generator, so
drop them. SSDT generation will be simplified in a subsequent commit.
Change-Id: I51a11e7ed6686ab67dac3f02097457ea9c6a7e6a
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
NDID/DID entries are no longer used by the GMA SSDT generator, so
drop them. SSDT generation will be simplified in a subsequent commit.
Change-Id: Ie7491409681d8c2721dd6d6a16a8d5004cd0cf8a
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
NDID/DID entries are no longer used by the GMA SSDT generator, so
drop them. SSDT generation will be simplified in a subsequent commit.
Change-Id: Iec3a18871725fd5f5c4c568c2bd771bb56245bc7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add framework to generate ACPI methods in SSDT for
screen backlight control. Adjust params for gtt_ methods
to match prototypes in i915.h and avoid conflicts.
To make use of this, individual boards will need to
include default_brightness_levels.asl in their dsdt, as
well as add 'register "gfx" = "GMA_STATIC_DISPLAYS(0)"' to
their devicetree.
Change-Id: If93b7690ef36b5d19ca43957e8a1bef91ec5821d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Whether the GMA is used depends on the mainboard, so we shouldn't rely
on the presence of the static ACPI code around `GFX0`.
Change-Id: I4d20b459b8361e43435b535b2b395f51ce1704e6
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39978
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These two identifiers were always very confusing. We're not filling and
injecting generators. We are filling SSDTs and injecting into the DSDT.
So drop the `_generator` suffix. Hopefully, this also makes ACPI look a
little less scary.
Change-Id: I6f0e79632c9c855f38fe24c0186388a25990c44d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39977
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: David Guckian
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds new memory topologies (SODIMM, MIXED) that are
supported by DDR4 and macros required for DDR4 support.
Memory initialization support for DDR4 will be added in a follow-up
change.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I4b565c3d71bbf437da64ac29597cc19e58f1b98a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39866
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
This change reorganizes memory initialization code for LPDDR4x on
TGL to allow sharing of code when adding support for other memory
types. In follow-up changes, support for DDR4 will be added.
1. It adds configuration for memory topology which is currently only
MEMORY_DOWN, however DDR4 requires more topologies to be
supported.
2. spd_info structure is organized to allow mixed topologies as well.
3. DQ/DQS maps are organized to reflect hardware configuration.
TEST=Verified that volteer still boots and memory initialization is
successful.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib625f2ab30a6e1362a310d9abb3f2051f85c3013
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39865
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
The initialization code in common//psp is very specific to Family 15h.
Move this to the stoneyridge directory.
BUG=b:130660285
TEST: Verify PSP functionality on google/grunt
Change-Id: Ice3d06d6437f59a529c26fc2359565c940d39482
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/2020365
Reviewed-by: Eric Peers <epeers@google.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40000
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The commands used in Family 15h for loading the SMU FW blobs out of
flash had already been defined differently in Family 17h. To begin
removing Family 15h dependencies from the common/psp, change the
definitions of blob type to no longer match the Family 15h commands.
Consolidate the two functions used for interpreting the command and
applying the command into a single one.
BUG=b:130660285
TEST: Verify PSP functionality on google/grunt
Change-Id: Ic5a4926175d50c01b70ff9b10908c38b3cbe8f35
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/2020364
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Raul E Rangel <rrangel@chromium.org>
Tested-by: Eric Peers <epeers@google.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39999
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This commit creates a malefor variant for Volteer. The initial settings
override the baseboard was copied from variant ripto. Fine tune GPIO
and memory DQ based on malefor schematics.
BUG=b:150653745
BRANCH=volteer
TEST=emerge-volteer coreboot
Signed-off-by: William Wei <wenxu.wei@bitland.corp-partner.google.com>
Change-Id: Idbeebb13e537287686344740211143df35b7863a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39857
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds GOOGLE_LAZOR which is just a copy of GOOGLE_TROGDOR for
now.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0dca8e1c29bdd91625d58b3cb583b530ed925e9f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bob Moragues <moragues@chromium.org>
Reviewed-by: Philip Chen <philipchen@google.com>
CB:35077 pulled TPM measurement code into the bootblock, with the catch
that we'll only cache PCR extensions and not actually write them to the
TPM until it gets initialized in a later stage. The goal of this was to
keep the heavy TPM driver code out of the size-constrained bootblock.
Unfortunately, a small mistake in the tspi_tpm_is_setup() function
prevents the compiler from eliminating references to the TPM driver
code in the bootblock on platforms with CONFIG_VBOOT and
CONFIG_SEPARATE_VERSTAGE. In those cases vboot_logic_executed() is known
at compile-time to be 0, but that still makes the final expression
`return 0 || tpm_is_setup;`. We know that tpm_is_setup can never be set
to 1 in the bootblock, but the compiler doesn't.
This patch rewrites the logic slightly to achieve the same effect in a
way that the compiler can follow (because we only really need to check
tpm_is_setup in the stage that actually runs the vboot code).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Idc25acf1e6c02d929639e83d529cc14af80e0870
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39993
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Switch to using Jasper Lake SoC code from soc/intel/jasperlake and stop
referring from soc/intel/tigerlake.
Addtionally mainboard changes are done to support build.
BUG=b:150217037
TEST=Build and boot waddledoo. Build jasperlake_rvp and volteer board.
Change-Id: I39f117bd66cb610a305bcdb8ea65332fd0ff4814
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39825
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
cmos.default used to be loaded only when cmos is needed to be reset,
but conditional loading of CBFS files may change the calculated PCRs
if measurement is hooked on each loading.
In order to resolve this, loadings should be made less conditional,
(if a file might be used, it should be loaded and measured) but the
use of loaded data remains conditional.
Change-Id: If6ea0d1cbaa7d96f7dea7e77b7548ca2b30efe9e
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39906
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds the path to chrome EC headers to the depthcharge
build. Depthcharge currently includes a manually maintained copy of
the EC headers which are perpetually out of sync with the real
interface definitions. By adding the include path, we can build
depthcharge with the actual EC interface definitions and eliminate the
manual maintenance of copies of EC headers. Once the include path is
in place, we can remove the copies of the EC headers from depthcharge.
BUG=b:152373049
Change-Id: I1ce0ad9dc99ea52f177d4fb034fd23efd95a7864
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39947
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
I will pass my responsibilities to Christian Walter.
I have hardly any time left for the coreboot project.
Change-Id: Ia60e71c5cbd361486dbc924ad954db203e285a5a
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39897
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Update FSPM header to include DisableDimmCh Upds for Tiger Lake
platform version 2457.
BUG=b:152000235
BRANCH=none
TEST="Build and Boot on Ripto/Volteer"
Change-Id: Ic743cb2134e6273a63c1212506c81ccbbdec442a
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39797
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Certain PCIe endpoints cause an exception inside AmdInitMid when PCIe
ClockPM is enabled in AGESA PCIe initialization structures. Disable it
to allow platform to boot with such devices. coreboot driver enables
the ClockPM correctly on such devices anyway.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I7fb13f915861c26cf773960abb12a3a1c0211cdc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39970
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Include types.h in src/soc/intel/common/block/include/intelblocks/cse.h
to use type bool.
Without this, there can be a build error like below,
src/soc/intel/common/block/include/intelblocks/cse.h:208:1:
error: unknown type name 'bool'; did you mean '_Bool'?
bool cse_is_hfs1_com_soft_temp_disable(void);
^~~~
_Bool
src/soc/intel/common/block/include/intelblocks/cse.h:214:1:
error: unknown type name 'bool'; did you mean '_Bool'?
bool cse_is_hfs3_fw_sku_custom(void);
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Change-Id: I92ee533bca7dc255f7a341b2a68bbc09900996a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change Graphics Init default for RUN_FSP_GOP to depend on
INTEL_GMA_HAVE_VBT rather than INTEL_GMA_ADD_VBT, since
RUN_FSP_GOP selects INTEL_GMA_ADD_VBT for several Intel SoC's.
Test: create default config for gogle/cyan, RUN_FSP_GOP
still default display init selection but no more circular
dependency warning from config.
Change-Id: I8b978d9938c3d0024d4dd40000b988430664cee7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Including gma.asl at the platform level (vs the board level)
means that even desktop boards need to include the default
brightness levels, which makes no sense. To begin to clean this up,
include gma.asl in default_brightness_levels.asl (as well as
the handful of board-specific brightness files) and remove it
from the various platforms.
A follow-on commit will remove default_brightness_levels.asl
from all boards which lack an internal display.
Change-Id: I8063deeef4ab6d6ab34ed9b0be5b1d541d6e9b6b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39878
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allow Chrome OS to be enabled for this QEMU target. By default
this does not change anything unless it is selected in the build
configuration, but it makes it possible.
Native VGA init is not forced when Chrome OS is enabled because the
drm-bochs driver does not work with chrome (even the latest upstream
kernel driver with drm atomic support) but it does work with virtio.
The coreboot graphics init needs to match what is selected with qemu
(with -vga std or -vga virtio) which in turn will determine which
kernel driver is used.
A second FMAP is added with both RW-A and RW-B regions which is
required by chromeos.
Recovery mode can be entered by supplying a custom fw_cfg option
when launching qemu: -fw_cfg name=opt/cros/recovery,string=1
Change-Id: I24b4532ea961e68558663292c99d121f0a30ce3b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39837
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This enables the mainboard to use a TPM if it is selected in the
configuration. By default this does nothing, but it allows the
TPM to be enabled and used with the CONFIG_USER_TPM2 Kconfig option.
Using a TPM with QEMU requires either a physical TPM backend or
the swtpm package with a socket:
-chardev socket,id=swtpm,path=/tmp/swtpm/socket
-tpmdev emulator,id=tpm0,chardev=swtpm
-device tpm-tis,tpmdev=tpm0
Change-Id: I0d79a5a0f590c57998ababb660b52d9e3ed2d484
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
QEMU does not have a separate northbridge chip, so the mainboard
needs to handle the ACPI name and paths so that devices can get
generated into the SSDT properly. This fixes the PIRQ and TPM
table generation.
This issue can be seen in the coreboot output:
ACPI_PIRQ_GEN: Missing LPCB ACPI path
Change-Id: Ifc7d4359eea38ac0b55d655e39191ae7f8655fe4
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Ensure that the low memory is properly reserved so it does not get
marked as normal RAM and get wiped or reused by firmware or the kernel.
This ensures that the low RSDP is always available for the kernel.
This is only noticed if something wipes the RSDP before the kernel
boots, which happens if you use the depthcharge payload and boot in
developer mode.
Change-Id: I7295018416229bc957ecbf26f77623a57965557e
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When the TPM is enabled in QEMU the fw_cfg interface will return
~200KiB of ACPI tables, so this needs to be increased from the default
in order to be able to boot.
This is seen when using a TPM with qemu as it will hang when
processing the fw_cfg tables.
qemu-system-x86_64 \
-machine q35 -enable-kvm -vga virtio -serial stdio \
-drive 'id=hd,file=disk.bin' -bios coreboot.rom \
-chardev 'socket,id=swtpm,path=/tmp/swtpm/swtpm-sock' \
-tpmdev 'emulator,id=tpm0,chardev=swtpm' \
-device 'tpm-tis,tpmdev=tpm0'
Change-Id: I21980aace8e86e636f5ae7b55148f4c31404edba
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The maximum ACPI table size is currently hardcoded to 144 KiB.
When using QEMU with TPM enabled there is ~200 KiB of ACPI tables
returned by the fw_cfg interface, so in order to allow this to be
overridden by a mainboard move it to Kconfig.
This is seen when using a TPM with qemu as it will hang when
processing the fw_cfg tables.
qemu-system-x86_64 \
-machine q35 -enable-kvm -vga virtio -serial stdio \
-drive 'id=hd,file=disk.bin' -bios coreboot.rom \
-chardev 'socket,id=swtpm,path=/tmp/swtpm/swtpm-sock' \
-tpmdev 'emulator,id=tpm0,chardev=swtpm' \
-device 'tpm-tis,tpmdev=tpm0'
Change-Id: Ib5baa8fe12cb9027a340875f1ccf5fef6f9460bd
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39832
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
After measured boot is decoupled from verified boot in CB:35077,
vboot_platform_is_resuming() is never vboot-specific, thus it is
renamed to platform_is_resuming() and declared in bootmode.h.
Change-Id: I29b5b88af0576c34c10cfbd99659a5cdc0c75842
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
mrc.bin, on platforms where it is present, is code executed on CPU, so
it should be considered a part of CRTM.
cbfs_locate_file_in_region() is hooked to measurement here too, since
mrc.bin is loaded with it, and CBFS_TYPE_MRC (the type of mrc.bin) is
measured to TPM_CRTM_PCR rather than TPM_RUNTIME_DATA_PCR.
TODO: I have heard that SMM is too resource-limited to link with vboot
library, so currently tspi_measure_cbfs_hook() is masked in SMM.
Please correct me if I am wrong.
Change-Id: Ib4c3cf47b919864056baf725001ca8a4aaafa110
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Since the variants' devicetrees are almost identical, convert to
using an overridetree setup for simplicity.
Test: build all slippy variants, compare generated static.c to ensure
resulting generated contents unchanged (although layout will)
Change-Id: If237fad38a1bccfb8e51edfae3ecb75d05ade240
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Clean up Link's mainboard dir by putting the SPD files in
a spd subdirectory like all other/newer boards use, and
selecting GENERIC_SPD_BIN to include them in the build.
Test: build google/link and verify spd.bin unchanged
Change-Id: I9c2f9f77dbdd6552c5ae1e7a0df2051b9b85badc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Link's DID data makes no sense, and ACPI backlight controls don't work
as a result. Replace them with the default profile used by most/all
other boards.
Test: build/boot google/link, verify ACPI backlight controls functional
Change-Id: Ia7cb3f10bd3c05ebaf414c17a8f94d2e9b40ae26
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39908
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Update the Lenovo Ivy Bridge documentation that no issues could be
observed on W530.
Tested on Lenovo W530 with stripped ME and found no issues:
commit 93b0c7cfc6
* USB
* Bluetooth
* Wifi
* Wifi-kill switch
* libgfxinit
* SATA
* mSATA
* Audio
* SD-card
* Ethernet
* Keyboard
* Fn-Keys
* Display brightness
* ACPI S3 resume
* CPU temperature reporting
* Stress test stable (intel_pstate no_turbo due to W530 overheating bug)
* Youtube videos
* stress -c 8 -m 1 -t 3600
Change-Id: I46d23d41cc6ade5e641a6ddb3f357a6036002edc
Signed-off-by: Marcello Sylvester Bauer <sylv@sylv.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39603
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Matt DeVillier