is_devfn_enabled() function helps to check if a device
is enabled based on given device function number. This
function internally called is_dev_enabled() to check
device state.
Change-Id: I6aeba0da05b13b70155a991f69a6abf7eb48a78c
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55278
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Allows compile-time optimisation on platforms that do not wish
to enable runtime checking of X2APIC.
Legacy lapic_cpu_init() is incompatible so there is dependency
on PARALLEL_MP. Also stop_this_cpu() is incompatible, so there
is dependency on !AP_IN_SIPI_WAIT.
Since the code actually lacks enablement of X2APIC (apparently
assuming the blob has done it) and the other small flaws pointed
out in earlier reviews, X2APIC_RUNTIME is not selected per
default on any platform yet.
Change-Id: I8269f9639ee3e89a2c2b4178d266ba2dac46db3f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
acpi_soc_get_bert_region only gets called when a chipset's Kconfig
selects the ACPI_BERT option in which case the chipset code needs to
implement this function. In the case of acpi_soc_get_bert_region not
being implemented, but ACPI_BERT being selected for a chipset this patch
changes the behavior from never generating a BERT ACPI table to a build
error which is more obvious and easier to catch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id479fce823d8534a7790f39125d1a2b3635fc029
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55277
Reviewed-by: Lance Zhao
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Check if the ACPI_BERT Kconfig option is selected and only then try to
generate the BERT table. Also remove the acpi_is_boot_error_src_present
weak function from the ACPI global compilation unit and use the return
value of acpi_soc_get_bert_region to determine if there is a valid BERT
region with logged errors.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2a281f5f636010ba3b2e7e097e9cf53683022aea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The return value indicates if the function has found valid BERT data and
wrote them to the region and length parameters. This will be used in a
follow-up patch to remove the acpi_is_boot_error_src_present function
call in the common code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaaa3eed51645e1b3bc904c6279d171e3a10d59be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55053
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lance Zhao
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
acpi_device_add_power_res currently generates a `_STA` method hardcoded
to ON. This change enables the ability to generate a `_STA` method that
queries the status of the GPIOs to determine if the power resource is ON
or OFF.
BUG=b:184617186
TEST=Dump SSDT table for guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I91410556db002c620fd9aaa99981457808da93a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55027
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add a function to check sanity of a given RTC date and time.
Invalid values in terms of overrun ranges of the registers can lead to
strange issues in the OS.
Change-Id: I0a381d445c894eee4f82b50fe86dad22cc587605
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54913
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
In order to add more option backends, transform the current CMOS option
backend into a Kconfig choice. Replace the `select` directives, as they
cannot be used with choice options.
Change-Id: Id3180e9991f0e763b4bae93a92d40668e7fc99bc
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54728
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Intel CBnT (and Boot Guard) makes the chain of trust TOCTOU safe by
setting up NEM (non eviction mode) in the ACM. The CBnT IBB (Initial
BootBlock) therefore should not disable caching.
Sidenote: the MSR macros are taken from the slimbootloader project.
TESTED: ocp/Deltalake boot with and without CBnT and also a broken
CBnT setup.
Change-Id: Id2031e4e406655e14198e45f137ba152f8b6f567
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Over the last couple of years we have continuously added more and more
CBMEM init hooks related to different independent components. One
disadvantage of the API is that it can not model any dependencies
between the different hooks, and their order is essentially undefined
(based on link order). For most hooks this is not a problem, and in fact
it's probably not a bad thing to discourage implicit dependencies
between unrelated components like this... but one resource the
components obviously all share is CBMEM, and since many CBMEM init hooks
are used to create new CBMEM areas, the arbitrary order means that the
order of these areas becomes unpredictable.
Generally code using CBMEM should not care where exactly an area is
allocated, but one exception is the persistent CBMEM console which
relies (on a best effort basis) on always getting allocated at the same
address on every boot. This is, technically, a hack, but it's a pretty
harmless hack that has served us reasonably well so far and would be
difficult to realize in a more robust way (without adding a lot of new
infrastructure). Most of the time, coreboot will allocate the same CBMEM
areas in the same order with the same sizes on every boot, and this all
kinda works out (and since it's only a debug console, we don't need to
be afraid of the odd one-in-a-million edge case breaking it).
But one reproducible difference we can have between boots is the vboot
boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten
lucky in the past that we didn't have differences in CBMEM allocations
in different boot modes. With the recent addition of the RW_MCACHE
(which does not get allocated in recovery mode), this is no longer true,
and as a result CBMEM consoles can no longer persist between normal and
recovery modes.
The somewhat kludgy but simple solution is to just create a new class of
specifically "early" CBMEM init hooks that will always run before all
the others. While arbitrarily partitioning hooks into "early" and "not
early" without any precise definition of what these things mean may seem
a bit haphazard, I think it will be good enough in practice for the very
few cases where this matters and beats building anything much more
complicated (FWIW Linux has been doing something similar for years with
device suspend/resume ordering). Since the current use case only relates
to CBMEM allocation ordering and you can only really be "first" if you
allocate in romstage, the "early" hook is only available in romstage for
now (could be expanded later if we find a use case for it).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
hexdump and hexdump32 do similar things, but hexdump32 is mostly a
reimplementation that has additional support to configure the console
log level, but has a very unexpected len parameter that isn't in bytes,
but in DWORDs.
With the move to hexdump() the console log level for the hexdump is
changed to BIOS_DEBUG.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6138d17f0ce8e4a14f22d132bf5c64d0c343b80d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54925
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Generic Initiator Affinity structure is introdcued in ACPI spec 6.3.
This structure is used to define NUMA affinity domain which is
established by generic initiator (such as by CXL device).
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: Ic6ef01c59e02f30dc290f27e741027e16f5d8359
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao
Update SA & IGD DIDs table as per latest EDS (Doc no: 601458).
Add extra SKUs and fix the mismatched SKU numbers accordingly.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: I62fd9e6a7cf0fc6f541f3d6d9edd31d41db7279f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Prepare to allow using other backends to store options.
Change-Id: I3f838d27bf476207c6dc8f2c1f15c3fa9ae47d87
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54727
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Commit 88dcb3179b (src: Retype option API to use unsigned integers)
changed the option API to use unsigned integers, but missed this.
Change-Id: I5deb17157db41c40cc72078e2af9cf65bdbe0581
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54726
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
With the introduction of fw_config support in coreboot, it is possible
for mainboards to control the state of a device (on/off) in ramstage
using fw_config probe conditions. However, the device tree in
immutable in all other stages and hence `is_dev_enabled()` does not
really reflect the true state as in ramstage.
This change adds a call to `fw_config_probe_dev()` in
`is_dev_enabled()` when device tree is immutable (by checking
DEVTREE_EARLY) to first check if device is disabled because of device
probe conditions. If so, then it reports device as being
disabled. Else, dev->enabled is used to report the device state.
This allows early stages (bootblock, romstage) to use
`is_dev_enabled()` to get the true state of the device by taking probe
conditions into account and eliminates the need for each caller to
perform their own separate probing.
Change-Id: Ifede6775bda245cba199d3419aebd782dc690f2c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54752
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds a helper function `fw_config_probe_dev()` that allows
the caller to check if any of the probe conditions are true for any
given device. If device has no probe conditions or a matching probe
condition, then it returns true and provides the matching probe
condition back to caller (if provided with a valid pointer). Else, it
returns false. When fw_config support is disabled, this function
always returns true.
Change-Id: Ic2dae338e6fbd7755feb23ca86c50c42103f349b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54751
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updated CPU ID and IGD ID for Alder Lake as per EDS.
TEST=Code compilation works and coreboot is able to boot and identify
new device Ids.
Change-Id: I2759a41a0db1eba5d159edfc89460992914fcc3c
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add initial HMAT (Heterogeneous Memory Attribute Table) support based
on ACPI spec 6.4 section 5.2.27.
Add functions to create HMAT table (revision 2) and create HMAT Memory
Proximity Domain Attribute (MPDA) Structure.
TESTED=Simulated HMAT table creation on OCP DeltaLake server, dumped
the HMAT table and exmained the content. HMAT table and one MPDA
structure are added.
OCP Delatake server is based on Intel CooperLake Scalable Processor
which does not support CXL (Compute Express Link). Therefore solution
level testing is not done.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I5ee60ff990c3cea799c5cbdf7eead818b1bb4f9b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
List of changes:
1. Make the FSP notify phases name prior in comments section.
2. Fix discrepancies in FSP notify before and after postcode comments.
3. Add FSP notify postcode macros for after pci enumeration(0xa2)
and ready to boot(0xa3) call.
Change-Id: Ib4c825d5f1f31f80ad2a03ff5d6006daa7104d23
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52894
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename and update POST_ENTRY_RAMSTAGE postcode value from 0x80 to 0x6f
to make the ramstage postcodes appear in an incremental order.
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: I60f4bd8b2e6b2b887dee7c4991a14ce5d644fdba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52947
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Fix booting issues on google/kahlee introduced by CB:51723.
Update use inital apic id in smm_stub.S to support xapic mode error.
Check more bits(LAPIC_BASE_MSR BIT10 and BIT11) for x2apic mode.
TEST=Boot to OS and check apicid, debug log for CPUIDs
cpuid_ebx(1), cpuid_ext(0xb, 0), cpuid_edx(0xb) etc
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: Ia28f60a077182c3753f6ba9fbdd141f951d39b37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
These global variables are not used anywhere. Drop them.
Change-Id: I3fe60b970153d913ae7b005257e2b53647d6f343
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53977
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
None of the options accessed within coreboot is a string, and there are
no guarantees that the code works as intended with them. Given that the
current option API only supports integers for now, do not try to access
options whose type is 's' (string).
Change-Id: Ib67b126d972c6d55b77ea5ecfb862b4e9c766fe5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52637
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
The CMOS option system does not support negative integers. Thus, retype
and rename the option API functions to reflect this.
Change-Id: Id3480e5cfc0ec90674def7ef0919e0b7ac5b19b3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
With the recent switch to SMM module loader v2, the size of the SMM for
module google/volteer increased to above 64K in size, and thus failed to
install the permanent SMM handler. Turns out, the devicetree is all
pulled into the SMM build because of elog, which calls
`pci_dev_is_wake_source`, and is the only user of `struct device` in
SMM. Changing this function to take a pci_devfn_t instead allows the
linker to remove almost the entire devicetree from SMM (only usage left
is when disabling HECI via SMM).
BUG=b:186661594
TEST=Verify loaded program size of `smm.elf` for google/volteer is
almost ~50% smaller.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I4c39e5188321c8711d6479b15065e5aaedad8f38
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52765
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The boolean is stored in ChromeOS NVS, not GNVS.
Change-Id: I5c424a052d484228a456f8f0ad4fb0bed3165e09
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50877
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The existing helpers for reading/writing MSRs (rdmsr, wrmsr) require use
of the struct `msr_t`, which splits the MSR value into two 32 bit parts.
In many cases, where simple 32 bit or 64 bit values are written, this
bloats the code by unnecessarly having to use that struct.
Thus, introduce the helpers `msr_read` and `msr_write`, which take or
return `uint64_t` values, so the code condenses to a single line or two,
without having to deal with `msr_t`.
Example 1:
~~~
msr_t msr = {
.lo = read32((void *)(uintptr_t)0xfed30880),
.hi = 0,
};
msr.lo |= 1;
wrmsr(0x123, msr);
~~~
becomes
~~~
uint32_t foo = read32((void *)(uintptr_t)0xfed30880);
msr_write(0x123, foo | 1)
~~~
Example 2:
~~~
msr_t msr = rdmsr(0xff);
uint64_t msr_val = (msr.hi << 32) | msr.lo;
~~~
becomes
~~~
uint64_t msr_val = msr_read(0xff);
~~~
Change-Id: I27333a4bdfe3c8cebfe49a16a4f1a066f558c4ce
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52548
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds full EINJ support with trigger action tables. The actual
error injection functionality is HW specific. Therefore, HW specific
code should call acpi_create_einj with an address where action table
resides. The default params of the action table are filled out by the
common code. Control is then returned back to the caller to modify or
override default parameters. If no changes are needed, caller can
simply add the acpi table. At runtime, FW is responsible for filling
out the action table with the proper entries. The action table memory
is shared between FW and OS. This memory should be marked as reserved
in E820 table.
Tested on Deltalake mainboard. Boot to OS, load the EINJ driver (
modprobe EINJ) and verify EINJ memory entries are in /proc/iomem.
Further tested by injecting errors via the APEI file nodes. More
information on error injection can be referenced in the latest ACPI
spec.
Change-Id: I29c6a861c564ec104f2c097f3e49b3e6d38b040e
Signed-off-by: Rocky Phagura <rphagura@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49286
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Rocky Phagura
Intel document 335192-004 contains the PCI device IDs for Z370 and
H310C, but lacks the ID for B365. The ID appears on some websites:
https://linux-hardware.org/index.php?id=pci:8086-a2cc-1849-a2cc
Change-Id: Iea3c435713c46854c5271fbc266f47ba4573db52
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52703
Reviewed-by: Timofey Komarov <happycorsair@yandex.ru>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The code name for these PCHs is Union Point, abbreviated as `UPT`. There
are some 300-series Union Point PCHs (H310C, B365, Z370) which are meant
to be paired with Coffee Lake CPUs instead of Skylake or Kaby Lake CPUs,
and referring to them as `KBP` (Kaby Point, I guess) would be confusing.
Tested with BUILD_TIMELESS=1, HP 280 G2 remains identical.
Change-Id: I1a49115ae7ac37e76ce8d440910fb59926f34fac
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52700
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Timofey Komarov <happycorsair@yandex.ru>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The slot ID can be passed in from the function caller but
parsing slot ID from devicetree is not yet supported and
would still be 0.
Add Slot ID in SMBIOS type 9 for Delta Lake.
Tested=Execute "dmidecode -t 9" to verify.
Signed-off-by: JingleHsuWiwynn <jingle_hsu@wiwynn.com>
Change-Id: I9bf2e3b1232637a25ee595d08f8fbbc2283fcd5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49917
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change adds the ATC_REQUIRED flag for the address translation cache
indicator and fixes the devices scope entry in the SATC reporting
structure. The SoC integrated devices in the specified PCI segment
with address translation caches are a type of PCI Endpoint Device.
BUG=None
TEST=Built image successfully.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I57b3551f11502da48f3951da59d9426df5a40723
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao
Reviewed-by: Nico Huber <nico.h@gmx.de>
Low Power Idle States defines additional information not present in the
_CST.
See ACPI Specification, Version 6.3 Section 8.4.4.3 _LPI.
BUG=b:178728116, b:185787242
TEST=Boot guybrush and dump ACPI tables
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Signed-off-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Change-Id: I4f5301b95ff8245facaf48e2fbd51cc82df2d8cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52529
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
See ACPI Specification, Version 6.3, Section 6.2.11 _OSC (Operating
System Capabilities)
We can add more UUIDs and capability flags in the future.
BUG=b:178728116
TEST=Builds
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I6e2ac1e1b47b284489932d6ed12db9d94e8d7310
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The {get,set}_option() functions are not type-safe: they take a pointer
to void, without an associated length/size. Moreover, cmos_get_option()
does not always fully initialise the destination value (it has no means
to know how large it is), which can cause issues if the caller does not
initialise the value beforehand.
The idea behind this patch series is to replace the current type-unsafe
API with a type-safe equivalent, and ultimately decouple the option API
from CMOS. This would allow using different storage mechanisms with the
same option system, maximising flexibility.
Most, if not all users of get_option() have a value to fall back to, in
case the option could not be read. Thus, get_int_option() takes a value
to fall back to, which avoids repeating the same logic on call-sites.
These new functions will be put to use in subsequent commits.
Change-Id: I6bbc51135216f34518cfd05c3dc90fb68404c1cc
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
We had the addrspace_32bit rdev in prog_loaders.c for a while to help
represent memory ranges as an rdev, and we've found it useful for a
couple of things that have nothing to do with program loading. This
patch moves the concept straight into commonlib/region.c so it is no
longer anchored in such a weird place, and easier to use in unit tests.
Also expand the concept to the whole address space (there's no real need
to restrict it to 32 bits in 64-bit environments) and introduce an
rdev_chain_mem() helper function to make it a bit easier to use. Replace
some direct uses of struct mem_region_device with this new API where it
seems to make sense.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ie4c763b77f77d227768556a9528681d771a08dca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use the same stack location during relocation as for the permanent
handler.
When the number of CPUs is too large the stacks during relocation
don't fit inside the default SMRAM segment at 0x30000. Currently the
code would just let the CPU stack base grow downwards outside of the
default SMM segment which would corrupt lower memory if S3 is
implemented.
Also update the comment on smm_module_setup_stub().
Change-Id: I6a0a890e8b1c2408301564c22772032cfee4d296
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
