Currently the SPI ROM is mapped completely when the boot device is
initialized. That mapping remains active throughout the execution time
of PSP verstage. Every 1 MiB of mapped SPI ROM region consumes 1 TLB
Slot in PSP for use during memory mapped or DMA access. With 16 MiB of
mapped SPI ROM + FCH devices + 4 reserved TLB slots, 31 out of 32 total
TLB slots is consumed. This leaves almost no scope for future expansion.
With upcoming programs possibly using 32 MiB SPI ROM, PSP will run out
of TLB slots to support 32 MiB.
Hence instead of mapping the entire SPI ROM upfront, get the SPI ROM SMN
address during the boot device initialization. Update the boot device
region operations to map and unmap the SPI flash with the desired offset
and size using the SVC call. Then anytime a memory mapped SPI ROM access
is performed: map the required area, read the data and immediately unmap
the area. There is no update required when using CCP DMA, since the
concerned SVC call performs mapping and unmapping of the required SPI
flash area implicitly.
With these changes, maximum of 8 slots(size of RO section) might get
used at any point in time during the PSP verstage execution.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim. Perform cold, warm reboots and
suspend/resume cycles for 50 iterations each. Ensured that there is no
impact to boot time.
Change-Id: Icd44ea7b2a366e9269debcab4186d1fc71651db2
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74606
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently unsigned PSP verstage binary is copied from ELF file only when
required in amdfw*.rom. If a signed PSP verstage binary is supplied
while building amdfw*.rom, then it is dropped. Copy the unsigned PSP
verstage binary always so that it can be used for signing directly from
the CI build infrastructure instead of a locally built binary.
BUG=None
TEST=Build Skyrim BIOS image and ensure that the unsigned PSP verstage
is part of the build artifacts.
Change-Id: If797dcfd20aa2991f3517904ef862406b9b9875c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75334
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>
Show an error if an option table is used, and the ramtop entry is not
defined on a platform that uses it.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ie48f0766b29be8e1fb0c1f71c4b2ce6ed20e6207
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74920
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch adds an API to check FSP reset pending requests. This
information is useful to understand if FSP would like boot firmware to
issue any reset to complete the silicon initialization.
As per recent debug it has been found that, FSP is accumulating all
platform resets and executing a single reset from FSP Notify Phase.
As coreboot skipped calling into the FSP Notify APIs hence, it might
have missed the scope to issue the platform reset.
BUG=b:282266168
TEST=Able to build and boot google/rex and able to detect FSP reset
pending request.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ibf7c996f09affa099c9124773fe2d581f370d1a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75310
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
As announced in the 4.20 release notes, support for the Intel Quark SoC
is moved to the 4.20 branch and dropped from master.
Change-Id: I8a1ca7a2092aaeaea9c72eac5a8dd8f7d72e8f09
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The `ramtop_table` is 10 bytes long, so adjust the check to
account for this.
Also, adjust the wording to make it clear what is required to fix it,
should the error be shown.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: If2898c4bb22abb1779035aadc08f32898e9a096b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Enable PSYS capability. PSYS is required to safeguard the system
stability if no charger IC.
BUG=b:281479111
TEST=emerge-dedede coreboot chromeos-bootimage & ensure the value is
passed to FSP by enabling FSP log & Boot into the OS
Change-Id: Ibe54acaf80700252558b82f194b9536b6117b84e
Signed-off-by: Chia-Ling Hou <chia-ling.hou@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75196
Reviewed-by: Reka Norman <rekanorman@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add igd device name in soc_acpi_name(), and src/drivers/gfx/generic
can generate device in GFX0 scope in SSDT.
BUG=b:277629750
TEST=emerge-rex coreboot then check SSDT on DUT
Signed-off-by: Won Chung <wonchung@google.com>
Change-Id: Id7a136b5234cf5c0f60ecf253ee78c123f1f573b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75274
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch drops the assert check around
`FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN` config to ensure
`fsp_get_pch_reset_status()` can be used by all other FSP APIs to know
the status of the pending reset.
As per recent debug it has been found that, FSP is accumulating all
platform resets and executing a single reset from FSP Notify Phase.
As coreboot skipped calling into the FSP Notify APIs hence, it might
have missed the scope to issue the platform reset.
Going forward coreboot needs to implement the corresponding logic to be
able to identify any pending platform reset request and execute to
complete the silicon initialization flow.
BUG=b:282266168
TEST=Able to build and boot google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2c9e37fadc27eab820a3121e47e09529de34d10e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75309
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The `ramtop` can be obtained from the `option.h`, so remove the
hardcoded value. Keep the check for the value being byte aligned.
Change-Id: I5327b5d4e78b715a85072e5d9a62cf8fd2ae92c0
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74511
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch overrides FSP-S UPD `LogoPtr/LogoSize` with a valid
logo.bmp file if `BMP_LOGO` config is enabled.
TEST=Able to see splash screen while booting google/marasov
with BMP_LOGO config enable.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I421da2b4dadb892f17a859ce0ec586a2880469eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75294
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch overrides FSP-S UPD `LogoPtr/LogoSize` with a valid
logo.bmp file if `BMP_LOGO` config is enabled.
TEST=Able to see splash screen while booting Intel Meteor Lake RVP
with BMP_LOGO config enable.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iaba187456dd4dfb2f69d3532e83a3850f31783ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75198
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Both the AMD AGESA reference code and the default coreboot
ACPI_CPU_STRING use hexadecimal numbers in the ACPI CPU object names, so
change the ACPI_CPU_STRING format string in the both the Stoneyridge
Kconfig and the common non-CAR AMD SoC config Kconfig which covers all
other AMD SoCs in soc/amd. All platforms where the P state and C state
SSDT from binaryPI (Stoneyridge) or FSP (Picasso) was used in coreboot
before it got replaced by native code, had at most 8 cores/threads, so
the mismatch never became apparent.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9d6822c5df01786ee541ce90734b75ed1a761fca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75250
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set the default soft fuse bits to the recommended values
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I2354aefe90a08eaef95a68926806d11a9118c3de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In ACPI 1.0 the processor objects were inside the \_PR scope, but since
ACPI 2.0 the \_SB scope can be used for that. Outside of coreboot some
firmwares still used the \_PR scope for a while for legacy ACPI 1.0 OS
compatibility, but apart from that the \_PR scope is deprecated.
coreboot already uses the \_SB scope for the processor devices
everywhere, so move the \_SB scope out of the ACPI_CPU_STRING to the
format string inside the 3 snprintf statements that use the
ACPI_CPU_STRING.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: I76f18594a3a623b437a163c270547d3e9618c31a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Don't set bit 2 of the return value of the _STA method in order for
Windows not to show a warning about an unknown device in the device
manager for this device.
TEST=The unknown device with device instance path ACPI\AMD0040\3
disappeared from the device manager in Windows 10 build 19045 on a
Mandolin board with a Picasso APU.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If005f06843956004c281fd70cf364171148cb9ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68962
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 396fb3db74 ("soc/amd/*/acpi/mmio.asl,sb_fch.asl: hide AAHB
device") didn't only change the visibility of the device, but also
changed the _STA method to a name. While this worked, the specification
says that _STA is supposed to be a method, so change it back to being a
method.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id0932b2875aaf563a4dbd860bdd11a04272e3780
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75169
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch defines enum type for MKHI group IDs and ME SKU types instead
of macros.
TEST=Build code for Rex
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I102e802938a6a664a43a362d90a26755cff8f316
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Harsha B R <harsha.b.r@intel.com>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Having `_cmos_offset` in a CMOS offset is superfluous; remove it
so the CMOS entry is just `ramtop`.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ibc1e7d78d2e3ae04330d19e64c3437ff07060ea8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74516
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
In GEN_PMCON1 (Offset 1020h), Bit 0 is the "After G3 Enable" (ag3e)
(source Intel document #569262). Only use 8 bits, in the same way as
most other Intel SOCs do, for pmc_soc_set_afterg3_en.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Idb290d1480b03cb3425edc6ff29b9c78a6545df1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74955
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The return value of cse_get_bp_info() is an enum integer, where zero
means success and non-zero means failure. The function
store_cse_rw_fw_version() calls the function cse_get_bp_info() and
validates the return value as a boolean causing prematurely returns of
the parent API even if cse_get_bp_info() is successful.
This patch corrects this logical error by returning only if
cse_get_bp_info() fails.
TEST=Build and boot google/nivviks and verify that the ISH version info
command is only being sent during cold boot.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ice278e5ac69ff2f2c9f1936b76d71ae9deb6f855
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74998
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
If the ME is disabled with the `me_state` CMOS setting, boot
times are approximately 5 seconds longer:
942:before sending EOP to ME 1,240,773 (5,599)
943:after sending EOP to ME 6,263,951 (5,023,177)
Total Time: 6,167,443
This is because the current code only checks if the ME is
disabled for CSE LITE SKUs. With this patch, boot times are
approximately 5 seconds quicker:
Total Time: 1,143,932
Tested on `starbook/adl` and `starbook/tgl`.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I182f30d4fbf43955747c6a7a0b284a43f9c5e4ef
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74435
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This fixes an issue where pcie was not power gating and blocked
S0ix entry. Overwrite pcie max non-snoop and snoop latency tolerance
values to 15.73ms as stated in doc #729123 - MTL External Design
Specification.
BUG=none
TEST=Boot google/rex, print/check values.
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.corp-partner.google.com>
Change-Id: I9dfb9edbac95d28d50653777466ea172be64f612
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68308
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Intel SoC Meteor Lake requires a higher pcie max non-snoop and
snoop latency tolerance. Add config to let SoC overwrite the common
code settings if needed.
BUG=none
TEST=Boot google/rex and print/check if able to overwrite values.
Change-Id: Ic2b9a158d219e6c6e7f6e7f0ae0f093c1183b402
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74141
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Intel's EHL FSP offers the possibility to select the connected hard
drive type to SATA ports. One has the option to choose between HDD ('0'
- default) and SSD ('1').
This patch provides a chip config so that this FSP parameter can be set
as needed in the devicetree on mainboard level.
Change-Id: Idb03aff5b6c5df592b47e2f4abe4fe58ac7151ba
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74946
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Assigning duty_offset while duty_width==0 has no purpose.
Under intel/common/block, previous assignment for fadt->gpe0_blk
resolves GPE0_STS(0) from xeon_sp/ebg/.../soc_pm.h and also assigns
value matching pmbase + 0x60.
Change-Id: Iaf688d9471ac527ac20307cf16216abdab731a06
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74827
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
FSP-M is normally memmapped and then decompressed. The SPI DMA
controller can actually read faster than mmap. So by reading the
contents into a buffer and then decompressing we reduce boot time.
It is interesting that FSP-M takes an additional 8ms to execute. I
suspect since we call it 50ms earlier it's having to wait for one of
its dependencies.
BUG=b:179699789
TEST=Boot guybrush and see 30ms reduction in boot time
| 970 - loading FSP-M | 0.316 | 0.997 Δ( 0.68, 0.05%) |
| 17 - starting LZ4 decompress (ignore for x86) | 0.026 | 13.874 Δ( 13.85, 0.96%) |
| 18 - finished LZ4 decompress (ignore for x86) | 64.361 | 0.337 Δ(-64.02, -4.43%) |
| 2 - before RAM initialization | 0.534 | 0.529 Δ( -0.01, -0.00%) |
| 950 - calling FspMemoryInit | 1.455 | 1.132 Δ( -0.32, -0.02%) |
| 951 - returning from FspMemoryInit | 207.695 | 216.537 Δ( 8.84, 0.61%) |
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I850b1576501753a355e7b23745e04802a0560387
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Beware that there's no XHCI2 controller and the USB4 controller device
pointers were added right after the xhci_0 and xhci_1 controller device
pointers.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I14725d4b546ffcca42e21bbe7756babaaff8fea3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74658
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
For early Sign of Life to work, we may need certain pin configurations
very early in boot (e.g. HDMI). This may happen before romstage GPIOs
are configured, and bootblock is not suitable for field upgrading
existing devices. Add a separate GPIO table that can be configured
when early graphics is invoked.
BUG=b:277861633
BRANCH=firmware-brya-14505.B
TEST=Builds and SoL functions on HDMI enabled variants
Change-Id: I7b3ce96a4166451e72aa70b3086eff3fb8b082b7
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Return 0xf from PCI0 _STA method so that bit 2 is set which indicates
that the device should be shown in the user interface. This ports commit
c259d71928 ("soc/amd/stoney/acpi: Unhide PCI0 root device from OS")
forward from Stoneyridge to the newer AMD SoCs.
TEST=On Mandolin the PCI Express Root Complex now shows up in the device
manager on Windows 10 and when switching the view to 'devices by
connection', all PCI(e) devices are shown below it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4155556dc5df8f163fe06aa6719fadbb2684cc19
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74949
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the PRERAM_CBMEM_CONSOLE_SIZE and
CONSOLE_CBMEM_BUFFER_SIZE hold a larger cbmem buffer size to contain
the entire FSP debug serial log.
The existing implementation was not appropriate, where the larger cbmem
size was even applicable for serial AP firmware (w/o FSP debug) image
as well.
This change is necessary to ensure that the FSP debug serial log is
always available, even in cases where the cbmem buffer size is
limited.
BUG=b:280481298
TEST=Able to build and boot google/rex with non-FSP serial AP image
and with FSP serial AP image. Able to see the AP log completely inside
the cbmem.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib35780fd558c8b6d9aa2e17241131ea4a58c2b9c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75030
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch makes CSE sync in romstage default enabled unless ramstage
config (SOC_INTEL_CSE_LITE_SYNC_IN_RAMSTAGE) chooses to override it.
TEST=Able to build google/marasov with this change where CSE sync is
performed early inside romstage.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I3f5017fbcf917201eaf8233089050bd31c3d1917
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74805
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Adjust a few things so that the sleepstates.asl file is the same for
sb/amd and soc/amd. These adjustments don't have a functional impact.
Change-Id: I0cc9462b326cdc371ffdbf5759d8adc42456ce74
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74960
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit cbc5d3f34b ("soc/intel: Don't
report _S1 state when unsupported") added the `ACPI_S1_NOT_SUPPORTED`
option and commit 0eb5974def ("acpigen:
Add a runtime method to override exposed _Sx sleep states") added a
mechanism to override the enabled sleep states at runtime. However,
these were only hooked up to Intel sleepstates. so the options would
not have any effect on AMD platforms.
Apply the changes from these two commits to AMD sleepstates so that
both options can be used on AMD platforms as well.
Change-Id: I7d5ef2361e36659ac5c6f54b2c236d48713a07c9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74959
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The commit a0b199c6b4 ("soc/intel/xeon_sp/spr: Add soc
set_cmos_mrc_cold_boot_flag") introduced a copy-paste issue in two error
messages. The error messages should mention the Intel platform SPR
instead of CPX. Fix that.
Change-Id: I4de61ec2cf9fbd98263a7a7a588938d548148656
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74956
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Now that we don't need to find a specific resource in the set resources
function any more, there's no need to use hard-coded indices for the
fixed resources. Instead use an index variable that gets incremented
after each fixed resource got added. The index now starts at 0 instead
of at 1, but now the only requirement is that those indices are unique.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ida5f1f001c622da2e31474b62832782f5f303a32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74849
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Drop the custom lpc_set_resources implementation that does some register
access that has no effect and then calls pci_dev_set_resources and use
pci_dev_set_resources for set_resources in amd_lpc_ops instead.
The SPI controller's base address got configured early in boot in the
lpc_set_spibase call and the enable bits got set early in boot in the
lpc_enable_spi_rom call.
TEST=The contents of the SPI_BASE_ADDRESS_REGISTER at the beginning and
at the end of the call stay the same, so it's simply a no-op.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7a5e3e00b2e38eeb3e9dae6d6c83d11ef925ce22
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74848
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The memory map granularity for those devices is 4kByte.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8806128bdce8988f5cd7c8fa8a342fdb01eb7f42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since the 16MByte of memory-mapped SPI flash region right below the 4GB
boundary is both a fixed region and isn't decoded on a device below the
LPC device, but assumed to be decoded by the LPC device itself, it
shouldn't be reported as a subtractive resource, but as an MMIO resource
instead.
TEST=On mandolin the 16MByte MMIO-mapped SPI flash now show up as a
reserved region in the e820 memory map which wasn't the case before:
13. 00000000ff000000-00000000ffffffff: RESERVED
The Linux kernel doesn't show any new or possibly related errors.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: Ib52df2b2d79a1e6213c3499984a5a1e0e25c058a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74839
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
At present the problem has only been reported with Alder Lake and
Raptor Lake FSP where MultiPhaseSiInit API is unable to return any ERROR
status. Hence, this patch ensures to select applicable W/A config to
read FSP return status from the FSP Reset HOB.
BUG=b:278665768
TEST=Able to select FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN for ADL/RPL SoC
code and call into this API to know the return status from
MultiPhaseSiInit FSP API.
Without this patch:
IshInit() Start
IshDisable() Start
IshPerformGlobalReset()
....
....
FSP returning control to Bootloader with reset required return
status 40000003
FspMultiPhaseSiInit Index-1 returned 0 <-- after control returns
into coreboot, the `status` from the FSP API is reset to `0`
instead 0x40000003. Hence, coreboot avoid hitting the reset.
With this patch:
IshInit() Start
IshDisable() Start
IshPerformGlobalReset()
....
....
FSP returning control to Bootloader with reset required return
status 40000003
FSP: handling reset type 40000003 <-- coreboot is able to understand
the reset request in proper.
GLOBAL RESET!
global_reset() called!
HECI: Global Reset(Type:1) Command
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I18a918cca7e19e03ed6020c55c86c64a94212963
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74785
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch creates a function to read the FSP API Reset Status. This
function relies on the FSP Scheduled Reset HOB which holds the reset
type (warm/cold/shutdown) information along with any platform specific
reset need (like global reset).
Ideally FSP API should be able to return the status (both success and
error code) upon exiting the FSP API but unfortunately there are some
scenarios in ADL/RPL FSP where MultiPhaseSiInit API is unable to return
any ERROR status. Hence, this function provides an additional hook to
read the FSP reset status by reading the dedicated HOB without relying
on the FSP API exit status code.
Additionally, create FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN config option
to handle broken FSP API return status issue.
Any SoC platform that selects the `FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN`
config will call into this newly added API to get the FSP return status
from MultiPhaseSiInit.
BUG=b:278665768
TEST=Able to select FSP_MULTIPHASE_SI_INIT_RETURN_BROKEN for ADL/RPL SoC
code and call into this API to know the return status from
MultiPhaseSiInit FSP API.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ief5d79736cc11a0a31ca2889128285795f8b5aae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
These were hidden because no Windows drivers existed, but now that
they do, the ACPI devices need to be visible in order for the
drivers to properly attach.
TEST=build google/banshee, boot Windows, verify Windows drivers
correctly attach to PCM/IOM devices.
Change-Id: Idbbaee29bffb49059d8450abd09e0c3f7b490fae
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74850
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
These were hidden because no Windows drivers existed, but now that
they do, the ACPI devices need to be visible in order for the
drivers to properly attach.
TEST=build google/drobit, boot Windows, verify Windows drivers
correctly attach to PCM/IOM devices.
Change-Id: I1520a71e318674baa234fc6a2126d1d17933d983
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
In order for Windows to detect/load drivers for any child devices,
the PCI0 root device status must be enabled and visible.
TEST=build google/liara, boot Windows, verify PCI child devices
visible in Device Manager.
Change-Id: I3fb1ba11247f0811120a4cf8a4fd99342ae201de
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The change 'commit Iac37aaa5ede5e1cd ("Add Kconfigs to indicate
when CSE FW sync is performed")' adds support to choose CSE FW update
to be performed in ROMSTAGE or RAMSTAGE. The patch also introduced a
dependency on ME_RW firmware compression.
This patch removes the dependency between CSE FW sync in RAMSTAGE and
ME_RW firmware compression as these two are not related and should be
decoupled to support CSE FW sync in RAMSTAGE without the requirement
to compress ME_FW.
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I5ca4e4a993e4c4cc98b8829cbefff00b28e31549
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74796
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
I forgot to remove these in commit 0fe36db154eb ("ACPI: Make FADT
entries for SMI architectural").
Change-Id: Ib1bc1dad6053ddb0454d4510917fd2bcf0901f35
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74811
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY
that points to same offset. Since the century field inside
RTC falls within the NVRAM space, and could interfere with
OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY.
There were no reference for the use of offset 0x48 for century.
Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
On boards with RECOVERY_MRC_CACHE FMAP section, populate type 0x63 BIOS
directory entry in RO with that section. If the RECOVERY_MRC_CACHE
section is not present, then fall back to RW_MRC_CACHE.
BUG=b:270569389
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ic5ac87685eaa5fec717e3efa4df7af511b4ce8aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73257
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
This ports back commit d75ee46d3c ("soc/amd/picasso/acpi: Change PCI0
BAR window") to Stoneyridge so that the correct end of the non-fixed
MMIO region gets reported in PCI0's _CRS method.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I19153947cbb1b1b684291765eb1902caac65b9ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74809
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
This ports commit 8c28e51a16 ("soc/amd/picasso: fix host bridge bus
numbers") back to Stoneyridge so that the correct number of PCI buses
gets reported from PCI0's _CRS method. The MCFG ACPI table already had
the correct last bus number.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I40121ab0e0438281192b6a0bec8dbecdc1749379
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74804
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
VGA defined the extended ASCII set based on CP437, but the function
vga_write_text() accepts a signed char array.
This will cause unnecessary confusion that if we want to print u with
umlaut (code=129 in CP437), we need to explicitly cast it to -127 in
signed char.
Since we still want to leverage the built-in string utilities
which only accepts const char*, we still need to cast it to signed char
while processing, and cast it back to unsigned once we write into the
frame buffer.
BRANCH=brya
BUG=b:264666392
TEST=emerge-brya coreboot chromeos-bootimage
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: If555bbc05f40ce3f02339c0468afff6dda8b7ded
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Add UPD parameter for eDP power sequence adjustment.
The edp_panel_t9_ms parameter is set for bloff to varybloff.
BUG=b:271704149
BRANCH=Skyrim
TEST=Build; Verify the UPD was pass to system integrated table.
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Change-Id: Id651c9cc4d6f4e27f6c78ca10ca12936d66ef43b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74789
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
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>
Rename the UPD pwr_on_vary_bl_to_blon to edp_panel_t8_ms to
match the eDP sequence timing in milliseconds.
BUG=b:271704149
BRANCH=Skyrim
Test=Build/Boot to ChromeOS
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Change-Id: Iecdfe47cd9142d8a1ddeee0ec988d37b2a11028e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74787
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
It is unused. The use of field irq is problematic as it should
appear relative to IOAPIC GSI bases in the devicetree.
Change-Id: I460fd5fde3a7fba5518ccfc153a266d097a95a39
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This patch implements helper function get_cse_ver_from_cbfs() to
retrieve the CSE Lite version from CBFE RW's metadata and calls
the helper function from cse_check_update_status()
TEST=Verified CSE Lite version in coreboot boot log
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Change-Id: Ie1bf186adfc3f87826a7ce9b0167a6bbe6767299
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74755
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Commit c7b8809f155a ("soc/amd/common/block/gfx: Use TPM-stored hash
for vbios cache validation") replaced checking the vbios signature
(first two bytes) with checking against a TPM-stored hash, but there
exists an edge case where the empty cache can be hashed and therefore
never updated with the correct vbios data. To mitigate this, re-add
the signature check to ensure that an empty cache will never be hashed
to TPM.
BUG=b:255812886
BRANCH=skyrim
TEST=build/boot skyrim w/selective GOP enabled, flash full firmware
image, ensure GOP driver is run until cache updated with valid data
and hashed to TPM.
Change-Id: Id06a8cfaa44d346fb2eece53dcf74ee46f4a5352
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74525
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Since skylake Intel hardware does not support this sleep state. Trying
to enter S1 by having the OS enter sleep results in a system hang on at
least Alder lake (prodrive/atlas).
CONFIG_SOC_INTEL_COMMON_BLOCK_PMC is a good proxy whether devices
support 'skylake style' PMC PCI device for ACPI registers.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ic9e19410696240755e8714db53a0525284f3a2da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Fix copy-paste comment on closing endif
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I9671a9228c304988eb3903391f74a21d80d0a8bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
For the first IOAPIC, use the common MADT generator with
default IRQ overrides.
Change-Id: Ie6e3eae1728a9a94205ec59557d4af1655191166
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Change IRQ #0 to GSI #2 override to positive edge trigger from
the bus ISA default (positive edge).
Change-Id: I2de941071fca6f7208646a065a271fbf47ac2696
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74354
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Change IRQ #0 to GSI #2 override to positive edge trigger from
the bus ISA default (positive edge).
Change-Id: I3a61a0ceb0e6e4a09570beef6d0170354eb498ac
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Change IRQ #0 to GSI #2 override to positive edge trigger from
the bus ISA default (positive edge).
Change-Id: Iab3d38da9610ede1d338440b4a8ec0f1537c17e6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add Kconfig COMMON_ACPI_MADT_IOAPIC to replace platforms'
implementations of adding IOAPIC and IRQ override entries
for ACPI MADT tables.
Platforms that have a more complex MADT may continue to
add custom entries using CUSTOM_ACPI_MADT.
Change-Id: I0b77769f89cc319ad228eb37bc341e2150b8a892
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74348
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Platform needs to implement this to provide information about SCI IRQ
pin and polarity, to be used for filling in ACPI FADT and MADT entries.
Change-Id: Icea7e9ca4abf3997c01617d2f78f25036d85a52f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
According to ACPI Release 6.5 systems supporting PIC (i8259)
interrupt mechanism need to report IRQ vector for the SCI_INT
field. In PIC mode only IRQ0..15 are allowed hardware vectors.
This change should cover section 5.2.9 to not pass SCI_INT
larger than IRQ15. Section 5.2.15.5 needs follow-up work.
Care should be taken that ioapic_get_sci_pin() is called
after platform code has potentially changed the routing
from the default.
It appears touched all platforms except siemens/mc_aplX
currently program SCI as IRQ9.
Change-Id: I723c207f1dcbba5e6fc0452fe1dbd087fad290ee
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74326
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add the missing 'b' to the 4gb so that get_top_of_mem_above_4gb is in
line with get_top_of_mem_below_4gb.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic9170372d8b0c27d7de3bd04d822c95e2015cb10
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Glinda doesn't have an eMMC controller and also doesn't have GPIO pins
that eMMC signals can be multiplexed on, so drop the eMMC related code
from Glinda.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I49ead01075780ea97dae99a36632f7659fd00587
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74662
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Phoenix doesn't have an eMMC controller, so remove the remaining eMMC-
related defines.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I412c968479d23deb7f2e060b26b4a56ec9c764f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Mendocino and Rembrandt don't have an eMMC controller and also don't
have GPIO pins that eMMC signals can be multiplexed on, so drop the eMMC
related code from Mendocino.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib8ec49a7084bdd62e480baee75a280fde8b13d01
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74660
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Set power limit values dynamically based on Meteor Lake
CPU TDP and PCI ID of SKU.
BRANCH=None
BUG=b:270664854
TEST=Built and verified power limit values for 15W SKU on Rex board
Change-Id: I20c9bc21dfa79696b07c460dbcedb4fa51838bdb
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Since it's an internal bus, it's PCIE_ABC_C_DEVFN and not
PCIE_GPP_C_DEVFN. This also makes it consistent with the rest of the
internal PCI buses.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ica8b666161c3cd3b0b4a29f8a4b0aff473b4d833
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74656
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
In the PPRs #57019 Rev 3.03 and #57396 Rev 3.04, SMITYPE_XHC3_PME,
SMITYPE_XHC4_PME and SMITYPE_CUR_TEMP_STATUS_5 are defined, so add those
defines. When doing the initial update for Phoenix, at least XHC3 and
XHC4 PME events were missing from the PPR. Those two are the PME events
of the two USB4 controllers. SMITYPE_XHC2_PME doesn't exist on this SoC.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic6fff9175b73cc9d0fd324d4a568a5761b92d078
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74655
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The patch makes `cse_get_fpt_partition_info()` AP local/static as all
the references to this function are in local to the cse_lite.c file.
BUG=b:273661726
TEST=Able to build and boot google/marasov with this code change.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ie50453946c8abe55c29e9001263f0264a73c8fac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74388
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch implements `soc_is_ish_partition_enabled()` override to
uniquely identify the SKU type between UFS and non-UFS to conclude
if ISH partition is enabled and need to retrieve the ISH version from
CSE FPT by sending HECI command.
TEST=Able to uniquely identify the UFS and non-UFS SKUs while booting
to google/marasov.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I7771aebb988f11d9d1b2824aa28e6f294fd67c25
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74532
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set the `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag to request End-Of-Post
right after PCI enumeration and handle the command response at
`BS_PAYLOAD_BOOT'.
With these settings we have observed a boot time reduction of about
100ms on google/rex.
TEST=Tests on google/rex with `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
End-Of-Post after PCI initialization and EOP message received at
`BS_PAYLOAD_BOOT'.
Change-Id: I27b540eeddcada521eba91fcc51504831d6dc855
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74562
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Use D3COLD_SUPPORT Kconfig option to adjust the maximum supported sleep
state in ACPI.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ifa55a19727e6adb6864158c2c323d08a0c22b996
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The patch stores the ISH in the CBMEM table. It verifies CSE has been
updated by comparing previous and current CSE versions. If it has, the
patch updates the previous CSE version with the current CSE version. It
then updates the CBMEM table with the current ISH version.
BUG=b:273661726
TEST=The current and old CSE and ISH versions are verified on the
google/nissa during cold and warm reboots.
Additionally, version updates are verified by a debug patch that
purposely updated the stored cse version.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ie5c5faf926c75b05d189fb1118020fff024fc3e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
The patch implements an API that stores the CSE firmware version in the
CBMEM table. The API will be called from RAMSTAGE based on boot state
machine BS_PRE_DEVICE/BS_ON_EXIT
Additionally, renamed ramstage_cse_fw_sync() to ramstage_cse_misc_ops()
in order to add more CSE related operations at ramstage.
This patch also adds a configuration option,
'SOC_INTEL_STORE_CSE_FPT_PARTITION_VERSION', which enables the storage
of firmware version information in CBMEM memory. This information can be
used to identify the firmware version that is currently installed on the
system. The option depends on the `DRIVERS_INTEL_ISH` config and
platform should be flexible enough to opt out from enabling this
feature.
The cost of sending HECI command to read the CSE FPT is significant
(~200ms) hence, the idea is to read the CSE RW version on every cold
reset (to cover the CSE update scenarios) and store into CBMEM to
avoid the cost of resending the HECI command in all consecutive warm
boots.
Later boot stages can just read the CBMEM ID to retrieve the ISH
version if required.
Finally, ensure this feature is platform specific hence, getting
enabled for the platform that would like to store the ISH version into
the CBMEM and parse to perform some additional work.
BUG=b:273661726
TEST=Able to build and boot google/marasov.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I923049d2f1f589f87e1a29e1ac94af7f5fccc2c8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74256
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
When one of the General-Purpose PCIe bridges is not used, it doesn't
show up on the PCI bus at all, so coreboot notes it as an issue in the
devicetree. This happens even if the device is marked as off.
To solve this, we're marking the GPP bridge devices in devicetree as
hidden, so they'll only show up in devicetree if they're actually used
on a mainboard.
BUG=b:277997811
TEST=Build
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7b7577baa2dbb0ea7ebbcdb1a8ae81770e61d76f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74527
Reviewed-by: Matt DeVillier <matt.devillier@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>
When one of the General-Purpose PCIe bridges is not used, it doesn't
show up on the PCI bus at all, so coreboot notes it as an issue in the
devicetree. This happens even if the device is marked as off.
To solve this, we're marking the GPP bridge devices in devicetree as
hidden, so they'll only show up in devicetree if they're actually used
on a mainboard.
BUG=None
TEST=Don't see the "PCI: Leftover static devices:" warning for these in
the boot console.
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I517776e4dedc70e957a0c836ab3c2e5d49e156d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74526
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This change adds the VPU into the DMAR SATC table in order to support
the VPU IO virtualization.
BUG=None
TEST=Enabled the VPU, booted to kernel and verified that DMAR SATC table
includeded the VPU entry.
Change-Id: I6d4af7c9844e33483a1e616eaee061a90d0be6fc
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch refactors cse_fw_sync() function to include timestamp
associated with the CSE sync operation.This effort will ensure the
SoC code just makes a call into the cse_fw_sync() without bothering
about adding timestamp entries.
TEST=Able to build and boot google/marasov.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib5e8fc2b8c3b605103f7b1238df5a8405e363f83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Use get_top_of_mem_below_4gb instead of open-coding the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icc9e5ad8954c6203fc4762aa976bba7e8ea16159
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Use get_top_of_mem_below_4gb instead of open-coding the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic673deb725a541c7535ae769f589cd82ea42a561
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Use get_top_of_mem_below_4gb and get_top_of_mem_above_4g instead of
open-coding the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I04f2a3744aee9beedaa97b154a652ce6f0c705c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Use get_top_of_mem_below_4gb and get_top_of_mem_above_4g instead of
open-coding the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I35895340f6e747e2f5e1669d40f40b201d8c1845
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74612
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
To use generated build.h one should have had a pre-requisite in the
Makefile. Reference coreboot_build_date from lib/version.c instead.
Change-Id: Icd6fa2ddf8aa584b0f51ba130592f227bbdad975
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74447
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Rename amd_topmem and amd_topmem2 to get_top_of_mem_below_4gb and
get_top_of_mem_above_4g to make it clearer what those functions return.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic6e98d94c731af74aea0ce276a9a7e4867e3986f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74589
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Set up SoC-specific XHCI defines and enable SOC_AMD_COMMON_BLOCK_XHCI
to allow for XHCI events to be logged.
BUG=b:277273428
TEST=builds
Change-Id: I3ca4f84fb0f1fef8441ab6ef7b6f6348c52b2922
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74280
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After the obsoletion of Processor() it is necessary to provide
_CST package to define P_LVLx IO addresses for C2/C3 transitions.
The latency values from _CST will always replace those in FADT.
Change-Id: I3230be719659fe9cdf9ed6ae73bc91b05093ab97
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Iabba97e003d1a5140c98e3fc5a3496f66f8795c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74528
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
srcclk_pin is 0-based and '0' is a valid clock source number. If
srcclk_pin is set to -1, then the clock will not be disabled in D3.
Therefore, clock source gating method should not be generated.
BUG=b:271003060
BRANCH=firmware-brya-14505.B
TEST=Boot to OS and check that rtd3 ACPI entries are generated as
expected. For those PCI devices with RTD3 driver whose srcclk_pin to
0, the RTD3 entries should not be missing due to check error.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: Ia831b8fd17572cc35765bd226d1db470f12ddd41
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73889
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
This patch sends the CSE EOP command asynchronous implementation early
as part of `soc_init_pre_device`.
Without this patch the duration between asynchronous CSE EOP send and
receive commands is not ample which causes idle delay while waiting
for EOP response.
The goal of the CSE async implementation is to avoid idle delay while
capturing the response from CSE EOP cmd. This patch helps to create
ample duration between CSE EOP command being sent and response being
captured.
TEST=Able to boot google/rex sku to ChromeOS and observed ~100ms of
boot time savings (across warm and cold reset scenarios)
Change-Id: I91ed38edbd5a31d61d4888e1466169a3494d635a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Parts of this file were still a copy of the file from the Mendocino SoC,
so update the file to match the PPR #57019 Rev 3.03 and the chipset
devicetree of the Phoenix SoC. Phoenix has 4 GFX/GPP PCIe bridges/ports,
the numbering scheme of the GPP PCIe bridges/ports was changed so that
the numbers match the device and function numbers, and there are new
device functions for the IPU and the USB4 controller and router devices.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie9429c03839bb0199a04cd6cafe9a955ebdacc91
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74565
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In both PPR #57019 Rev 3.03 and PPR #57396 Rev 3.04, the i2s_ac97
function on bus C isn't mentioned any more and the microarchitecture
specification document for this SoC also doesn't mention it, so remove
it from the devicetree.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibd115953bdd60e1dfcc79797b0c2158e5d861636
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74564
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5e067f6fb2bab66d9b2f6965636845dfd8b7cacd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Remove the `TcssD3ColdDisable` option in devicetree, as it exists
in Kconfig. The setting is currently unused.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I08930ef84438140a13df74900570b126088bd1cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74478
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove the `TcssD3ColdDisable` option in devicetree, as it exists
in Kconfig. The setting is currently unused.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I2590e8dec0a308e0dc3d467cb3dd2bb97e877492
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74477
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove the `TcssD3ColdDisable` option in devicetree, as it exists
in Kconfig. The setting is only used on `starlabs/starbook` which
selects D3COLD_SUPPORT so the UPDs will not change.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I50e49e900c96748edd5b678765e47cc0e0d9b280
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74476
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use D3COLD_SUPPORT Kconfig option to set the maximum support sleep
state. Report `4` in `_S0W` only when D3COLD_SUPPORT is enabled, as
if it is not, it will break S3 exit.
When D3COLD_SUPPORT is not enabled, return `3` (D3Hot).
This fixed S3 exit on both TGL and ADL. Tested on StarBook
Mk V and Mk VI.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I578d4933b6144aec79fe0b2eb168338ef82c0b9d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74406
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The Kconfig option SOC_INTEL_TIGERLAKE_S3 suggests that it's doing
something with S3, but it's actually disabling D3Cold support.
Remove it, and instead use D3COLD_SUPPORT so it's clear what the
option is doing.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Id43f3e5c8620d474831cc02fcecebd8aac961687
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74405
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move D3COLD_SUPPORT to device, so it can be used by multiple
SOCs.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ie92736458ab95374c51346107665dc0fd1e653a4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74404
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Intel FSP used on ChromeOS platform has dropped the
`CpuFeaturesPei.ffs` module to opt for coreboot running this
additional feature programming on BSP and APs.
TEST=Able to build and boot google/rex without any boot regression.
Please refer to the boot time and SPI flash savings after dropping
the FSP feature programming:
Boot time savings=10ms
SPI Flash size savings=34KB
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iaed0a009813098610190b2a3a985b0748c0d51de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
CBFS library performs memory mapped access of the files during loading,
verification and de-compression. Even with MTRRs configured correctly,
first few file access through memory map are taking longer times to
load. Update the SPI DMA driver to load the files into CBFS cache, so
that they can be verified and de-compressed with less overhead. This
saves ~60 ms in boot time.
BUG=None
TEST=Build Skyrim BIOS image and boot to OS. Observe ~60 ms improvement
with the boot time. Performing additional test to confirm there are no
regressions.
Before:
=======
970:loading FSP-M
15:starting LZMA decompress (ignore for x86) 760,906 (60,035)
16:finished LZMA decompress (ignore for x86) 798,787 (37,881)
8:starting to load ramstage
17:starting LZ4 decompress (ignore for x86) 1,050,093 (13,790)
18:finished LZ4 decompress (ignore for x86) 1,054,086 (3,993)
971:loading FSP-S
17:starting LZ4 decompress (ignore for x86) 1,067,778 (3,313)
18:finished LZ4 decompress (ignore for x86) 1,068,022 (244)
90:starting to load payload
17:starting LZ4 decompress (ignore for x86) 1,302,155 (11,285)
18:finished LZ4 decompress (ignore for x86) 1,303,938 (1,783)
After:
======
970:loading FSP-M
15:starting LZMA decompress (ignore for x86) 709,542 (12,178)
16:finished LZMA decompress (ignore for x86) 739,379 (29,837)
8:starting to load ramstage
17:starting LZ4 decompress (ignore for x86) 1,001,316 (12,368)
18:finished LZ4 decompress (ignore for x86) 1,001,971 (655)
971:loading FSP-S
17:starting LZ4 decompress (ignore for x86) 1,016,514 (3,031)
18:finished LZ4 decompress (ignore for x86) 1,016,722 (207)
90:starting to load payload
17:starting LZ4 decompress (ignore for x86) 1,244,602 (10,313)
18:finished LZ4 decompress (ignore for x86) 1,244,831 (228)
Change-Id: Ie30b6324f9977261c60e55ed509e979ef290f1f1
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The Kconfig option SOC_INTEL_ALDERLAKE_S3 suggests that it's doing
something with S3, but it's actually disabling D3Cold support.
Rename it to D3COLD_SUPPORT to make it clear what it's doing.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ifc3f19912ac7ee55be8ec7a491598140f9532675
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Add function needed to generate ACPI backlight control SSDT, along with
Kconfig values for accessing the registers.
Tested by adding gfx register on google/magpie. Backlight controls
work on Windows 10 and Linux 6.1.
Change-Id: Iaa9872cd590c3b1298667cc80354ed3efd91c6c8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74324
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
The patch moves API that gets the CSE FW partition information into
CSE Lite specific file aka cse_lite.c because the consumer of this API
is the cse_lite specific ChromeOS devices hence, it's meaningful to
move the cse lite specific implementation inside cse_lite.c file.
BUG=b:273661726
TEST=Able to build and boot google/marasov with this code change.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I49ffaec467f6fb24327de3b2882e37bf31eeb7cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74382
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable early caching of the TOM region to optimize the boot time by
selecting `SOC_INTEL_COMMON_BASECODE_RAMTOP` config.
Purpose of this feature is to cache the TOM (with a fixed size of
16MB) for all consecutive boots even before calling into the FSP.
Otherwise, this range remains un-cached until postcar boot stage
updates the MTRR programming. FSP-M and late romstage uses this
uncached TOM range for various purposes (like relocating services
between SPI mapped cached memory to DRAM based uncache memory) hence
having the ability to cache this range beforehand would help to
optimize the boot time (more than 50ms as applicable).
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I3b68d13aa414e69c0a80122021e6755352db32fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73738
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable early caching of the TOM region to optimize the boot time by
selecting `SOC_INTEL_COMMON_BASECODE_RAMTOP` config.
Purpose of this feature is to cache the TOM (with a fixed size of
16MB) for all consecutive boots even before calling into the FSP.
Otherwise, this range remains un-cached until postcar boot stage
updates the MTRR programming. FSP-M and late romstage uses this
uncached TOM range for various purposes (like relocating services
between SPI mapped cached memory to DRAM based uncache memory) hence
having the ability to cache this range beforehand would help to
optimize the boot time (more than 50ms as applicable).
TEST=Able to build and boot Starlab ADL laptop to OS.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: Iba554af4ff0896e133d20860ff72dd1a10ebd1e3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73736
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
This patch adds CPU ID for B0 stepping (aka ES2).
DOC=#723567
TEST=Able to boot on B0 rvp and get correct CPU Name in coreboot log.
Signed-off-by: Musse Abdullahi <musse.abdullahi@intel.com>
Change-Id: I8b939ccc8b05e3648c55f8f2a0a391cb08f04184
Signed-off-by: Musse Abdullahi <musse.abdullahi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74300
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
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>
Boards with SOC_INTEL_COMMON_BLOCK_ACPI_CPU_HYBRID have
special handling for the time being.
Change of aopen/dxplplusu is coupled with sb/intel/i82801dx.
Change of emulation/qemu-i440fx is coupled with intel/i82371eb.
For asus/p2b, this adds MADT LAPIC entries, even though platform
has ACPI_NO_MADT selected. Even previously ACPI_NO_MADT creates
the MADT, including an entry for LAPIC address.
Change-Id: I1f8d7ee9891553742d73a92b55a87c04fa95a132
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74316
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This fixes the Jenkins build error when building INTEL_ARCHERCITY_CRB
that was caused by the API change in commit 36e6f9bc04. This patch removes the
broken API function and also adds package_id log print same as previous
commit mentioned above.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I89e14b40186007ab0290b24cd6bd58015be376b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74436
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
This patch avoids cannonlake base config to select eNEM for CAR by
default. Rather allow other SoC config to choose the applicable CAR
mode between eNEM and NEM.
CML and WHL select eNEM whereas CFL decided to use NEM for CAR setup.
Here is some background about why CFL SoC platform decided to choose
NEM over eNEM:
It was found that some coffeelake CPUs like Intel i3 9100E fail to enter
CAR mode because some MSR used by NEM enhanced are lacking. According to
the Intel SDM CPUID.EAX=07h.ECX=0 reg EBX[12 or 15] should indicate the
presence of IA32_PAR_ASSOC and CPUID.EAX=10h.ECX[1 or 2] reg ECX[2]
should indicate IA32_L3_QOS_CFG and IA32_L2_QOS_CFG respectively but
even on a Intel coffeelake CPU that works with the NEM_ENHANCED these
CPUID bits are all 0 so there is no way of knowing whether NEM_ENHANCED
will work at runtime. Instead just always use regular NEM.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ibeaa4d53279ff9cbcd0b2ac5f2ad71925872355b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
To provide power to MIPI panel STA_HIMAX83102_J02, add support for
regulator VIO18.
BUG=b:272425116
TEST=test firmware display pass for STA_HIMAX83102_J02 on Starmie.
Change-Id: I3c3aa105e648b87fc39f881d762002f67b4422b5
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74341
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Currently the xeon_sp code reassigns struct devices apic_id so that srat
entries can be added in a certain order.
This is not a good idea as it breaks thread local storage which contains
a pointer to its struct device cpu.
This moves the sorting of the lapic_ids to the srat table generation
and adds the numa node id in each core init entry. Now it is done in
parallel too as a bonus.
Change-Id: I372bcea1932d28e9bf712cc712f19a76fe3199b1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68912
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Avoid asserts related to CNVi UPDs which are not boot critical.
Instead, add error messages which are more helpful in identifying
the issue.
BUG=none
TEST=Boot to the OS on google/rex
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I49a988b7eda009456d438ba7be0d2918826e1c36
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74370
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The reference to a constant FCH IOAPIC interrupt count used
with GNB IOAPIC was a bit obscure.
Change-Id: I2d862e37424f9fea7f269cd09e9e90056531b643
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This patch retrieves details of a specified firmware partition table.
The information retrieved includes the current firmware version and
other information about the firmware partition. The patch communicates
with the ME using the HECI command to acquire this information.
BUG=b:273661726
Test=Verified the changes for ISH partition on nissa board.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: I0582010bbb836bd4734f843a8c74dee49d203fd8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Hook the newly created/exposed CnviWifiCore UPD up as a chip driver.
Enable this option by default to maintain the existing behavior.
BUG=b:270985197
TEST=Verified by enabling/disabling the UPD on google/rex
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I5b4662c2a064f7c9074797c8a2541dcf1dd686fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74306
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>
The patch updates total cpu count variable and total P-core count in
cpu_apic_info_type structure to `unsigned short int` to address more
cores.
TEST=Verify the build on Rex
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I46239cc7ad9870e7134955af56b9f6625be2b002
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Processor attached memory should not use reserved_ram_from_to and
treat the calculation of gi_mem_size size as 64MB.
By default SOC_INTEL_HAS_CXL is enabled for Sapphire Rapids platforms,
this should fix small total memory issue. Before the fix running
command 'free -g -h' under Linux shows the total memory is only 1.4Gi,
after the fix it's showing the expected total memory size 15Gi.
Tested=On AC without attaching CXL memory, the total memory size is
the same as de-selecting SOC_INTEL_HAS_CXL.
On OCP Crater Lake with CXL memory attached, CXL memory can be recognized
in NUMA node 1:
numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 .. 59
node 0 size: 95854 MB
node 0 free: 93860 MB
node 1 cpus:
node 1 size: 63488 MB
node 1 free: 63488 MB
node distances:
node 0 1
0: 10 14
1: 14 10
Change-Id: I38e9d138fd284620ac616a65f444e943f1774869
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74296
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Use the common acpi_fill_root_complex_tom function instead of the SoC-
level northbridge_fill_ssdt_generator function that does basically the
same.
TEST=Resulting coreboot SSDT remains unchanged on Careena.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie0f100e0766ce0f826daceba7dbec1fb88492938
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The Kconfig is only used in common code to gather the build time
maximum socket number FSP support. The same information is available
in FSP header as MAX_SOCKET, thus use the FSP as truth of source.
Currently MAX_SOCKET is 4.
Change-Id: I10282c79dbf5d612c37b7e45b900af105bb83c36
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74339
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Set the P2SB device as hidden as FSP-S is hiding the PCI configuration
space from coreboot on Alder Lake systems.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I5cfde7c1f6791578a03d73e89bcde31af608f12d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
P2SB device is being hidden from coreboot by FSP-S. This breaks the
resource allocator which does not report P2SB BAR via intel common
block P2SB driver. Hook up the common block P2SB driver ops to
soc_enable function so that the resources will be reported. The P2SB
device must be set as hidden in the devicetree.
This fixes the silent resource allocation conflicts on machines with
devices having big BARs which accidentally overlapped P2SB BAR.
TEST=Boot MSI PRO Z690-A with multiple PCIe devices/dGPUs with big
BARs and see resource conflicts no longer occur.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I7c59441268676a8aab075abbc036e651b9426057
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69949
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Printing the value of a variable is not informative for a normal user,
so decrease the value from BIOS_INFO to BIOS_DEBUG.
Fixes: b9caac74a3 ("soc/amd/mendocino: Reinterpret smu_power_and_thm_limit")
Change-Id: I22f6293fd47633dfdbdae37b7257f47a5a4bb29c
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74271
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Fix a couple of bugs in the _OSC method for handling
"PCI Host Bridge Device" on Xeon-SP.
- Drop the Sleep. The code doesn't write to hardware at all, so
there's no need to sleep here.
- Make sure that the number of DWORD passed in Arg2 is at least 3.
The existing check was useless as it would not create the
DWordField, but then use it anyways.
- Add check for CXL 2 device method calls which provide a 5 DWORD
long buffer to prevent buffer overflows when invoking the
"PCI Host Bridge Device" method.
Test:
Boot on Archer City and confirm that no ACPI errors are reported
for _OSC.
Change-Id: Ide598e386c30ced24e4f96c37f2b4a609ac33441
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com>
According to ADL PCH BIOS specification (DOC# 630603) ADL-S PCH
uses a fixed SBREG_BAR of 256MiB starting at 0xe0000000.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ied59a6dad8fb065dc3aeb6281bd32074aaa5e3b8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69948
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Now the CPU topology is filled in struct device during mp_init.
Change-Id: I7322b43f5b95dda5fbe81e7427f5269c9d6f8755
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69223
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch sends the CSE EOP command asynchronous implementation early
as part of `soc_init_pre_device`.
Without this patch the duration between asynchronous CSE EOP send and
receive commands is not ample whichcauses idle delay while waiting
for EOP response.
The goal of the CSE async implementation is to avoid idle delay while
capturing the response from CSE EOP cmd.
This patch helps to create ample duration between CSE EOP command
being sent and response being captured.
TEST=Able to boot google/marasov EVT sku to ChromeOS and observed
~30ms of boot time savings (across warm and cold reset scenarios).
Without this patch:
963:returning from FspMultiPhaseSiInit 907,326 (97,293)
...
...
115:finished elog init 967,343 (2,581)
942:before sending EOP to ME 967,821 (478)
…
16:finished LZMA decompress (ignore for x86) 1,017,937 (12,135)
943:after sending EOP to ME 1,067,799 (49,861)
…
…
1101:jumping to kernel 1,144,587 (13,734)
Total Time: 1,144,549
With this patch:
963:returning from FspMultiPhaseSiInit 918,291 (97,320)
942:before sending EOP to ME 918,522 (230)
...
...
16:finished LZMA decompress (ignore for x86) 1,029,476 (12,483)
943:after sending EOP to ME 1,033,456 (3,980)
...
...
1101:jumping to kernel 1,111,410 (14,007)
Total Time: 1,111,375
Change-Id: Idaf45ef28747bebc02347f0faa77cc858a4a8ef1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74293
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
PCIe bridges need to provide the LTR (latency tolerance reporting)
maximum snoop/non-snoop values so that they are inherited by downstream
PCIe devices which support and enable LTR. Without this, downstream
devices cannot have LTR enabled, which is a requirement for supporting
PCIe L1 substates. Enabling L1ss without LTR has unpredictable behavior,
including some devices refusing to enter L1 low power modes at all.
Program the max snoop/non-snoop latency values for all PCIe bridges
using the same value used by AGESA/FSP, 1.049ms.
BUG=b:265890321
TEST=build/boot google/skyrim (multiple variants, NVMe drives), ensure
LTR is enabled, latency values are correctly set, and that device
power draw at idle is in the expected range (<25 mW).
Change-Id: Icf188e69cf5676be870873c56d175423d16704b4
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74288
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Create a new GPIO driving info table that contains only the pins used
in the bootblock. The GPIO driving info table is downsized from 1480
bytes to 24 bytes.
BUG=b:270911452
TEST=build pass
Change-Id: I24775ba93cd74ae401747c2f5a26bbf1c8f6ac0a
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74062
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original lastbus configuration consumes constant memory size by
allocating 16 and 8 members arrays and the utilization is bad. Refactor
the lastbus structs to save memory usage.
BRANCH=none
BUG=none
TEST=bootblock.raw.bin size is reduced from 60328 bytes to 59048 bytes.
Change-Id: I07ff9ff7c75f03219e1792b92b62814293ef43fe
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74061
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently coreboot presents the BSP core first, then efficient cores and
Performance cores as indicated below:
```
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0-1
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:0-1
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2-3
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:2-3
```
Existing code presents mix of different cores to OS and causes CPU load
balancing and power/performance impact. So, the patch fixes this
disorder by ordering the Performance cores first, compute die efficient
cores next, and finally SOC efficient cores if they are present. This
is done to run the media applications in a power efficient manner,
please refer the ChromeOS patches for details:
https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3963893
BUG=b:262886449
TEST=Verified the code on Rex system
After the fix:
```
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0-1
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:0-1
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2-3
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:2-3
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
```
Change-Id: I21487a5eb0439ea0cb5976787d1769ee94777469
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Set the `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag to request End-Of-Post
right after PCI enumeration and handle the command response at
`BS_PAYLOAD_BOOT'.
With these settings we have observed a boot time reduction of about 20
to 30 ms on brya0.
BUG=b:268546941
BRANCH=firmware-brya-14505.B
TEST=Tests on brya0 with `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
End-Of-Post after PCI initialization and EOP message received at
`BS_PAYLOAD_BOOT'.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Ib850330fbb9e84839eb1093db054332cbcb59b41
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74215
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
coreboot supports three instances of sending EOP:
1. At CSE `.final' device operation
2. Early as with Alder Lake in chip_operations.init if
`SOC_INTEL_CSE_SEND_EOP_EARLY' is selected
3. At BS_PAYLOAD_BOOT as designed for Meteor Lake if
`SOC_INTEL_CSE_SEND_EOP_LATE' is selected
Currently, Alder Lake uses #3 as it results in better and more stable
boot time. However, what would deliver even better result is to not
actively wait for CSE completion.
This patch introduces a new `SOC_INTEL_CSE_SEND_EOP_ASYNC' Kconfig
which split the action of sending EOP request and receiving EOP
completion response from the CSE.
This patch used in conjunction with #1 can significantly
improves the overall boot time on a Raptor Lake design. For example
`SOC_INTEL_CSE_SEND_EOP_ASYNC' on a skolas board can deliver up to 36
ms boot time improvement as illustrated below.
| # | Late EOP | Async EOP |
|----------+----------+-----------|
| 1 | 1020.052 | 971.272 |
| 2 | 1015.911 | 971.821 |
| 3 | 1038.415 | 1021.841 |
| 4 | 1020.657 | 993.751 |
| 5 | 1065.128 | 1020.951 |
| 6 | 1037.859 | 1023.326 |
| 7 | 1042.010 | 984.412 |
|----------+----------+-----------|
| Mean | 1034.29 | 998.20 |
| Variance | 4.76 % | 5.21 % |
The improvement is not stable but comparing coreboot and FSP
performance timestamps demonstrate that the slowness is caused by a
lower memory frequency (SaGv point) at early boot which is not an
issue addressed by this patch.
We also observe some improvement on an Alder Lake design. For example,
the same configuration on a kano board can deliver up to 10 ms boot time
improvement as illustrated below.
| # | Late EOP | Async EOP |
|----------+----------+-----------|
| 0 | 1067.719 | 1050.106 |
| 1 | 1058.263 | 1056.836 |
| 2 | 1064.091 | 1056.709 |
| 3 | 1068.614 | 1055.042 |
| 4 | 1065.749 | 1056.732 |
| 5 | 1069.838 | 1057.846 |
| 6 | 1066.897 | 1053.548 |
| 7 | 1060.850 | 1051.911 |
|----------+----------+-----------|
| Mean | 1065.25 | 1054.84 |
The improvement is more limited on kano because a longer PCIe
initialization delays EOP in the Late EOP configuration which make it
faster to complete.
CSME team confirms that:
1. End-Of-Post is a blocking command in the sense that BIOS is
requested to wait for the command completion before loading the OS or
second stage bootloader.
2. The BIOS is not required to actively wait for completion of the
command and can perform other operations in the meantime as long as
they do not involve HECI commands.
On Raptor Lake, coreboot does not send any HECI command after
End-Of-Post. FSP-s code review did not reveal any HECI command being
sent as part of the `AFTER_PCI_ENUM', `READY_TO_BOOT' or
`END_OF_FIRMWARE' notifications.
If any HECI send and receive command has been sent the extra code
added in `cse_receive_eop()' should catch it.
According to commit 387ec919d9 ("soc/intel/alderlake: Select
SOC_INTEL_CSE_SEND_EOP_LATE"), FSP-silicon can sometimes (on the first
boot after flashing of a Marasov board for instance) request coreboot
to perform a global request out of AFTER_PCI_ENUM notification. Global
request relies on a HECI command. Even though, we tested that it does
not create any issue, `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag should not
be associated to the `SOC_INTEL_CSE_SEND_EOP_EARLY' flag to prevent
potential a global reset command to "conflict" with the EOP command.
This patch also introduces a new code logic to detect if CSE is in the
right state to handle the EOP command. Otherwise, it uses the
prescribed method to make the CSE function disable. The typical
scenario is the ChromeOS recovery boot where CSE stays in RO partition
and therefore EOP command should be avoided.
[DEBUG] BS: BS_PAYLOAD_LOAD exit times (exec / console): 0 / 14 ms
[INFO ] HECI: coreboot in recovery mode; found CSE in expected
SOFT TEMP DISABLE state, skipping EOP
[INFO ] Disabling Heci using PMC IPC
[WARN ] HECI: CSE device 16.0 is hidden
[WARN ] HECI: CSE device 16.1 is disabled
[WARN ] HECI: CSE device 16.2 is disabled
[WARN ] HECI: CSE device 16.3 is disabled
[WARN ] HECI: CSE device 16.4 is disabled
[WARN ] HECI: CSE device 16.5 is disabled
BUG=b:276339544
BRANCH=firmware-brya-14505.B
TEST=Tests on brya0 with and `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
End-Of-Post sent soon after FSP-s and EOP message receive at
`BS_PAYLOAD_BOOT'. Verify robustness by injecting a
`GET_BOOT_STATE' HECI command with or without `heci_reset'. The
implementation always successfully completed the EOP before
moving to the payload. As expected, the boot time benefit of the
asynchronous solution was under some injection scenario
undermined by this unexpected HECI command.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I01a56bfe3f6c37ffb5e51a527d9fe74785441c5a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This function calls into `set_feature_ctrl_lock()` to lock
IA32_FEATURE_CONTROL MSRfeature control.
TEST=Able to build and boot google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ie9a03ee6786144dae6fd3a18bcc53cb62919dd42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74162
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>
This function calls into `set_feature_ctrl_vmx_arg()`
to enable VMX for virtualization if not done by FSP (based on
DROP_CPU_FEATURE_PROGRAM_IN_FSP config is enabled) in MeteorLake
SoC based platform.
TEST=Able to build and boot google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I7e49c15fd4f78a3e633855fea550720f0a685062
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74161
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>
This function performs locking of the AES-NI enablement state.
TEST=Able to build and boot google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I16f1c14d8a0ca927a34c295cb95311bd4972d691
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74160
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>
This patch calls into API to disable 3-strike error on
Meteor Lake SoC based platform.
TEST=Able to build and boot google/rex to ChromeOS.
Dumping MSR 0x1A4 shows BIT11 aka 3-strike error is disabled
```
localhost ~ # iotools rdmsr 0 0x1a4
0x0000000000000900
```
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I5c33a1fa2d7e27ec8ffdea876edbb86adc3b45b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74159
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>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This patch introduces a new config named
`DROP_CPU_FEATURE_PROGRAM_IN_FSP` to avoid FSP running basic CPU
feature programming on BSP and on APs using the "CpuFeaturesPei.efi"
module.
Most of this feature programming is getting performed today in scope
of coreboot doing MP Init. Running this redundant programming in
scope of FSP (when `USE_FSP_FEATURE_PROGRAM_ON_APS` config is enabled)
results in CPU exception (for example: attempting to reprogram CPU
feature lock MSR is causing CPU exception).
SoC users should select this config after dropping "CpuFeaturesPei.ffs"
module from FSP-S Firmware Volume (FV). Upon selection, coreboot runs
those additional feature programming on BSP and APs.
This feature is by default enabled, in case of "coreboot running MP
init" aka `MP_SERVICES_PPI_V2_NOOP` config is selected.
At present, this option does not do anything unless any platform
eventually decides to drop FSP feature programming module and choose
coreboot CPU feature programming over it.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I3be5329390401024d7ec9eed85a5afc35ab1b776
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74167
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>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
In Intel designs, internal processor errors, such as a processor
instruction retirement watchdog timeout (also known as a 3-strike
timeout) will cause a CATERR assertion and can only be recovered from by
a system reset.
This patch prevents the Three Strike Counter from incrementing (as per
Intel EDS doc: 630094), which would help to disable Machine Check Catastrophic error. It will provide more opportunity to collect more useful CPU traces for debugging.
TEST=Able to build and boot google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I286037cb00603f5fbc434cd1facc5e906718ba2f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74158
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Restrict DPTC to 15W boards, since we only have 15W values defined in
the devicetree. This will revert the 6W boards back to their default
values, rather than (incorrectly) configuring them with 15W values.
BUG=b:253301653
TEST=Verify DPTC values are set for 15W boards
TEST=Verify DPTC values are set not set for 6W boards
Change-Id: I94f3974fce6358e3cbb0c30c1af33eb7ecb29ad7
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74127
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The FSP will return the TDP in the format 0xX0000, where 'X' is the
value we're interested in. For example: 0xF0000 (15W), 0x60000 (6W).
Re-interpret the value so the caller just sees the TDP directly, without
needing to re-interpret things themselves.
BUG=b:253301653
TEST=Manually verify value is correct
Change-Id: I632e702d986a4ac85605040e09c1afab2bbdc59d
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74126
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop devicetree setting X2apic as the same functionality is already
exposed in Kconfig.
To activate X2apic select X2APIC_ONLY or X2APIC_RUNTIME in
the "APIC operation mode".
Note: Your OS must have support for X2APIC. If you are using less
than 256 CPU cores select XAPIC_ONLY here.
Test:
- Booted to OS in X2APIC mode when X2APIC_ONLY or X2APIC_RUNTIME
was selected.
- Booted to OS in XAPIC mode when XAPIC_ONLY was selected.
Change-Id: I65152b0696a45b62a5629fd95801187354c7a93b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When more than 255 CPU cores are present on a board
the X2APIC must be used.
Select DEFAULT_X2APIC_RUNTIME to support X2APIC by
default when a mainboard enables it in the devicetree.
Change-Id: I3e84cfbd2a7f05b142dc4d782764edce81646c8a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74184
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Inject ACPI code for all generated ASL templates.
This fixes ACPI errors shown in linux when not all sockets
are currently plugged in or some have been disabled.
Test:
Boot Archer City with CONFIG_MAX_SOCKET=4
Change-Id: I9562a37a92c6140a5623db3c8fb5972e6a90aaa4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74183
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
When 'use_rp_mutex' (default = 0) is set in the device tree, a root
port mutex will be added. This mutex is used in _ON and _OFF method,
where the GPIO reset and/or enable GPIO value is changed. The
companion driver, such as WWAN driver, needs to acquire this root
port mutex when accessing the same GPIO pins. Using this common mutex
prevents those invoked methods from being called from different thread
while one is not completed.
An example is that WWAN driver calling _RST method to reset the device
and does remove/rescan for the device while the pm runtime work might
call RTD3 _OFF.
For those root port without additional driver, this mutex is not needed.
BRANCH=firmware-brya-14505.B
TEST=boot to OS and check the generated SSDT table for the root port.
The RPMX mutex should be generated and _ON and _OFF should use this
mutex.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: Ibc077528692b2d7076132384fb7bd441be502511
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
This reverts commit e7a1204f26.
This initial change was causing a boot failure when transitioning into
recovery mode.
BUG=b:276927816
TEST='emerge-brya coreboot chromeos-bootimage', flash and boot a skolas
SKU1 to kernel, then press Esc-Refresh-PowerButton to try to reboot into
recovery mode.
Change-Id: Ibebb20a000a239c344af1c96b8d376352b9c774e
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74207
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 11f2f88a27.
Revert initial change as it was causing a boot failure when
transitioning into recovery mode.
BUG=b:276927816
TEST='emerge-brya coreboot chromeos-bootimage', flash and boot a skolas
SKU1 to kernel, then press Esc-Refresh-PowerButton to try to reboot into
recovery mode.
Change-Id: I91c8d0434a2354dedfa49dd6100caf0e5bfe3f4c
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74206
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the newly introduced 'all_x86' make target to add the compilation
unit to all stages that run on the x86 cores, but not to verstage on
PSP.
TEST=Timeless builds for Mandolin without verstage on PSP and Guybrush
with verstage on PSP result in identical images with and without this
patch applied.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I94de6de5a4c7723065a4eb1b7149f9933ef134a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74151
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Get boot performance timestamps from CSE and inject them into CBMEM
timestamp table.
990:CSME ROM started execution 0
944:CSE sent 'Boot Stall Done' to PMC 47,000
945:CSE started to handle ICC configuration 225,000 (178,000)
946:CSE sent 'Host BIOS Prep Done' to PMC 225,000 (0)
947:CSE received 'CPU Reset Done Ack sent' from PMC 516,000 (291,000)
991:Die Management Unit (DMU) load completed 587,000 (71,000)
0:1st timestamp 597,427 (10,427)
BUG=b:259366109
TEST=Able to see TS elapse prior to IA reset on Rex
Change-Id: I548cdc057bf9aa0c0f0730d175eaee5eda3af571
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73713
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
CSE performance data timestamps are different for version 1
Alder Lake/Raptor Lake and version 2 Meteor Lake. This patch
moves the current ADL/RPL timestamp definitions to a separate
header file. It marks current structure as version 1.
BUG=b:259366109
TEST=Boot to OS, check ADL/RPL pre-cpu timestamps.
Change-Id: I780e250707d1d04891a5a1210b30aecb2c8620d3
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73712
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
The i2c.c compilation unit is added to all stages in all cases, so use
the all target instead of adding it to all stages separately. Also order
the all targets alphabetically.
TEST=Timeless build on Mandolin results in identical image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie90380075a3c87d226cdcb0f41f7e94275eaaa42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74149
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The Intel Power and Performance (PnP) team requested to update the
following:
- TDC settings for RPL-U 15W variant should be 22A.
- TDC settings for RPL-P 28W variant should be 33A.
BUG=b:275694022
BRANCH=firmware-brya-14505.B
TEST=PnP validated performance impact with these settings on both
RPL-U 15W and RPL-P 28W
Change-Id: I1141414785a990b975e32ebc03e490b83082aab7
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74046
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Baieswara Reddy Sagili <baieswara.reddy.sagili@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch defines acpi_set_cpu_apicid_order() which orders the APIC IDs
based on APIC IDs of Performance cores and Efficient cores, calculates
the total core count and total Performance cores count, populates the
information in the cpu_apicid_order_info struct.
The helper function useful to present the Performance and Efficient
cores in order to OS through MADT table and _CPC object.
TEST=Verify the build for Gimble (Alder Lake board)
Change-Id: I8ab6053ffd036185d74d5469fbdf36d48e0021ce
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72131
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to document 640858 MTL EDS Vol2, bit 18 (PWR_PERF_PLATFRM_OVR) of MSR_POWER_CTL must be set.
This patch is backported from
`commit 117770d324 ("soc/intel/
alderlake: Enable Energy/Performance Bias control")`.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ic83225b619c49db0b49b521a83a2f1dc1ad69be8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74155
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This updates energy performance preference value to all logical CPUs
when the corresponding chip config is true.
This patch is backported from
`commit 0bb2225718 ("soc/intel/alderlake: Add EPP override
support")`.
BUG=b:266522659
TEST=Able to build and boot google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I8172276159fe3987dae36ec30ebceb76dd0ef326
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74154
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the 28W TDP version of the ADL-P with MCHID 0x4629.
Verified that all 28W SoCs have the same PL1/PL2 defined
in Intel document #655258 "12th Generation Intel Core
Processors Datasheet, Volume 1 of 2".
Fixes the error seen in coreboot log:
[ERROR] unknown SA ID: 0x4629, skipped power Limit Configuration
Change-Id: Iad676f083dfd1cceb4df9435d467dc0f31a63f80
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74116
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
tsc_freq.c gets built into all stages, but the tsc_freq_mhz function it
implements calls the get_pstate_0_reg function which was only built into
ramstage. Since tsc_freq_mhz was only called in ramstage, commit
2323acab6a ("soc/amd/stoneyridge: implement and use get_pstate_0_reg")
didn't cause the build to fail, but better factor out the P-state-
related utility functions into a separate compilation unit and include
it in all stages that also include tsc_freq.c.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id3a3ee218f495be5e60a888944487704e7e8a1a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74145
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
monotonic_timer.c, tsc_freq.c and uart.c get added to all stage targets,
so just add those to the all stage targets. They still need to be added
to the smm stage target, since the all target doesn't add things to the
smm stage.
TEST=Timeless build results in identical image for Gardenia.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I16c02bc0ff54553f212b94d110abef6a7bdedbb4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74144
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add ACPI support for Sapphire Rapids. Passes FWTS ACPI tests.
The code was written from scratch because there are Xeon-SP specific
implementation especially Integrated Input/Output (IIO).
Change-Id: Ic2a9be0222e122ae087b9cc8e1859d257e3411d6
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71967
Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Intel FSP has "debug" build which is not public, used for debugging by
approved developers. Add a Kconfig to indicate that coreboot is building
with debug version of FSP so we can adjust few things (i.e. flash
layout) in the case.
BUG=b:262868089
TEST=Able to build and boot google/rex.
Change-Id: I5555a2ab4182ad0036c42be6fea3d934ffd0db8c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74139
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
PortUsb30Enable has been overridden unexpectedly, this patch fixed it.
BUG=b:276181378
Test=boot to rex and check USB3 ports are working.
Signed-off-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Change-Id: Ic04b9eb236ed28a76ee516c52fc0c983cb8f2c0e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74143
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The patch enables addition of core_type member to 'struct cpu_info'
for MeteorLake platform.
TEST=Build and verify the code for Rex
Change-Id: I01abed6b87bec2f8eb39bfc941faff070b83abe6
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74130
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Now that only one build target per stage is included in the build
depending on CONFIG_SOC_AMD_COMMON_BLOCK_TSC being set, don't use a
separate ifeq block for this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id9e551b37707081eb2ea1d682013f57c7ca8aabd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74017
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All AMD SoCs with Zen-based CPU cores are already using timestamps based
on the TSC counter, so use the existing common infrastructure instead of
reimplementing it in a similar way.
The behavior of the code changes slightly, but results in identical
timestamps. The timestamp_get implementation in soc/amd/common/block/cpu
divided the result of rdtscll() in timestamp_get by the result of
tsc_freq_mhz() and didn't override the weak timestamp_tick_freq_mhz
implementation that returns 1. The non AMD specific code returns the
result of rdtscll() in timestamp_get, but returns tsc_freq_mhz() instead
of 1 in timestamp_tick_freq_mhz, so we still get the correct timestamps.
TEST=The raw timestamps printed on the serial console are now multiplied
by the expected factor of the TSC frequency in MHz.
TEST=Normalized timestamps printed on the serial console by the x86 code
don't change significantly on Mandolin when comparing before and after
this patch. A slight variation in the timestamps is expected. An example
would be:
Before: CPU_CLUSTER: 0 init finished in 630 msecs
After: CPU_CLUSTER: 0 init finished in 629 msecs
TEST=The calculations of the time spent in verstage on PSP before
entering the bootblock on Guybrush result in similar times when
multiplying the value before the patch with the TSC frequency in the
case with the patch applied. The raw values printed on the serial
console by the verstage on PSP use the 1us time base, but the timestamp
logs that end up in CBMEM will be fixed up to use the same time base as
the x86 part of coreboot.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I57b732e5c78222d278d3328b26bb8decb8f4783e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Set the `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag to request End-Of-Post
right after PCI enumeration and handle the command response at
`BS_PAYLOAD_BOOT'.
With these settings we have observed a boot time reduction of about 20
to 30 ms on brya0.
BUG=b:268546941
BRANCH=firmware-brya-14505.B
TEST=Tests on brya0 with `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
End-Of-Post after PCI initialization and EOP message received at
`BS_PAYLOAD_BOOT'.
Change-Id: I81e9dc66f952c14cb14f513955d3fe853396b21c
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73922
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot supports three instances of sending EOP:
1. At CSE `.final' device operation
2. Early as with Alder Lake in chip_operations.init if
`SOC_INTEL_CSE_SEND_EOP_EARLY' is selected
3. At BS_PAYLOAD_BOOT as designed for Meteor Lake if
`SOC_INTEL_CSE_SEND_EOP_LATE' is selected
Currently, Alder Lake uses #3 as it results in better and more stable
boot time. However, what would deliver even better result is to not
actively wait for CSE completion.
This patch introduces a new `SOC_INTEL_CSE_SEND_EOP_ASYNC' Kconfig
which split the action of sending EOP request and receiving EOP
completion response from the CSE.
This patch used in conjunction with #1 can significantly
improves the overall boot time on a Raptor Lake design. For example
`SOC_INTEL_CSE_SEND_EOP_ASYNC' on a skolas board can deliver up to 36
ms boot time improvement as illustrated below.
| # | Late EOP | Async EOP |
|----------+----------+-----------|
| 1 | 1020.052 | 971.272 |
| 2 | 1015.911 | 971.821 |
| 3 | 1038.415 | 1021.841 |
| 4 | 1020.657 | 993.751 |
| 5 | 1065.128 | 1020.951 |
| 6 | 1037.859 | 1023.326 |
| 7 | 1042.010 | 984.412 |
|----------+----------+-----------|
| Mean | 1034.29 | 998.20 |
| Variance | 4.76 % | 5.21 % |
The improvement is not stable but comparing coreboot and FSP
performance timestamps demonstrate that the slowness is caused by a
lower memory frequency (SaGv point) at early boot which is not an
issue addressed by this patch.
We also observe some improvement on an Alder Lake design. For example,
the same configuration on a kano board can deliver up to 10 ms boot time
improvement as illustrated below.
| # | Late EOP | Async EOP |
|----------+----------+-----------|
| 0 | 1067.719 | 1050.106 |
| 1 | 1058.263 | 1056.836 |
| 2 | 1064.091 | 1056.709 |
| 3 | 1068.614 | 1055.042 |
| 4 | 1065.749 | 1056.732 |
| 5 | 1069.838 | 1057.846 |
| 6 | 1066.897 | 1053.548 |
| 7 | 1060.850 | 1051.911 |
|----------+----------+-----------|
| Mean | 1065.25 | 1054.84 |
The improvement is more limited on kano because a longer PCIe
initialization delays EOP in the Late EOP configuration which make it
faster to complete.
CSME team confirms that:
1. End-Of-Post is a blocking command in the sense that BIOS is
requested to wait for the command completion before loading the OS or
second stage bootloader.
2. The BIOS is not required to actively wait for completion of the
command and can perform other operations in the meantime as long as
they do not involve HECI commands.
On Raptor Lake, coreboot does not send any HECI command after
End-Of-Post. FSP-s code review did not reveal any HECI command being
sent as part of the `AFTER_PCI_ENUM', `READY_TO_BOOT' or
`END_OF_FIRMWARE' notifications.
If any HECI send and receive command has been sent the extra code
added in `cse_receive_eop()' should catch it.
According to commit 387ec919d9 ("soc/intel/alderlake: Select
SOC_INTEL_CSE_SEND_EOP_LATE"), FSP-silicon can sometimes (on the first
boot after flashing of a Marasov board for instance) request coreboot
to perform a global request out of AFTER_PCI_ENUM notification. Global
request relies on a HECI command. Even though, we tested that it does
not create any issue, `SOC_INTEL_CSE_SEND_EOP_ASYNC' flag should not
be associated to the `SOC_INTEL_CSE_SEND_EOP_EARLY' flag to prevent
potential a global reset command to "conflict" with the EOP command.
BUG=b:276339544
BRANCH=firmware-brya-14505.B
TEST=Tests on brya0 with and `SOC_INTEL_CSE_SEND_EOP_ASYNC' show
End-Of-Post sent soon after FSP-s and EOP message receive at
`BS_PAYLOAD_BOOT'. Verify robustness by injecting a
`GET_BOOT_STATE' HECI command with or without `heci_reset'. The
implementation always successfully completed the EOP before
moving to the payload. As expected, the boot time benefit of the
asynchronous solution was under some injection scenario
undermined by this unexpected HECI command.
Change-Id: Ib09dcf9140eb8a00807a09e2af711021df4b416f
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73619
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
In order for the code to find the correct VBIOS file in CBFS, remap the
revision ID in the RAVEN2_VBIOS_VID_DID case to the one that matches the
CBFS file name. This will make the code work as expected on devices with
the PCI ID RAVEN2_VBIOS_VID_DID and a revision != RAVEN2_VBIOS_REV.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I94412dc2e778e7c4f74e475cd49114a00a81b2ce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74045
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch enables addition of core_type member to 'struct cpu_info' for
Alderlake platform.
TEST=Build and verify the code for Gimble
Change-Id: Ia065b98c2013e78328fd38bed9c667792d6d1f4d
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74089
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The patch adds new member 'core_type' to the 'struct apic_path' and
updates core type information.
TEST=Build the code for MTL
Change-Id: I1d34068fd5ef43f8408301bf3effa9febf85f683
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74088
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Refactor map_oprom_vendev_rev as a preparation to also remap the
revision ID in the RAVEN2_VBIOS_VID_DID case.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3b81a9464ed49672889fcb767920154fe6efdfcc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74044
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Use enum cb_err as return value of fsp_find_range_hob instead of using
the raw -1 and 0 values. Also update the call sites accordingly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6c9f69a886f53868f1ef543c8fa04be95381f53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Since the return value of the fsp_find_range_hob call is only used in
one location, move the call and return value check into the if condition
block to not need the status variable.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4b9e9251368b86382dc4e050cf176db79dbfb230
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This patch avoids the redundant programming of SRAM BAR when
the SRAM PCI device is enabled. Rather read the PCH SRAM Base
Address Register while enabling crashlog feature.
Additionally, this patch relies on PCI enumeration to get the
SRAM BAR rather than hijacking the SPI temporary base address
which might have resulted in problems if SPI is disabled on
some platform with BAR being implemented.
TEST=Able to build and boot google/marasov and crashlog is working.
Change-Id: I8eb256aa63bbf7222f67cd16a160e71cfb89875a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Instead of using the PSTATE SSDT generated by binaryPI, use the common
AMD code by selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE. To
match the SSDT from binaryPI, set ACPI_SSDT_PSD_INDEPENDENT to n. There
are two differences to the binaryPI SSDT: Now coreboot includes the C1
state in the _CST package instead of just having the kernel add this due
to the ACPI_FADT_C1_SUPPORTED bit being set and the address of the
PS_STS_REG P state status MSR is written to the corresponding field of
the _PCT package instead of being 0.
TEST=On Careena the new P and C state ACPI packages are nearly identical
to the ones from the SSDT from binaryPI with the two functional
differences mentioned above.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icdf6bc8f0e0363f185a294ab84edcb51322e7eb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74023
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Both the algorithm and the registers involved are described in the
public version of BKDG #55072 Rev 3.09 in chapter 2.5.2.1.7.3.2 _PSS
(Performance Supported States).
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9b2c177d9d80c5c205340f3f428186d6b8eb7e98
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The help text for VGA_BIOS_SECOND_ID was outdated and from a time before
we found out that just looking at the CPUID doesn't reliably tell us on
which type of silicon we're running and which VBIOS file to pick, so we
had to use a different method. Update the help text to match what the
code does.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia568771ed7dfa0c7bb850b0efcd2959d7ddfd4a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73335
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
On the Zen-based CPUs, the transition and bus master latency are always
written as 0, but on but on Stoneyridge hardware-dependent values are
used. Introduce get_pstate_latency that returns 0 for all non-CAR AMD
CPUs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I81086fa64909c7350b3b171ea6ea9b46f1708f67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Introduce get_pstate_0_reg and use it in tsc_freq_mhz to get the P state
register number corresponding to P state 0.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7b92a858bf36b04a570d99c656e5ccfc84457724
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74022
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
On the Zen-based CPUs, P state 0 corresponds to the first P state MSR,
but on Stoneyridge this isn't the case. Introduce get_pstate_0_reg that
returns 0 for all non-CAR AMD CPUs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icc11e5b6099d37edb934e66fe329d8013d25f68d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Factor out the MSR access into a function with a more descriptive name.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I331c3205390edcbd8749b2d52b7cc7ac3a8ced5a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The C state ACPI packages binaryPI generates and passes to coreboot in
the PSTATE SSDT only include the C2 state, but the kernel will add the
C1 state to its usable C states in this case. The native C state code
will generate both the C1 and C2 state packages to be more complete and
also to be more in line with the other AMD SoCs.
The code added in this commit isn't used yet, but will be used as soon
as Stoneyridge will be using the common AMD generate_cpu_entries by
selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE once all needed
helper functions are implemented for Stoneyridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I06f90306ac196704e0102d0da6eab03f51513c29
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74001
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option is valid for all SoCs
with Zen-based CPU cores including the family 1Ah, so remove the suffix.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I58d29e69a44b7b97fa5cfeb0e461531b926f7480
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74015
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Move the static mhz variable inside the only function that is accessing
it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ief98c0a1c35fe1bbc4ff38dd175f12e0b3ddc515
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Use get_pstate_core_freq instead of open-coding the calculations in
tsc_freq_mhz. In the case of the CPU frequency divider being 0,
get_pstate_core_freq will return 0; in this case that shouldn't happen,
TSC_DEFAULT_FREQ_MHZ will be used as frequency, since for the TSC
frequency it's better to err on the end of the expected frequency being
too high which will cause longer than expected delays instead of too
short delays.
Now that the code is using get_pstate_core_freq, this code is valid for
Glinda too, so also remove the comment on the
SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option being selected in the Glinda
Kconfig. This Kconfig option will be renamed in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I01168834d4018c92f44782eda0c65b1aa392030d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Use get_pstate_core_freq instead of open-coding the calculations in
tsc_freq_mhz.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If5d526e6b365c62a6669241f4fcdd25eca3f15fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This function will be used in follow-up patches for both the TSC rate
calculation and the still to be implemented P state ACPI table
generation in coreboot. The was checked against BKDG 52740 Rev 3.05,
BKDG #55072 Rev 3.04, and BKDG #50742 Rev 3.08.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9afaa044da994d330c3e546b774eb1f82e4f30e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Factor out the get_pstate_core_freq function from the SoC's acpi.c files
to both avoid duplication and to also be able to use the same function
in the TSC frequency calculation in a follow-up patch. The family 17h
and 19h SoCs use the same frequency encoding in the P state MSRs while
the family 1Ah SoCs use a different encoding. The family 15h and 16h
SoCs use another encoding, but since this isn't implemented in
Stoneyridge's acpi.c, this will be added in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8619822c2c61e06ae5db86896d5323c9b105b25b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Due to a non-constant TSC rate before the microcode update is applied,
the Performance Time Stamp Counter is used instead. To clarify this, add
a comment to the timestamp_get implementation. See commit 24079323d4
("soc/amd/stoneyridge: provide alternate monotonic timer") and the
description of the TscInvariant bit in CPUID Fn8000_0007_EDX Advanced
Power Management Information in the public version of BKDG #55072 Rev
3.09 for more details.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I824b372c36fa6f3eb912469b235a9474f6a58ff5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74018
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Add UPD parameter for eDP power sequence adjust.
The pwr_on_vary_bl_to_blon is set one unit per 4ms.
BUG=b:271704149
TEST=Build; Verify the UPD was pass to system integrated table;
measure the power on sequence on whiterun
Signed-off-by: Chris.Wang <chris.wang@amd.corp-partner.google.com>
Change-Id: I25c9f962e70f599c780259f0943a03f8aa7cbfd1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73752
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
From Meteor Lake onwards Intel FSP will generate the Trace Hub related
HOB if the Trace Hub is configured to save data in DRAM. This memory
region is used by Trace Hub to store the traces for debugging purpose.
This driver locates the HOB and marks the memory region reserved so
that OS does not use it.
Intel Trace Hub developer manual can be found via document #671536 on
Intel's website.
Change-Id: Ie5a348071b6c6a35e8be3efd1b2b658a991aed0e
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72722
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
This patch adds a check for zero based SRAM base address. It will
help to avoid running into problems if the SRAM is disabled and
the base address register is zero.
TEST=Able to build and boot google/marasov with PCH SRAM being
disabled.
Change-Id: Iebc9dc0d0851d5f83115f966bf3c7aad1eb6bc01
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74055
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Move map_oprom_vendev to graphics.c to match the other AMD SoCs. Also
change the comment style to be more in line with the rest of coreboot
and drop the unneeded line break in the printk call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icc1f3d73fba973413c5a22e2f5ae01bc58bc3e76
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Fix the VGA_BIOS_ID IDs to match the PCI IDs in the VBIOS binaries and
the PCI ID Stoneyidge's map_oprom_vendev returns. This fixes the problem
that the display wasn't initialized due to not finding the VBIOS file in
CBFS. This bug in the Stoneyridge Kconfig was unmasked by commit
42f0396a10 ("device/pci_rom: rework PCI ID remapping in
pci_rom_probe").
TEST=Display in Careena lights up again.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4d1e6a3a65d7d7b07f49df9ce90620b79d9a2d78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74019
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change to use simple device function for setting PMAX_LOCK because
the Sapphire Rapids PCU device is not scanned during coreboot PCIe
bus scan and would see "PCI: dev is NULL!" failure.
Change-Id: I3156a6adf874b324b5f4ff5857c40002220e47ab
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72400
Reviewed-by: Simon Chou <simonchou@supermicro.com.tw>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Stoneyridge uses the serial voltage ID 2 standard to tell the VRM on the
board which voltage it wants, so select the SOC_AMD_COMMON_BLOCK_SVI2
Kconfig option to have the corresponding code to decode the raw SVI2
value into a voltage.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7d7031d9ad997a86c18d0e9e7af9a88ddf2d873c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73999
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
A core voltage ID larger than 0xff shouldn't happen, since SVI2's core
VID is only 8 bit long. In order for making it more difficult to use
this function in a wrong way that results in a very wrong voltage being
returned, also return 0 for those invalid core VID values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I95417c45db86cd2373879cdad8a07fb9eb8dfdda
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74000
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add UPD usb3_port_force_gen1 to support USB3 port force to gen1
BUG=b:273841155
BRANCH=skyrim
TEST=Build, verify USB3 port setting to gen1.
Change-Id: Iaa476f56cf10588d7de2203deca4122958c00783
Signed-off-by: Patrick Huang <patrick.huang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73916
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs which will be
used in future patches to generate the P state ACPI packages for the CPU
objects. BKDG #55072 Rev 3.04 was used as a reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I944c8598ba95a0333124655c61ef9eba8a7595c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73998
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that all get_pstate_core_power implementations in each SoC's acpi.c
file is identical, factor it out into a common implementation. This
implementation will also work for Stoneyridge which isn't using the
common P state code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iba3833024a5e3ca5a47ffb1c1afdbfd884313c96
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73997
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since SVI3 has the CPU voltage ID split into two parts, a serial voltage
ID version specific function is needed to get the raw core VID value.
This will allow making get_pstate_core_power common for all AMD CPUs in
a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I71ca88c38b307558905a26cce8be1e8ffc5fbed4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73996
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of implementing the conversion from the raw serial voltage ID
value to the voltage in microvolts in every SoC, introduce the
SOC_AMD_COMMON_BLOCK_SVI[2,3] Kconfig options for the SoC to select the
correct version, implement get_uvolts_from_vid for both cases and only
include the selected implementation in the build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I344641217e6e4654fd281d434b88e346e0482f57
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73995
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch moves USB Port Status and Control (PORTSC) Reg definition
into IA common code to allow other SoC code to reuse it without
redefining the same for each SoC.
TEST=Able to build and boot google/taeko where USB wake is working.
Change-Id: I6b540eab282403c7a6038916f5982aa26bd631f8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
For some Xeon-SP (such as SPR-SP), more buses should be probed.
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Change-Id: Ica3c61493a0ff6c699b500f30788b2cf5a06c250
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71965
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com>
The included acpi/acpigen.h provides the cppc_config struct and nothing
in this header file is using the cppc_config struct.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia91fd4105e6872d812f595447783d02a0dd1568b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73993
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the code was made common in commit 8f7f4bf87a ("soc/amd/cezanne,
common: factor out CPPC code to common AMD SoC code"), the include guard
wasn't renamed accordingly, so do that now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9eefe2065fae31e97aa4e6710008a6f9712bed40
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73992
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Picasso and Cezanne use the serial voltage ID 2 standard to communicate
the CPU voltage to the voltage regulator module on the mainboard, while
Mendocino, Phoenix and Glinda use the serial voltage ID 3 standard for
this. Both standards encode the voltage in a different way, so add the
serial VID version number to the defines to clarify for which version
the define is.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8ddab8df27c86dc2c70a6dfb47908d9405d86240
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73994
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Mendocino uses the SVI3 standard for CPU core voltage control which uses
9 data bits instead of the 8 in the SVI2 case and also calculates the
actual voltages with a different formula. The Mendocino code uses the
correct formula since commit 8d2bfbce23 ("soc/amd/sabrina/acpi:
Correct VID decoding on Sabrina"), but the MSR definition in the PPR
hasn't been updated to show the additional bit. The definition of the
register that is mirrored by these MSRs descries this 9th CPU voltage ID
bit though. Since this bit is expected to be zero, this shouldn't cause
a change in behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I05acd239300836a34e40cd3f31ea819b79766e2e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73969
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
For SPR-SP, the SMM_FEATURE_CONTROL register is in UBOX_URACU_FUNC
instead of UBOX_DEV_PMON.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Change-Id: Ide46c5f9cdf65b7e05552449b08ad4d7246664cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The _LO part in the definition names is a leftover from before moving to
the pstate_msr union access to the bitfield elements where it still
mattered if a bit was in the lower of higher half of the MSR. With the
mask-and-shift access to the two parts of the MSR being gone, the _LO
part in the name isn't useful any more and possibly a bit misleading, so
drop that part.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib43c71e946388c944ecf40659d4c12ca02a27a5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73927
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@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>
Since we already have and use the pstate_msr union in get_pstate_info,
also pass it directly to the get_pstate_core_freq and
get_pstate_core_power function calls avoids having to sort-of convert
the msr_t type parameter in the implementations of those two functions.
In amdblocks/cpu.h a forward declaration of the pstate_msr union is used
since soc/msr.h doesn't exist in the two pre-Zen SoCs that also include
amdblocks/cpu.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I112030a15211587ccdc949807d1a1d552fe662b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73926
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@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>
Use the pstate_msr union in get_pstate_info to check if the P state
enable bit is set. Also drop the now unused PSTATE_DEF_HI_ENABLE_SHIFT
and PSTATE_DEF_HI_ENABLE_MASK definitions.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I79119e09af79a4bb680a18e93b4a61a049f0080e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73925
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs which will be
implemented in a following patch. PPR #57254 Rev 1.52 was used as a
reference. This patch adds and uses the cpu_vid_8 bit which is the 9th
bit of the voltage ID specified in the SVI3 spec. The way the CPU
frequency is encoded in the PSTATE MSR has changed compared to Phoenix,
so also update the comment in the SoC's Kconfig file that the selected
SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H is likely incompatible which will be
addressed in the future.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3d1878ce4d9bc62ac597e6f71ef9630491628698
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
PPR #57019 Rev 1.65 and PPR #57396 Rev 1.54 were used as a reference as
well as the reference code. This patch also adds and uses the cpu_vid_8
bit which is the 9th bit of the voltage ID specified in the SVI3 spec.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia024d32ae75cf2ffbc2a2e86a8b3af3dc6cbad61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73923
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>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Add platform cpu info for known microcode, print cpuid & processor
branding string. This will print as in the following example:
CPU: Intel(R) Xeon(R) Platinum 8468H
CPU: ID 806f6, Sapphire Rapids E3, ucode: 2b000130
CPU: AES supported, TXT supported, VT supported
Change-Id: I9c08fb924aad81608f554523432ab6a549b1b75f
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
FSP may program a different ID under certain circumstances.
Read IOAPIC ID from hardware instead of using some define that
might not reflect how hardware is configured.
Change-Id: Ia91cb4aef9d15520b8b3402ec10e7b0a4355caeb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Having these two functions public allow "asynchronous"
HECI command implementation.
Typically, these function can be use to implement an asynchronous
End-Of-Post.
BUG=b:268546941
BRANCH=firmware-brya-14505.B
TEST=Successful compilation for brya0
Change-Id: I7d029bb9af4b53f219018e459d17df9c1bd33fc1
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The internal GPP bridge to bus B is not used on MDN, so remove it.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4f95afd192c5b799b7a3e12650476b7933cdd118
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The default SPD size is set to 256 bytes, instead of 512 for
LPDDR4/DDR4 if not overridden by the mainboard Kconfig. This caused
the SMBus libraries to read only the lower half of the DIMM SPD on
protectli/vault_ehl. The lower half of the SPD passed to FSP causes
a bug in DIMM change detection, which relies on the CRC of the
manufacturer bytes in the upper half of the SPD (CRC of zero bytes
always gives zero so no change was assumed). Setting the DIMM SPD size
to 512 fixes it.
Setting the SPD size in SoC will also avoid such problems in the future
Elkhart Lake ports. Elkhart Lake supports only LPDDR4/DDR4 so providing
the correct default of 512 bytes is an obvious thing to do.
TEST=Boot Protectli VP2420 (vault_ehl) with different DIMMs and see
FSP is retraining the memory instead of doing the fastboot with old
DIMM data.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I998ed8781951034419cadc26c04ff1e0a124b267
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73933
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch renames all references of `top_of_ram` (TOM) in IA common
`basecode` module (for example: functions, variables, Kconfig,
Makefile and comments) with `ramtop` aka top_of_ram to make it more
meaningful and to avoid conflicts with Intel SA chipset TOM registers.
BUG=Able to build and boot google/rex with the same ~49ms savings
in place.
Change-Id: Icfe6300a8e4c5761064537fb256cfecbe2afb2d8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73881
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To be consistent with other occurrences in soc/intel/common, remove the
return statements of weak void funtions since they are not generally
useful.
Found by the linter.
Signed-off-by: Yuchen He <yuchenhe126@gmail.com>
Change-Id: I3fb8217cfcae65b5dc317458b59aa431f1ccdaef
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73866
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Assign true/false instead of 1/0 to the valid_freq_divisor bool variable
in get_pstate_core_freq.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I92d0eb029c55f80a2027ff6d404c63ed84282750
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
If the host supports CXL, get proximity domain info from FSP HOB. The
proximity domains may include both processor domains and CXL domains.
Add header definition for proximity domain.
Add CXL memory into memory map.
Change-Id: If3f856958a3e6ed3909240ee455bb639e487087f
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
DPR should not be configured for VTD devices of other stacks for
SPR-SP. Such processor(s) would be configured with
SOC_INTEL_MMAPVTD_ONLY_FOR_DPR.
Change-Id: Ib33b1b62f59a10d362c6585b1403490d4a1aedeb
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: David Hendricks <ddaveh@amazon.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72616
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
... instead of ME base/limit if the processor is configured with
SOC_INTEL_HAS_NCMEM.
Change-Id: I95783cad1a2d5a3599d120ea0c98e2aa8703bdb4
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: David Hendricks <ddaveh@amazon.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72615
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This soc utility function can set cmos flag to enforce
FSP MRC training.
Change-Id: I88004cbfdcbe8870726493576dfc31de4b6036a9
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72598
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
After calling FSP MemoryInit API, if there is an error, some FSPs
(such as SPR-SP FSP) is capable of generating FSP_ERROR_INFO_HOB.
Check existence of such a HOB and handle it accordingly.
Change-Id: Icb5c31daa223ba6b06ba1b2de4f8808e0b27899e
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
The Kconfig help section says FSP uses 192 KiB of stack (0x30000) and
coreboot's romstage requires ~1 KiB, but it is not satisfied currently.
Increase the BSP stack size by the missing 1KiB for romstage like
other SoCs do.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Iddd4a4613bc174aec4331732371a27450225258c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73820
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Commit 6a6ac1e0b9 ("arch/x86/cpu: introduce and use
device_match_mask") added the device_match_mask element to the
cpu_device_id struct and uses it to be able to mask off for example the
stepping ID when checking for CPU table entry that matches the silicon
the code is running on. Commit 3ed903fda9 ("soc/intel/xeon_sp/spr: Add
Sapphire Rapids ramstage code") added a CPU table that was missing the
device_match_mask which results in this being 0, so the first entry of
the CPU table would match for any Intel CPU which isn't the intended
behavior. Also use CPU_TABLE_END instead of the final {0, 0, 0} array
element.
Likely all entries could be replaced by one entry that uses the
CPUID_ALL_STEPPINGS_MASK instead of the CPUID_EXACT_MATCH_MASK, but
that's out of scope for this fix.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib0be2e9fe3c31487c83c9b1cf305a985416760b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Programming MTRR happens later in the
CONFIG_SOC_INTEL_COMMON_BLOCK_CPU_MPINIT codepath.
fast_spi_cache_bios_region() assumes an existing MTRR solution from
x86_setup_mtrrs_with_detect().
This fixes a problem introduced by 829e8e6 "soc/intel: Use common
codeflow for MP init".
Change-Id: I9b6130cf76317440ebe7a7a53e460e2b658d198e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73836
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mendocino only has 4 PCIe lanes exposed, so there's no need for 6
PCIe functions to control them. These functions just show up as
leftover devicetree devices.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5b801d82f085d77706b8053a8fc9728101f155e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73853
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Replace the legacy ACPI Processor() object as it only
supports 8bit IDs and thus no more than 255 cores. Use the
new ACPI Device() object that supports more than 255 cores.
Test:
- Observed no ACPI errors on IBM/SBP1 and Linux 5.15 running
384 CPU cores in total.
- Verified on Intel ADL RVP with 20 cores that Linux 5.15 is
still working without errors.
Change-Id: I309c06b6824704c84fd16534655334a6f269904a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73578
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
In cases where there are limitations on the connected device behind the
PCIe root port it can be necessary to limit the speed. The FSP parameter
'PcieRpPcieSpeed' allows to set the speed limit.
This patch provides a chip config so that this FSP parameter can be set
as needed in the devicetree on mainboard level.
Change-Id: I9fc24de1682279e4ae4c090147a6ef7995b441bc
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Add the AlderLake-P 4+4+2 (28W) with MCH_ID 0x4629 to the
vr_config table.
Change-Id: I606ef429f47dfe386177f7257b153acc1611bb61
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic489b8e1332dde2511647c065ccbdef541bcbcc5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73645
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If92a4773c669ac2df45396eee52f6de780adbdca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73644
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
TEST=The coreboot-generated SSDT containing the P state packages stays
identical on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8dc293351f9941cfb8a9c84d9fb9a4fd76361d5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Enable SOC_INTEL_COMMON_BLOCK_GPIO_IOSTANDBY so the pads can be
configured with non-zero IOSSTATE values.
TEST=Able to build and boot google/rex. GPIO debug print is showing
GPIO PAD config DW1 bit[14:17] are getting programmed.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I9e63fe946d541769fa0ddbb23f902f9c905735c1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Provide support function to query fsp misc_data hob and return smu
reported power and thermal limit.
BUG=b:253301653
TEST=Use get_amd_smu_reported_tdp(&tdp) values match what FSP placed in
the hob.
Change-Id: I9f0d8cdd616726c5a714e99504b83b0126dd273b
Signed-off-by: Jason Glenesk <jason.glenesk@amd.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73747
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It implements SPR ramstage including silicon initialization, MSR
programming, MP init and certain registers locking before booting
to payload.
Change-Id: I128fdc6e58c49fb5abf911d6ffa91e7411f6d1e2
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Several FSP HOBs processing codes are similar to Intel Cooperlake-SP
codes in soc/intel/xeon_sp/cpx.
Register datasheet please reference Sapphire Rapids EDS Vol2 Doc#612246
and Emmitsburg PCH EDS Doc#606161.
Change-Id: Ia022534e5206dbeec946d3e5f3c66bcb5628748f
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch modifies the serial msg log_level at runtime to highlight
an ERROR if the DIMM count is zero. It would help to draw the
attention while parsing the serial msg and catch any underlying issue.
TEST=Able to see ERROR msg while booting google/rex with FSP v3064
Without this patch:
[DEBUG] 0 DIMMs found
With this patch:
[ERROR] No DIMMs found
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Iacf41efecb4962f91cf322bbc50636dc44033e3e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73756
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some MSRs used in SPR code are common among currently supported
Xeon-SP generations and are added to the top-level Xeon-SP msr.h. MSRs
which have changed are added to SPR's soc_msr.h.
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Signed-off-by: David Hendricks <ddaveh@amazon.com>
Change-Id: I92b433a9686734716dc7936895fb79c7751f7f9b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73172
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com>
TEST=Enable DMA protection on MSI PRO Z690-A DDR4 and observe
the I/O devices like USB and NVMe fail to enumerate in UEFI
Payload (basically proving that DMA protection works).
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Iecaa3d04f1447b7e73507ca57a0d23d42e24d663
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68450
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The HSPHY firmware must be downloaded to DMA-allowed host address
space. Check for DMA buffer presence and use it as the buffer for HSPHY
firmware to be downloaded from CSME.
TEST=Successfully load HSPHY firmware to CPU on MSI PRO Z690-A DDR4
with DMA protection enabled.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I88edda26a027b557eeaba80426a5b7be7199507d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68556
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new common block with VT-d/IOMMU support. The patch adds an
option to enable DMA protection with PMR. However the payload and
OS must support VT-d in order to properly handle I/O devices.
TEST=Enable DMA protection on MSI PRO Z690-A DDR4 and observe
the I/O devices like USB and NVMe fail to enumerate in UEFI
Payload (basically proving that DMA protection works).
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Id7edf982457c1139624e5cd383788eda41d6a948
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
This patch passes a hint flag to QcLib on Lazor boards to tell it to
limit the DDR frequency for certain memory parts (8GB Hynix) to work
around a board-specific stability issue.
BRANCH=trogdor
BUG=b:267387867
TEST=Validated on qualcomm sc7180 development board
Change-Id: I45915cf93d2a57ff0c9710f2ac36dfb665eff1c6
Signed-off-by: Sudheer Kumar Amrabadi <samrabad@codeaurora.org>
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73727
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
With newer xeon_sp processors, the concept of "north bridge" became
obsolete, instead uncore should be used. Therefore we use uncore_acpi.c
(instead of nb_acpi.c) going forward.
Change-Id: I91ec9023152996bf9f2300a369aff3c4f19d75fd
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jon.zhixiong.zhang@gmail.com>
The MP2 firmware doesn't do anything useful when booting into recovery
mode, so don't include it in the RO image if vboot is enabled.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5afbf7e9e730e6951c416f3a3ca75f69a22099cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73660
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When doing coreboot builds, we can set V=1 to see all of the make info
printed as the compile is happening. Use this flag to set the debug
flag for amdfwtool so it doesn't have to be enabled separately.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5b05cbc9f9b540a174db479822af657cf35733de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73658
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The regex getting rid of lines containing a '*' didn't match anything
in any configs, so get rid of it. There's nothing in the amdfwtool
dataparse.c file that would match it either.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I05aaf46cfb479cebab9234a47574073335984a5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
After adding the ability to add paths into the amdfw.cfg file for the
amdfwtool, the dependency generation needs to be updated to not add
the firmware location in front of those values.
This also allows us to filter out the MP2 binaries as dependencies
based on whether or not the Kconfig value is set.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3a9b9c8246808dc60020a32a7d9d926bc5e57ccd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This patch selects `X86_CLFLUSH_CAR` config for running `clflush`
to invalidate the cache region based on commit 3134a81 for boot
performance improvement.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I97c8c07db9b44aa89b433e7962ec77c8501ecaa9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73688
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch selects `X86_CLFLUSH_CAR` config for running `clflush`
to invalidate the cache region based on commit 3134a81 for boot
performance improvement.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I8f8a0bfeaea508d3b4ad1b3fe2e68742cbab5570
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73687
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch selects `X86_CLFLUSH_CAR` config for running `clflush`
to invalidate the cache region based on commit 3134a81 for boot
performance improvement.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: Icd3d16ab2cb34dc81fc12ec139c52ecaa170528d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73686
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch selects `X86_CLFLUSH_CAR` config for running `clflush`
to invalidate the cache region based on commit 3134a81 for boot
performance improvement.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I1fe6072a3c23a02c9a691406f179bfc8f0f18a93
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Currently on power key long press, PMIC will be reset. It would cause
an unwanted reset pulse in the power-off sequence. To match expected
sequence, change PMIC behavior to "force shutdown".
BUG=b:271771606
TEST=long-pressing power key doesn't trigger PMIC_AP_RST_L pulse
BRANCH=corsola
Change-Id: I9ab35d82e57f43bac99fa8bd7bb69fcf52250311
Signed-off-by: Sen Chu <sen.chu@mediatek.corp-partner.google.com>
Signed-off-by: jason-ch chen <jason-ch.chen@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73705
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Currently on power key long press, PMIC will be reset. It would cause
an unwanted reset pulse in the power-off sequence. To match expected
sequence, change PMIC behavior to "force shutdown".
BUG=b:271771606
TEST=long-pressing power key doesn't trigger PMIC_AP_RST_L pulse
Change-Id: I1626892fd582dfab8fe1c1ede1da00549bc97142
Signed-off-by: Sen Chu <sen.chu@mediatek.corp-partner.google.com>
Signed-off-by: jason-ch chen <jason-ch.chen@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73704
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Intel Meteor Lake decides to enable early caching of the TOM region to
optimize the boot time by selecting `SOC_INTEL_COMMON_BASECODE_TOM`
config.
TEST=Able to build and boot google/rex to ChromeOS and reduce the boot
time by 77 ms.
Without this patch:
950:calling FspMemoryInit 936,811 (19,941)
951:returning from FspMemoryInit 1,041,935 (105,123)
With this patch:
950:calling FspMemoryInit 905,108 (20,103)
951:returning from FspMemoryInit 964,038 (59,929)
Change-Id: Iebb3485b052386b43d5bccd67a04e6115cbcc20d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73274
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements a module that can store the top_of_ram (TOM)
address into non-volatile space (CMOS) during the first boot and
use it across all consecutive boot.
As top_of_ram address is not known until FSP-M has exited, it
results into lacking of MTRR programming to cache the 16 MB TOM,
hence accessing that range during FSP-M and/or late romstage causing
long access times.
Purpose of this driver code is to cache the TOM (with a fixed size of
16MB) for all consecutive boots even before calling into the FSP.
Otherwise, this range remains un-cached until postcar boot stage
updates the MTRR programming. FSP-M and late romstage uses this
uncached TOM range for various purposes (like relocating services
between SPI mapped cached memory to DRAM based uncache memory) hence
having the ability to cache this range beforehand would help to
optimize the boot time (more than 50ms as applicable).
TEST=Able to build and boot google/rex to ChromeOS.
Without this patch:
950:calling FspMemoryInit 936,811 (19,941)
951:returning from FspMemoryInit 1,041,935 (105,123)
With this patch:
950:calling FspMemoryInit 905,108 (20,103)
951:returning from FspMemoryInit 987,038 (81,929)
Change-Id: I29d3e1df91c6057280bdf7fb6a4a356db31a408f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73272
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Documentation and hardware differ in the number of MCA bank names, so
remove the excess ones to prevent a "CPU has an unexpected number of MCA
banks!" warning message.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I75a2348561833f3f19181b4f30a6971ecb317899
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73650
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, the address of the microcode update can
be directly written to the raw value instead of needing to split it into
the lower and higher 32 bits and assigning those separately.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I51c84164e81477040a4b7810552d3d65c0e3656b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73636
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, the address of the bootblock_resume_entry
can be directly written to the raw value instead of needing to split it
into the lower and higher 32 bits and assigning those separately.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I7ebab1784ec592e18c29001b1cf3ee7790615bf8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This separates the SPL fusing function into a separate C file which can
be excluded if it is not needed. This allows the psp_set_spl_fuse()
function to be made static again as the state of the function will
always match the boot_state entry.
Move the required #defines to the common header file so they can be
used by both psp_gen2.c & spl_fuse.c.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ifbc774a370dd35a5c1e82f271816e8a036745ad5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73655
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Even though right now TSEG will always be located below 4GB, better not
make assumptions in the SMM relocation code. Instead of clearing the
higher 32 bits and just assigning the TSEG base and per-core SMM base to
the lower 32 bits of the MSR, assign those two base addresses to the raw
64 bit MSR value to not truncate the base addresses. Since TSEG will
realistically never be larger than 4GB and it needs to be aligned to its
power-of-two size, the TSEG mask still only needs to affect the lower
half of the corresponding MSR value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1004b5e05a7dba83b76b93b3e7152aef7db58f4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, there's no need to convert the lower and
higher 32 bits into a 64 bit value and we can just use the 64 bit raw
value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5923df84f0eb3a28ba6eda4a06c7421f4459e560
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, there's no need to convert the lower and
higher 32 bits into a 64 bit value and we can just use the 64 bit raw
value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibc5d64c74eaabfc4b7834a34410b48f590f78a12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73637
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Lastbus is a bus debug tool. When the bus hangs, the bus transmission
information before resetting will be recorded.
The watchdog cannot clear it and it will be printed out for bus hanging
analysis.
There are two versions for lastbus:
Version 1 for MT8186, and version 2 for MT8188.
BUG=b:263753374
TEST=build pass.
Change-Id: Ibaf510481d1941376bd8da0168ef17c99a0fb9a2
Signed-off-by: ot_zhenguo.li <ot_zhenguo.li@mediatek.corp-partner.google.com>
Signed-off-by: jason-ch chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73624
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The get_threads_per_core function isn't specific to the non-CAR CPUs and
also applies for Stoneyridge and even for family 16h model 30h outside
of soc/amd, so move it from the non-CAR-specific cpu.c file to the
common AMD SoC cpu.c file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I05946f163112ff93f33139f6c43fed5820fd0a3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73615
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>
Picasso already uses the Cxxx ACPI CPU device naming scheme, due to it
being what the AGESA reference code uses. We initially relied on the
AGESA/FSP generated SSDT for the P- and C-state support before we had a
native implementation for this in coreboot. The Cxxx naming scheme can
also be used for the other AMD SoCs except Stoneyridge which is pre-Zen
and doesn't select SOC_AMD_COMMON_BLOCK_NONCAR. The main advantage of
using Cxxx instead of CPxx is that the Cxxx scheme supports systems with
more than 256 CPU threads.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I884f5c0f234b5a3942dacd60847b2f095f9c0704
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73620
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For Intel SPR-SP, the SAD device is hidden, so pcidev_path_on_bus()
returns NULL. Therefore use pci_s_write_config32() instead.
Move lock_pam0123() from finalize.c to util.c, to be together with
unlock_pam_regions().
Change-Id: Ib08d423d8c4d482612077b66dab3878018da8f2b
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Intel SPR-SP has its specific way to get the bus number of ubox.
Move the current implementations to CPX-SP and SKX-SP folders.
Change-Id: I2b69be74d140115f9f78bc991fb690e3c90c88db
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
The GPE number used for XHCI has now been defined in AMD's common code
in CB:67936. Change over existing code to use this new definition.
BRANCH=guybrush
BUG=b:186792595
TEST=Ran on nipperkin device and verified that XHCI events string use
GPE 31.
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I9c2a44f7d2eb47422ae8c585e5e01ea0b420d461
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69917
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPE number used for XHCI has now been defined in AMD's common code
in CB:67936. Change over existing code to use this new definition.
BUG=b:186792595
TEST=Ran on skyrim device and verified XHCI GPE setting.
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I3bfc2256ea2ca851afe88f2cdb419f39eee76fdd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69916
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
AMD SoCs currently only log the GPE# when an XHCI controller wakes the
system. Add code to log XHCI wake events to the elog.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Change-Id: Ic0489e1df55c4e63cb8a306099e3f31c82eebd58
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This fixes the case where a Broadwell CPU is combined with an AMD or
NVIDIA GPU would result in using the Broadwell GPU VBIOS file from CBFS
for the discrete GPU too. A further improvement would be to use a list
of the Intel iGPU PCI IDs like it is done in the Skylake code.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3eb50cb9a0539255d50e5cd8163f10c3a062cc4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73611
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
This patch updates PMC API name from `pmc_send_pci_enum_done` to
`pmc_send_bios_reset_pci_enum_done` to inform PMC IPC about BIOS done
is also set along with PMC enumeration being done.
BUG=b:270942083
TEST=Able to build and boot google/rex.
Change-Id: I1cf8cb1ecadeb68c109be6b0e751a3f2c448ae4f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This adds checks for three more error bits before requesting that the
SPL fuses are updated.
- While I'm here, I'm adding the include of types.h which was previously
done through other include files, but should be done independently.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I87a7d40850c4e9ddbb2d1913c1588a919fdb29d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Use the presence of an SPL (Software Patch Level) file to trigger the
function that reads and writes the SPL fuses. The current Kconfig
option will be used to decide to write the fuses. This allows us to
see the state of the SPL update bit which determines whether or not
SPL fusing is allowed and needed before enabling the fusing.
- Refactor a bit to prepare for following changes.
- Update phrasing
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7bd2798b984673a4bd3c72f3cab52f1c9a786c67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Now that the code using the ACPI_SSDT_PSD_INDEPENDENT Kconfig symbol is
moved to soc/amd/common/block/acpi/cpu_power_state.c, also move the
Kconfig symbol to the Kconfig file in this directory.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ide18111df38d4e9c81f7d183f49107f382385d85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73550
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce the get_cstate_io_base helper function that write_cstate_entry
can call directly to get the C state control IO base address instead of
having get_cstate_info pass this Io address to each write_cstate_entry
call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I4cc80ded0a2fbc2dee9ca819e86284d9ffd58685
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The bit position of the P state enable bit in the 8 P state MSRs is
identical for all AMD chips including the family 16h model 30h APU that
lives outside of soc/amd. The other bits in those 8 MSRs are more or
less family- and model-specific.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia69c33e28e2a91ff9a9bfe95859c1fd454921b77
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The implementations of get_pstate_info of Picasso, Cezanne, Mendocino,
Phoenix and Glinda are identical, so factor it out and move it to the
common AMD SoC code. The SoC-specific get_pstate_core_freq and
get_pstate_core_power functions remain in the SoC-specific code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibe0494f1747f381a75b3dd71a8cc38fdc6dce042
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
With the exception of the generate_cppc_entries call, the
implementations of generate_cpu_entries of Picasso, Cezanne, Mendocino,
Phoenix and Glinda are identical, so factor it out and move it to the
common AMD SoC code. Since all SoCs that support CPPC already select the
SOC_AMD_COMMON_BLOCK_ACPI_CPPC Kconfig option, this can be used to only
call generate_cppc_entries for platforms where it is available.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I71323d9d071b6f9d82852479b60dc56c24f2b9ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73504
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Split the big PSP FW data into two parts, head and body. The head
needs to be located at original specific location. The body address is
more flexible. So the big body will not cover other needed FWs like
EC.
Give the body a specific named AMDFWBODY, which should be defined in
flashmap.
This is one of series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: Ia8b318f71632a2c9b97ce67486374dc24d23e63e
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72703
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Instead of hoping that the default the C state control IO address in
binaryPI won't interfere with any other IO space usage in coreboot,
assign the ACPI_CSTATE_CONTROL value to the CStateIoBaseAddress platform
config structure element to make sure that binaryPI will use a known
address for the IO port based C state control. binaryPI will write this
address to the MSR_CSTATE_ADDRESS and will then also use these IO ports
in the _CST packages in the PSTATE SSDT, so changing this won't cause
a mismatch between those two.
The default CStateIoBaseAddress in the FT4 Stoneyridge binaryPI used on
Careena is 0x1770, so this didn't collide with any other IO space
registers, but it's still much better to tell binaryPI which exact IO
addresses to use.
TEST=On Careena MSR_CSTATE_ADDRESS now contains the ACPI_CSTATE_CONTROL
IO base address 0x420 and the PSTATE SSDT has the IO address 0x421 in
the _CST package entry for the second C state which are both the
expected values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I207202802427d4bf00f283bcbd83a174ab0a2846
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5157fc031c5b19d8633132222520f582620208c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4f5743dd2e4dfdfeb3ffb2e9b964bdc75c84e6c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73502
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>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3669c66094f0137081888ebdd1af838e2ea269b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73501
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>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id97fcb74ff3d48994a3181d9c31cbbeb5a76c60a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73500
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>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6bd8879ce5968b24893b43041be98db55a4c3c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73499
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>
Instead of using a magic constant in the bit_offset field of the C state
resource for the C1 state that's entered via the MWAIT instruction, use
the existing ACPI_FFIXEDHW_CLASS_MWAIT define. This value is checked by
acpi_processor_ffh_cstate_probe in the Linux kernel.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9edc681efab15b5ceba91c8105f7dc6d687d8be8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73498
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>
Introduce the get_cstate_info helper function that populates the caller-
provided cstate_values array with the data returned by the SoC-specific
get_cstate_config_data function. From the array get_cstate_config_data
returns, only the ctype, latency and power fields are used, so the rest
can be left uninitialized. Those 3 fields are compile-time constants.
For each entry, write_cstate_entry will generate the corresponding
resource information from the given data. In the C1 case where ctype is
1, the state is entered via a MWAIT instruction, while the higher C
states are entered by doing an IO read from a specific IO address. This
IO address is x - 1 bytes into the IO region starting at
MSR_CSTATE_ADDRESS for the Cx state. So for example C2 is entered by
reading from the C state IO base address + 1. This resource information
is generated during runtime, since the contents of MSR_CSTATE_ADDRESS
aren't necessarily known at compile-time.
MAX_CSTATE_COUNT is introduced so that the caller can allocate and pass
a buffer with space for the maximum number of C state entries. This
maximum number corresponds to the number of IO addresses the CPU traps
beginning from MSR_CSTATE_ADDRESS. In practice, it's unlikely that more
than 3 or maybe 4 C states will be available though.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c36c1d604ced349c609882b9d9fe84d5f726a8d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
