The current HWIDs for ADL RVP are reported as invalid by Chrome on
ChromeOS; fix it by generating new valid HWIDs with the following
commands:
```
./util/chromeos/gen_test_hwid.sh ADLRVPM
./util/chromeos/gen_test_hwid.sh ADLRVPN
./util/chromeos/gen_test_hwid.sh ADLRVPP
```
BUG=b:243899466
Change-Id: Iad6f47e67c2d35363b042aabec8b3317d5bfc111
Signed-off-by: Victor Ding <victording@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67532
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Most of these changes are suggested by clang-format(13.0-54) tool on
Debian testing.
Change-Id: I68a288b3f7e911331e7324bf13cf9bde259a29de
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64781
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Most of these changes are suggested by clang-format(13.0-54) tool on
Debian testing.
Change-Id: I9bf5f516db4f12ffe1e9a714c7a8ae179c12b149
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Problem: OTA is triggering warmboot, where DDR is
in self-refresh mode. Due to which DDR training
is not going well.
Change: Verify reboot type in case of OTA. If it is warmboot, will
force for cold boot inorder to trigger DDR training
BUG=b:236990316
TEST=Validated on qualcomm sc7180 development board.
Test observation: Cold boot is triggered forcefully,
if current reboot is warmboot in case of OTA
Signed-off-by: Venkat Thogaru <quic_thogaru@quicinc.com>
Change-Id: I908370662292d9f768d1ac89452775178e07fc78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67406
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update ASPM configuration, disabling ASPM for the SSD due to s0i3
issues. Bug b:245550573 created to track the SSD issue.
TEST=Boot to OS and verify suspend via `suspend_stress_test -c 10`
BUG=b:243771794
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I45a290c8ceddd39f65c6fe1390e3a753cad99899
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Add go.mod containing the full name of the project according to the
docs [1]: review.coreboot.org/coreboot.git/util/intelp2m, and also,
based on this, rename the internal packages to point to the absolute
path. This will allow Go Managing Dependencies System to integrate
packages from intelp2m to third-party Go written on the Go language [1].
This also requires fixing the Golang compiler version in go.mod: use
go1.18 [2], the latest up-to-date version.
[1] https://web.archive.org/web/20220910100342/https://go.dev/doc/modules/managing-dependencies
[2] https://web.archive.org/web/20220910100206/https://tip.golang.org/doc/go1.18
[ TEST ]
1) Import the coreboot project into some go project:
$cd path/to/go-project
$go get review.coreboot.org/coreboot.git
go: downloading review.coreboot.org/coreboot.git v0.0.0-20220903004133
-39914a50ae16
go: added review.coreboot.org/coreboot.git v0.0.0-20220903004133
-39914a50ae16
Thus, 'go get' correctly downloaded the contents of the repository.
2) Import intelp2m:
$cd path/to/go-project
$go get review.coreboot.org/coreboot.git/util/intelp2m
review.coreboot.org/coreboot.git/util/intelp2m imports
./config: "./config" is relative, but relative import paths are
not supported in module mode
review.coreboot.org/coreboot.git/util/intelp2m imports
./parser: "./parser" is relative, but relative import paths are
not supported in module mode
Thus, the problem is in the package names, but after this patch, the
import should be without errors.
3) Import a repository with an incorrect url:
$cd path/to/go-project
$go get review.coreboot.org/coreboot/test
go: unrecognized import path "review.coreboot.org/coreboot/test":
reading https://review.coreboot.org/coreboot/test?go-get=1:
404 Not Found
This has not happened in previous cases.
Change-Id: I12efae31227129b8c884af10fb233f398c4094e7
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This reverts commit f83b7d494e.
It turns out we have tests which use `futility validate_rec_mrc` to
validate the MRC cache, which includes verifying the data checksum.
Revert this to allow the tests to pass while we figure out how to fix
this.
BUG=b:245277259, b:242667207
TEST=None
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Change-Id: Id913d00584444c21cb94668bdc96f4de51af7cee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The following boards are setting DTPC tablet mode values without
corresponding device tree values, meaning they are effectively setting
"random" values for tablet mode:
1. Cezanne
2. Mendocino
The device tree has tablet mode disabled, so the code should never be
exercised, but this CL removes it entirely to cleanup "dead" code.
BRANCH=none
BUG=b:217911928
TEST=Build nipperkin
TEST=Boot skyrim
Signed-off-by: Tim Van Patten <timvp@google.com>
Change-Id: Ide96f255b69670d1b4c37ca2f94cc3504a958b57
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Refer to PCI Express Base rev6.0 v1.0, 4.2.7 Link Training and Status
State Rules, Lane Error Status is normal to record the error when link
training. To make sure Lane Error Status is correct in OS runtime,
add a Kconfig PCIEXP_LANE_ERR_STAT_CLEAR that clears the PCIe lane error
status register at the end of PCIe link training.
Test=On Crater Lake, lspci -vvv shows
bb:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)
(prog-if 00 [Normal decode])
Capabilities: [a30 v1] Secondary PCI Express
LnkCtl3: LnkEquIntrruptEn- PerformEqu-
LaneErrStat: LaneErr at lane: 0
Signed-off-by: Wilson Chou <Wilson.Chou@quantatw.com>
Change-Id: I6344223636409d8fc25e365a6375fc81e69f41a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Some microcode patches are padded with zeros, which make
parse_microcode_blob() read beyond the end of the buffer.
BRANCH=firmware-brya-14505.B
BUG=b:245380705
TEST=No segmentation fault with a padded microcode patch
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: Id9c5fb6c1e264f3f5137d29201b9021c72d78fdd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67460
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change removes all references to HybridStorageMode
UPD since it has been deprecated starting from FSP v2344_00
BUG=b:245167089
TEST=build coreboot mtlrvp
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: I16eb33cb1260484b0651d40211323c6ae986a546
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Linux always "turns on" a PowerResource when it boots, regardless of
_STA, so the _ON routine should be idempotent. In this case, it all is,
except for the LTR restore, which would restore a value of 0 when _ON is
run the first time, which means that LTR is disabled on the root port
from then on, as the save/restore routines will keep saving/restoring
that 0. THis patch fixes the problem by moving the power checks from
PGON/PGOF to GCOO/GCOI.
BUG=b:244409563
TEST=boot agah and verify that LTR is still enabled on the root port
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I4ed78323608eede5b8310598f1f1115497ab2b5b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67278
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
The Linux kernel runtime D3 framework expects a PCIe device to have a
power resource in order to be properly power-manageable. The _PR0/_PR3
values were pointing at the PEG0 Device, which is not a PowerResource,
so this must have confused the RTD3 framework and RTD3 was not
functional. Removing the _PR0/_PR3 fixes the problem.
BUG=b:243888246
TEST=echo auto > /sys/bus/pci/devices/0000:01:00.0/power/control;
sleep 10;
echo on > /sys/bus/pci/devices/0000:01:00.0/power/control
After this there are no longer errors seen in dmesg about failing
to place the device into D0.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I83fa1e5fabd3257b097c10e7a13c9861872685ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67212
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Mostly there are too many extraneous `\_SB.PCI0.` prefixes, also a few
minor cleanups, but nothing functional.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I79d919d2f04f57232f8f6a4e4d0690833faeb834
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Similar to the prior CL (commit db8ad5e), do the same register dance
before/after GCOFF.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I8fecba40c5a5af11e24f82db07face3ce10481bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67086
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.corp-partner.google.com>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On some platforms the HFSTS4 bit 19 does not indicate active PTT.
Instead of ME HFSTS4, use TXT FTIF register to check active TPM for
the current boot. Discrete TPM shall be deactivated when PTT is
enabled so this always should return true value of PTT state.
Leave the old method for backwards compatibility if TXT FTIF would not
be applicable for older microarchitectures.
Based on DOC #560297.
TEST=Check if PTT is detected as active on MSI PRO Z690-A DDR4 WIFI
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I3a55c9f38f5bb94fb1186592446a28e675c1207c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Instead of just printing the fatal errors, do early return so that
boot up time will be reduced during display init failure. Remove malloc
allocation and make tu a local variable.
Change-Id: I51f7a86d143128d2c426fb8940ff34a66152b426
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66975
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Refactor AMD DPTC tablet mode in preparation for adding low/no battery
DPTC settings.
1. Refactor and simplify acpigen_write_alib_dptc() into the following
functions:
- acpigen_write_alib_dptc_default()
- acpigen_write_alib_dptc_tablet()
2. Add device tree register value dptc_tablet_mode_enable to control
whether DPTC tablet mode is enabled for a variant.
3. Add dptc.asl to perform the necessary ACPI checking before modifying
the DPTC settings.
BRANCH=none
BUG=b:217911928
TEST=Build zork
TEST=Build nipperkin
TEST=Boot skyrim
Change-Id: I2518fdd526868c9d5668a6018fd3570392e809c0
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66994
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Thermal configuration registers are now located behind PMC PWRMBASE
for MeteorLake as well (same as ADL). Hence, using thermal common code
to sets the thermal low threshold as per mainboard provided
`pch_thermal_trip`.
Note: These thermal configuration registers are RW/O hence, setting
those early prior to FSP-S helps coreboot to set the desired low
thermal threshold for the platform.
TEST=Dump thermal configuration registers PWRMBASE+0x150c etc on
Google/rex prior to FSP-S shows that registers are now programmed
based on 'pch_thermal_trip' and lock register BIT31 is set.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I1d6b179a1ed43f00416d90490e0a91710648655e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67462
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch updates `pch_thermal_trip` as per Intel MTL vol1
chapter 14.
Additionally, dropped the `FIXME` tag for `pch_thermal_trip`.
TEST=Able to boot the Google/rex to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I86f97c9245fe953832d3b408aa902d6a41e55651
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67461
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch drops redundant MCHBAR programming in romstage as bootblock
already done with MCHBAR setting up.
TEST=Able to boot Google/Rex to ChromeOS and MCHBAR is set to correct
value as per iomap.h
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ic2c05f47ab22dc7fe087782a1ce9b7b692ea157e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Update the Google Meet link to match the one found in the meeting
agenda and the reminders sent on the various community forums.
Change-Id: Ic4b8e0bb01e57850ea199c62b66a16e4d14de5c5
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67459
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Unit-tests had more strict warning setings than main build. Sometimes it
can cause unit-tests builds to fail even if code compiles correctly when
building normal coreboot image.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ia219ccc8631b069436497eb45a1552a0910f7aa1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Add functionality such that the FPMCU is power cycled and has its reset
sequenced on boot.
This has been added such that we do not need to update the bootblock.
We are required to do this as bootblock exists in read-only flash for
devices that have already been manufactured and so have no method of
updating the sequencing there.
Power remains off during coreboot (after briefly being turned on in the
unchangeable bootblock).
Once control is handed over to the Kernel, it takes care of sequencing
the power and reset appropriately and ensures the FPMCU is unpowered for
>200ms on boot.
BUG=b:240626388
TEST=Confirmed FPMCU is still functional on Vell and Anahera.
Confirmed power is off for approximately 6 seconds on boot (target
>200ms).
Confirmed reset is de-asserted approx 5ms after power application
(target >2.5ms)
Change-Id: I9694f8837e0a72eaed42a5eeee92b0f120269086
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66915
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
- Enable Acoustic noise mitigation
- Set slow slew rate to fast/4 for VCCIA and VCCGT
- Disable fast slew rate for deep package C states for VCCIA and VCCGT
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: Ia344d9d939c3323bac82afdf25d5fff81081f9c8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67380
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Lastbus is a bus debug tool. When the bus hangs, the bus transmission
information before resetting will be recorded.
The watchdog cannot clear it and it will be printed out for bus hanging
analysis.
TEST=build pass.
BUG=none
Signed-off-by: ot_zhenguo.li <ot_zhenguo.li@mediatek.corp-partner.google.com>
Change-Id: Iff39486dfad556a3104b2f2b6811c34c2ded6954
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67437
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Victor Ding