This commit removes config guard around FSPM_ARCH_UPD from the
FspApi.h header file. This change is done to ensure
that this header file can be used with both x86_32 and x86_64
architectures and also with different FSP specification versions.
The following modifications are made:
- Removes PLATFORM_USES_FSP2_X86_32 config guard around
FSPM_ARCH_UPD, this was added to isolate the structure from
x64 build. This is not really required since the x64 build uses
FSP2.4 structures.
BUG=b:343428206
TEST=Verified x86_32 and x86_64 builds on Meteor Lake board (Rex)
Change-Id: Idc849de73723036323f81dfd055730f6669cd52e
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82425
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This commit introduces new header files of V3471.91 for the x86_64
architecture in the fsp2_0/meteorlake directory. FSP2.4 brings FSP
64-bits support and the soc Kconfig file has been updated to select
this new header path when FSP2.4 is in use.
BUG=b:329034258
TEST=Verified x86_32 and x86_64 builds on Meteor Lake board (Rex)
Change-Id: Ib41b57e794311db729ac65a968f562aa127e86c3
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82473
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: Dinesh Gehlot <digehlot@google.com>
This commit moves FSP V3471.91 header files for Meteor Lake
into a new x86_32 directory to better organize the files based
on the architecture. The Kconfig file has been modified accordingly
to reflect the new paths of the relocated headers.
BUG=b:329034258
TEST=Verified x86_32 and x86_64 builds on Meteor Lake board (Rex)
Change-Id: Id30186a8b1b5a9082f498e18a3378f5e9907b668
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82424
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
<stdio.h> header is used for input/output operations (such as printf,
scanf, fopen, etc.). Although some input/output functions can manipulate
strings, they do not need to directly include <string.h> because they
are declared independently.
Change-Id: Ibe2a4ff6f68843a6d99cfdfe182cf2dd922802aa
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82665
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chip drivers in the devicetree use the path where the corresponding
chip.h file resides both to include this chip.h file in the static.c
generated by util/sconfig from the devicetree and also for the names of
the chip config and chip ops struct. To be able to build a SoC using
either the MPIO chip driver from the openSIL stub or from the actual
openSIL glue code without needing different devicetree files for the
different cases, introduce a common MPIO chip.h file that then includes
the correct MPIO header file. The chip config and ops structures also
need to be renamed to take this change into account.
Thanks to Matt for pointing out how to make the path to the actual MPIO
chip.h file configurable via a Kconfig setting. This allows overriding
this path from site-local without the need to have any reference to
site-local in the upstream code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iead97d1727569ec0d23a2b9c4fd96daff4bebcf6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82262
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
RAMOOPS memory region was being overwritten by coreboot bmp_load_logo()
function. The CBMEM_ID_FSP_LOGO region created during bmp_load_logo()
was overlapping with RAMOOPS space created earlier. This resulted in
memory corruption of RAMOOPS buffer.
To prevent this, the RAMOOPS region allocation is moved to
BS_DEV_INIT_CHIPS phase from earlier BS_WRITE_TABLES phase of boot.
BUG=b:332910298
TEST=build and boot coreboot image on google/rex HW. Check RAMOOPS
CBMEM region creation using cbmem -l command
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: Ibae06362cd80eacb16f6cf0eed8c9aa1fbfb2535
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82042
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This change refactors EDK2 essential header management within the FSP
directory to ensure compatibility.
Header selection is now dynamically based on:
* FSP specification version: Distinguishes between 1.1 and 2.x
* EDK2 revision (for FSP 2.x): Chooses the appropriate FSP info header
FSP Header
|
|-> FSP 1.1 specification FSP_INFO_HEADER
|-> FSP 2.0 specification EDK2 release
|-> EDK2_2017 FSP_INFO_HEADER
|-> EDK2_2020 FSP_INFO_HEADER
|-> EDK2_2021 FSP_INFO_HEADER
|-> EDK2_2023 FSP_INFO_HEADER
Any .C/.H file requires to include FSP_INFO_HEADER can now just add the
FSP header alone.
BUG=b:242829490
TEST=Able to build google/rex0 with 64-bit FSP.
Change-Id: I29e5002821843c9cffbc8f6317d1062175f014ff
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81623
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces the FSP_SIG macro into EDK2 headers to ensure
compilation compatibility when using FSP 2.x specifications.
Previously, the macro was only defined for FSP 1.1.
BUG=b:242829490
TEST=Successful build of google/rex0 with 64-bit FSP.
Change-Id: I4f97fc303ca2881ccd17b4d149d01c3b671dbbde
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81622
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
GNR N-1 FSP headers are a set of stub headers used to fulfill
build sanity check for GNR SoC and CRB codes before the formal
FSP headers are published. The N-1 headers are forward compatible
with the later formal headers.
Change-Id: I1c8125dd64e5a9619073c2f17aeade1d33607870
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This prepares the code for enabling both CONFIG_TPM1 and CONFIG_TPM2
during compilation, in which case actual TPM family in use can be
determined at runtime.
In some places both compile-time and runtime checks are necessary.
Yet in places like probe functions runtime state checks don't make sense
as runtime state is defined by results of probing.
Change-Id: Id9cc25aad8d1d7bfad12b7a92059b1b3641bbfa9
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69161
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No functional changes. Refactor code such that there won't be any
compiler or linker errors if TSS 1.2 and TSS 2.0 were both compiled
in.
One might want to support both TPM families for example if TPM is
pluggable, while currently one has to reflash firmware along with
switching TPM device.
Change-Id: Ia0ea5a917c46ada9fc3274f17240e12bca98db6a
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Print that the MPIO chip of one of the MPIO-related PCI device functions
is unused and is skipped, if the type is IFTYPE_UNUSED and the
corresponding PCI device function isn't enabled. This allows to
differentiate between this case and the case where the type isn't
IFTYPE_UNUSED.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4fc28d39a229494b487b300b28f92bf3adad66f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81384
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since we're already passing a pointer to the corresponding device to
per_device_config, we don't need to pass the chip_info as separate
parameter. Before moving the PCIe port function device below the MPIO
chip, the chip_info struct was from a different device, so that change
allows this simplification.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0466f7ad2f5c9874d45712fa9f89b978bd2a09bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Move the gpp_bridge_* device functions that are bridges to the external
PCIe ports below the corresponding mpio chip. This avoids the need for
dummy devices and does things in a slightly more coreboot-native way.
TEST=PCIe lane config reported by openSIL is identical
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: I7e39bf68d30d7d00b16f943953e8207d6fe9ef41
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81340
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove those MSVC compiler defaults checks so that the GCC defaults for
wchar_t can be used with UDK_202111_BINDING Kconfig.
Compilation error:
src/vendorcode/intel/edk2/edk2-stable202111/MdePkg/Include/Base.h:807:25:
error: static assertion failed: "sizeof (L\'A\') does not meet UEFI
Specification Data Type requirements"
src/vendorcode/intel/edk2/edk2-stable202111/MdePkg/Include/Base.h:807:25:
error: static assertion failed: "sizeof (L\"A\") does not meet UEFI
Specification Data Type requirements"
BUG=b:296433836
TEST=Able to build google/crassk with UDK_202111_BINDING.
Change-Id: Ib2716436a910b43a5e546afdedb9eec88c5da8c6
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81328
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add IFTYPE_UNUSED as first element to the mpio_type enum. This allows
checking if the type was set in the devicetree, since the default will
now be IFTYPE_UNUSED. If the type is set to IFTYPE_UNUSED although the
corresponding PCI device function, a warning is printed and the PCI
device function is disabled.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I85e2589c021b4f05662369fd551146b6f2fa0ad4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add a stub MPIO chip driver to the openSIL stub code, so that the
devicetree entries needed for the MPIO chip can already be added to the
mainboard's devicetree files. This driver won't do anything, but still
allows the register settings in the devicetree to be set to make
switching over to the actual openSIL code and the corresponding glue
code easier.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib4f5c232859b9abcd10bfa5c21e2f2c3a70b4b0e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81100
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
This reverts commit b5f6320c69.
ADL-N FSP uses 202111 Edk2. There are structure definition changes
between 202005 and 202111. One of change is in FSP_INFO_HEADER structure.
This patch is to bring back support of edk2-stable202111.
BUG=b:296433836
TEST=Able to build google/crassk.
Change-Id: Id1d3e2c5b368a479e637f3ab3d18e242607849ed
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
* Introduces logic to display context-specific boot splash logos.
* Logo selection considers:
* Chromebook-Plus hardware compliance (using factory_config).
* VPD-based product segmentation (soft-branded vs. regular
chromebook).
* Default Chromebook logo as fallback for regular Chromebook.
This patch fixes the problem where existing logic was unable to pick
correct ChromeOS boot splash logo based on the product segmentation.
Relation between product segment and boot splash screen:
1. Chromebook-Plus Hard-branded device: Renders "cb_plus_logo.bmp" logo
2. Chromebook-Plus Soft-branded device: Renders "cb_plus_logo.bmp" logo
3. Regular Chromebook device: Renders "cb_logo.bmp"
BUG=b:324107408
TEST=Verified logo selection based on compliance and product
requirements.
Change-Id: I9bb1e868764738333977bd8c990bea4253c9d37b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80738
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Add FSP header files for Twin Lake. Currently these are just a copy of
ADL-N headers.
BUG=none
BRANCH=firmware-nissa-15217.B
TEST=Build and boot Google/Yaviks with Twin Lake kconfig enabled
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I37579335c784866ebbf978e28936abf046a85b48
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80698
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Macros MAX_ACPI_MEMORY_AFFINITY_COUNT and MAX_SRAT_MEM_ENTRIES_PER_IMC
are ACPI table specific, and could be used across Xeon-SP SoCs.
This patch moves their definition from FSP header to Xeon-SP layer
ACPI header.
TEST=intel/archercity CRB
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Change-Id: I6c3a84b04a452bc8d4217947a7d12f050c94b56b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80629
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a stub implementation of the openSIL interface between coreboot and
vendorcode. This can be used to add most of the coreboot-side support
for a SoC using openSIL without the actual opnSIL code already being
publicly available. Once the corresponding openSIL code is available,
the SoC can then switch over to using the actual openSIL implementation.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9284b0cbacba6eae7e2e7e69bc687f015076c2b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80292
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Provide 3 separate functions for each openSIL time point instead of one,
so that we don't need the xSIM-api header file to be included in
opensil.h to decouple the coreboot code more form the openSIL code. This
will allow to create an openSIL stub implementation to already get most
of the coreboot-side SoC code in place before the openSIL source code is
done and released.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I969bc0862560b7254c48f04e9a03387417f328bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Since reporting the PCI ECAM MMCONF MMIO region and the IO ports for the
legacy PCI config space access is needed on all AMD SoCs, implement a
common add_pci_cfg_resources function that reports both and gets called
from amd_pci_domain_read_resources and don't report those in the SoC-
specific code any more. The only functional change is that on Genoa now
the IO ports used for the legacy PCI config space access get reserved.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibbcc2aea4f25b6dc68fdf7f360e5a4ce53f6d850
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
To make add_opensil_memmap match the other function that are directly or
indirectly called by amd_pci_domain_read_resources, pass the resource
index as a pointer instead of passing it by value and then returning the
new resource index.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6a17e488a01cc52b2dab5dd3e3d58bdf3acb554d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80269
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Macros can be confusing on their own; hiding commas make things worse.
This can sometimes be downright misleading. A "good" example would be
the code in soc/intel/xeon_sp/spr/chip.c:
CHIP_NAME("Intel SapphireRapids-SP").enable_dev = chip_enable_dev,
This appears as CHIP_NAME() being some struct when in fact these are
defining 2 separate members of the same struct.
It was decided to remove this macro altogether, as it does not do
anything special and incurs a maintenance burden.
Change-Id: Iaed6dfb144bddcf5c43634b0c955c19afce388f0
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80239
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
