Commit bd9c562a9e ("acpi: Configure
slp-s0 residency counter frequency in LPIT table") led to jenkins
reporting the following error:
!!!!! Error: defined(CONFIG_ACPI_SOC_INTEL_SLP_S0_FREQ_HZ)
used at src/include/acpi/acpi.h:457. Symbols of type 'hex'
are always defined.
Since hex Kconfig are always defined there is no need to test it being
defined but also no need to handle zero or non-zero values.
In addition:
1. This config was defined in Meteor Lake specific Kconfig file while
it should actually be define closer to where it is being used (here
soc/intel/common/block/acpi/Kconfig) and only set by the SoC Kconfig.
2. Once moved and under control of `SOC_INTEL_COMMON_BLOCK_ACPI_LPIT'
gating (lpit.c), the Kconfig name needed to be adjusted to better fit
its use.
3. Make Meteor Lake Kconfig sets the config but does not define it
anymore.
TEST=LPIT ACPI table Counter Frequency field is set to 0x2005 on rex
Change-Id: I2083c9209e61be6180cca2c9f74097e2f4b4ce9a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78458
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The microcode for RPL-S C0 and H0 is actually available, however, the
name of the file contained a typo: 06-b7-05 vs 06-bf-05. Fix the typos
in the comments.
Moreover, the ADL-S C0/H0 microcode file 06-97-05 has the same sha256
sum as the equivalent RPL-S C0/H0 microcode file 06-bf-05. The sha256
sum of ADL-S/RPL-S C0/H0 microcode on intel-microcode tag
microcode-20230808:
5d8d4a4d5456c43b7cc04937c80aec094ccbf3bd89f34ffa5182913ef944a9f9
Update the comments to correctly indicate supported CPU steppings.
Change-Id: I4c848e0dfc40f6c8e26a9b31e7c4cf4c5a09128f
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78413
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove the existing FSP 4221.00 headers subdirectory called
4221.00_google, and have Google vendor devices use FSP 4301.01.
BUG=b:306181828
TEST=`emerge-brya coreboot chromeos-bootimage`, flash and boot skolas to kernel.
Change-Id: Ic64b3aec62f0d6302278393bf06d090f43c0d592
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: <srinivas.kulkarni@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
System sleep time (SLP_S0 signal asserted) is measured in ticks, for
Meteor Lake soc in 122us (i.e. ~8197Hz) granularity/ticks.
Change-Id: I1e95cd69e941d4d72d5c36a07660ca07ee2499ba
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78277
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 ensures that the IGD joins the MBUS when the firmware splash
screen feature is enabled (aka BMP_LOGO config is enabled).
For ChromeOS platform, it prevents the i915 driver from reinitializing
the display, which can save up to 75ms-80ms of boot time and eliminate
a brief period of blank screen between the firmware splash screen and
the OS login prompt.
BUG=b:284799726
TEST=Able to build and boot google/rex.
Change-Id: I36af167afa902053a987602d494a8830ad9b1b1a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
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>
Only the lower half of the flash gets memory mapped below 4G in the
current setup.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: Iffe5c17a50f3254411a4847c7e635ce0fd282fde
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76499
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch selects LZ4 decompression for logo CBFS file. Able to save
2ms of the boot time when HAVE_FSP_LOGO_SUPPORT config is enabled.
However, the compressed BMP logo size is increased by ~2KB.
Raw BMP Image size is ~97KB.
BUG=b:284799726
TEST=Able to see pre-boot splash screen while booting google/redrix
with 32MB (W25Q256JWEIM) SPI-Flash.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I98e2c9a4f77d0b91f84eda9aec5060b236bd5e94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78121
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Jasper Lake was missing these bases, so attempting to enable an SCI
would poke unrelated registers starting from offset 0. Set them so
GPEs can be enabled.
GPE is used on the Librem 11 for the keyboard dock connector, its sense
signal on GPP_D4 raises a GPE which is used to indicate tablet/laptop
mode to the OS.
The register offsets are documented in the datasheet volume 2 (Intel
document 634545), all groups' GPE_STS/GPE_EN start at the same offsets.
Change-Id: Ib6b9b9a79e9cc4467e609eaf591ec4e87b78d617
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78097
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rather than disabling C State demotions for every single Raptor
Lake board due to an issue with S0ix, regardless of if they even
use S0ix, configure it in the mainboard.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I4f941a549bc717ae2f8ec961ead7ac7668347c99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77087
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Currently the HDA device can neither be disabled using softstraps
nor can it be disabled by using FSP UPDs. Add code to disable it in
coreboot when it's marked as 'off' in coreboot's devicetree.
TEST: Device 00:1f.3 is hidden and platform boots into OS without issue.
Change-Id: Ifa1422d653cf81ee6faf2bdda27a471c2084642b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77873
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On the first boot after flashing, the data read from the FMAP and
stored in vbios_data is not valid, so hashing it produces a value which
will not match on the subsequent boot, requiring an additional boot
before the vbios_data and hash match / before the GOP driver can be
skipped. To fix this, update vbios_data before hashing.
BUG=b:271850970
BRANCH=skyrim
TEST=build/boot google/skyrim with USE_SELECTIVE_GOP_INIT selected,
verify that GOP driver execution is skipping on 2nd boot after flashing
when booting in normal / verified boot mode.
Change-Id: Idc10d752bfa004a34b91307a743c620fb97eeb82
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77727
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This reverts commit 21e61847c4.
Reverting as it breaks booting on google/dedede based boards. First boot
after flashing is successful, 2nd hangs with the following error:
[EMERG] FspMemoryInit returned with error 0x80000003!
TEST=build/boot google/dedede (magpie, metaknight)
Change-Id: I6a2474617b444414c4248dbeda23ed0915704a17
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
cse_store_rw_fw_version() stores CSE RW firmware version in global
variable or cbmem in romstage and ramstage respectively, based on the
stage it is called in. The call to this function is from the
cse_print_boot_partition_info() in cse_get_bp_info.
In the subsequent patches, the idea is to send the cse_get_bp_info early
in romstage and store in cbmem once memory is initialized. So when the
cse_fw_sync is called in early ramstage, the stored cse_bp_info_rsp is
used instead of sending the CSE get boot partition info command again.
To de-link the call to cse_store_rw_fw_version from cse_get_bp_info and
to ensure the CSE RW FW version is stored in all cases, moving the
function to do_cse_fw_sync.
BUG=b:273207144
Change-Id: I0add2c167c85cbddef2ecb4c019061a08562bbdf
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/+/78051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.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.
CSE Lite SKU firmware supports a command to backup PSR data before
initiating a firmware downgrade. PSR data backup command works only
after memory has been initialized. Moving only the downgrade would add
complexity of splitting the cse_fw_sync across pre-RAM and post-RAM
stages. So the idea is to move cse_fw_sync into ramstage when PSR is
enabled.
We are introducing a flow to get CSE boot partition info in early
romstage and then same data will be stored in cbmem once DRAM is
initialized. The CSE BP info data in cbmem will be utilized in early
ramstage to perform cse firmware sync operations. This helps in avoiding
re-sending the CSE get boot partition info command in ramstage. Having
cse_bp_info_rsp as global helps in de-linking cse_get_bp_info from
cse_fw_sync.
Many functions take cse_bp_info as input parameter. Since
cse_bp_info_rsp is global now, we can make use of global cse_bp_info and
remove it as input parameter from those functions.
BUG=b:273207144
TEST=Verify cse_bp_info_rsp holds value across the stage.
Change-Id: I0ee050b49fcae574882378b94329c36a228e6815
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/+/77070
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Hook the newly exposed LowerBasicMemTestSize UPD up so that boards
can configure it via devicetree.
BUG=b:301441204
TEST=Verified by enabling/disabling the UPD on google/rex.
Change-Id: Iec466aeaebd72f222d97f720a85bbb8c27e26325
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78066
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
commit 06cb756f02 ("soc/intel/common/block/cse/Kconfig: Remove
unused symbols") removed these Kconfigs since it's not obvious where
they're used. Add a comment to make it easier to grep for their uses.
Change-Id: I27d94e8a558d6e73004d45cd2aedd94678d29b94
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78041
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 06cb756f02.
Reason for revert: These Kconfigs are needed by boards which use the
CSE stitching tools (i.e. select STITCH_ME_BIN). They're selected by
some boards in the downstream ChromeOS repo. They're used in
src/soc/intel/Makefile.inc (see the line with
`$(CONFIG_CSE_$(2)_FILE)`).
Change-Id: Ide6fc74b457439f06b7ef9b37f11d6c9ff226b80
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76719
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move following definitions to common/
1) the definition of the bit fields for domain remap
2) the definition of the structure for the permission of all domains
Change-Id: Iac84ebc908ae384a6280388af4120f6349a32ed4
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77860
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since all non-CAR AMD SoCs have the same mp_init_cpus implementation,
factor it out and move it to a common location.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibf4fa667106769989c916d941addb1cba38b7f13
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Currently MP2 Firmware is not built into RO firmware section but the
soft fuse bit to disable MP2 firmware loading is not set. This causes
the device to boot loop during recovery mode. Set the bit to disable MP2
firmware loading in RO.
BUG=b:259554520
TEST=Build and boot to OS in Skyrim under both normal and recovery
modes.
Change-Id: I9e4cf4f72e2d36ad3cc33629ddb501ecdbf5eda9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78023
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Hook up the OC watchdog common block and initialize it if requested.
TEST=Enable watchdog on MSI PRO Z690-A and see the platform resets
after some time. Enable the watchdog in driverless mode and see the
platform no longer resets and periodic SMI keeps feeding the watchdog.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I1c2c640d48b7e03ad8cd8d6cdf6aac447e93cd86
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68945
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reduce the OC WDT integration code footprint by consolidating
multiple API calls into a single function to be called by SoC.
Change-Id: Iba031cd8e0b72cabc4d0d8a216273d763231c889
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77574
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Certain Intel Meteor Lake specific features are only enabled in
production silicon (not available in early SoC aka pre-production
silicon).
- SPI usage for production SoC is much optimized compared to pre-
production silicon.
- MIPI driver requires a way to identify between pre-prod vs prod
silicon.
This patch adds config options to select the Pre-Production
aka Engineering Silicon (ES). The mainboard users can specify which
underlying SoC is being used for the target platform.
BUG=b:300652989
TEST=No change in the functionality, just added new configs.
Change-Id: I60fe11c1151a3a6c290cd0105eb570cb78e81797
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Add the eMMC MMIO device to the devicetree and make it use the common
AMD eMMC driver. Since there is now a device for this in the devicetree,
also use this device to determine if the FSP should be told if the eMMC
controller is supposed to be disabled.
TEST=On Mandolin the eMMC controller both disappears in the Windows 10
device manager and in dmesg on Ubuntu 2022.04 LTS
TEST=Morphius with NVMe SSD still works
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5453b69df776d2ce1f3be11e37cd26c8c64f0cd5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
When the eMMC MMIO device is enabled in the devicetree, it needs to be
exposed in ACPI in order for the OS driver to be able to attach to it.
The Cezanne eMMC controller isn't used in google/guybrush, so this the
code path where the eMMC MMIO device is enabled in the devicetree can't
be easily tested.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I69ff79b2d1c6a08cf333a2bb3996931962c2c102
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Add a separate Kconfig option for adding np_region.c to the build. Only
the code for Picasso, Cezanne, Mendocino, Phoenix and Glinda call
data_fabric_set_mmio_np which is implemented in that file, so only
select the new SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig option
for those.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic49ce039462b52e2c593c7d2fef43efc50901905
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77987
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make naming convention consistent across all functions return values.
BUG=b:296439237
TEST=Boot to OS on Skyrim
BRANCH=None
Change-Id: If86805b39048800276ab90b7687644ec2a0d4bee
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77536
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Factor out data_fabric_set_mmio_np and the helper functions it uses into
a separate compilation unit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I58625c5a038f668f8e30ae29f03402e1e2c4bee3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Use data_fabric_get_mmio_base_size in data_fabric_print_mmio_conf
instead of open coding the functionality. This will fix the printing of
the MMIO config in the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO
case which wasn't handled properly before.
TEST=Console output from this function doesn't change on Mandolin:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 0 ffff 90 9
4 fed00000 fed0ffff 93 x x 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If602922648deca0caef23a9999c82acdd128b182
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
data_fabric_disable_mmio_reg and data_fabric_find_unused_mmio_reg are
only used by data_fabric_set_mmio_np in the same file, so make them
static and drop the prototype from the header file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6bf7a868aae2fd01b8adecd3e4cba6ff6d5119af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Added Raptor Lake U graphics device ids.
Renamed Raptor Lake U graphics device ids that were marked as
Raptor Lake P.
Added Raptor Lake P graphics device ids.
References:
RaptorLake External Design Specification Volume 1 (640555)
TEST=Boot to OS
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I44734f927764f872b89e3805a47d16c1ffa28865
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77898
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cpu_cl_cleanup() function checks if the SOC supports storage-off
feature. This feature allows to turn off PUNIT SSRAM to save power.
Enable the storage-off if it's supported. Enabling it also clears the
crashlog records from PUNIT SSRAM.
cpu_cl_rearm() function rearms the CPU crashlog.
BUG=b:262501347
TEST=Able to build google/rex. Verified both features get asserted.
Change-Id: Id9ba0f5db0b5d2bd57a7a21f178ef1e86ca63fae
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77239
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add more details in CPU crashlog header structure, such as
storage off status and support, re-arm status etc. These fields
are used to check of particular feature is supported or not and
if supported what is the status of the feature.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: I4242b6043b8f8ad9212780f44ca0448cd2b6b9f8
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77562
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Not all SOC follow the same programming to clear crashlog
data. So make common implementation of cpu_cl_clear_data()
weak.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: Ic2b4631d57703abff0ab1880fb272ef67bb1b8e9
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
relanding original commit 5013c60a87
("soc/intel/meteorlake: Generate new TME key on each warm boot") which was previously reverted by commit 19e66b7c95
(Revert "soc/intel/meteorlake: Generate new TME key on each warm boot")
due to consecutive reboot post warm reset issue.
The consecutive reboot post warm reboot issue has been fixed with
commit ba7a9eefcf ("soc/intel/common: Fix
invalid MADT entries creation"), hence, reattempting to land the original TME key related patch.
BUG=299294328
TEST=Boot up the system, generate kernel crash using following
commands:
$ echo 1 > /proc/sys/kernel/sysrq
$ echo "c" > /proc/sysrq-trigger
System performs warm boot automatically. Once it is booted,
execute following commands in linux console of the DUT and confirm
ramoops can be read.
$ cat /sys/fs/pstore/console-ramoops-0
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I5d45d265ccef1a7d37669ea22a74b52e2f3ae20d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC is added to mipi camera
driver to extend the same support for all SoCs, so removing this config
from Alderlake SoC code.
BUG=None
TEST=Build rex and brya to check if the build passes without an
error.
Change-Id: I5bc23fce89f0ae22b64b90cb12621320cac30d85
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Move the existing FSP 4221.00 headers for Raptor Lake to a
subdirectory called 4221.00_google, and select this if the
vendor is Google.
Add the standard FSP 4301.01 headers to a separate directory,
from Intel download #686654, and select this for all other
vendors.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Icd99bdee1eeac70dfcaca3d07150d3de6bb83d81
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77101
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
BUG=b:264960828
TEST=On dibbi, ACPI tables contain entries for USB 3.4 and 3.5
Change-Id: If3266d356a2deaf42aa0943f85593416d80637ad
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77866
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The PMC and P2SB IDs for Raptor Lake-S PCH were missing. Add them based
on doc 619362 rev 2.2.
Change-Id: I5de00adf2d87cf50571abb02b28e7feebdc3911e
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77448
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch addresses the increased boot time issue that occurs when ISH
store is enabled, such as in the "rex4es_ec_ish" variant.
During a cold reboot, the CBMEM memory resets and loses the stored
firmware versions. This causes the firmware versions to be fetched again
from the CSE, which increases the boot time by about 200 ms. This patch
stores a backup of the firmware version in CMOS and updates the CBMEM
memory during a cold reboot.
BUG=b:280722061
Test=Verified the changes on rex board.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ibc5a027aa2bb7217e5032f56fece0846783557a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75755
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements APIs to access the CSE FW partition versions in
CMOS. The get API allows users to retrieve the current version from
CMOS memory. The set API allows users to set the version in CMOS
memory.
BUG=b:280722061
TEST=APIs verified on rex board.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Idd0ee19575683691c0a82a291e1fd3b2ffb11786
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74995
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Remove the check to follow the new flow that commit 9c348a7b7e
("soc/intel/alderlake: Fix processor hang while plug unplug of
TBT device") introduced.
Processor hang is observed while hot plug unplug of TBT device. BIOS
should execute TBT PCIe RP RTD3 flow based on the value of
TBT_DMA_CFG_VS_CAP_9[30]. It should skip TBT PCIe RP RTD3 flow, if
BIT30 in TBT FW version is not set.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ie822b8e1fd7592a31275db8455519c4cc6ac02ad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The memory log we get returned by QcLib contains Windows line endings
("\r\n"), while we prefer to have POSIX line endings in the CBMEM
console (just "\n"). Filter the '\r' character out when copying that log
into the CBMEM console to convert.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0652300c2393fbc0b3c9875bb0ca1aa921e59098
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77722
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When using Intel(R) Xeon(R) Platinum 8490H on IBM/SBP1 the platform runs
with 480 cores. With 480 cores coreboot needs at least 440KiB for ACPI
tables. Bump the config to 512 KiB to have some free space for future
changes.
Change-Id: I2c0bbc36f45aab921f3189459de4438a0cd5dd1f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
When CSE jumps between RO and RW, it triggers global reset so the
AP goes down to S5 and back to S0. For Chromebox, when AP goes
down to S5 EC set AP_IDLE flag. This cause an issue to warm reset
the Chromebox device when it is in recovery mode and powered by
USB-C adapter. This patch allows AP to direct EC to clear AP_IDLE
flag before trigger reset.
BUG=b:296173534
BRANCH=firmware-dedede-136-6.B
TEST=Chromebox DUT which is powered by USB-C adapter boots up
after warm reset in recovery mode
Change-Id: Ib0002c1b8313c6f25d2b8767c60639aed8a4f904
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77632
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
The ACPI used for Tiger Lake, Alder Lake and Meteor Lake are very
similar, so can be moved to shared code.
This commit aligns minor difference between then, such as comments and
tabs/spaces.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: If6554c7ef9e83740d7ec5dcca6a9d7e32fb182db
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77453
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The EFS data structure diagrams in the Makefiles of Picasso and newer
SoCs were wrong, since the BIOS directory table pointer is in a
different location than shown in the diagram. Since the diagram also
wasn't that easy to understand and amdfwtool does all of that handling,
drop the wrong diagram from the Makefiles.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5f86fea29f956ff10746d35dbe967a4a89e11cca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
commit f8ac3dda02 ("soc/intel/common:
Order the CPUs based on their APIC IDs") sort algorithnm walks all the
`cpu_info' entries without discarding empty ones. Since `cpu_info' is
not initialized, the data that is used is undefined and it generally
results in the creation of invalid `Local x2APIC' entries in the
MADT ("APIC") ACPI table.
Depending on the X2APIC ID value the Linux kernel behavior
changes (cf. arch/x86/kernel/acpi/boot.c::acpi_register_lapic()):
1. If (int)ID >= MAX_LOCAL_APIC (32768), the Linux kernel discards the
entry with the "skipped apicid that is too big" INFO level
message.
2. If (int)ID < MAX_LOCAL_APIC (32768) (including negative) this data
is taken into account and it can lead to undesirable behavior such
as core being disabled as (cf. "native_cpu_up: bad cpu" ERROR
kernel message).
TEST=Verified the MADT does not contain any invalid entries on rex.
Change-Id: I19c7aa51f232bf48201bd6d28f108e9120a21f7e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77615
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
It makes the detection of this feature accessible without the
CONFIG_SOC_INTEL_COMMON_BLOCK_CPU dependency.
BUG=288978352
TEST=compilation
Change-Id: I005c4953648ac9a90af23818b251efbfd2c04043
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77697
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the LidStatus UPD is passed a dynamic value,
rather than always passing 1 (CONFIG_RUN_FSP_GOP enabled) for FSP 2.0
devices.
Problem statement:
* FSP-S GFX PEIM initializes the on-board display (eDP) even when the
LID is physically closed, because LidStatus is always set to 1.
* FSP-S skips external display initialization even when the LID is
closed.
Solution:
* FSP-S GFX PEIM module understands the presence of an external display
if LidStatus is not set, and tries to probe the other display
endpoint.
* Statically passing LidStatus as always enabled (aka 1) does not
illustrate the exact device scenarios, so this patch updates
LidStatus dynamically by reading the EC memory map offset.
BUG=b:299137940
TEST=Able to build and boot google/rex to redirect the display
using external HDMI monitor while LID is closed.
Change-Id: I7d7b678227a6c8e32114de069af8455b8c1aa058
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Instead of reporting all I2C controllers in the system as enabled in the
corresponding ACPI device's _STA method, report the I2C devices that are
disabled in the devicetree as disabled in the corresponding _STA method
too. This is done by returning the contents of the STAT variable inside
each device's scope in the DSDT that have a default value of 0 (device
not present/disabled). For all enabled and hidden I2C devices
i2c_acpi_fill_ssdt gets called which then writes 0xf (device enabled and
visible) or 0xb (device enabled, but hidden) to the STAT name inside the
same scope, but in the SSDT. This object in the SSDT will then override
the default in the DSDT resulting in the _STA method returning the
correct status of each device. The code was inspired by
commit 7cf9c74518 ("soc/amd/*: Fix UART ACPI device status").
TEST=On Mandolin all I2C controllers are disabled and with this patch
none shows up in the Windows 10 device manager. When enabling an I2C
controller in the devicetree for testing, it shows up again in the
Windows device manager.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4cd9f447ded3a7f0b092218410c89767ec517417
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Per the PSP team, this field in the transfer buffer isn't used anymore
and always set to zero, causing devices to incorrectly report having
pre-production silicon.
Change-Id: Ida4bf4b9328ac83d905e4c3f822e6ceabe9be79d
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77630
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
We don't have file for the fuse chain, but we need to set the level
for some cases.
Change-Id: Idb546f761ae10b0d19a9879a9a644b788828d523
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Specify the default path to, and automatically include the FSP binaries
needed to boot a board if USE_AMD_BLOBS is selected. Simplifies board
configs, and matches use in previous patforms.
TEST=build/boot google/skyrim
Change-Id: Ic837d264327723c8dc18a60fb16e8d41fe38b44e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77625
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Automatically include the FSP binaries needed to boot a board if
USE_AMD_BLOBS is selected. Simplifies board configs, and matches
use in soc/amd/picasso.
TEST=build/boot google/guybrush
Change-Id: I5b6e34085410a2aafe5d7876be5097f28f521ce8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77624
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch renames `SAVE_MRC_AFTER_FSPS` config to
`FSP_NVS_DATA_POST_SILICON_INIT` to highlight the violation in the Xeon
SP FSP implementation, where the FSP Silicon Init API produces
Non-Volatile Storage (NVS) instead of the FSP-Memory Init API.
According to the FSP 2.x specification (section 11.3), the FSP
populates the NVS data using the FSP_NON_VOLATILE_STORAGE_HOB and
expects the boot firmware to parse the FSP_NON_VOLATILE_STORAGE_HOB
after the FspMemoryInit() API in API mode.
However, not all Intel SoC platforms that support the FSP 2.x
specification adhere to this requirement. For example, the FSP binary
for XEON SP platform produces NVS data (aka
FSP_NON_VOLATILE_STORAGE_HOB) after the FspSiliconInit() API.
Therefore, attempting to locate NVS data after the FspMemoryInit() API
on these platforms would result in an error. The `save_mrc_data.c`
implementation provides the required hooks to locate the NVS post
FSP-Silicon Init and store into Non-Volatile Storage.
BUG=b:296704537
TEST=Able to build and boot Intel Xeon SP w/o any functional impact.
Change-Id: I815a64263fa1415bfe30bb3c1c35e4adee307e86
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This patch ensures that the VR configuration for IA, SA, and GFX is
properly initialized, assigning zero values to VR causes a black screen
(no display) issue.
Problem Statement:
Override CEP (Current Excursion Protection) value with zero aka set to
disable results into black screen issue (no display).
Solution:
Keep CEP default enabled and don't override w/ zero value.
w/o this patch:
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[0] : 0x0
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[1] : 0x0
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[2] : 0x0
w/ this patch:
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[0] : 0x1
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[1] : 0x1
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[2] : 0x1
Change-Id: I8908e8b6c995390b559212d456db6ddf984448a3
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
All of the SoCs in the cannonlake directory select the following
options. So move them to the common option SOC_INTEL_CANNONLAKE_BASE
in order to deduplicate selections.
* FSP_USES_CB_STACK
* HAVE_INTEL_FSP_REPO
* SOC_INTEL_CONFIGURE_DDI_A_4_LANES
Change-Id: I6ce5edb2ba2c138b44601b32c3ecba2e761136f7
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77447
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Intel Cannon Lake was removed with commit d456f65056. Thus, remove this
dead code.
Change-Id: I53cd9d53b01e26f530684aa9c404f50b305c1f54
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77446
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Allows boards which enable the GNA device to provide an attachment
point for the OS drivers.
TEST=tested with rest of patch train
Change-Id: I3398eefb80e4407594883dd39128cd7885105ac3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77528
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Remove MAILBOX word from CPU_CRASHLOG_MAILBOX_WAIT_STALL
and CPU_CRASHLOG_MAILBOX_WAIT_TIMEOUT macros, because they
can be used for other interface as well.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: I62b04fa4b05c427db494a536ca6504db02dfeb68
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77236
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Region with metadata tag contains information about BDF entry for
SOC PMC SRAM and IOE SRAM. We don't need to parse this as we already
define BDFs in soc/pci_devs.h for these SRAMs. Also we need to skip
to region as it does not contain any crashlog data.
BUG=b:262501347
TEST=Able to build google/rex. Able to trigger crashlog and decode
correctly.
Change-Id: Id8ed40b865cde8e89045f5c9e713398fcbff5890
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76834
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When parsing descriptor table the record can have tag type = 7.
This tag contains metadata depending on SOC. The platform may
choose to parse it based on implementation of crashlog.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: I60dda06950974f7949fa5635141e4b7798c4d1f2
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
CPU crashlog discovery table and crashlog record is considered
invalid if first 32bits of the table is either 0x0 (no crashlog)
or 0xdeadbeef (invalid crashlog).
Crashlog record is considered consumed if bit 31 is set. So in this
case stop processing the subsequent records.
BUG=b:289600699
TEST=Able to build and verified invalid records are skipped on
google/rex.
Change-Id: Ia81bd293a533217425e44473ae85b2115c85faf6
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76333
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a dummy soc (genoa) based on EXAMPLE_MIN86 with
amd linker script hooked up.
Default to 64bit code as that will be a sensible default for this
platform (high memory access required for RAS setup).
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I69253466084d17c4359d7e824d69f12490b076e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76495
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Older FSP releases don't have an option to do MP init via PPI, so it
should not be visible.
Change-Id: I74b4bd5dd72980b859763e89ead7d7f619321e66
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63759
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The amdfw.rom is mostly in region COREBOOT. Calculate the relative
address as the CBFS module address. That is for future 32M flash size
support.
TEST=binary identical test on amd/birman amd/majolica amd/gardenia
amd/mayan amd/bilby amd/mandolin amd/chausie amd/pademelon
pcengines/apu2
google/skyrim google/guybrush google/zork google/kahlee google/myst
This commit is part of a series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: I2add8e4e6755e582b3be6a150cf83d1468f2f1be
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72961
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It is based on work by Arthur Heymans, 69852.
Get rid of the confusing "position index" and use the relative flash
offset as the Kconfig setting instead.
TEST=binary identical on amd/birman amd/majolica amd/gardenia
amd/mayan amd/bilby amd/mandolin amd/chausie amd/pademelon
pcengines/apu2
google/skyrim google/guybrush google/zork google/kahlee google/myst
(The test should be done with INCLUDE_CONFIG_FILE=n)
Change-Id: I26bde0b7c70efe9f5762109f431329ea7f95b7f2
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The Genoa SoC supports MMIO addresses larger than 48 bits. Since the
MMIO base and limit registers in the data fabric only contain bits 16 to
47 of the MMIO address, the MMIO address extension register is
introduced on some SoCs like Genoa. This additional register contains
the upper bits of the MMIO base and limit. Since it's not available on
all SoCs, introduce the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO
Kconfig option to select the correct data_fabric_get_mmio_base_size
implementation to be added to the build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic304f5797bc5661c1d511c95e457c6dde169d329
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77514
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
This patch adds option to override Fast Vmode on Meteor Lake SoC.
This requires CepEnable, EnableFastVmode, IccLimit FSPM UPDs in FSP
header. If the hardware supports Fast Vmode, the FSPM will set the
ICC limit value to the value passed from coreboot.
With CepEnable and EnableFastVmode enabled, if IccLimit is not
specified by coreboot, FSPM sets IccLimit as default value. If no
values assigned to all the three CepEnable, EnableFastVmode and
IccLimit, coreboot sets their values to 0 and Fast Vmode is disabled.
BUG=b:286809233
TEST=In debug MTL FSP logs, the value of FSP parameters is as passed
from coreboot including enable_fast_vmode, cep_enable, and
fast_vmode_i_trip. Also, fast_vmode_i_trip value is passed to pcode
using mailbox command without any error. This test done on google/rex
board.
Signed-off-by: Jay Patel <jay2.patel@intel.com>
Change-Id: Id05dccac56c504523f9327babe0c6fbeff488ec2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75566
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
The !CONFIG_SOC_AMD_COMMON_BLOCK_APOB_NV_DISABLE comment was likely a
copy-paste leftover, so remove it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I45b12d1dc5af84be99d54fea0c9ccf610cf5dae3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77513
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This reverts commit 5013c60a87.
Reason for revert: consecutive reboots are causing kernel panic.
BUG=b:297153853
TEST=Able to perform 50 cycles of consecutive reboot after reverting
this CL and it boots to the OS every single time(w/o any kernel panic).
Change-Id: If6c96dcc62c706a522b98a1cf1dd1920ad6473a1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77467
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The psp_transfer.h file was the same under all SoCs, and is really
tied to the file common/vboot/transfer.c, not the SOC.
This patch makes an include directory under vboot to put the header into
and sets it to be included for all SoCs using SOC_AMD_COMMON. This makes
the header file available to all platforms, so that new chips that don't
use the psp_verstage don't have to make a psp_transfer.h file just to
satisfy the compiler.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5b9f2adee3a1d4d8d32813ec0a850344b7d717b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77303
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new block for handling overclocking watchdog. The watchdog is
present since Skylake or maybe even earlier so it is safe to use with
most of the microarchitectures utilizing intelblocks.
The patch adds the common block for initializing and feeding the
watchdog. Timeout is defined statically in Kconfig and should be set
high enough by the board or SoC Kconfig to let the board boot with
full memory training and avoid reset loops. Full training of 128GB
DDR5 DIMM memory on AlderLake takes about 5 minutes. Newer SoCs
with newer memory technologies and higher RAM capacity may take more.
The default has been set to 10 minutes.
The patch also adds support for feeding watchdog in driverless mode,
i.e. it utilizies periodic SMI to reload the timeout value and restart
the watchdog timer. This is optional and selectable by Kconfig option
as well. If the option is not enabled, payload and/or software must
ensure to keep feeding the watchdog, otherwise the platform will
reset.
TEST=Enable watchdog on MSI PRO Z690-A and see the platform resets
after some time. Enable the watchdog in driverless mode and see the
platform no longer resets and periodic SMI keeps feeding the watchdog.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ib494aa0c7581351abca8b496fc5895b2c7cbc5bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68944
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `use_8254` should be flipped, the same as the other Intel
SOCs.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I2d6c859c0910b796d2ae5874a560ff9974578106
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
