A mainboard might want to configure some things differently when a
device is in an unprovisioned state. In the case when fw_config comes
from the Chromium EC, an unprovisioned device will not have a FW_CONFIG
tag in its CBI. This patch will set the fw_config value to
UNDEFINED_FW_CONFIG in the case of an error retrieving the value, as
well as adding a function, `fw_config_is_provisioned()` to indicate the
provisioning status.
BUG=none
TEST=remove fw_config from chromium EC CBI, add code to mainboard to
print return value of fw_config_is_provisioned() (`0`), add
fw_config back to CBI, run same test and see `1`.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ib3046233667e97a5f78961fabacbeb3099b3d442
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47956
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently it's not possible to add multiple graphics driver into
one coreboot image. This patch series will fix this issue by providing
a single API that multiple graphics driver can use.
This is required for platforms that have two graphic cards, but
different graphic drivers, like Intel and Aspeed on server platforms or
Intel and Nvidia on consumer notebooks.
The goals are to remove duplicated fill_fb_framebuffer(), to advertise
multiple independent framebuffers in coreboot tables, and better
runtime/build time graphic configuration options.
Add an implementation in edid_fill_fb that supports registering
multiple framebuffers, each with its own configuration.
As the current code is only compiled for a single graphics driver
there's no change in functionality.
Change-Id: I7264c2ea2f72f36adfd26f26b00e3ce172133621
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39002
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This change adds details about the memory map windows to translate
addresses between SPI flash space and host address space to coreboot
tables. This is useful for payloads to setup the translation using the
decode windows already known to coreboot. Until now, there was a
single decode window at the top of 4G used by all x86
platforms. However, going forward, platforms might support more decode
windows and hence in order to avoid duplication in payloads this
information is filled in coreboot tables.
`lb_spi_flash()` is updated to fill in the details about these windows
by making a call to `spi_flash_get_mmap_windows()` which is
implemented by the driver providing the boot media mapping device.
BUG=b:171534504
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I00ae33d9b53fecd0a8eadd22531fdff8bde9ee94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48185
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbmem_online() always returns 1 in stages after romstage. However, CBMEM
isn't actually immediately available in those stages -- instead, it will
only become available when cbmem_initialize() is called. That usually
happens very early in the stage, but there are still small amounts of
code running beforehand, so it is useful to reflect this distinction.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I623c0606a4f49ea98c4c7559436bf32ebb83b456
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since config_of() calls die() if dev or dev->chip_info are NULL,
config_of_soc() will either return a non-NULL pointer or won't return.
Change-Id: I6de6bb1610e823af215436c94ff1a78ff6b86b78
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48359
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
This patch adds the first stage of the new CONFIG_CBFS_VERIFICATION
feature. It's not useful to end-users in this stage so it cannot be
selected in menuconfig (and should not be used other than for
development) yet. With this patch coreboot can verify the metadata hash
of the RO CBFS when it starts booting, but it does not verify individual
files yet. Likewise, verifying RW CBFSes with vboot is not yet
supported.
Verification is bootstrapped from a "metadata hash anchor" structure
that is embedded in the bootblock code and marked by a unique magic
number. This anchor contains both the CBFS metadata hash and a separate
hash for the FMAP which is required to find the primary CBFS. Both are
verified on first use in the bootblock (and halt the system on failure).
The CONFIG_TOCTOU_SAFETY option is also added for illustrative purposes
to show some paths that need to be different when full protection
against TOCTOU (time-of-check vs. time-of-use) attacks is desired. For
normal verification it is sufficient to check the FMAP and the CBFS
metadata hash only once in the bootblock -- for TOCTOU verification we
do the same, but we need to be extra careful that we do not re-read the
FMAP or any CBFS metadata in later stages. This is mostly achieved by
depending on the CBFS metadata cache and FMAP cache features, but we
allow for one edge case in case the RW CBFS metadata cache overflows
(which may happen during an RW update and could otherwise no longer be
fixed because mcache size is defined by RO code). This code is added to
demonstrate design intent but won't really matter until RW CBFS
verification can be supported.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I8930434de55eb938b042fdada9aa90218c0b5a34
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41120
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch introduces two new CBFS API functions which are equivalent to
cbfs_map() and cbfs_load(), respectively, with the difference that they
always operate on the read-only CBFS region ("COREBOOT" FMAP section).
Use it to replace some of the simple cases that needed to use
cbfs_locate_file_in_region().
Change-Id: I9c55b022b6502a333a9805ab0e4891dd7b97ef7f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39306
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Looks like the option is generally not compatible with
garbage collections.
Nothing gets inlined, for example is_smp_boot() no longer
evaluates to constant false and thus the symbols from
secondary.S would need to be present for the build to pass
even if we set SMP=n.
Also the addresses of relocatable ramstage are currently
not normalised on the logs, so util/genprof would be unable
dress those.
Change-Id: I0b6f310e15e6f4992cd054d288903fea8390e5cf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfs_boot_locate() is supposed to be deprecated eventually, after slowly
migrating all APIs to bypass it. That means common features (like
RO-fallback or measurement) need to be moved to the new
cbfs_boot_lookup().
Also export the function externally. Since it is a low-level API and
most code should use the higher-level loading or mapping functions
instead, put it into a new <cbfs_private.h> to raise the mental barrier
for using this API (this will make more sense once cbfs_boot_locate() is
removed from <cbfs.h>).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4bc9b7cbc42a4211d806a3e3389abab7f589a25a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tiger Lake introduces new wake-capable devices, including thunderbolt
ports, TCSS XHCI & XDCI as well as DMA ports. Add new ELOG_WAKE_SOURCE
macros for each of these types of devices.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ie5dae6514c2776b30418a390c4da53bda0b2d456
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Add weak function for SMBIOS type 16 error correction type.
Tested=Execute "dmidecode -t 16" to check if error correction type
is correct.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I85b37e9cfd22a78544d03e5506ff92b1f2404f8e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47508
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only two definitions are actually used somewhere, the rest is unused.
Change-Id: Iec52d0d47fce6a1ec5455b670824b995a7a34a4c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47407
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the NHLT specification[1], PDM_DEV is defined as "1" on
Kabylake based platforms. coreboot currently sets it to "0" on
all platforms. Add an entry to the enum and use it to define
NHLT_PDM_DEV for Kabylake.
"Device Type" will resume from "2" on all platforms, but entries are
currently reserved.
Tested on an Acer Aspire VN7-572G (Skylake-U), which has a 1ch array
DMIC, on Windows 10.
1. https://01.org/sites/default/files/595976_intel_sst_nhlt.pdf
Change-Id: Ifbc67228c9e7af7db5154d597ca8d67860cfd2ed
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45010
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a weak function to let the platform code provide the processor
voltage in 100mV units.
Implement the function on Intel platforms using the MSR_PERF_STATUS msr.
On other platforms the processor voltage still reads as unknown.
Tested on Intel CFL. The CPU voltage is correctly advertised.
Change-Id: I31a7efcbeede50d986a1c096a4a59a316e09f825
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch adds a new CBFS "mcache" (metadata cache) -- a memory buffer
that stores the headers of all CBFS files. Similar to the existing FMAP
cache, this cache should reduce the amount of SPI accesses we need to do
every boot: rather than having to re-read all CBFS headers from SPI
flash every time we're looking for a file, we can just walk the same
list in this in-memory copy and finally use it to directly access the
flash at the right position for the file data.
This patch adds the code to support the cache but doesn't enable it on
any platform. The next one will turn it on by default.
Change-Id: I5b1084bfdad1c6ab0ee1b143ed8dd796827f4c65
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It was supposed to return true for both S2 and S3, but
level S2 was never stored in acpi_slp_type or otherwise
implemented.
Change-Id: Ida0165e647545069c0d42d38b9f45a95e78dacbe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Different models within family 17h have different PCI IDs for their PCIe
GPP port and internal bus devices.
Change-Id: I386df908ce5451b4484be2a2e4a9018c3d47d030
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Different models within family 17h have different PCI IDs for their data
fabric PCI devices.
Change-Id: I44f8d32c950710e962dc519495b08c92f357ed20
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The code that uses the GPU device ID uses the correct ATI vendor ID, but
the description wrongly used AMD as vendor. In the AMD APUs the GPU PCI
device and the corresponding audio controller use the ATI PCI vendor ID
while all other PCI devices in the SoC use the AMD PCI vendor ID.
Also move the two entries in a separate section right below the one they
were in.
Change-Id: Ia0b5bd4638f5b07c487f223321872563b36337e9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47674
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This is a trivial patch to fix some comments that were generating
notes in the kconfig lint test.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I26a95f17e82910f50c62215be5c29780fe98e29a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47366
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes all of the current code in coreboot/src where a bare
unsigned is used incorrectly. A follow-on will fix the comments
so that we can enable the unsigned lint checker for src/coreboot.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I37f34a95bb1894e70cd9e076d4b81ebac665eaeb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47482
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
List of changes:
1. Add new PCH ID 0x5181 into device/pci_ids.h
2. Update new PCH ID into common lpc.c
3. Add new PCH ID description into report_platform.c
TEST=Able to build and boot ADLRVP with new PCH ID.
Change-Id: I4343b7343876eb40c2955f6f4dd99d6446852dc0
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47474
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It is too easy to confuse those with IA32_SMRR_PHYS_x registers.
Change-Id: Ice02ab6c0315a2be14ef110ede506262e3c0a4d5
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46896
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This prototype will be used outside of soc/amd.
Change-Id: Icc69cf8a910764b27edf64f0f527b8f6a9013121
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45813
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently coreboot has limited use for the SMM save state. Typically
the only thing needed is to get or set a few registers and to know
which CPU triggered the SMI (typically via an IO write). Abstracting
away different SMM save states would allow to put some SMM
functionality like the SMMSTORE entry in common places.
To save place platforms can select different SMM save sate ops that
should be implemented. For instance AMD platforms don't need Intel SMM
save state handling.
Some platforms can encounter CPUs with different save states, which
the code then handles at runtime by comparing the SMM save state
revision which is located at the same offset for all SMM save state
types.
Change-Id: I4a31d05c09065543424a9010ac434dde0dfb5836
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44323
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a new CONFIG_OVERRIDE_UART_FOR_CONSOLE token to override the index
of uart port, platform use a get_uart_for_console routine to decide what
index value should be used for console.
Signed-off-by: Bryant Ou <Bryant.Ou.Q@gmail.com>
Change-Id: I2079bd1e5ffa209553383b6aafe3b8724849ba2a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Move this function to pci_ops.c, which is already included in the smm
build. This is required to use this function in elog functionality,
which is called from SMM.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ie5583c04366c9a16bc1b00a6892d39eeafe5da49
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47260
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
acpigen_write_debug_namestr() - Debug = NAME
acpigen_write_return_namestr() - Return (NAME)
acpigen_set_package_op_element_int() - Set package pointer element
DeRefOf (PKG[ELEM]) = INT
acpigen_get_package_element() - Get package (not pointer) element
dest_op = PKG[ELEM]
acpigen_set_package_element_int() - Set package element to integer
PKG[ELEM] = INT
acpigen_set_package_element_namestr() - Set package element to namestr
PKG[ELEM] = NAME
acpigen_write_delay_until_namestr_int() - Delay while waiting for
register to equal expected value.
BUG=b:160996445
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I9b20a23872b7d4a50f03761032426ffbb722b9ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47196
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When getting the address of a structure's member that is not on
offset 0, GCC9+ assumes that the address can never be NULL. However
the code relied on the fact that it can be NULL by letting the pointer
intentionally overflow.
Manually calculate the address using uintptr_t. This allows to
gracefully terminate the list_for_each MACRO instead of crashing at the
end of the list.
Tested on qemu-system-arm:
coreboot no longer crashed in the devicetree parser and is able to boot
Linux 5.5.
Change-Id: I0d569b59a23d1269f8575fcbbe92a5a6816aa1f7
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
As an intermediate step for CB:45150, add an additional Kconfig option
which is used to configure bus mastering for any devices and use
PCI_ALLOW_BUS_MASTER to allow coreboot setting the bus mastering bit in
general.
Change-Id: I33b37a79022007a16e97350db61575b63fa8256b
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45149
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change drops the PCI IDs for Jefferson Peak and Harrison Peak
CNVi modules from wifi/generic drivers as well as pci_ids.h. These IDs
actually represent the CNVi WiFi controller PCI IDs and are now
supported by intel/common/block/cnvi driver.
The only ID that is being dropped without adding support in
intel/common/block/cnvi driver is
PCI_DEVICE_ID_HrP_6SERIES_WIFI(0x2720) since this was not found in the
list of PCI IDs for any SoC.
Change-Id: I82857a737b65a6baa94fb3c2588fe723412a7830
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46866
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clarify what the function does by renaming it from do_lapic_init() to
lapic_virtual_wire_mode_init().
Change-Id: Ie4430bf0f6c6bf0081b6aaeace351092bcf7f4ac
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The "Nominal Performance" is not the same as the "Guaranteed
Performance", but is defined as the performance a processor can deliver
continously under ideal environmental conditions.
According to edk2, this is the "Maximum Non-Turbo Ratio", which needs to
be read from MSR_PLATFORM_INFO instead of IA32_HWP_CAPABILITIES.
Correct the entry in the CPPC package.
Test: dumped SSDT from Supermicro X11SSM-F and checked decompiled
version
Change-Id: Ic2c27fd3e14af18aa4101c0acd7a5ede15d1f3a9
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46464
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are currently 3 different strapping ID entries in the coreboot
table, which adds overhead. The new fw_config field is also desired in
the coreboot table, which is another kind of strapping id. Therefore,
this patch deprecates the 3 current strapping ID entries (board ID, RAM
code, and SKU ID), and adds a new entry ("board_config") which provides
board ID, RAM code, SKU ID, as well as FW_CONFIG together.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I1ecec847ee77b72233587c1ad7f124e2027470bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Further patches will make use of this raw 64-bit value.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I161893c09da6a44265299f6ae3c3a81249a96084
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46604
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
