After final production, it's possible by setting particular
bit using DCFG the OEM/ODM locks down thermal tuning beyond
what is usually done on the given platform.
In that case user space calibration tools should not try
to adjust the thermal configuration of the system.
By adding new DCFG (Device Configuration) it allows the
OEM/ODM to control this thermal tuning mechanism. They can
configure it by adding dcfg config under overridetree.cb file.
The default value for all bits is 0 to ensure default behavior
and backwards compatibility.
For an example if Bit 0 being set represents Generic DTT UI
access control is disabled and Bit 2 being set represents DTT
shell access control is disabled.
Each bit represents different configuration access control
for DTT as per BIOS specification document #640237.
It also gives the provision for user space to check the current
mode. This mode value is based on BIOS specification document
number #640237.
BUG=b:272382080
TEST=Build, boot on rex board and dump SSDT to check DCFG value.
Also, verified the newly added sysfs attribute "production_mode"
present under /sys/bus/platform/devices/INTC1042:00 path.
Change-Id: I507c4d6eee565d39b2f42950d888d110ab94de64
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78386
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch creates a new tivviks variant, which is a Twinlake
platform. This variant uses Nivviks board mounted with the
Twinlake SOC and hence the plan is to reuse the existing
nivviks code.
BUG=b:327550938
TEST= Genearte the Tivviks firmware builds and verify with boot check.
Change-Id: Ia833a1dad45e13cd271506ade364b116c5880982
Signed-off-by: Sowmya V <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81262
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Set FW_CONFIG bit 21 to enable ISH PCI device and define ISH main
firmware name so ISH shim loader can load firmware from file system.
ISH also need to be enabled if STORAGE_UFS is set.
BUG=b:280329972
TEST= Set bit CBI FW_CONFIG bit 21
Boot Brox board, check that ISH is enabled and loaded
lspci shows: 00:12.0 Serial controller: Intel Corporation Alder
Lake-P Integrated Sensor Hub (rev 01).
Change-Id: Iadc5108c62737d27642a6948c00b5c122541aaba
Signed-off-by: Li Feng <li1.feng@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80773
Reviewed-by: Tanu Malhotra <tanu.malhotra@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Yuval Peress <peress@google.com>
Add IFTYPE_UNUSED as first element to the mpio_type enum. This allows
checking if the type was set in the devicetree, since the default will
now be IFTYPE_UNUSED. If the type is set to IFTYPE_UNUSED although the
corresponding PCI device function, a warning is printed and the PCI
device function is disabled.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I85e2589c021b4f05662369fd551146b6f2fa0ad4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This data is used by smm_region_overlaps_handler(). Callers use this
helper to determine if it's safe to read/write to memory buffers taken
from untrusted input.
coreboot SMI handlers must not be confused into writing over any SMRAM
subregion, which includes the TSEG_STAGE_CACHE and chipset-specific area
(sometimes, IED), not just the handlers.
If stage cache writes were permitted, this could compromise the
integrity of the S3 resume path.
The consequences to overwriting the chipset-specific area are undefined.
Change-Id: Ibd9ed34fcfd77a4236b5cf122747a6718ce9c91f
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80703
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Select USE_UNIFIED_AP_FIRMWARE_FOR_UFS_AND_NON_UFS in brox Kconfig.
This enables a single binary for both SKU1 and SKU2. For SKU2, upon
boot from cold reset, it will disable the UFS Controller and then
trigger a warm boot.
BUG=b:329209576
BRANCH=None
TEST=Boot image on SKU1/SKU2 and check S0ix working.
Change-Id: Iabd0b3a83aa386e09310b671632368807a4018d4
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Shelley Chen <shchen@google.com>
Adjust touchscreen power sequencing for eKTH5015M.
The INX touch panel (eKTH5015M) contains a pull-up register which causes TCHSCR_REPORT_EN pull-up abnormally from Z1 power on.Because the t25 must be at least greater than 20ms, TCHSCR_REPORT_EN is initialized to GPO_L in the early stage (romstage) to meet the spec.
BUG=b:328170008
BRANCH=firmware-nissa-15217.B
TEST=Build and check I2C devices timing meet spec.
[INFO ] input: Elan Touchscreen as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-10/i2c-ELAN0001:00/input/in4
Change-Id: I50f9c21ddee2bc9c1d313f63049cb587b4ae047a
Signed-off-by: Frank Chu <frank_chu@pegatron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81135
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Improves user experience by highlighting a possibility of runtime
hangs caused by unsupported WB caching during NEM.
Recently we have encountered an issue on Intel platform and came to
know about the NEM logical limitation where due to cache sets are not
in power_on_two running into a runtime hang upon enabling WB caching.
BUG=b:306677879
BRANCH=firmware-rex-15709.B
TEST=Verified boot on google/ovis and google/rex (including Ovis with
non-power-of-two cache configuration).
Change-Id: Ic4fbef1fcc018856420428139683897634c9f85d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81336
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
There are 2 ways of referring to linker symbols, as extern
u8[] or extern u8*. Only the former will be correctly
initiated into an immediate operand (a constant) to asm.
DECLARE_REGION defines reference in form of extern u8[].
Use DECLARE_REGION as a standard way for these references.
TEST=intel/archercity CRB
Change-Id: I5f7d7855592d99b074f7ef49c285a13f8105f089
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81097
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
As of now coreboot only supported one PCI segment group and thus the
MMCONF size had to be limited to 256 buses on ibm/sbp1. Since the
default FSP doesn't allow to disable unused IIO stacks a patched
version had to be used. Those unused IIO stacks consume lots of PCI
bus ranges, leaving no free buses for the secondary side behind PCI
bridges. The IIO disable mechanism doesn't work after ACPI G3 exit
and thus requires multiple reboots when the previous state was G3.
Since coreboot now supports multi PCI segment groups enable 512
MMCONF buses on 4S platforms by default and drop the IIO stack
disable UPDs on ibm/sbp1. This allows to boot faster without the
need for a patched FSP.
The use of multiple PCI segment groups might prevent legacy software
from working properly, however the only board where multiple PCI
segment groups are used uses u-root as default payload.
TEST=Booted on ibm/sbp1 to ubuntu22.04 using two PCI segment groups.
TEST=intel/archercity CRB
Change-Id: I4e6e5eca1196d4ab50e43b4b58d24eca444ab519
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add PCI enumeration support by reading the PCIeSegment reported in the
FSP HOB and add it when creating the PCI domain for each stack.
The PCI enumeration will be able to scan the additional PCI segment
groups and properly handle those devices.
TEST=Booted on ibm/sbp1 with multiple PCI segment groups enabled
to ubuntu 22.04.
TEST=intel/archercity CRB
Change-Id: I0ba5e426123234979d746d3bdfc1ddfbd71c3447
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79878
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For every PCI segment group generate a new SATC header.
Allows to generate proper ACPI code when multiple PCI segment
groups are enabled.
TEST=Booted on ibm/sbp1 with multiple PCI segment groups.
Properly generates multiple SATC headers.
TEST=intel/archercity CRB
Change-Id: I93b8ee05a7e6798e034f7a5da2c6883f0ee7a0e5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81180
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
In DECLARE_REGION and DECLARE_OPTIONAL_REGION, a set of 3 variables
will be defined, that is the region 'base', 'end' and 'size'.
However, in many codes, the users will only selectively use 'end'
or 'size' instead of both of them, which will trigger compiler errors
for unused variables. This patch sets __maybe_unused attributes on
'end' and 'size' so that users do not need to use all of them.
TEST=intel/archercity CRB
Change-Id: Ia5ed183b2dd7a474ce51de47dbc1f9e3f61e5a41
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81209
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The DMAR entries of type "PCI" have no "Enumeration ID" and thus
there's no need to print it. Drop all unused Enumeration IDs to
simplify the code and debug prints.
Document ID: Intel Virtualization Technology for Directed I/O
Architecture Specification, Rev. 4.0, Order Number: D51397-015
TEST=intel/archercity CRB
Change-Id: I009fbfb9f9d62855d351c5db2d3d88722b5dbfa2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81186
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the bujia variant of the brask reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:327549688
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_BUJIA
Change-Id: I453a50f1aa64f8d4119bf0f860d928aa3e00a144
Signed-off-by: Shon Wang <shon.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81198
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kevin Chiu <kevin.chiu.17802@gmail.com>
The value for CCACHE in site-local/Kconfig gets overridden by the
default in src/Kconfig. Remove the default to make overrides possible.
Change-Id: I6b9dbbb31caa3ef09afd7ecb355c01bd53807b39
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81267
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch enables the `SOC_INTEL_COMMON_BASECODE_RAMTOP` configuration
at the SoC level for all MTL devices. This change streamlines the
configuration process, avoiding redundant selections on individual
mainboards.
BUG=b:306677879
BRANCH=firmware-rex-15709.B
TEST=Verified boot functionality on google/ovis and google/rex.
Change-Id: I3aa3a83c190d0a0e93c267222a9dca0ac7651f9c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81271
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch ensures Ovis baseboard can select RAMTOP caching to improve
the boot time w/o any runtime hang.
BUG=b:306677879
BRANCH=firmware-rex-15709.B
TEST=Verified boot on google/ovis with ~30ms savings in boot time.
Change-Id: Ic0b73eb8fb9cd6ca70d3d7168b79dfd0fbc550e3
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch refactors RAMTOP MTRR type selection to address a critical
NEM logic bug on SoCs with non-power-of-two cache sets. This bug can
cause runtime hangs when Write Back (WB) caching is enabled.
Workaround: Force MTRR type to WC (Write Combining) on affected SoCs
when the cache set count is not a power of two.
BUG=b:306677879
BRANCH=firmware-rex-15709.B
TEST=Verified boot on google/ovis and google/rex (including Ovis with
non-power-of-two cache configuration).
Change-Id: Ia9a8f0d37d581b05c19ea7f9b1a07933caa956d4
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81269
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a function to determine whether the number of cache sets is
a power of two. This aligns with common cache design practices that
favor power-of-two counts for efficient indexing and addressing.
BUG=b:306677879
BRANCH=firmware-rex-15709.B
TEST=Verified functionality on google/ovis and google/rex (including
a non-power-of-two Ovis configuration).
Change-Id: I819e0d1aeb4c1dbe1cdf3115b2e172588a6e8da5
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81268
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
NVMe using clk_src[0] and clk_req[1] mapping to hardware design,
Due to inconsistency between PMC firmware and FSP, we need to set
clk_src to clk_req number, not same as hardware mapping in coreboot.
Then swap correct setting to clk_src=0,clk_req=1 in mFIT.
BUG=b:328318578
TEST=build firmware and veirfy suspend function on NVMe SKU DUT.
Cq-Depend: chrome-internal:7063434
Change-Id: I1777310782a0f4417bd1bb21287bec5852be966e
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81230
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch moves commonlib/stdlib.h -> commonlib/bsd/stdlib.h, since
all code is BSD licensed anyway.
It also moves some code from libpayloads stdlib.h to
commonlib/bsd/stdlib.h so that it can be shared with coreboot. This is
useful for a subsequent commit that adds devicetree.c into commonlib.
Also we don't support DMA on arm platforms in coreboot (only libpayload)
therefore `dma_malloc()` has been removed and `dma_coherent()` has been
moved to architecture specific functions. Any architecture that tries to
use `dma_coherent()` now will get a compile time error. In order to not
break current platforms like mb/google/herobrine which make use of the
commonlib/storage/sdhci.c controller which in turn uses `dma_coherent` a
stub has been added to arch/arm64/dma.c.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I3a7ab0d1ddcc7ce9af121a61b4d4eafc9e563a8a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77969
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Rewrite the function by iterating IOMMU (Input/Output Memory
Management Unit) devices instead of iterating socket and stacks,
which is more aligned to coreboot infrastructure.
TEST=intel/archercity CRB
coreboot DRHD generation is compared, the order of sections are
changed as expected but the content is kept equvalient.
Change-Id: I700513e05181303cf3f4effc793a872eb23340cb
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81228
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Obtain IOMMU (Input/Output Memory Management Unit) info and
enumerate devices using device utils instead of FSP HOB interface,
which might change across SoC generations and no ambiguity across
multiple PCIe segments.
TEST=intel/archercity CRB
coreboot DRHD generation log no changes before and after
Change-Id: Ic5c404899172a0e4fba2721b8e8ca6c1f0856698
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81227
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
pmc_gpe_init uses soc_get_gpi_gpe_configs to initialize dw0, dw1
and dw2. dw0, dw1 and dw2 are uninitialized before calling
soc_get_gpi_gpe_configs. This is error prone for some soc
implementations where soc_get_gpi_gpe_configs does nothing.
This patch is simple, just to assign zero values to dw0, dw1 and
dw0, to enhance the code robustness.
TEST=intel/archercity CRB
Signed-off-by: Gang Chen <gang.c.chen@intel.com>
Change-Id: I8a710a2ac1482eed8c11977d51b187d834122d26
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81210
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PMP (Physical Memory Protection) is a feature of the RISC-V
Privileged Architecture spec, that allows defining region(s) of
the address space to be protected in a variety of ways: ranges
for M mode can be protected against access from lower privilege
levels, and M mode can be locked out of accessig to memory
reserved for lower privilege levels. Limits on Read, Write, and
Execute are allowed. In coreboot, we protect against Write and
Execute of PMP code from lower levels, but allow Reading, so as
to ease data structure access. PMP is not a security boundary,
it is an accident prevention device.
PMP is used here to protect persistent ramstage code that is
used to support SBI, e.g. printk and some data structures. It
also protects the SBI stacks. Note that there is one stack per
hart. There are 512- and 1024-hart SoC's being built today, so
the stack should be kept small.
PMP is not a general purpose protection mechanism and it is easy
to get around it. For example, S mode can stage a DMA that
overwrites all the M mode code. PMP is, rather, a way to avoid
simple accidents. It is understood that PMP depends on proper OS
behavior to implement true SBI security (personal conversation
with a RISC-V architect). Think of PMP as "Protection Minus
Protection".
PMP is also a very limited resource, as defined in the
architecture. This language is instructive: "PMP entries are
described by an 8-bit configuration register and one XLEN-bit
address register. Some PMP settings additionally use the address
register associated with the preceding PMP entry. Up to 16 PMP
entries are supported. If any PMP entries are implemented, then
all PMP CSRs must be implemented, but all PMP CSR fields are
WARL and may be hardwired to zero. PMP CSRs are only accessible
to M-mode."
In other words if you implement PMP even a little, you have to
impelement it all; but you can implement it in part by simply
returning 0 for a pmpcfg. Also, PMP address registers (pmpaddr)
don't have to implement all the bits. On a SiFive FU740, for
example, PMP only implements bits 33:0, i.e. a 34 bit address.
PMPs are just packed with all kinds of special cases. There are
no requirements that you read back what you wrote to the pmpaddr
registers. The earlier PMP code would die if the read did not
match the write, but, since pmpaddr are WARL, that was not
correct. An SoC can just decide it only does 4096-byte
granularity, on TOR PMP types, and that is your problem if you
wanted finer granulatiry. SoC's don't have to implement all the
high order bits either.
And, to reiterate, there is no requirement about which of the pmpcfg
are implemented. Implementing just pmpcfg15 is allowed.
The coreboot SBI code was written before PMP existed. In order
for coreboot SBI code to work, this patch is necessary.
With this change, a simple S-mode payload that calls SBI putchar
works:
1:
li a7, 1
li a0, 48
ecall
j 1b
Without this change, it will not work.
Getting this to build on RV32 required changes to the API,
as it was incorrect. In RV32, PMP entries are 34 bits.
Hence, the setup_pmp needed to accept u64. So,
uinptr_t can not be used, as on 32 bits they are
only 32 bit numbers. The internal API uses uintptr_t,
but the exported API uses u64, so external code
does not have to think about right shifts on base
and size.
Errors are detected: an error in base and size will result
in a BIOS_EMERG print, but not a panic.
Boots not bricks if possible.
There are small changes to the internal API to reduce
stack pressure: there's no need to have two pmpcfg_t
on the stack when one will do.
TEST: Linux now boots partly on the SiFive unmatched. There are
changes in flight on the coreboot SBI that will allow Linux to
boot further, but they are out of scope for this patch.
Currently, clk_ignore_unused is required, this requires a
separate patch.
Change-Id: I6edce139d340783148cbb446cde004ba96e67944
Signed-off-by: Ronald G Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81153
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Hug <philipp@hug.cx>
In Xeon-SP, the domain0, which is located at stack0, usually needs
special handling due to the compatible devices on it (HEPT, IO-APIC
and legacy IOs). This patch adds util function detect whether a
give domain or stack is with such a role.
TEST=intel/archercity CRB
Change-Id: I2f26b4ac54091c24c554f17964502c364288aa40
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
For Xeon-SP, there are 4 main domain roles (PCIe/CXL/IOAT/UBOX).
This patch adds util function to check whether a given domain
belongs to one of these roles, or a give device belongs to
a domain of the specific role.
TEST=intel/archercity CRB
Change-Id: I6b31c29564c774c27e86f55749ca9eca057a0cfe
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81046
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
