The UPDs for PM power cycle duration and SLP_* signal durations are all
identical to Tiger Lake, so add similar support, but use enums instead
of comments to represent the durations symbolically.
BUG=b:184799383
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I4a531f042658894bcbc6a76eff453c06e90d66b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57891
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These methods are never used in the code. Drop them.
Change-Id: If5568b494f821d2647ada5ae845bcd015708520e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
These fields are never used in the code. Drop them.
Change-Id: Icd07f2d704c19126bf6df4d740c21d5a1342061b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57983
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
This field is never used in the code. Drop it.
Change-Id: I88207ec369ab83823ef2f3fc40f68a0980ce9663
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57982
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
DFD (Design for Debug) is a debugging tool, which scans
flip-flops and dumps to internal RAM on the WDT reset.
After system reboots, those values could be showed for
debugging.
BUG=b:192429713
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Change-Id: Ied63913db94b2e52ab394a66c70f7edfd507c99b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57980
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.corp-partner.google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current MRC binaries for Bay Trail are always ELF files. Always
adjust the position in CBFS using the ELF header regardless of file
names. Without adjusting the position, the system hangs right after
calling into MRC.
TEST: MRC position in CBFS does not change for bostentech/gbyt4.
Change-Id: I74e1246a5fac3f3649be9842ff13c2fc70f72a20
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57989
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This file does not exist in the coreboot tree. One should place this
file in the `site-local` subdirectory and specify the paths by means
of `site-local/Kconfig`.
Change-Id: I86ac2a6176947f12194bec6b63bedd7db79820a0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54761
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
mb_set_up_early_espi should only be called when
SOC_AMD_COMMON_BLOCK_USE_ESPI is selected.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic8ad724a2a79c1995fbe9d97f11a0f69eed9435c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57781
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Enable CCP DMA use in PSP verstage. This helps to reduce the boot time.
BUG=b:194990811
TEST=Build and boot to OS in Guybrush. Observed a 35 - 40 ms improvement
in the boot time.
Before CCP DMA:
508:finished loading body 898,286 (287,576)
Total Time: 2,146,182
After CCP DMA:
508:finished loading body 853,627 (240,061)
Total Time: 2,110,117
Cq-Depend: chrome-internal:4116566
Change-Id: I6e4f081622a2ec78763adf56548204efc1bccf39
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57564
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
PSP verstage can access the boot device either in Programmed I/O mode or
DMA mode. Introduce a boot device driver and use the appropriate mode
based on the SoC support.
BUG=b:194990811
TEST=Build and boot to OS in Guybrush.
Change-Id: I8ca5290156199548916852e48f4e11de7cb886fb
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57563
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support to access the boot device from PSP through Crypto
Co-Processor (CCP) DMA. Implement a SVC call to use CCP DMA on SoCs
where it is supported and a stub on SoCs where it is not supported. This
provides an improved performance while accessing the boot device and
reduces the boot time by ~45 ms.
BUG=b:194990811
TEST=Build and boot to OS in guybrush. Perform cold and warm reboot
cycling for 250 iterations.
Change-Id: I02b94a842190ac4dcf45ff2d846b8665f06a9c75
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57562
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The Always On Always Connected block is referenced as AOAC in the code,
so add that acronym in the comment and change the "Connect" to
"Connected".
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6a23e0ccff62c6ceddae70e1bef5c5abf872c495
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57926
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
`intel_microcode_find()` function uses cached ucode data hence it would
avoid locating ucode.bin from CBFS while passing ucode.bin pointer to
FSP.
Change-Id: I8f92c9f20dfb055c19c6996e601c8c24767aecb7
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change replaces the device tree walks with device pointers by
using alias for tcss_usb3_port* devices.
Change-Id: I65d9c83a9d0aab5a42f5a7cc6df98a154e79d16a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57848
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Since the binaryPI glue code is specific to a binary interface, but not
for a hardware block, move it out of the common blocks directory. This
also brings the binaryPI support in line with the FSP support which is
used on the newer generations. This also drops the
SOC_AMD_COMMON_BLOCK_PI Kconfig option and makes use of the already
existing SOC_AMD_PI Kconfig option instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I014e538f2772938031950475e456cc40dd05d74c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The code in soc/amd/common/block/s3 is specific to the AMD binaryPI
coreboot integration, so move the code to soc/amd/common/block/pi. This
drops the SOC_AMD_COMMON_BLOCK_S3 Kconfig option and integrates the
dependencies and selections into the SOC_AMD_COMMON_BLOCK_PI Kconfig
option. Since only selecting SOC_AMD_COMMON_BLOCK_PI but not
SOC_AMD_COMMON_BLOCK_S3 resulted in missing functions in the linking
process, we don't lose support for any working configuration by only
having one Kconfig option for both parts.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib2bd99a88d8b05216688bc45d9c4f23a007ce870
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This brings the AMD SoC GPIO code in line with the Intel SoC code and
removes the not really needed suffix.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie2dbec81dfe503869beb2872b01a7475e2b88b33
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57842
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This brings the AMD SoC GPIO code in line with the Intel SoC code and
removes the not really needed suffix.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3dfcca2f126eb49c962b5cc32cbcf72e04f3f170
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57841
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Use the same function name as in soc/intel for this functionality. This
also brings the function name more in line with the extended version of
this function gpio_configure_pads_with_override which additionally
supports passing a GPIO override configuration.
This might cause some pain for out-of-tree boards, but at some point
this should be made more consistent, so I don't see a too strong reason
not to do this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I88852e040f79861ce7d190bf2203f9e0ce156690
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57837
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Explicitly point out that gpio_configure_pads_with_override will ignore
GPIOs that are only in the override configuration, but not in the base
configuration.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1bdfcac89b81fef773938133a2699897c6ee9415
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Some headers in vendorcode are still needed but the UPD definitions
can be taken from the FSP repo.
Change-Id: I7bb96649ecba9d313cfce50af202aabcf610680f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
coreboot expects different names for FSP UPDs so use some CPP to make
it happy.
Change-Id: I4b2c2dd6ba40cb58bc2089eb9204fd4f70b037aa
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
There is another gpio group, namely HVCMOS, between GPP_C and GPP_E. Add
it, so the group index calculation for GPI/SMI/NMI results in the
correct value.
Reference: Linux linux/drivers/pinctrl/intel/pinctrl-icelake.c
Change-Id: I7725191173ddc0d43bbe940cdf3b0dc2aa3e5f8d
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57719
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
SPD files are being moved from the soc and mainboard directories to a
centralised spd/ directory. This change migrates all dedede variants to
use this new location. The contents of the new SPDs are identical, only
their file paths have changed.
The variant Makefile.inc and dram_id.generated.txt files were generated
using the part_id_gen tool. E.g. for cret:
util/spd_tools/bin/part_id_gen \
JSL \
lp4x \
src/mainboard/google/dedede/variants/cret/memory \
src/mainboard/google/dedede/variants/cret/memory/mem_parts_used.txt
For cappy, the Makefile.inc was manually modified to use the new
placeholder value.
BUG=b:191776301
TEST=Check that each variant's coreboot.rom is the same with and without
this change. Built using:
abuild -p none -t google/dedede -a -x --timeless
Change-Id: I2871ff45d6202520d4466b68a4d5bb283faf2b63
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
SPD files are being moved from the soc and mainboard directories to a
centralised spd/ directory. This change migrates all volteer variants to
use this new location. The contents of the new SPDs are identical, only
their file paths have changed.
The variant Makefile.inc and dram_id.generated.txt files were generated
using the part_id_gen tool. E.g. for voema:
util/spd_tools/bin/part_id_gen \
TGL \
lp4x \
src/mainboard/google/volteer/variants/voema/memory \
src/mainboard/google/volteer/variants/voema/memory/mem_parts_used.txt
BUG=b:191776301
TEST=Check that each variant's coreboot.rom is the same with and without
this change. Built using:
abuild -p none -t google/volteer -a -x --timeless
Change-Id: Ibd4f42fd421bfa58354b532fe7a67ee59dac5e1d
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57695
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
SPD files are being moved from the soc and mainboard directories to a
centralised spd/ directory. This change migrates all brya variants to
use this new location. The contents of the new SPDs are identical, only
their file paths have changed.
The variant Makefile.inc and dram_id.generated.txt files were generated
using the part_id_gen tool. E.g. for anahera:
util/spd_tools/bin/part_id_gen \
ADL \
lp4x \
src/mainboard/google/brya/variants/anahera/memory \
src/mainboard/google/brya/variants/anahera/memory/mem_parts_used.txt
BUG=b:191776301
TEST=Check that each variant's coreboot.rom is the same with and without
this change. Built using: abuild -p none -t google/brya -a -x --timeless
Change-Id: I08efe1d75438c81161d9b496af2fa30ce6f59ade
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Before this patch, gpio_configure_pads_with_override called
program_gpios once for each GPIO that needed to be configured which
resulted in base_num_pads - 1 unneeded master_switch_set/
master_switch_clr sequences for the gpio_configure_pads_with_override
call. Instead implement gpio_configure_pads_with_override as the more
generic function and program_gpios as a special case of that which
passes an empty override configuration and override pad number to
gpio_configure_pads_with_override.
TEST=GPIO configuration and multiplexer register values are the same for
all GPIOs on google/guybrush right before jumping to the payload before
and after the patch.
Change-Id: Ia8e47b2a278a1887db5406c1f863ddafa6a68675
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Earlier generation platform used `HeciEnabled` chip config (set to 0)
and HECI_DISABLE_USING_SMM Kconfig to make the CSE function disable at
the end of the post. `HeciEnabled` chip config remains enabled in all
latest generation platforms hence drop HECI_DISABLE_USING_SMM Kconfig
selection from SoC Kconfig as CSE remains default enabled.
BUG=b:200644229
TEST=No functional impact during boot as CSE (B:0, D:0x16, F:0) device
is listed with `lspci`.
Change-Id: I5278e5c2e015b91bb3df3a3c73a6c659a56794b5
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
In this file bool, uint8_t and uint32_t are used, so include types.h
directly to have those types defined instead of relying to have those
included indirectly via amdblocks/gpio_banks.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6f4626a50219fab818e8bc5087961a731b44e71b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57788
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
This implements the SPI driver for the QUP core.
BUG=b:182963902
TEST=Validated on qualcomm sc7180 and sc7280 development board.
Signed-off-by: Rajesh Patil <rajpat@codeaurora.org>
Change-Id: I7e5d3ad07f68255727958d53e6919944d3038260
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56399
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The aliases are defined in the chipset devicetree, so the device
pointers will be available for all boards using this SoC.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id4c921575e978bb29e61f35e78ff2a1711acf06a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The aliases are defined in the chipset devicetree, so the device
pointers will be available for all boards using this SoC.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id655e9eba9b8e9898fa01bf03876074e136cc7c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Normally for vboot-enabled x86 board, the VBNV region is stored in CMOS
and backed up to flash (RW_NVRAM). However, on the very first boot after
a flash of the full SPI image (so RW_NVRAM is empty), if
RTC_BATTERY_DEAD is set, coreboot persistently requests recovery before
FSP-M finishes (which appears to be the current location that
RTC_BATTERY_DEAD is cleared on this platform). This is because
vbnv_cmos_failed() will still return 1. Therefore, immediately after
reading RTC_BATTERY_DEAD, it is cleared. This prevents an infinite boot
loop when trying to set the recovery mode bit.
Note that this was the behavior for previous generations of Intel PMC
programming as well (see southbridge/intel, soc/skylake, soc/broadwell,
etc).
BUG=b:181678769
Change-Id: I95753fa536fae8ca4bb95007419875815c1bcb06
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Normally for vboot-enabled x86 board, the VBNV region is stored in CMOS
and backed up to flash (RW_NVRAM). However, on the very first boot after
a flash of the full SPI image (so RW_NVRAM is empty), if
RTC_BATTERY_DEAD is set, coreboot persistently requests recovery before
FSP-M finishes (which appears to be the current location that
RTC_BATTERY_DEAD is cleared on this platform). This is because
vbnv_cmos_failed() will still return 1. Therefore, immediately after
reading RTC_BATTERY_DEAD, it is cleared. This prevents an infinite boot
loop when trying to set the recovery mode bit.
Note that this was the behavior for previous generations of Intel PMC
programming as well (see southbridge/intel, soc/skylake, soc/broadwell,
etc).
BUG=b:181678769
Change-Id: I1a55df754c711b2afb8939b442019831c25cce29
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Normally for vboot-enabled x86 board, the VBNV region is stored in CMOS
and backed up to flash (RW_NVRAM). However, on the very first boot after
a flash of the full SPI image (so RW_NVRAM is empty), if
RTC_BATTERY_DEAD is set, coreboot persistently requests recovery before
FSP-M finishes (which appears to be the current location that
RTC_BATTERY_DEAD is cleared on this platform). This is because
vbnv_cmos_failed() will still return 1. Therefore, immediately after
reading RTC_BATTERY_DEAD, it is cleared. This prevents an infinite boot
loop when trying to set the recovery mode bit.
Note that this was the behavior for previous generations of Intel PMC
programming as well (see southbridge/intel, soc/skylake, soc/broadwell,
etc).
BUG=b:181678769
Change-Id: Idfaa9a24f7b7fefa4f63ab8e3bc4ee6a0f1faedf
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56670
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Normally for vboot-enabled x86 board, the VBNV region is stored in CMOS
and backed up to flash (RW_NVRAM). However, on the very first boot after
a flash of the full SPI image (so RW_NVRAM is empty), if
RTC_BATTERY_DEAD is set, coreboot persistently requests recovery before
FSP-M finishes (which appears to be the current location that
RTC_BATTERY_DEAD is cleared on this platform). This is because
vbnv_cmos_failed() will still return 1. Therefore, immediately after
reading RTC_BATTERY_DEAD, it is cleared. This prevents an infinite boot
loop when trying to set the recovery mode bit.
Note that this was the behavior for previous generations of Intel PMC
programming as well (see southbridge/intel, soc/skylake, soc/broadwell,
etc).
BUG=b:181678769
Change-Id: Ie86822f22aa5899a7e446398370424ca5a4ca43d
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
This enables runtime power management for the I2C controllers.
BUG=b:182556027, b:183983959
TEST=enable dynamic debug in kernel and check i2c D3/D0 transitions
during suspend_stress_test.
Change-Id: Ia6b9ca95d751f32b7cd701494377f15091c22d2f
Signed-off-by: Julian Schroeder <julianmarcusschroeder@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56462
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
