Some PLLs are not used in firmware, so we should keep them as hardware
default values. If their modules want to set them, the corresponding
drivers should set them in the kernel stage.
BUG=b:233720142
TEST=build pass.
Signed-off-by: Garmin Chang <Garmin.Chang@mediatek.com>
Change-Id: I9bee18005ffed7fc1785c7fd3c0370c8293064ad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67547
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
vpp_sel and ethdr_sel are vdosys clock source select mux.
Steps to change to support 4K source:
1. Change vpp_sel source to mainpll_d6 to run at 416MHz.
2. Change ethdr_sel source to univpll_d6 to run at 416MHz.
BUG=b:233720142
TEST=build pass.
Signed-off-by: Garmin Chang <Garmin.Chang@mediatek.com>
Change-Id: I24f133b9b383fd019983cb29a213b47717148e97
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67545
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To improve boot time, raise little CPU from 500MHz to 2GHz at romstage
(before DRAM calibration).
FW logs:
Check CPU freq: 1999968 KHz, cci: 1600012 KHz
TEST=cpu freq and cci freq run correctly.
BUG=b:244251006
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: Ic1bed53669baa15f797c9a952455376a39d29cf3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67544
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The observed CPU big core frequency is double compared with the current
PLL setting. Therefore fix the wrong setting for PLL register
APMIXED_ARMPLL_BL.
Moreover, we also fix some wrong settings for other PLLs.
TEST=CPU frequency of big core CPU is correct and bootup correctly.
BUG=b:244215537
Signed-off-by: Garmin Chang <Garmin.Chang@mediatek.com>
Change-Id: I9126f439d7a5136b2fb8d66f103ef427a0b08a99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67543
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since mono_time is now 64-bit, the utility functions interfacing with
mono_time should also be 64-bit so precision isn't lost.
Fixed build errors related to printing the now int64_t result of
stopwatch_duration_[m|u]secs in various places.
BUG=b:237082996
BRANCH=All
TEST=Boot dewatt
Change-Id: I169588f5e14285557f2d03270f58f4c07c0154d5
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66170
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This patch fixes MeteorLake GPIO PINCTRL entries as per 5.15
kernel pintrl driver:
https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/kernel/v5.15/drivers/pinctrl/intel/pinctrl-meteorlake.c
In order to support using ACPI GPIOs it is necessary for coreboot
to be compatible with this implementation. The GPIO groups that
are usable by the OS are declared with a pad base which is then
used to compute the number for ACPI GPIOs.
BUG=b:232573696
TEST=Tested on Google Rex board. After this change, driver rt5682s
is able to claim pinctrl IRQ 358 corresponding to GPP_B06.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: Icabbe9e125ee9efaf0eef4c4cdc8be9f734aa703
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67565
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This message is not really an error message, so BIOS_ERR is
inappropriate. Since the message is informational, switch to
BIOS_INFO instead.
BUG=b:244687646
TEST=emerge-rex coreboot
before
[ERROR] USB Type-C 0 mapped to EC port 0
after
[INFO] USB Type-C 0 mapped to EC port 0
Signed-off-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Change-Id: Ia08fd45dd484c79d81527ea46cfaaa5a01a410c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67536
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Add the 'detect' flag to the Elan touchpad, so coreboot can determine
which touchpad type is present at runtime and generate the correct
ACPI entry for it (the Synaptics touchpad already has the flag).
Test: build/boot google/nami, verify touchpad works under Linux/Windows
Change-Id: I437d1d470552d55496dfe611f441331127c64250
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67306
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tidy up the layout to remove unnecessary sizes. This change also makes
the flash start at 0x0 and increases the size of the FMAP to 0x1000.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I46663003857eb50271c6ad1da6c4e56c8f4bb6c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67542
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
Elyes Haouas