During CSE FW downgrade we erase CSE data. This would result in
Platform Service Record(PSR) data also to be erased.
To avoid losing PSR data we need to make a backup before data clear.
This patch sends PSR_HECI_FW_DOWNGRADE_BACKUP HECI command to CSE,
informing the CSE to backup PSR data before a data clear operation
during downgrade.
CMOS memory is used to track the backup status. PENDING is the default
state, it is updated to DONE once PSR_HECI_FW_DOWNGRADE_BACKUP HECI
command is sent.
PSR data can be backed up only post DRAM is initialized. The idea is to
perform cse_fw_sync actions in ramstage when PSR is enabled on a
platform. As part of the cse_fw_sync actions, when a firmware downgrade
is requested the command to back-up data is sent. Once the backup has
been done, trigger the firmware downgrade.
BRANCH=None
BUG=b:273207144
TEST=build CB image for google/rex board and check PSR backup command
is being sent during a CSE FW downgrade. Also check PSR data is not
lost/erased after a downgrade using intel PSR tool.
Change-Id: I135d197b5df0a20def823fe615860b5ead4391f8
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74577
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data. Since firmware downgrade
and PSR data backup flows involve global resets, there is a need to
track the PSR data backup status across resets. So adding a CMOS
variable for the same.
This patch implements API to access PSR backup status stored in CMOS.
The get API allows to retrieve the PSR backup status from CMOS memory.
The update API allows to update the PSR backup status in CMOS.
BRANCH=None
BUG=b:273207144
TEST=Able to retrieve PSR backup status across resets.
Change-Id: I270894e3e08dd50ca88e5402b59c211d7e693d14
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
CSE firmware downgrade and PSR data backup flows involve global resets,
there is a need to track the PSR data backup status across resets. In
the subsequent patches, a CMOS structure to store PSR back-up status
will be added.
The current SOC_INTEL_CSE_FW_PARTITION_CMOS_OFFSET of 68 can only store
cse_specific_info, as ramtop is at offset 100 and PSR back-up status
structure will not be able to fit within the range.
This patch overrides the SOC_INTEL_CSE_FW_PARTITION_CMOS_OFFSET to 161
to accommodate all CSE related info in adjacent CMOS memory.
BUG=b:273207144
TEST=Verify CSE RW FW versions are stored in CMOS memory in rex.
Change-Id: I8bae5245f93b99be15b4e59cfeffbc23eec95001
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78054
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Platform Service Record(PSR) will be enabled on Meteor Lake
platforms. cse_fw_sync actions happen in ramstage when PSR is enabled.
To avoid the boot time penalty of sending the cse_get_bp_info in
ramstage, call cse_fill_bp_info to get cse_bp_info response early in
romstage and store in cbmem. This data can be later used in ramstage.
BUG=b:273207144
TEST=Verify cse_bp_info is filled in romstage in rex.
Change-Id: Ic0e8fb34f21ff07e182a7b848d38e9d329010028
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data, and this command can be
sent only in post-RAM stages. So the cse_fw_sync actions needs to be
moved to ramstage.
Sending cse_get_bp_info command in ramstage takes additional boot time
of ~45-55ms on rex. To avoid the boot time penalty, this patch provides
an API to get the cse_bp_info in early romstage. The response data is
then migrated to cbmem once memory is initialized. The same data in
cbmem can be utilized in ramstage to perform other cse_fw_sync actions.
This patch also adds check to validate cse_bp_info in cbmem and avoids
sending the command again if the data is valid.
BUG=b:273207144
TEST=Verify the command works in early romstage, data is migrated to
cbmem and valid data is available in ramstage on rex.
Change-Id: Ib1e72c950ba0f4911924805f501ec1bd54b6ba3c
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78053
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `SDK_VERSION` was incorrectly set to itself instead of keeping the
`COREBOOT_IMAGE_TAG` variable, leaving it as an empty string.
Test: Run `make coreboot-sdk` and see `SDK_VERSION` matches the tag.
Fixes: d3a89cdb74 ("util/docker: Replace use of sed with build args")
Change-Id: I4c8be7d0f7c1ac82da397e720d13a7075f22ec4d
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78141
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Since commit 9b186e0ffe ("util/xcompile: Add NASM to xcompile") NASM
from the coreboot toolchain is properly hooked up to the build system.
So it's not needed to install the distro package. Remove it.
Change-Id: I2ab0317531e25ae6d5baa8be8ac4d41dc145658f
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77728
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: I1439f785cb9ceeefab9d24caa88e35bd43f68315
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78126
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: I5ff9170ac6a3f50830a707dacf4f941587e531ef
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75076
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: Iface0fd1d44649c6d9773940818e028e3d3a4292
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: I5a321680b1b84ca0b2598d2446ff10257947a733
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: I80bd87aa2f97da74a1bbcf05b16f0d5980e142f2
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: I6b71c7c5c9e32e21c757c0ed0e9c6bd9d58a4f75
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78131
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: I6a78efa4be2ee34e7dac06a8b8014da12b21fbdc
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78130
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: I817faab0438a35d2e8859342e7c2b2dbaa0afeeb
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78129
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: Iec0829ba80d3d4b4bc79e14a97d085930c4c5202
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78128
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: If6b666478e15a8e843b50b60be490593349240bd
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Now that Intel has publicly released FSP headers/binaries for
RaptorLake-P/S client platforms, set the defaults accordingly if
FSP_USE_REPO is not selected. This does not change any existing
defaults as the RaptorLake headers in vendorcode are only used when
FSP_USE_REPO is not set.
TEST=build/boot google/brya (osiris)
Change-Id: Ida92d269fcaf6f323599ec174f4dcedbbe65f03c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78190
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: I5527d5968be35f52b912d9d6e1d9f46f24569bbc
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Selects should be done in the Kconfig file instead of Kconfig.name and
not mixed over both files.
Change-Id: Ic199a60013ceedfd15b191a5fe707be6654ad3a2
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75078
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
During suspend, the ISH I2C transactions cannot go through
because the GPIO pads remain the pervious value.
The IO Standby State (IOSSTATE) needs to be changed to keep I2C bus
active and functional during suspend.
BUG=b:302612549
TEST=on Google/rex platform with ISH enabled, do suspend_stress_test
and check that no i2c failure.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I9a2c902ed56461f3a535428db399c2050756f2da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78179
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Li1 Feng <li1.feng@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set default to enabled for hibernate on setup failure for all devices
using a Google EC. This will have no impact on devices that don't
bring the GSC down on hibernate, but will provide a recovery path
for all devices that do.
BUG=b:296439237
TEST=Force error on Skyrim with custom build, boot normally with
normal build
Change-Id: I2d9e8f75b25fb6c530a333024c342bea871eb85d
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78098
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Librem 11's volume keys act as a PS/2 keyboard with only those two
keys. Reduce the minimum number of top-row keys to 2. Make the
"rest of keys" (alphanumerics, punctuation, etc.) optional.
Change-Id: Idf80b184ec816043138750ee0a869b23f1e6dcf2
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78095
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Separate these so a mainboard can describe a PS/2 keyboard without a
PS/2 mouse or vice-versa.
Librem 11 has a PS/2 keyboard for the volume keys, but does not have a
PS/2 mouse, and the presence of a mouse device can cause the cursor to
appear on the desktop incorrectly.
ps2_controller.asl remains since many boards include it, it now just
includes the two new files.
Change-Id: I13a4c2caf8dc9e5004b775dc0a9ac2488e39f184
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78096
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Simplify the code a bit by returning 0 early in the function when the
SYSCFG_MSR_SMEE bit isn't set.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I7536b82d98e55c51105448090d1206e1ed7f62d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78176
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of having the get_usable_physical_address_bits function that
only got used in the data fabric domain resource reporting code, drop
this function, select RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT in the
common AMD non-CAR CPU and rename get_sme_reserved_address_bits to
get_reserved_phys_addr_bits so that the common cpu_phys_address_size
function will return the correct number of usable physical address bits
which now can be used everywhere. The common AMD CAR CPU support is only
selected by Stoneyridge which doesn't support secure memory encryption,
so RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT isn't selected by the
SOC_AMD_COMMON_BLOCK_CAR Kconfig option.
Before only the MMIO region reporting took the reserved physical address
bits into account, but now also the MTRR calculation will take those
reserved bits into account. See the AMD64 Programmers Manual volume 2
(document number 24593) for details. Chapter 7.10.5 from revision 3.41
of this document was used as a reference. The MTRR handling code in
older Linux kernels complains when the upper reserved bits in the MTRR
mask weren't set, but sets them after complaining and then continues to
boot. This issue is no longer present in version 6.5 of the Linux
kernel.
The calculation of the TSEG mask however still needs to take all
physical bits into account, including the ones reserved for the memory
encryption. When not setting the reserved bits in the TSEG mask, the
Mandolin board with a Picasso APU won't boot to the OS any more due to
not returning from SeaBIOS calling into the VBIOS. Haven't root-caused
what exactly causes this breakage, but I think previously when something
else was wrong with the SMM initialization, also something went wrong
when calling into the VBIOS.
TEST=Ubuntu 2023.10 nightly build boots on Mandolin via SeaBIOS and EDK2
and Windows 10 boots on it via EDK2.
TEST=On Ubuntu 2022.04 LTS, the kernel complained with the following
warning, but it still continues the boot process as described above:
mtrr: your BIOS has configured an incorrect mask, fixing it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iad65144006f1116cd82efc3c94e1d6d1ccb31b6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
In the cpuid helper functions eax is always written to
by the cpuid instruction, so add it to the output clobbered list.
This prevents GCC from generating code with undefined behaviour
when the function is inlined.
Test: Verified that the generated assembly is sane and runtime
tests showed no "strange" behaviour when calling cpuid
functions.
Change-Id: I5dc0bb620184a355716b9c8d4206d55554b41ab9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78192
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Updating from commit id a72794810884 (2023-09-07):
IoT ADL-N MR1 (4172_00)
to commit id 481ea7cf0bae (2023-09-19):
Move to RaptorLakeFspBinPkg.dec
This brings in 9 new commits:
481ea7cf0b Move to RaptorLakeFspBinPkg.dec
55e25b819e Raptor Lake FSP C.1.BD.40
2b0aac4f64 Raptor Lake FSP C.0.BD.40
3fa75657aa Add Client Raptor Lake FSP
8d24189361 Add Alder Lake and Raptor Lake to README.md
98f4a1fe2f Rename to AlderlakeSiliconPkg
c78a6784cb Add FvLateSilicon for Alder Lake
849ce8261b Tiger Lake FSP A.0.7E.70
4b0b1eb4e3 Update SplitFspBin.py to latest from edk2
Change-Id: I8a724bf0a03cba5a9689894e1aec0a81a5bf2c94
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78189
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
BOARD_SPECIFIC_OPTIONS is duplicate to BOARD_GOOGLE_CORSOLA_COMMON.
Thus, move all selects to the latter option.
Change-Id: I498c6671b2dfc72820fc522744af7ce3b0a62930
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Yidi Lin <yidilin@google.com>
Configure the SCP to operate within domain 8, allowing it to access
only the necessary registers. Any unauthorized access will be prevented
by the DAPC.
- Set SCP domain from domain 0 to domain 8.
- Lock register settings down to prevent unexpected modification.
BUG=b:270657858
TEST=scp bootup successful with dapc settings
Change-Id: I049486c997542d91bd468e0f4662eafbca4c17e0
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77883
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Currently, all the masters controlled by DAPC are in domain 0. With
this setting, there is a potential security problem. For example, if a
certain master is somehow hacked, it may attempt to access registers
that it is not supposed to, with successful results. This is due to the
fact that, in the current setting, all masters are in domain 0 and can
access almost all registers. To prevent this problem, we assign masters
to different domains and restrict access to registers based on each
domain.
This patch sets domains for masters:
SSPM - domain 3
CPUEB - domain 14
PCIE0 - domain 2
SPM - domain 9
Change-Id: Ie3e1d5055e72824257b66d6257982652eeb05953
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77862
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, all the masters controlled by DAPC are in domain 0. With
this setting, there is a potential security problem. For example, if a
certain master is somehow hacked, it may attempt to access registers
that it is not supposed to, with successful results. This is due to the
fact that, in the current setting, all masters are in domain 0 and can
access almost all registers. To prevent this problem, we assign masters
to different domains and restrict access to registers based on each
domain.
This patch updates the permission settings for domains 2, 3, 4, 5, 7,
8, 9, and 14, as these domains will be assigned masters in the upcoming
patch.
BUG=b:270657858
TEST=build pass
Change-Id: I6e95ddb5d84a09ff865d7615596430e25b69d3fc
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77861
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Since also some AMD CPUs have reserved physical address bits that can't
be used as normal address bits, introduce the
RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT Kconfig option which gets
selected by CPU_INTEL_COMMON, and use the new common option to configure
if the specific SoC/CPU code implements get_reserved_phys_addr_bits or
if the default of this returning 0 is used instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0059e63a160e60ddee280635bba72d363deca7f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The number of physical address bits and reserved address bits shouldn't
ever be negative, so change the return type of cpu_phys_address_size,
get_reserved_phys_addr_bits, and get_tme_keyid_bits from int to unsigned
int.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9e67db6bf0c38f743b50e7273449cc028de13a8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Update the default branch used for MrChromebox's edk2 fork from 2023-06
to 2023-09. This updated branch has been rebased on the latest upstream
stable tag (edk2-stable202308), and fixes some USB detection issues, as
well the coreboot Kconfig for prefering internal or external boot
devices.
TEST=build/boot google boards link, panther, lulu,reef, ampton, akemi,
banshee, zork, frostflow with edk2 payload selected.
Change-Id: I7c5f9ae1ca4edd8211f55f4ecf2b3b495f473a43
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78136
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Disabling TPM support in edk2 can actually cause problems booting from
USB on some Intel-based boards with a CR50 TPM when using the edk2
GOP driver option, so rather than disable the TPM for all CR50 boards,
restrict the default to only AMD boards, where the boot hang with
TPM enabled was originally observed.
TEST=build/boot Win11, Linux from usb on google/fizz when built
with edk2 payload and edk2 GOP driver option selected.
Change-Id: I01509fea2dd42b741c00abcf9fb8b936e895b932
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78031
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
ASPM on the WLAN PCIe bus introduces large latency spikes, which can be
measured with cyclictest:
$ cyclictest --policy=rr --priority=12 --interval=10000 --threads=1 --loops=6000
Disabling ASPM for WLAN reduces the latency spikes from 2,500-3,000 usec
down to 35-65 usec. These latency spikes can impact the user when
real-time processes like Audio (cras) are starved of CPU time, leading
to buffer underruns resulting in crackling/distorted audio.
ASPM is already disabled for Nipperkin devices (CB:63537), so this CL
disables it for both in the shared declaration of
guybrush_czn_dxio_descriptors.
Power impact for Dewatt:
* ASPM enabled
power_VideoCall.FDO_25min_webrtc
w_energy_rate 7.425043688811071
power_Idle.default20min
wh_energy_used 1.4164200000000022
* ASPM disabled
power_VideoCall.FDO_25min_webrtc
w_energy_rate 8.779998551703423
power_Idle.default20min
wh_energy_used 1.4860800000000012
When using Google Meet over WiFi, power increases by ~1.5W.
BUG=b:297970318
TEST=cyclictest --policy=rr --priority=12 --interval=10000 --threads=1 --loops=6000
Change-Id: I16940987d598943bd5d6ace8b4008eba4d4a177c
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77963
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Implement support for elan i2c touchscreen and use fw_config
to pick between i2c or HID-over-i2c touchscreen.
Support G2 TS have different slave address by fw_config
BUG=b:295272539
BRANCH=firmware-nissa-15217.B
TEST=build and verified touchscreen work
Change-Id: I5e3f85106606d84e1cfa204e62b7b2662db6546b
Signed-off-by: Shon Wang <shon.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Revise the Makefile.inc rules for generating FMD parser files.
- lex: If --header-file is supported then the lex (usually flex) should
also support '-o' so we don't need to do redirection (-t).
- yacc: Bison is already required by bincfg and sconfig so we
can change the default parser compiler to Bison. That also
allows us to use -o and --defines to override the output files.
- both: Line directives are only helpful when debugging the scanner and
the parser, so we should remove them to get better git diff
results (-L for lex, -l for bison).
Also regenerated the shipped files with latest version of flex (2.6.4)
and bison (3.8.2).
Change-Id: I15b58ff65dcd9f3f3a6095aa004091ff733ffec3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75851
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data, and this command can be
sent only in post-RAM stages. So the cse_fw_sync actions needs to be
moved to ramstage.
This patch ensures SOC_INTEL_CSE_LITE_SYNC_IN_RAMSTAGE is selected when
PSR is enabled.
BUG=b:273207144
Change-Id: I7c9bf8b8606cf68ec798ff35129e92cd60bbb137
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78055
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable hibernate on TPM setup error for Skyrim devices.
BUG=b:296439237
TEST=Force the error by hard coding the return code and observe the
device entering hibernate.
BRANCH=None
Change-Id: Ibf96b830f07dac98035d3152c8ec220685a912bc
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77668
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add additional failure mode logic for the TPM to enable an
automated recovery mode for GSC hangs.
BUG=b:296439237
TEST=Force the error by hard coding the return code and observe the
device entering hibernate.
BRANCH=None
Change-Id: Ieec7e9227d538130354dea8b772d0306cdda1237
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77667
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add additional failure mode reporting to the TPM driver to provide
additional visibility into what failures are occurring.
BUG=b:296439237
TEST=Verify code paths on Skyrim, ensure behavior is unchanged.
BRANCH=None
Change-Id: I77a653201acf1bddc1ed1e2af701c8d3dd4f0606
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77491
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Convert TPM functions to return TPM error codes(referred to as
tpm_result_t) values to match the TCG standard.
BUG=b:296439237
TEST=build and boot to Skyrim
BRANCH=None
Change-Id: Ifdf9ff6c2a1f9b938dbb04d245799391115eb6b1
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77666
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>
Anil Kumar