The tree contains engineering sample boards, that ship with
pre-production Meteor Lake SoC. These boards are not sold.
BUG=b:300652989
TEST=Ensure mainboards like google/rex4es and screebo4es have
`SOC_INTEL_METEORLAKE_PRE_PRODUCTION_SILICON` config enabled.
Change-Id: I1a875a0f1d2c38582f35250ebe645e53599f62de
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77992
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Certain Intel Meteor Lake specific features are only enabled in
production silicon (not available in early SoC aka pre-production
silicon).
- SPI usage for production SoC is much optimized compared to pre-
production silicon.
- MIPI driver requires a way to identify between pre-prod vs prod
silicon.
This patch adds config options to select the Pre-Production
aka Engineering Silicon (ES). The mainboard users can specify which
underlying SoC is being used for the target platform.
BUG=b:300652989
TEST=No change in the functionality, just added new configs.
Change-Id: I60fe11c1151a3a6c290cd0105eb570cb78e81797
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Add the eMMC MMIO device to the devicetree and make it use the common
AMD eMMC driver. Since there is now a device for this in the devicetree,
also use this device to determine if the FSP should be told if the eMMC
controller is supposed to be disabled.
TEST=On Mandolin the eMMC controller both disappears in the Windows 10
device manager and in dmesg on Ubuntu 2022.04 LTS
TEST=Morphius with NVMe SSD still works
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5453b69df776d2ce1f3be11e37cd26c8c64f0cd5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
When the eMMC MMIO device is enabled in the devicetree, it needs to be
exposed in ACPI in order for the OS driver to be able to attach to it.
The Cezanne eMMC controller isn't used in google/guybrush, so this the
code path where the eMMC MMIO device is enabled in the devicetree can't
be easily tested.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I69ff79b2d1c6a08cf333a2bb3996931962c2c102
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Add a separate Kconfig option for adding np_region.c to the build. Only
the code for Picasso, Cezanne, Mendocino, Phoenix and Glinda call
data_fabric_set_mmio_np which is implemented in that file, so only
select the new SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig option
for those.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic49ce039462b52e2c593c7d2fef43efc50901905
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77987
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
tis_init calls into tis_probe and returns an error or success, simplify
the call stack by removing the current tis_init implementation and
renaming tis_probe to tis_init.
BUG=None
TEST=builds
Change-Id: I8e58eda66a44abf5858123cf9bcf620626f1b880
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77943
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Patch adds:
- vboot_fail_and_reboot() for vboot failures handling.
- reboot() weak implementation for payloads to implement, used
by vboot_fail_and_reboot().
- vboot_recovery_mode_enabled() to check if recovery mode flag is set in
vboot context. Implemented for future libcbfs implementation
of VBOOT_CBFS_INTEGRATION in libpayload.
BUG=b:197114807
TEST=none
Change-Id: I53d1955573d54bc56d05f7780c18dcc8ac1fd399
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
To fully and easily implement fallback/recovery in libcbfs with vboot
support the codebase requires access to vboot context. Moving context
management to libpayload allows to avoid unnecessary overhead and code
complication and still allows payloads to access it in a way it was
designed. Access to this codebase will also allow implementation of e.g.
vboot_fail_and_reboot() and other helpful utilities used by coreboot and
depthcharge.
BUG=b:197114807
TEST=make unit-tests
TEST=Build and boot on google/ovis4es with CL:4839296 and
VBOOT_CBFS_INTEGRATION enabled
Change-Id: Id719be7c4f07251201424b7dc6c1125c6b5756d8
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Use data_fabric_get_mmio_base_size in data_fabric_print_mmio_conf
instead of open coding the functionality. This will fix the printing of
the MMIO config in the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO
case which wasn't handled properly before.
TEST=Console output from this function doesn't change on Mandolin:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 0 ffff 90 9
4 fed00000 fed0ffff 93 x x 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If602922648deca0caef23a9999c82acdd128b182
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Since vboot_extend_pcr() returns vb2_error_t, the return type of
extend_pcrs() should be vb2_error_t too.
Also fix an assignment for vboot_locate_firmware(), which returns int
instead of vb2_error_t.
Change-Id: I1a2a2a66f3e594aba64d33cfc532d1bd88fa305e
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
For GICD and GICR a SOC needs to implement 2 callbacks to get the base
of those interrupt controllers.
For all the cpu GIC the code loops over all the DEVICE_PATH_GICC_V3
devices in a similar fashion to how x86 lapics are added. It's up to the
SOC to add those devices to the tree.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5074d0a76316e854b7801e14b3241f88e805b02f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76132
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot offers two vboot schemes VBOOT_SLOTS_RW_A and
VBOOT_SLOTS_RW_AB. When VBOOT_SLOTS_RW_AB is not selected then the
resulting image is rather not expected to have the FW_MAIN_B FMAP
region. When only RW_A region is used, vboot does additional full_reset
cycles to try RW_B, even though it does not exist / the build was not
configured for two RW partitions. To avoid it, a new vboot context
flag has been introduced, VB2_CONTEXT_SLOT_A_ONLY, which can be set
right after context initialization to inform vboot about absence of
slot B. This will result in less full_reset cycles when vboot runs
out of available slots and cause vboot to switch to recovery mode
faster.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ie123881a2f9f766ae65e4ac7c36bc2a8fce8d100
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75462
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit dc7cc5bc6e ("mb/google/skyrim: Disable
USE_SELECTIVE_GOP_INIT") but limits the default enablement to Skyrim
variant only, to allow for continued testing.
BUG=b:271850970
BRANCH=skyrim
TEST=build/boot ChromeOS R117+ on google/skyrim, verify no display init
failures with feature enabled on cold/warm boots or S0i3 resume.
Change-Id: I21c70111a5f407a7e8dd1ad1f2c2759ddb91893e
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77964
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
cpu_cl_cleanup() function checks if the SOC supports storage-off
feature. This feature allows to turn off PUNIT SSRAM to save power.
Enable the storage-off if it's supported. Enabling it also clears the
crashlog records from PUNIT SSRAM.
cpu_cl_rearm() function rearms the CPU crashlog.
BUG=b:262501347
TEST=Able to build google/rex. Verified both features get asserted.
Change-Id: Id9ba0f5db0b5d2bd57a7a21f178ef1e86ca63fae
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77239
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add more details in CPU crashlog header structure, such as
storage off status and support, re-arm status etc. These fields
are used to check of particular feature is supported or not and
if supported what is the status of the feature.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: I4242b6043b8f8ad9212780f44ca0448cd2b6b9f8
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77562
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
relanding original commit 5013c60a87
("soc/intel/meteorlake: Generate new TME key on each warm boot") which was previously reverted by commit 19e66b7c95
(Revert "soc/intel/meteorlake: Generate new TME key on each warm boot")
due to consecutive reboot post warm reset issue.
The consecutive reboot post warm reboot issue has been fixed with
commit ba7a9eefcf ("soc/intel/common: Fix
invalid MADT entries creation"), hence, reattempting to land the original TME key related patch.
BUG=299294328
TEST=Boot up the system, generate kernel crash using following
commands:
$ echo 1 > /proc/sys/kernel/sysrq
$ echo "c" > /proc/sysrq-trigger
System performs warm boot automatically. Once it is booted,
execute following commands in linux console of the DUT and confirm
ramoops can be read.
$ cat /sys/fs/pstore/console-ramoops-0
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I5d45d265ccef1a7d37669ea22a74b52e2f3ae20d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This reverts commit 449c6d981c.
Reason for revert: (EVT board build does not exhibit shutdown followed
by warm reboot)
This commit reverts the workaround that limits the TCC activation
temperature. The original issue that was reported (shutdown followed
by warm reboot) was not seen in the EVT board build, so this change is
likely unnecessary.
Change-Id: I22adcdee6512e57ad0b6d531f2611e22a95c863e
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77806
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Configure _DSC to ACPI_DEVICE_SLEEP_D3_COLD so that the driver skips
initial probe during kernel boot and prevent privacy LED blink.
TEST=Boot to OS, check camera LEDs.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: Ib9375d602171aa5018b1add1deac3021724dc207
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC is added to mipi camera
driver to extend the same support for all SoCs, so removing this config
from Alderlake SoC code.
BUG=None
TEST=Build rex and brya to check if the build passes without an
error.
Change-Id: I5bc23fce89f0ae22b64b90cb12621320cac30d85
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Move the existing FSP 4221.00 headers for Raptor Lake to a
subdirectory called 4221.00_google, and select this if the
vendor is Google.
Add the standard FSP 4301.01 headers to a separate directory,
from Intel download #686654, and select this for all other
vendors.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Icd99bdee1eeac70dfcaca3d07150d3de6bb83d81
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77101
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
