Use amd_pci_domain_read_resources function that gets the configured MMIO
regions for the PCI root domain from the data fabric's MMIO decode
registers instead of using pci_domain_read_resources. This results in
the same IO port range being used by the allocator, but makes sure that
the allocator will only allocate non-fixed MMIO resources in the address
ranges that get decoded to the PCI root complex. In order for the PCI0
_CRS ACPI resource template to match the decoded PCI root domain MMIO
windows, use amd_pci_domain_fill_ssdt to generate the _CRS ACPI code
instead of having a mostly hard-coded _CRS method in the DSDT. This
makes sure that the OS will know about the MMIO regions it is allowed to
used.
Before this patch, only the region from TOM1 to right below
CONFIG_ECAM_MMCONF_BASE_ADDRESS was advertised as usable PCI MMIO in the
PCI0 _CRS method. Also the resource allocator didn't get any constraint
on which address ranges it can use to put the non-fixed MMIO resources.
This approach worked until now, since all address range from 0 up to
right below TOM1 was filled with either usable or reserved memory and
the allocator was allocating beginning right from TOM1, since it was
using the bottom-up allocation approach and everything below TOM1 was
already in use. The MMIO region from TOM1 to right below
CONFIG_ECAM_MMCONF_BASE_ADDRESS also matched the MMIO decode window
configured in the data fabric's MMIO decode registers, so everything
seemed to work fine. However, when either selecting
RESOURCE_ALLOCATION_TOP_DOWN or enabling above 4GB MMIO, things broke
badly. This was partially due to the allocator putting non-fixed MMIO
resources in regions that weren't decoded to the PCI root, since AMD
family 17h and 19h silicon doesn't subtractively decode PCI MMIO and the
wrong ranges the allocator used also weren't advertised in ACPI.
TEST=Even when selecting RESOURCE_ALLOCATION_TOP_DOWN that usually ends
up with a non-working system when the MMIO ranges aren't reported
correctly to the resource allocator due to the reasons descried above,
Ubuntu 22.04 LTS still boots on Mandolin both with SeaBIOS and EDK2
payload and Windows 10 boots with EDK payload. There's however an EDK2
bug that results the MMCONFIG region not being advertised in the e820
table, which causes Linux to not use the MMCONFIG and fall back to the
legacy PCI config access method. This only happens with EDK2 payload and
everything works fine when using SeaBIOS as payload. That e820 issue is
unaffected by this patch.
At the end of the data_fabric_set_mmio_np call, this is the data fabric
MMIO register configuration:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
The limit of the data fabric MMIO decode register 1 is configured as
0xffffffffffff although this is way beyond the addressable memory space.
add_data_fabric_mmio_regions fixes this up, so the range that gets
passed to the allocator in that case is 0x7fcffffffff which takes both
the reserved most significant address bits used for the memory
encryption and the 12GB reserved data fabric MMIO at the top of the
usable address space into account.
This results in the following domain ranges passed to the resource
allocator:
DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done
DOMAIN: 0000 mem: base: fc000000 size: 0 align: 0 gran: 0 limit: febfffff
DOMAIN: 0000 mem: base: 10000000000 size: 0 align: 0 gran: 0 limit: 7fcffffffff
DOMAIN: 0000 mem: base: d0000000 size: 0 align: 0 gran: 0 limit: f7ffffff
The IO resource producer region is split into two parts to not cover the
PCI config IO region resource consumer. This results in these resources
being added to the PCI0 _CRS resource template:
amd_pci_domain_fill_ssdt ACPI scope: '\_SB.PCI0'
PCI0 _CRS: adding busses [0-3f]
PCI0 _CRS: adding IO range [0-cf7]
PCI0 _CRS: adding IO range [d00-ffff]
PCI0 _CRS: adding MMIO range [fc000000-febfffff]
PCI0 _CRS: adding MMIO range [10000000000-7fcffffffff]
PCI0 _CRS: adding MMIO range [d0000000-f7ffffff]
PCI0 _CRS: adding VGA resource
Kernel version 5.15.0-43 from Ubuntu 2022.4 LTS prints this in dmesg:
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-3f]
pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff window]
pci_bus 0000:00: root bus resource [mem 0xfc000000-0xfebfffff window]
pci_bus 0000:00: root bus resource [mem 0x10000000000-0x7fcffffffff window]
Another noteworthy thing I wasn't aware of at first when testing ACPI
changes on Windows 10 is that a normal Windows shutdown and boot cycle
won't result in it processing the changed ACPI tables; you have to tell
it to reboot to do a proper full boot where it will process the updated
ACPI tables (and fail if it dislikes something about the ACPI tables and
bytecode).
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia24930ec2a9962dd15e874e9defea441cffae9f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74712
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Generate the PCI0 _CRS ACPI resource template to tell the OS which PCI
bus numbers and IO and MMIO regions can be used for PCI devices below
_SB/PCI0. This data corresponds to what amd_pci_domain_scan_bus and
amd_pci_domain_read_resources provided to the resource allocator. This
makes sure that the PCI0 _CRS ACPI resource template matches the
constraints the resource allocator used when allocating resources.
TEST=With also the rest of the current patch train applied, the
generated _CRS resource template contains the expected PCI bus numbers
and IO and MMIO resources and both Linux and Windows boot on Mandolin.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaf6d38a8ef5bb0163c4d1c021bf892c323d9a448
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74843
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Provide amd_pci_domain_scan_bus to enumerate the PCI buses in the one
PCI root domain and amd_pci_domain_read_resources to read the MMIO
regions that the resource allocator can use to allocate the PCI MMIO
BARs in the one PCI root domain from the corresponding data fabric MMIO
decode registers. This makes sure that the allocator will only put PCI
MMIO resources in areas that are decoded to the PCIe root complex. The
current code only covers the case of a system with one PCI root where
all PCI bus numbers belong to the only PCI root, all IO ports get
decoded to the only PCI root and the MMIO regions from the data fabric
MMIO decode registers get decoded to the only PCI root. In future
patches, this will be extended to also support the multi PCI root case.
TEST=With also the rest of the current patch train applied, the resource
allocator uses the constraints on the MMIO regions and both Linux and
Windows boot on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4aada7c8a2a43145ad08d11d0a38d9cdc182b98e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74717
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In case the secure memory encryption is enabled, some of the upper
usable address bits of the host can't be used any more. Bits 11..6 in
CPUID_EBX_MEM_ENCRYPT indicate how many of the address bits are taken
away from the usable address bits in the case the secure memory
encryption is enabled.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia810b0984972216095da2ad8f9c19e37684f2a2e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75623
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Meteor Lake SOC has a separate I/O Expander (IOE) die.
SRAM from this IOE die contains crashlog records for the IPs
of the IOE die.
This patch adds functions with empty implementation using
__weak attribute for IOE die related crashlog, changes common
data structures while maintaining backwards compatibility,
and support for filling IOE crashlog records, guarded by
SOC_INTEL_IOE_DIE_SUPPORT config and makes cl_get_pmc_sram_data
function as weak because it needs SOC specific implementation.
Bug=b:262501347
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog
Change-Id: Id90cf0095258c4f7003e4c5f2564bb763e687b75
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75475
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This makes sure that the resource allocator won't use those ports for
anything else.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I014ffe3ee94ec153e91113f9a17e89f24ca040b3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75619
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This makes sure that the resource allocator won't use those ports for
anything else.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie42260902ee2b383dd5867ac813cae029f706f2d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75556
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This commit adds a configuration option to enable RMT in the coreboot
build for the Intel Xeon SP SPR platform.
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: I9b9276116c22cfbbec132d7a1b0026a52a51398a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75416
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Based on the power sequence of the panel [1], the power on T2 sequence
VSP to VSN should be larger than 1ms, and the power off T2 sequence VSP
to VSN should be larger than 0ms. We modify the power sequence to meet
the datasheet requirement.
[1] B5 TV110C9M-LL0 Product Specification Rev.P0
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: I4ccb5be04062a0516f84a054ff3f40afbf5279be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75512
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Follow 57263_FP8_MBDG_rev_0_92 Table.57 to update the alias. We
can match the schematic for now.
BUG=b:285793461
TEST=USB still works.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Id1058279fe5b0e3131608a0b9bbd708dbbde7e87
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This adds printing content of 'manifest' file at ramstage.
It allows to learn about blobs version used to build the coreboot
binary, which is useful when investigating bugs.
Version data are stored in CBFS file, which was generated during
coreboot build. If AMD FW blobs will be manually replaced in coreboot
image, versions from CBFS file are no longer valid.
Log:
AMDFW blobs version:
type: 0x01 ver:00.3c.01.18
type: 0x08 ver:00.5a.28.00
type: 0x30 ver:2b.25.b0.10
type: 0x73 ver:00.3c.01.18
BUG=b:224780134
TEST=Tested on Skyrim device
Change-Id: I8df54b74cd987b4a3be635932d38ea178d0b0311
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74269
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The code is supposed to output debug messages but is commented out, so
do the same for variables.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ief1f9d2175fe1375fe6ac4bb0765b00513321fa6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
To support the localized text, we need to get the locale id by vboot
APIs and read raw string content file: preram_locales located at either
RO or RW.
The preram_locales file follows the format:
[string_name_1] [\x00]
[locale_id_1] [\x00] [localized_string_1] [\x00]
[locale_id_2] [\x00] [localized_string_2] ...
[string_name_2] [\x00] ...
This code will search for the correct localized string that its string
name is `memory_training_desc` and its locale ID matches the ID vb2api
returns. If no valid string found, we will try to display in English
(locale ID 0).
BUG=b:264666392
BRANCH=brya
TEST=emerge-brya coreboot chromeos-bmpblk chromeos-bootimage
Change-Id: I7e3c8d103c938a11b397c32c9228e44e31c3f01d
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch ensures to update the FSP-M UPDs related to PCIe RP mask
properly as per the SoC type.
For example: PCIe RPs belong to the SoC/IOE die for MTL-U/P whereelse
PCIe RPs are from PCH die in case of MTL-S.
BUG=b:276697173
TEST=Able to build and boot google/rex.
Change-Id: Ice81553274682476bb4c927061b1196dc142836d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75608
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 introduces the different SoC flavors of Intel Meteor Lake as:
* MTL-U
* MTL-P
* MTL-S
MTL-U and MTL-P are PCH less designs, while MTL-S is with PCH die.
The task for mainboard is to specify the correct SoC type rather than
selecting the MTL SoC by default.
This change is necessary to support the different SoC flavors of Intel
Meteor Lake.
BUG=b:276697173
TEST=Able to build and boot google/rex.
Change-Id: I27404bbbd0b489412953118e140f6f39b6e43426
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75606
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: Tarun Tuli <taruntuli@google.com>
pci_rom_probe() can allocate memory when mapping a CBFS
file, so pci_rom_free() should be called before leaving
the function.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: Ie6fbbfd36f0974551befef4d08423a8148e151e7
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74779
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Move microcode load/unload to pre_mp_init and post_mp_init callbacks.
It allows to make sure that ucode is freed only if all APs updated
microcode.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: I200d24df6157cc6d06bade34809faefea9f0090a
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The phoenix SoC does not support multiple EFS locations. Set the default
to the only valid value and prevent mainboard overrides by making the
option non-user-configurable.
TEST=build birman-phoenix
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I0f720dbadf2d28a3c39daa4bd653a407be4893d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74249
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
For a unification of the naming convension, change from pascal case to
snake case style for parameter 'SataPortsEnable'.
Change-Id: I0df35125360eb42a03d5445011d72842cb2b8d7e
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75553
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
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: Sean Rhodes <sean@starlabs.systems>
Change-Id: Iadbce3124a88cf5be0aebde4a76ec6fd4b670216
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Intel's APL 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: I52c3566fb3c959ada6be33f0546ac331f4867d10
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
In cases where there are limitations on the mainboard it can be
necessary to limit the used SATA speed even though both, the SATA
controller and disk drive support a higher speed rate. The FSP parameter
'SpeedLimit' allows to set the speed limit.
It should be noted that Gen 3 equals the default value '0'. This means
that inside FSP the same code is executed.
This patch provides a chip config so that this FSP parameter can be
set as needed in the devicetree on mainboard level.
Change-Id: I9c3eda0649546e3a40eb24a015b7c6efd8f90e0f
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75364
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Check existence of crashlog records in CBMEM before copying them
to BERT, otherwise it can lead to NULL pointer access.
Bug=None
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog.
Change-Id: I4288011866283a3a5fb8ec9e10cd51b794052b4e
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75528
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Do not copy the crashlog record if the record is 0xdeadbeef
Bug=None
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog.
Change-Id: I0edbf6902685a882876d525e63c5b602c1590ea1
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Check pmc_record_size variable for collecting PMC records,
instead of cpu_record_size variable.
Bug=None
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog.
Change-Id: I4c35ba2bcf757231aa2872802eb82d4d50742cd9
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75526
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the default pci_domain_read_resources() is used,
keep 32-bit memory resources below the limit given by
CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT. This serves as a
workaround for missing/wrong reservations of chipset
resources.
This will help to get more stable results from our own
allocator, but is far from a complete solution. Indvi-
dual platform ASL code also needs to be considered, so
the OS won't assign conflicting resources.
Most platforms have reserved space between 0xfe000000
and the 4G barrier. So use that as a global default.
In case of `soc/intel/common/`, use 0xe0000000 because
this is what is advertised in ACPI and there are traces
of resources below 0xfe000000 that are unknown to core-
boot's C code (PCH_PRESERVED_BASE?).
Tested on QEMU/Q35 and Siemens/Chili w/ and w/o top-
down allocation. Fixes EHCI w/ top-down in QEMU.
Change-Id: Iae0d888eebd0ec11a9d6f12975ae24dc32a80d8c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75102
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The TPS65132S is designed to supply positive/negative driven
application. It communicates through standard I2C compatible interface,
and it intergrates a EEPROM whose contents will be loaded into the
register at startup. Since TPS65132S is used in staryu and geralt
projects, we move the implementation to mediatek/common.
The datasheet: TPS65132-Single-Inductor-Dual-Output-Power-Supply.pdf
BUG=b:282902297
TEST=boot starmie to firmware screen
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: Iad2c9bdea5824455efcef18b44876111061cfa1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75488
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This brings the ACPI code more in line with both what the new code for
the AMD SoCs will do and also what the current Intel code does. This was
mainly done to have a reduced delta to the new AMD domain resource
handling functions to debug it, but it might still be useful to upstream
this change.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8cca05976b1c9d4e994e407b8c0197da7dd35eb2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75487
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>
cbfs_boot_map_optionrom will generate lower case hex digits for the
filename to look for in CBFS, so make sure that the file name will use
lower case hex digits and no upper case hex digits.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1d4daa04120de0f2c853a44691b7e2c52eb2af20
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75483
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit enables the build for IO Margining, ensuring that ASPM is
disabled and certain FSP knobs are adjusted in coreboot as below
1. Enable DFXEnable
2. Disable PcieGlobalAspm
3. Disable KtiLinkL1En & KtiLinkL0pEn
Since the FSP UPD does not provide all the necessary knobs for IO
Margining, the following settings need to be applied during the FSP
build process:
1. Enable PcdBiosDfxKnobEnabled
2. Disable PchDmiAspm
3. Enable SataTestMode
4. Enable WmphyMargining
5. Disable IioErrorEn
TEST=Build for IBM sbp1 board.
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: Ie306d12943adb76411d55358548b5cb2eb3a95be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75415
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
EFS header is mapped during PSP verstage and bootblock to read some SPI
configuration. After use it is left unmapped. Unmap the EFS region after
use.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I865f45a3d25bc639eb8435b54aa80895ec4afd27
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75455
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfs_unmap does not unmap the mapped region from the boot device. This
leads to some resource leaks eg. TLB slots in PSP. Explicitly call
rdev_munmap on the address mapped by cbfs_map.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I51b9d066a40103f2ebdf2ef2fc3da13beb467921
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
cbfs_unmap does not unmap the mapped region from the boot device. This
leads to some resource leaks eg. TLB slots in PSP. Explicitly call
rdev_munmap on the address mapped by cbfs_map.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: If1d355972cc743b8d8c451e1b3f827abd15e98fe
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
On FMAP without RW slots, PSP verstage fails to build because of
reference to FMAP_SECTION_FW_MAIN_A_*. Instead extract the offset and
size of relevant sections using fmap_locate_area().
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I29997534c6843b47a36655431f79e5c70bd17f9b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Add support to update power limit values for variants.
Until now, each SoC implements this themselves.
To avoid code duplication, add this to common code.
BRANCH=None
BUG=b:270664854
TEST=Built and verified power limit values as below log message
for 15W SKU on Rex board.
Overriding power limits PL1 (mW) (10000, 15000) PL2 (mW)
(57000, 57000) PL4 (W) (114)
Change-Id: I414715f211d816bbfad03a673ca96dd5df94caeb
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74620
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>
Hook the SaGvFreq, SaGvGear upds so that mainboard can change the
settings via devicetree. Meteor Lake supports 4 SaGv work points and it
can dynamically scale the work point based on memory bandwidth
utilization. Dynamic gearing technology allows the Memory Controller to
run at 1:1, 1:2 or 1:4 ratio of DRAM speed. The gear ratio is the ratio
of DRAM speed to Memory Controller Clock.
BUG=b:282164577
TEST=Verified the settings on google/rex using debug FSP logs.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I37169880af4019675374594e90735b5d7d0873b8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75290
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds an enum macro to define the different SaGv work points.
The enum macro is named `sagv_wp_bitmap` and it has three values:
The goal is to choose the optimal SaGv work point for the target
platform after considering the two inputs as power consumption and performance. The first group is for workloads that require high performance, even if it means consuming more power. The second group
is for workloads that can tolerate lower performance, in order to save
power.
SAGV_POINTS_0_1: The highest power consumption, but also the highest
performance.
SAGV_POINTS_0_1_2: A lower power consumption than work point
SAGV_POINTS_0_1, but also a lower performance.
SAGV_POINTS_0_1_2_3: The lowest power consumption, but also the lowest
performance.
Set SaGv work points after reviewing the power and performance impact
with SaGv set to 1 (Enabled) and various considering various work points
between 0-3 being enabled.
BUG=b:267879107
TEST=Able to build google/rex.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I4af0038f2799a458d1b006270068341f65d36609
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75362
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add CPU PortID for GPIO communities in order to calculate
IOM Aux Bias data correctly.
BUG=b:283044004
TEST=able to detect external display
Signed-off-by: Marx Wang <marx.wang@intel.com>
Change-Id: I79f27fb0b6bde0a4ce2466eaf707166a952fad81
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75390
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: Tarun Tuli <taruntuli@google.com>
The data payload size of PCIe root ports can be set to either 128
(default) or 256 bytes. A bigger payload size can improve PCIe data
throughput on the given port. FSP-S provides a parameter to configure
this value.
This patch provides a chip config so that this FSP parameter can be set
as needed in the devicetree on mainboard level.
Change-Id: I5798a72adaa8089dda0b4bc12266b5a235ed4aa3
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75126
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
1. Rename set_cmos_mrc_cold_boot_flag() to soc_set_mrc_cold_boot_flag
in case a certain platform may not support this via CMOS data, and
the function could in turn calls mainboard defined method in the
future. Move the code into soc_util.c.
2. Remove redundant static get_system_memory_map() from cpx/romstage.c
and call the soc_util.c one.
Change-Id: Ib7d9bed9092814658f4a0b1d6dcf3c7d79178048
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Earlier the entire SPI ROM is mapped at the start of verstage and then
unmapped at the end of verstage. With CB:74606, this behavior has
changed. So unmap the hash table CBFS file after usage.
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: I5c605f8ba8bbd571b589b3cdf91e9cc71d711c1c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75092
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
