This patch implements `.final` hooks for the IGD device to perform the
required operations before handing the control to the payload or OS.
The MBUS (Memory Bus) is a high-speed interface that connects the
graphics controller to the system memory. It provides a dedicated data
path for graphics data, which helps to improve graphics performance.
The MBUS is a key technology that helps to make the Intel i915 driver
powerful and versatile graphics drivers available. It provides the
high-speed data transfer capabilities that are essential for smooth
and responsive graphics performance.
Enable this config to ensure that the Intel GFX controller joins the
MBUS before the i915 driver is loaded. This is necessary to prevent
the i915 driver from re-initializing the display if the firmware has
already initialized it. Without this config, the i915 driver will
initialize the display to bring up the login screen although the
firmware has initialized the display using the GFX MMIO registers and
framebuffer.
Kernel graphics driver can avoid redundant display init by firmware,
which can optimize boot time by ~15ms-30ms.
Ensures hashing mode is 1x4 to enable a single pipe between Pipe A or B.
Typically, internal display is on Pipe-A, so 1x4 restricts MBUS joining
to internal display alone.
BUG=b:284799726
TEST=Able to build and boot google/rex
Change-Id: I60ae76dc783383e027e66edbcdeeb535472caeb1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78385
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For Raptor Lake, select Raptor Lake's .fd file and header.
TEST=Boot to OS on Google Brya board with RPL silicon.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: Ib3172b06b23e19be453142af764dd027bfe8043d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch adds support for detecting dual displays (eDP and HDMI) on
Intel platforms. This information is useful for setting the
`lb_framebuffer.has_external_display` variable, which is used to
determine whether depthchage should avoid shutting down when an
extended display is present.
TEST= Able to build and boot google/rex, where depthchage now
successfully avoids shutting down when both eDP and HDMI displays
are attached.
w/o this patch:
with eDP and HDMI attached: .has_external_display=0
with eDP attached: .has_external_display=0
with HDMI attached: .has_external_display=1
w/ this patch:
with eDP and HDMI attached: .has_external_display = 1
with eDP attached: .has_external_display=0
with HDMI attached: .has_external_display=1
Change-Id: Ie39d48da75a21e3508a1fbcf09da31caedaa1c0a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78383
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iec6e05bbe9fad7d78002560b78169dc293294af6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78341
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This code only gets built when the SOC selects
SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO which no SoC before Genoa
does.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia5495ebf0f157fd0c456ce44acaf1ab222a188dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reserve SBREG BAR if it is outside of the PCH reserved memory range.
Desktop series processors have larger SBREG BARs, which, unlike mobile
processors, do not fall into the standard PCH reserved range
(0xfc800000 - 0xfe7fffff). Create a separate reservation for such a case. There is no telling what could happen if the reservation is not
made in ACPI.
TEST=Boot Windows 11 and Ubuntu 22.04 on MSI PRO Z690-A DDR4
Change-Id: Ibaf45daba37e3acfcea0e653df69fa5c2f480c4a
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77445
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The board has three SATA controllers, so add the remaining two
on PCI device 18.0 and 19.0.
TEST=Verify in lspci the sata controllers.
Change-Id: Ia654c4ef895b52338554d89c25f61b262fbbcbbb
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77892
Reviewed-by: Annie Chen <chen.annieet@inventec.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Systemagent related functions are not used in this file. Remove the
unused the header file.
Change-Id: Ifbb04898e9dcebef96d8c73771e66e0d6fabc7fb
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78312
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This functionality will eventually be used by the common data fabric
domain resource reporting code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ieedd432c144e53e43d8099ec617a15056bb36fd1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78307
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I18871af0a8dbc1423524b681d516476e63b9596a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78306
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
We have a tiny HEAP_SIZE by default, except when we don't, and
mainboards that override it, or not.
Since memory isn't exactly at a premium these days, and unused heap
doesn't cost anything extra, just crank it up to the highest value
we have in the tree by default and remove all overrides.
Change-Id: I918a6c58c02496e8074e5fba06e38d9cfd691020
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78270
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is in preparation of a larger heap. I went for 2MB because why not?
Change-Id: I51f999a10ba894a7f2f5fce224d30bf914107c38
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Dojo fails to boot from NVMe with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN
enabled. The root cause is using __fls() will get a smaller value when
the size is not a power of 2, for example, __fls(0x3000000) = 25. Hence
the PCIe translation window size is set to 0x2000000. Accessing
addresses higher than 0x2300000 will fail.
Fix translation window by splitting the MMIO space to multiple tables if
its size is not a power of 2.
Resolves: https://ticket.coreboot.org/issues/508.
TEST=Build pass and boot up to kernel successfully via SSD on Dojo
board, it can boot with and without the
CONFIG_RESOURCE_ALLOCATION_TOP_DOWN option.
BUS=b:298255933
BRANCH=cherry
Change-Id: I42b0f0bf9222d284dee0c29f1a6ed6366d6e6689
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78044
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 26d54b70e2 ("soc/amd/common/cpu: use TSC_MONOTONIC_TIMER for
SOC_AMD_COMMON_BLOCK_TSC") updated all the AMD SoCs with Zen-based CPU
cores to use TSC_MONOTONIC_TIMER. The same change adjusted the PSP
Verstage timestamps (in microseconds) to the x86 TSC rate. But it
included only the base_time during the adjustment leaving the individual
entry timestamp. This leads to incorrectly adjusted PSP Verstage
timestamps. Fix the adjustment logic.
BUG=None
TEST=Build and boot to OS in Skyrim. Ensure that the PSP Verstage
timestamps in cbmem -t output are adjusted correctly.
Before this change:
5:start of verified boot 67,890 (69,936)
503:starting to initialize TPM 67,890 (0)
504:finished TPM initialization 67,902 (12)
505:starting to verify keyblock/preamble (RSA) 67,906 (3)
506:finished verifying keyblock/preamble (RSA) 67,984 (77)
511:starting TPM PCR extend 67,984 (0)
512:finished TPM PCR extend 67,992 (7)
513:starting locking TPM 67,992 (0)
514:finished locking TPM 67,995 (3)
6:end of verified boot 67,995 (0)
11:start of bootblock 572,152 (504,156)
After this change:
5:start of verified boot 71,000 (73,040)
503:starting to initialize TPM 71,065 (65)
504:finished TPM initialization 101,506 (30,441)
505:starting to verify keyblock/preamble (RSA) 110,624 (9,118)
506:finished verifying keyblock/preamble (RSA) 297,101 (186,477)
511:starting TPM PCR extend 297,297 (196)
512:finished TPM PCR extend 315,338 (18,041)
513:starting locking TPM 315,341 (3)
514:finished locking TPM 322,922 (7,581)
6:end of verified boot 322,943 (21)
11:start of bootblock 570,296 (247,353)
Change-Id: I3e52bef22f65596152f29c511bed680427660ff5
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78231
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The original code only reserves IOM mmio, but there is other asl
code that requires to program ioe p2sb mmio such as IOE PCIE clk request
control. See \_SB.ECLK.CLKD in src/soc/intel/common/acpi/pcie_clk.asl
TEST=as before: suspend_stress_test 50 cycle pass, type-c display OK
on screebo
Change-Id: Ie55f7975277b390f776e44596c42e426ba9cd235
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78252
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Package C-state auto demotion feature allows hardware to determine lower
C-state as per platform policy. Since platform sets performance policy
to balanced from hardware, auto demotion can be disabled without
performance impact.
Also, disabling this feature results soc to enter below PC8 state and
additional power savings ~30mW in Local-Video-Playback scenario.
BUG=b:303546334
TEST=Local build successfully & Boot to OS successfully
- Also check platform enter PC8 state in local video playback
- before this change: # iotools rdmsr 0 0xE2 -> 0x0000000060008008
- After # iotools rdmsr 0 0xE2 -> 0x0000000000008008
Change-Id: Ia4cf4a7cb6bd5eaae26197b55f9385c078960d7b
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78250
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Intel platforms use Low Power Idle Table (LPIT) to enumerate platform
Low Power Idle states. There are two types of low power residencies
a) CPU PKG C10 - read via MSR (Function fixed hardware interface)
b) Platform Controller Hub (PCH) SLP_S0 - read via memory mapped IO
Ref. https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf,
section 2.2.1: value of 0 indicates that counter runs at TSC frequency.
Ref. Intel 64 and IA-32 Architectures Software Developer’s Manual (Vol 4)
MSR 0x632: PC10 residency counter is at same frequency as the TSC.
Whereas slp_s0 residency counter running in different frequency.
BUG=b:300440936
TEST=check kernel cpuidle sysfs are created after kernel boot
cat /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
Change-Id: Ibde764551a21b9aecb1c269948f4823548294711
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch implements an API to report the presence of an external
display on Intel silicon. The API uses information from the transcoder
and framebuffer to determine if an external display is connected.
For example, if the transcoder is attached to any DDI ports other than
DDI-A (eDP), and the framebuffer is initialized, then it is likely
that an external display is present.
This information can be used by payloads to determine whether or not
to power on the display, even if eDP is not initialized.
BUG=b:299137940
TEST=Build and boot google/rex
Scenarios:
Booting with eDP alone: has_external_display value is 0
Booting with eDP + HDMI: has_external_display value is 0
Booting with HDMI alone: has_external_display value is 1
Booting with USB-C display alone: has_external_display value is 1
Change-Id: I77436940978c7fa9368d79394b46a5e794c32e42
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78080
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Intel GFX IP TRANS_DDI_FUNC_CTL register bit definitions have changed
since Tiger Lake.
This register is used to map ports and pipes to display controllers,
so reflecting the correct status is important for detecting physical
display end point devices.
This patch ensures that ADL, MTL, and TGL SoCs choose GMA version 2 to
properly reflect the updated port and pipe register definitions.
BUG=b:299137940
TEST=Build and boot google/rex successfully.
Change-Id: Ie2082747d18a5f136f410b1019be4d6c801617b1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Use the common UWES ACPI method to enable wake from USB. The only
difference to other SoCs is that JSL only has 8 USB2 ports, so the USB3
PORTSC register offset is different.
BUG=b:300844110
TEST=When enabled on taranza, all USB2 and USB3 ports can wake from
suspend
Change-Id: Ibc90246965d5d809123e954847543d28d78498a5
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78086
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
The ACPI methods for enabling USB wake are identical on ADL, CNL and
SKL. Move them to a common ASL file so they can be reused more easily
on other SoCs.
Also move the USB_PORT_WAKE_ENABLE macro used to create enable bitmasks
in devicetree to a common header.
BUG=b:300844110
TEST=Use abuild to build kinox, puff, and fizz with and without this
change. Check the generated dsdt.aml is unchanged.
Change-Id: Iabdfe2bece7fafc284ddf04382f1bbcacc370cce
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The SPL_TABLE_FILE and SPL_RW_AB_TABLE_FILE Kconfig options provide a
way to override the default SPL file configured in the SoC's fw.cfg file
by passing the '--spl-table' parameter to amdfwtool which will then use
the override instead of the SPL file from the fw.cfg file. When
SPL*_TABLE_FILE is an empty string, the corresponding add_opt_prefix
call in the makefile will result in no '--spl-table' parameter being
passed to amdfwtool, so it'll use the default SPL file from fw.cfg. In
order to not pass an SPL override by default, remove the default from
the SPL_TABLE_FILE in the SoC's Kconfig. The SoC default pointed to the
same SPL file as in fw.cfg file anyway. Now only when a mainboard sets
this option to point to a file, that file will be used as an override.
This override is used to include a special SPL file needed for the
verstage on PSP case on the Chromebooks. Since SPL_TABLE_FILE is an
empty string by default, neither the SPL_TABLE_FILE Kconfig option nor
it being evaluated in the Makefile need to be guarded by HAVE_SPL_FILE,
so remove the dependency in the Kconfig and the ifeq in the Makefile.
Before this patch, the HAVE_SPL_FILE option controlled two things that
shouldn't be controlled by the same Kconfig option: Only when
HAVE_SPL_FILE was set to y, the SPL_TABLE_FILE override was taken into
account, and it also controls if spl_fuse.c got added to the build which
when added will send the SPL fusing command to the PSP. So the case of
needing an SPL file override, but not updating the SPL fuses wasn't
supported before.
The SPL file in the amdfw part will be used by the PSP bootloader for
the anti-rollback feature which makes sure that the SPL file version
isn't lower than what is in the SPL fuses. For this the SPL file needs
to be present in the PSP directory table. The SPL version check happens
way before we're running code on the x86 cores. The SPL fusing PSP
command that can be sent by coreboot will tell the PSP to update the SPL
fuses so that the fused minimal SPL version will be updated to the
current SPL version.
Since the former HAVE_SPL_FILE option now only controls if the SPL
fusing command will be sent to the PSP mailbox, rename it to
PERFORM_SPL_FUSING to clarify what this will do and update the help text
correctly describe what this does.
TEST=With INCLUDE_CONFIG_FILE set to n, timeless builds for both Birman
with Phoenix APU and Skyrim result in identical binaries.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6cec1f1b285fe48e81a961414fbc9978fa1003cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78178
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
During CSE firmware downgrade, data is cleared. To preserve PSR data
during downgrade, it needs to be backed up. Select
SOC_INTEL_CSE_LITE_PSR config to ensure PSR backup related flow is
executed on CSE Lite SKU.
BRANCH=None
BUG=b:273207144
TEST=Verify CSE firmware upgrade/downgrade on rex.
Change-Id: I39af029a5f0c018a5db3ac68191764abfa9518ac
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76115
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds eventlog entries for the below scenarios:
1. To indicate success or failure of PSR data back-up command
2. To indicate the loss of PSR data when CSE update is corrupted, and
data clear command is issued to clear the data.
3. To indicate the loss of PSR data when CSE boot partition info
response is corrupted and data back-up is not initiated.
BRANCH=None
BUG=b:273207144
TEST=Verify elog event added after PSR data backup command is sent
cse_lite: PSR_HECI_FW_DOWNGRADE_BACKUP command sent
...
ELOG: Event(B9) added with size 10 at 2023-06-27 06:44:49 UTC
Change-Id: I2459a2b941d28a87b6c78f75dbe8779d73328d7a
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Get PSR bit state using MKHI_FWCAPS_GET_FW_FEATURE_STATE HECI command
Use this bit info to check if SKU supports PSR and consequently issue
PSR_HECI_FW_DOWNGRADE_BACKUP command for PSR data backup during
downgrade.
BUG=b:273207144
TEST=build CB image and boot on google/rex board. Check for
"PSR is supported in this SKU" message in coreboot logs to confirm
that PSR bit is set in SKU
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I6e92341a9dc799146eb8f1a70b3a4a16fd1aa0ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
During CSE FW downgrade we erase CSE data. This would result in
Platform Service Record(PSR) data also to be erased.
To avoid losing PSR data we need to make a backup before data clear.
This patch sends PSR_HECI_FW_DOWNGRADE_BACKUP HECI command to CSE,
informing the CSE to backup PSR data before a data clear operation
during downgrade.
CMOS memory is used to track the backup status. PENDING is the default
state, it is updated to DONE once PSR_HECI_FW_DOWNGRADE_BACKUP HECI
command is sent.
PSR data can be backed up only post DRAM is initialized. The idea is to
perform cse_fw_sync actions in ramstage when PSR is enabled on a
platform. As part of the cse_fw_sync actions, when a firmware downgrade
is requested the command to back-up data is sent. Once the backup has
been done, trigger the firmware downgrade.
BRANCH=None
BUG=b:273207144
TEST=build CB image for google/rex board and check PSR backup command
is being sent during a CSE FW downgrade. Also check PSR data is not
lost/erased after a downgrade using intel PSR tool.
Change-Id: I135d197b5df0a20def823fe615860b5ead4391f8
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74577
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data. Since firmware downgrade
and PSR data backup flows involve global resets, there is a need to
track the PSR data backup status across resets. So adding a CMOS
variable for the same.
This patch implements API to access PSR backup status stored in CMOS.
The get API allows to retrieve the PSR backup status from CMOS memory.
The update API allows to update the PSR backup status in CMOS.
BRANCH=None
BUG=b:273207144
TEST=Able to retrieve PSR backup status across resets.
Change-Id: I270894e3e08dd50ca88e5402b59c211d7e693d14
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
CSE firmware downgrade and PSR data backup flows involve global resets,
there is a need to track the PSR data backup status across resets. In
the subsequent patches, a CMOS structure to store PSR back-up status
will be added.
The current SOC_INTEL_CSE_FW_PARTITION_CMOS_OFFSET of 68 can only store
cse_specific_info, as ramtop is at offset 100 and PSR back-up status
structure will not be able to fit within the range.
This patch overrides the SOC_INTEL_CSE_FW_PARTITION_CMOS_OFFSET to 161
to accommodate all CSE related info in adjacent CMOS memory.
BUG=b:273207144
TEST=Verify CSE RW FW versions are stored in CMOS memory in rex.
Change-Id: I8bae5245f93b99be15b4e59cfeffbc23eec95001
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78054
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Platform Service Record(PSR) will be enabled on Meteor Lake
platforms. cse_fw_sync actions happen in ramstage when PSR is enabled.
To avoid the boot time penalty of sending the cse_get_bp_info in
ramstage, call cse_fill_bp_info to get cse_bp_info response early in
romstage and store in cbmem. This data can be later used in ramstage.
BUG=b:273207144
TEST=Verify cse_bp_info is filled in romstage in rex.
Change-Id: Ic0e8fb34f21ff07e182a7b848d38e9d329010028
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data, and this command can be
sent only in post-RAM stages. So the cse_fw_sync actions needs to be
moved to ramstage.
Sending cse_get_bp_info command in ramstage takes additional boot time
of ~45-55ms on rex. To avoid the boot time penalty, this patch provides
an API to get the cse_bp_info in early romstage. The response data is
then migrated to cbmem once memory is initialized. The same data in
cbmem can be utilized in ramstage to perform other cse_fw_sync actions.
This patch also adds check to validate cse_bp_info in cbmem and avoids
sending the command again if the data is valid.
BUG=b:273207144
TEST=Verify the command works in early romstage, data is migrated to
cbmem and valid data is available in ramstage on rex.
Change-Id: Ib1e72c950ba0f4911924805f501ec1bd54b6ba3c
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78053
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that Intel has publicly released FSP headers/binaries for
RaptorLake-P/S client platforms, set the defaults accordingly if
FSP_USE_REPO is not selected. This does not change any existing
defaults as the RaptorLake headers in vendorcode are only used when
FSP_USE_REPO is not set.
TEST=build/boot google/brya (osiris)
Change-Id: Ida92d269fcaf6f323599ec174f4dcedbbe65f03c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78190
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Simplify the code a bit by returning 0 early in the function when the
SYSCFG_MSR_SMEE bit isn't set.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I7536b82d98e55c51105448090d1206e1ed7f62d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78176
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of having the get_usable_physical_address_bits function that
only got used in the data fabric domain resource reporting code, drop
this function, select RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT in the
common AMD non-CAR CPU and rename get_sme_reserved_address_bits to
get_reserved_phys_addr_bits so that the common cpu_phys_address_size
function will return the correct number of usable physical address bits
which now can be used everywhere. The common AMD CAR CPU support is only
selected by Stoneyridge which doesn't support secure memory encryption,
so RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT isn't selected by the
SOC_AMD_COMMON_BLOCK_CAR Kconfig option.
Before only the MMIO region reporting took the reserved physical address
bits into account, but now also the MTRR calculation will take those
reserved bits into account. See the AMD64 Programmers Manual volume 2
(document number 24593) for details. Chapter 7.10.5 from revision 3.41
of this document was used as a reference. The MTRR handling code in
older Linux kernels complains when the upper reserved bits in the MTRR
mask weren't set, but sets them after complaining and then continues to
boot. This issue is no longer present in version 6.5 of the Linux
kernel.
The calculation of the TSEG mask however still needs to take all
physical bits into account, including the ones reserved for the memory
encryption. When not setting the reserved bits in the TSEG mask, the
Mandolin board with a Picasso APU won't boot to the OS any more due to
not returning from SeaBIOS calling into the VBIOS. Haven't root-caused
what exactly causes this breakage, but I think previously when something
else was wrong with the SMM initialization, also something went wrong
when calling into the VBIOS.
TEST=Ubuntu 2023.10 nightly build boots on Mandolin via SeaBIOS and EDK2
and Windows 10 boots on it via EDK2.
TEST=On Ubuntu 2022.04 LTS, the kernel complained with the following
warning, but it still continues the boot process as described above:
mtrr: your BIOS has configured an incorrect mask, fixing it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iad65144006f1116cd82efc3c94e1d6d1ccb31b6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Configure the SCP to operate within domain 8, allowing it to access
only the necessary registers. Any unauthorized access will be prevented
by the DAPC.
- Set SCP domain from domain 0 to domain 8.
- Lock register settings down to prevent unexpected modification.
BUG=b:270657858
TEST=scp bootup successful with dapc settings
Change-Id: I049486c997542d91bd468e0f4662eafbca4c17e0
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77883
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Currently, all the masters controlled by DAPC are in domain 0. With
this setting, there is a potential security problem. For example, if a
certain master is somehow hacked, it may attempt to access registers
that it is not supposed to, with successful results. This is due to the
fact that, in the current setting, all masters are in domain 0 and can
access almost all registers. To prevent this problem, we assign masters
to different domains and restrict access to registers based on each
domain.
This patch sets domains for masters:
SSPM - domain 3
CPUEB - domain 14
PCIE0 - domain 2
SPM - domain 9
Change-Id: Ie3e1d5055e72824257b66d6257982652eeb05953
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77862
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, all the masters controlled by DAPC are in domain 0. With
this setting, there is a potential security problem. For example, if a
certain master is somehow hacked, it may attempt to access registers
that it is not supposed to, with successful results. This is due to the
fact that, in the current setting, all masters are in domain 0 and can
access almost all registers. To prevent this problem, we assign masters
to different domains and restrict access to registers based on each
domain.
This patch updates the permission settings for domains 2, 3, 4, 5, 7,
8, 9, and 14, as these domains will be assigned masters in the upcoming
patch.
BUG=b:270657858
TEST=build pass
Change-Id: I6e95ddb5d84a09ff865d7615596430e25b69d3fc
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77861
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data, and this command can be
sent only in post-RAM stages. So the cse_fw_sync actions needs to be
moved to ramstage.
This patch ensures SOC_INTEL_CSE_LITE_SYNC_IN_RAMSTAGE is selected when
PSR is enabled.
BUG=b:273207144
Change-Id: I7c9bf8b8606cf68ec798ff35129e92cd60bbb137
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78055
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Convert TPM functions to return TPM error codes(referred to as
tpm_result_t) values to match the TCG standard.
BUG=b:296439237
TEST=build and boot to Skyrim
BRANCH=None
Change-Id: Ifdf9ff6c2a1f9b938dbb04d245799391115eb6b1
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77666
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
