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>
When the device right below the MPIO chip driver has downstream devices
without another chip in between, those downstream devices will also have
their chip_ops entry set to vendorcode_amd_opensil_genoa_poc_mpio_ops.
To avoid adding the same MPIO descriptor again for those additional
downstream devices, make sure that the chip_info pointer of the device
isn't the same as the one of the parent device, since that's only the
case for those additional downstream devices.
TEST=Onyx still boots to the payload and the MPIO configuration reported
from the openSIL code is still the same
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Nico Huber <nico.h@gmx.de>
Change-Id: I6ba90fdc83ba089127e6722778bfef29dd480bb4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80149
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Call setup_opensil, opensil_entry, and fch_init in the right order from
the init method of the SoC's chip operations. This brings this SoC both
more in line with the other SoCs and avoids using boot state hooks for
this which also makes the sequence in which those functions are called
easier to understand. Previously the boot states were used so that
setup_opensil was run before configure_mpio which was run before
opensil_entry(SIL_TP1), but since configure_mpio is called from
setup_opensil, this is no longer necessary.
TEST=Onyx still boots to the payload and the MPIO configuration reported
from the openSIL code is still the same. The FCH init code now runs
before the resource allocation like on the AMD SoCs that rely on FSP.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic752635da5eaa9e333cfb927836f0d260d2ac049
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79985
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of calling configure_mpio from the init function of the MPIO
chip struct for the first device that has this struct as chip_ops, call
if from setup_opensil. This will allow to do the calls into openSIL from
the SoC's chip_ops init function instead of having to rely on boot state
hooks. configure_mpio needs to be called after the xSimAssignMemoryTp1
call which sets up the openSIL data structures, but before the
opensil_entry(SIL_TP1) call for which the MPIO data structures need to
be filled for it to be able to initialize the hardware accordingly.
Since the vendorcode_amd_opensil_genoa_poc_mpio_ops struct now no longer
assigns configure_mpio to the init function pointer, we have to check
if the device's chip_ops pointer points to
vendorcode_amd_opensil_genoa_poc_mpio_ops instead of checking if the
chip_ops' init function is configure_mpio to match for the devices below
the MPIO chips in the devicetree.
TEST=Onyx still boots to the payload and the MPIO configuration reported
from the openSIL code is still the same
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If37077c879e266763fd2748a1a8d71c63c94729b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80148
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Since we pass va_list list to the print function, we need to use vprintk
instead of printk. Earlier versions of this code used vsnprintf and a
local buffer, but when that code was reworked to not need the temporary
buffer, it was replaced by printk instead of the correct vprintk.
TEST=Now the console output from openSIL looks as expected:
Example line from openSIL's console output when it prints the MPIO
configuration from a log some commits before this patch:
Host PCI Address - -1352681400:-1353251983:7
Same line with this patch applied looks how it's supposed to:
Host PCI Address - 0:0:0
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: Ia931cc80dea5b7eabb75cfb19f8baa9a09cd2dbf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80203
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I80559b7c86a8fd2583cb0335279f676e0aa0209e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80067
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
This commit adds support for showing different logos on the ChromeOS
firmware splash screen based on the device model (between
Chromebook-Plus and regular ChromeOS devices like Chromebook and
Chromebox). This allows OEMs to customize the branding on their
devices.
This patch also introduces three new Kconfigs:
- CHROMEOS_FW_SPLASH_SCREEN
- CHROMEOS_LOGO_PATH
- CHROMEBOOK_PLUS_LOGO_PATH
which allow users to enable the fw splash screen feature in the
vendorcode. Previously, we were using the BMP_LOGO Kconfig in
drivers/intel/fsp2_0, but we didn't want the top level Kconfigs to be
located inside the architecture specific files.
BUG=b:317880956
BRANCH=None
TEST=emerge-rex coreboot chromeos-bootimage
verify that FW splash screen appears
Change-Id: I56613d1e7e81e25b31ad034edae0f716c94c4960
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79775
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This patch ensures `chromeos_get_factory_config()` returns an
unsigned integer value because factory config represents
bit-fields to determine the Chromebook Plus branding.
Additionally, introduced safety measures to catch future
"factory_config" bit-field exhaustion.
BUG=b:317880956
TEST=Able to verify that google/screebo is branded as
Chromebook Plus.
Change-Id: I3021b8646de4750b4c8e2a2981f42500894fa2d0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79769
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch implements an API which relies on the
chromeos_get_factory_config() function to retrieve the factory
config value.
This information is useful to determine whether a ChromeOS device
is branded as a Chromebook Plus based on specific bit flags:
- Bit 4 (0x10): Indicates whether the device chassis has the
"chromebook-plus" branding.
- Bits 3-0 (0x1): Must be 0x1 to signify compliance with
Chromebook Plus hardware specifications.
BUG=b:317880956
TEST=Able to verify that google/screebo is branded as
Chromebook Plus.
Change-Id: Iebaed1c60e34af4cc36316f1f87a89df778b0857
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This code leverages the TPM vendor-specific function
tlcl_cr50_get_factory_config() to fetch the device's factory
configuration.
BUG=b:317880956
TEST=Able to retrieve the factory config from google/screebo.
Change-Id: I34f47c9a94972534cda656ef624ef12ed5ddeb06
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Acoustic noise in PCBs is a common problem and be caused by a variety
of factors, including:
Mechanical vibrations, Electromagnetic interference (EMI) and/or Thermal
expansion.
This patch adds the UPDs to FSPM header file for mitigating the acoustic
noise.
FSPM:
1. AcousticNoiseMitigation
2. FastPkgCRampDisable
3. SlowSlewRate
BUG=b:312405633
TEST=Able to build and boot google/rex.
Change-Id: Iea0bfa2f92bb82e722ffc1a0b2f1e374b32e4ebc
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79301
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
The openSIL code for the Genoa SoC is only a proof of concept, so change
the name of the Kconfig option to include this code in the build from
SOC_AMD_OPENSIL_GENOA to SOC_AMD_OPENSIL_GENOA_POC to clarify that this
is code that isn't intended or ready to be productized.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If91cdaa7c324426964bba2de2109b6c38482fab8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79574
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Even though this SoC is called 'Genoa', the openSIL implementation and
the corresponding coreboot integration is only a proof of concept that
isn't fully featured, has known limitations and bugs, and is not meant
for or ready to being productized. Adding the proof of concept suffix to
the name should point this out clearly enough so that no potential
customer could infer that this might be a fully functional and supported
implementation which it is not.
Change-Id: Ia459b1e007dcfd8e8710c12e252b2f9a4ae19b72
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77894
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To quote its repo[0]: Wuffs is a memory-safe programming language (and
a standard library written in that language) for Wrangling Untrusted
File Formats Safely. Wrangling includes parsing, decoding and encoding.
It compiles its library, written in its own language, to a C/C++ source
file that can then be used independently without needing support for
the language. That library is now imported to src/vendorcode/wuffs/.
This change modifies our linters to ignore that directory because
it's supposed to contain the wuffs compiler's result verbatim.
Nigel Tao provided an initial wrapper around wuffs' jpeg decoder
that implements our JPEG API. I further changed it a bit regarding
data placement, dropped stuff from our API that wasn't ever used,
or isn't used anymore, and generally made it fit coreboot a bit
better. Features are Nigel's, bugs are mine.
This commit also adapts our jpeg fuzz test to work with the modified
API. After limiting it to deal only with approximately screen sized
inputs, it fuzzed for 25 hours CPU time without a single hang or
crash. This is a notable improvement over running the test with our
old decoder which crashes within a minute.
Finally, I tried the new parser with a pretty-much-random JPEG file
I got from the internet, and it just showed it (once the resolution
matched), which is also a notable improvement over the old decoder
which is very particular about the subset of JPEG it supports.
In terms of code size, a QEmu build's ramstage increases
from 128060 bytes decompressed (64121 bytes after LZMA)
to 172304 bytes decompressed (82734 bytes after LZMA).
[0] https://github.com/google/wuffs
Change-Id: If8fa7da69da1ad412f27c2c5e882393c7739bc82
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Based-on-work-by: Nigel Tao <nigeltao@golang.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78271
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- First a console is set up for opensil.
- After that a region in CBMEM is reserved and passed to opensil which
will use it as a buffer for input/output information.
- Finally opensil is called and the return value handled.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4833a5a86034a13e6be102a6b68c3bb54108bc9a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
