Currently, Intel TME (Total Memory Encryption) can be enabled regardless
of SoC support. Add a Kconfig to guard the option depending on actual
support.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: Ia20152bb0fc56b0aec3019c592dd6d484829aefe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
FspMultiPhaseSiInit API was introduced with FSP 2.2 specification
onwards. EnableMultiPhaseSiliconInit is an arch UPD also introduced
as part of FSP 2.2 specification to allow calling FspMultiPhaseSiInit
API.
However, some platforms adhere to the FSP specification but
don't have arch UPD structure, for example : JSL, TGL and Xeon-SP.
Out of these platforms, TGL supports calling of FspMultiPhaseSiInit
API and considered EnableMultiPhaseSiliconInit as a platform-specific
UPD rather than an arch UPD to allow calling into FspMultiPhaseSiInit
API.
It is important to ensure that the UPD setting and the callback for
MultiPhaseInit are kept in sync, else it could result in broken
behavior e.g. a hang is seen in FSP if EnableMultiPhaseSiliconInit
UPD is set to 1 but the FspMultiPhaseSiInit API call is skipped.
This patch provides an option for users to choose to bypass calling
into MultiPhaseSiInit API and ensures the EnableMultiPhaseSiliconInit
UPD is set to its default state as `disable` so that FSP-S don't
consider MultiPhaseSiInit API is a mandatory entry point prior to
calling other FSP API entry points.
List of changes:
1. Add `FSPS_HAS_ARCH_UPD` Kconfig for SoC to select if
`FSPS_ARCH_UPD` structure is part of `FSPS_UPD` structure.
2. Drop `soc_fsp_multi_phase_init_is_enable()` from JSL and Xeon-SP
SoCs, a SoC override to callout that SoC doesn't support calling
MultiPhase Si Init is no longer required.
3. Add `FSPS_USE_MULTI_PHASE_INIT` Kconfig for SoC to specify if
SoC users want to enable `EnableMultiPhaseSiliconInit` arch UPD (using
`fsp_fill_common_arch_params()`) and execute FspMultiPhaseSiInit() API.
4. Presently selects `FSPS_USE_MULTI_PHASE_INIT` from IA TCSS common
code.
5. Add `fsp_is_multi_phase_init_enabled()` that check applicability of
MultiPhase Si Init prior calling FspMultiPhaseSiInit() API to
honor SoC users' decision.
6. Drop `arch_silicon_init_params()` from SoC as FSP driver (FSP 2.2)
would check the applicability of MultiPhase Si Init prior calling
FspMultiPhaseSiInit() API.
Additionally, selects FSPS_HAS_ARCH_UPD for Alder Lake as Alder Lake
FSPS_UPD structure has `FSPS_ARCH_UPD` structure and drops
`arch_silicon_init_params()` from SoC
`platform_fsp_silicon_init_params_cb()`.
Skip EnableMultiPhaseSiliconInit hardcoding for Tiger Lake and uses
the fsp_is_multi_phase_init_enabled() function to override
EnableMultiPhaseSiliconInit UPD prior calling MultiPhaseSiInit FSP API.
TEST=EnableMultiPhaseSiliconInit UPD is getting set or reset based on
SoC user selects FSPS_USE_MULTI_PHASE_INIT Kconfig.
Change-Id: I019fa8364605f5061d56e2d80b20e1a91857c423
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Commit 2eb100dd12 added PMC LPM requirements to the the PEP ACPI
objects, but it was not made clear that one of the pointer arguments to
the mentioned function is not supposed to be NULL and Coverity
complained. Make the intention clear by instead asserting that `info`
cannot be NULL.
Fixes: Coverity CID 1462119
Change-Id: I9e8862a100d92f4a7ed1826d3970a5110b47f4c4
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57645
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When the FSP driver fills out framebuffer information for the coreboot
tables, it assumes the orientation is always normal. This patch provides
a field for a mainboard to override the panel orientation from the
default (LB_FB_ORIENTATION_NORMAL). Later patches will have the FSP
driver use this value when filling out framebuffer information.
BUG=b:194967458
BRANCH=dedede
Change-Id: I559b3d6a076112a1c020ce5e296430d7ccba9ee4
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57558
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
After switching to runtime generation of the Intel Power Engine (PEPD)
device, this file is no longer required.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I2444433f08bfda6f79589a397a2ad2b5a3ecb0ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56015
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to get rid of pep.asl, skylake also needs to support runtime
generation of the Intel Power Engine, therefore add this support to
devices that have a discoverable PMC as well.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I4bf0c4a338301b335fa78617e0f2ed5a9f4360ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
There is a use-case for generating the AML bytecode at runtime for the
Intel Power Engine device, which comes in a followup patch.
BUG=b:185437326
TEST=verified on google/brya and google/dratini by dumping SSDT and
verifying the PEPD device matches what was previously in the DSDT:
Scope (\_SB.PCI0)
{
Device (PEPD)
{
Name (_HID, "INT33A1")
Name (_CID, EisaId ("PNP0D80")
Method (_DSM, 4, Serialized)
{
ToBuffer (Arg0, Local0)
If ((Local0 == ToUUID ("c4eb40a0-6cd2-11e2-bcfd-0800200c9a66")))
{
ToInteger (Arg2, Local1)
If ((Local1 == Zero))
{
Return (Buffer (One)
{
0x63
})
}
If ((Local1 == One))
{
Return (Package (0x01)
{
Package (0x03)
{
\NULL,
Zero,
Package (0x02)
{
Zero,
Package (0x02)
{
0xFF,
Zero
}
}
}
})
}
If ((Local1 == 0x02)){}
If ((Local1 == 0x03)){}
If ((Local1 == 0x04)){}
If ((Local1 == 0x05))
{
If (CondRefOf (\_SB.PCI0.LPCB.EC0.S0IX))
{
\_SB.PCI0.LPCB.EC0.S0IX (One)
}
If (CondRefOf (\_SB.MS0X))
{
\_SB.MS0X (One)
}
If (CondRefOf (\_SB.PCI0.EGPM))
{
\_SB.PCI0.EGPM ()
}
}
If ((Local1 == 0x06))
{
If (CondRefOf (\_SB.PCI0.LPCB.EC0.S0IX))
{
\_SB.PCI0.LPCB.EC0.S0IX (Zero)
}
If (CondRefOf (\_SB.MS0X))
{
\_SB.MS0X (Zero)
}
If (CondRefOf (\_SB.PCI0.RGPM))
{
\_SB.PCI0.RGPM ()
}
}
Return (Buffer (One)
{
0x00
})
}
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ie83722e0ed5792e338fc5c39a57eef43b7464e3b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56004
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change adds a new Kconfig `SOC_INTEL_ENABLE_USB4_PCIE_RESOURCES`
that can be selected by mainboard to reserve hotplug resources for
USB4 at the SoC level. `ADL_ENABLE_USB4_PCIE_RESOURCES` is dropped
from soc/intel/alderlake and instead the newly added Kconfig is now
used. This new Kconfig is added so that the same config can be used
across different platforms. In following changes, this Kconfig is
utilized by TGL as well.
Change-Id: Id7c359a0e255c43c2732f6cbe287bc7da14a46e3
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There are multiple HECI clients in the CSE. heci_send_receive() is
sending HECI messages to only the MKHI client. Add an argument to
heci_send_receive() function to provide flexibility to the caller to
select the client for which the message is intended.
With the above change heci_send() and heci_receive() functions are
no longer required to be exposed.
In the follow-up patches there will be messages sent to one other
client.
BUG=None
BRANCH=None
TEST=Build and boot brya. HECI message send and receive to MKHI client
is working. Also, MEI BUS message to disable bus is working.
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Change-Id: Icde6d0155b62472b6a7caadc5fc8ea2e2ba6eb0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add PMC IPC commands information for FIVR control functionality.
BUG=b:198582766
BRANCH=None
TEST=Build FW and test on brya0 board
Change-Id: Iccb43b7ba4f0765499bf1844efbbb526bd671a8f
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57095
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Get tdp value of CPU for different SKUs based on PKG POWER MSR.
BUG=b:194745919
BRANCH=None
TEST=Build FW and test on brya0 board
Change-Id: I9fba0a64da2f1d79d633054dddd9fdf1d3d8e258
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57143
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Since all mainboards use `CHIPSET_LOCKDOWN_COREBOOT`, make it the
default by changing its enum value to 0 and remove its configuration
from all related devicetrees.
If `common_soc_config.chipset_lockdown` is not configured with
something else in the devicetree, then `CHIPSET_LOCKDOWN_COREBOOT`
is used.
Also, add a release note for the upcoming 4.15 release.
Change-Id: I369f01d3da2e901e2fb57f2c83bd07380f3946a6
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56967
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Some FSPs provide a UPD to allow the bootloader to set the PAM lock bit
instead of the FSP, therefore add a function in the common code to do
this. Source: ADL & TGL FSP integration guides
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I1d6642b496617b6e8ccda8a0aa6bfd88ea9dc3ba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57145
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Alder Lake onwards IA SoC to select CAR_HAS_L3_PROTECTED_WAYS from SoC
Kconfig and here is modified flow as below:
Add new MSR 0xc85 IA32_L3_PROTECTED_WAYS
Update eNEM init flow:
- Set MSR 0xC85 L3_Protected_ways = (1 << data ways) - 1
Update eNEM teardown flow:
- Set MSR 0xC85 L3_Protected_ways = 0x00000
BUG=b:168820083
TEST=Verified filling up the entire cache with memcpy at the beginning
itself and then running the entire bootblock, verstage, debug FSP-M
without running into any issue. This proves that code caching and
eviction is working as expected in eNEM mode.
Change-Id: Idb5a9ec74c50bda371c30e13aeadbb4326887fd6
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48344
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
MSR IA_SF_QOS_INFO (0xc87) has been introduced since TGL and is used
to find out the NUM_SNOOP_FILTER_WAYS. Bit[5:0] of MSR 0xc87 indicates
the maximum number of bits that may be set in any of the SF MASK
register. Hence, this patch calculates SF way count using below logic:
Calculate SF masks 1:
1. Calculate SFWayCnt = (MSR 0xC87) & 0x3f
2. if CONFIG_SF_MASK_2WAYS_PER_BIT:
a. SFWayCnt = SFWayCnt / 2
3. Set SF_MASK_1 = ((1 << SFWayCnt) - 1) - SF_MASK_2
Change-Id: Ifd0b7e1a90cad4a4837adf6067fe8301dcd0a941
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
As per TGL EDS, two ways will be controlled with one bit of SF QoS
register hence, this patch introduces SF_MASK_2WAYS_PER_BIT Kconfig to
allow SoC users to select SF_MASK_2WAYS_PER_BIT to follow the EDS
recommendation.
Calculate SF masks 2:
1. if CONFIG_SF_MASK_2WAYS_PER_BIT:
a. data_ways = data_ways / 2
Also, program SF Mask#2 using below logic:
2. Set SF_MASK_2 = (1 << data_ways) - 1
Change-Id: I442bed75f13d26f357cfb32c54c5fe9efa4b474b
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The code is clearer when ACPI_DEVICE_SLEEP_D3_COLD is used instead of
the number 4.
Change-Id: I4b0ade1cd0b4b9cdb59f90f8d455269d0b69ed86
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
coreboot always assumes that BSP APIC ID will always be 0 but as
per Intel 64 and IA-32 Architectures Software Developer’s Manual
Volume 3: 8.4.1 BSP and AP Processors, it says that BSP can
be any processor whose index/APIC ID might not be 0.
To handle this situation, init_cpu call is required to modify to
handle dynamic detection of APIC ID from BSP instead of hardcoding
always through devicetree. Function has been updated to create
a new node with actual BSP APIC ID when devicetree doesn't contain
APIC ID defined. In case APID ID is defined, function will use a
node with the APIC ID defined in devicetree.
Changes also requires to remove "lapic 0" hardcoding from devicetree
to allow code to fill BSP APIC ID dynamically. Otherwise coreboot
will create an extra node for CPU with APIC ID 0 and it'll show as a
extra node in kernel. This will cause kernel to report wrong (extra)
core count information then actually present.
BUG=None
BRANCH=None
TEST=Boot the JSL system and observe there is no functional impacts.
Without this CL kernel core count in `lscpu` = 3
With this CL, kernel core count is corrected to 2.
Change-Id: Ib14a5c31b3afb0d773284c684bd1994a78b94445
Signed-off-by: MAULIK V VAGHELA <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This CL adds support for new ADL-M graphics Device ID 0x46aa.
TEST=boot to OS
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: Ib24b494b0eedad447f3b2a3d1d80c9941680c25d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56775
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Move post_codes.h from include/console to
commonlib/include/commonlib/console.
This is because post_codes.h is needed by code from util/
(util/ code in different commit).
Also, it sorts the #include statements in the files that were
modified.
BUG=b:172210863
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Change-Id: Ie48c4b1d01474237d007c47832613cf1d4a86ae1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56403
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 4c569b52f6. This has
introduced a regression in mainboards using JSL SoC such that it
overrides the soft straps for all the GPIOs. This in turn has led to
some of the peripherals not working.
BUG=None
TEST=Build and boot to OS in Storo. Ensure that the regressed
peripherals are working back again.
Change-Id: Ibfeed1075fe28051b926ddd7ca771693dc19dae8
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56613
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some of the Intel SoCs with more than 2 PAD configuration registers
support programming VCCIO selection. Add a pad configuration macro to
program VCCIO selection when the GPIO is an output pin.
BUG=b:194120188
TEST=Build and boot to OS in Gallop. Ensure that the VCCIO selection is
configured as expected and probing the GPIO reads the configured
voltage.
Change-Id: Icda33b3cc84f42ab87ca174b1fe12a5fa2184061
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56507
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As per the EDS revision 1.3 add support for I2C6 and I2C7.
Signed-off-by: Varshit B Pandya <varshit.b.pandya@intel.com>
Change-Id: Id918d55e48b91993af9de8381995917aef55edc9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55996
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch removes all local `CPUID_` macros from SoC directories and
creates a common cpu_ids.h inside include/cpu/intel/cpu_ids.h. SoC
users are expected to add any new CPUID support into cpu_ids.h and
include 'cpu/intel/cpu_ids.h' into respective files that look for
`CPUID_` macro.
Note: CPUIDs for HSW, BDW and Quark are still inside the respective
directory.
Change-Id: Id88e038c5d8b1ae077c822554582410de6f4a7ca
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch replaces the usage of GPR (General Purpose Registers) like
ECX and EBX for backing up data way and non-eviction mask with SPR
(Special Purpose Registers) EDI and ESI.
Purpose of this change is to ensure the safety while developers might
use ECX often while doing rdmsr/wrmsr rather than making use of EDI.
TEST=Able to boot JSL and TGL platform without any hang using eNEM.
Change-Id: I12e0cb7bb050e4f7b17ecf30108db335d1d82ab7
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56161
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the common mca_get_bank_count function instead of open-coding the
functionality to get the MCA bank number. Also re-type the num_banks
variable from signed in to unsigned int, since the number of MCA bank is
always positive, and make it constant.
Change-Id: I449c74629ff16057c4559d7fd3620208230560f5
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56245
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When accessing the MCA MSRs, the MCA bank number gets multiplied by 4
and added to the IA32_MC0_* define to get the MSR number. Add a macro
that already does this calculation to avoid open coding this repeatedly.
Change-Id: I2de753b8c8ac8dcff5a94d5bba43aa13bbf94b99
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56243
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Previously, irq_program_non_pch() was only programming the IRQ line, but
the pin is required as well.
BUG=b:176858827
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I2a2823c183a3495721a912de285cddb4a9444c55
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56174
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to disable X86_TOP4G_BOOTMEDIA_MAP it requires the definition
to be overridden. This makes it a little less ergonomic to use. Instead
introduce the inverse option that can be selected. I chose to leave
X86_TOP4G_BOOTMEDIA_MAP since it keeps the Makefiles simple.
BUG=b:179699789
TEST=none
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I65bbc118bde88687a7d7749c87acf1cbdc56a269
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The same pattern appears on all `xdci_can_enable()` call sites. Move the
logic inside the function and take the xDCI devfn as parameter.
Change-Id: I94c24c10c7fc7c5b4938cffca17bdfb853c7bd59
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55790
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch adds functionality to attempt to allow booting in a secure
configuration (albeit with potentially reduced functionality) when the
CSE EOP message fails in any way. These steps come from the CSME BWG
(13.5, 15.0, 16.), and tell the CSE to disable the MEI bus, which
disables further communication from the host. This is followed by
requesting the PMC to disable the MEI devices. If these steps are
successful, then the boot firmware can continue to boot to the
OS. Otherwise, die() is called, prefering not to boot over leaving the
insecure MEI bus available.
BUG=b:191362590
TEST=Set FSP UPD to disable sending EOP; called this function from a
BS_PAYLOAD_LOAD, ON_ENTRY entry; observed that with just
cse_mei_bus_disable() called, Linux can no longer communicate over MEI:
[ 16.198759] mei_me 0000:00:16.0: wait hw ready failed
[ 16.204488] mei_me 0000:00:16.0: hw_start failed ret = -62
[ 16.210804] mei_me 0000:00:16.0: H_RST is set = 0x80000031
[ 18.245909] mei_me 0000:00:16.0: wait hw ready failed
[ 18.251601] mei_me 0000:00:16.0: hw_start failed ret = -62
[ 18.257785] mei_me 0000:00:16.0: reset: reached maximal consecutive..
[ 18.267622] mei_me 0000:00:16.0: reset failed ret = -19
[ 18.273580] mei_me 0000:00:16.0: link layer initialization failed.
[ 18.280521] mei_me 0000:00:16.0: init hw failure.
[ 18.285880] mei_me 0000:00:16.0: initialization failed.
Calling both error recovery functions causes all of the slot 16 devices
to fail to enumerate in the OS
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I06abf36a9d9d8a5f2afba6002dd5695dd2107db1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55675
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
1. Remove 'PCH_EPOC_XTAL_FREQ(__epoc)' macro since it only be used
in 1 place.
2. Transform macro into more readable C code.
3. Add additional case check to make sure the returned value is
defined in the 'pch_pmc_xtal' enum.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: If57a99bf8e837a6eb8f225297399b1f5363cfa85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55587
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move PMC EPOC related code to intel/common/block because it is
generic for most Intel platforms and ADL, TGL & EHL use it.
Add a kconfig 'PMC_EPOC' to guard this common EPOC code.
The PMC EPOC register indicates which external crystal oscillator is
connected to the PCH. This frequency is important for determining the
IP clock of internal PCH devices.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: Ib5fd3c4a648964678ee40ed0f60ca10fe7953f56
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55565
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The IRQ for a single device may be required elsewhere, therefore provide
get_pci_devfn_irq.
BUG=b:130217151, b:171580862, b:176858827
Change-Id: Ibebd821767a2698c9e60b09eeeff3bb596359728
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55826
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The results of the PCI IRQ assignments are used in several places, so
it makes for a nicer API to cache the results and provide simpler
functions for the SoCs to call.
BUG=b:130217151, b:171580862, b:176858827
Change-Id: Id79eae3f2360cd64f66e7f53e1d78a23cfe5e9df
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55825
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Because the FSP interface for PCI IRQs only includes the PCH devices,
this function is the complement to that, taking the list of irq entries,
and programming the PCI_INTERRUPT_LINE registers.
BUG=b:130217151, b:171580862, b:176858827
TEST=boot brya with patch train, verify with `lspci -vvv` that for all
the north PCI devices, their IRQ was either the one programmed by this
function, or an MSI was used.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I81cf7b25f115e41deb25767669b5466b5712b177
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55817
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
