This option is duplicated in depthcharge:
https://crrev.com/c/1545144
BUG=b:124141368, b:124192753, chromium:943150
TEST=make clean && make test-abuild
CQ-DEPEND=CL:1545144
BRANCH=none
Change-Id: I48e20ad21cdcb948a23387d3e5fcf142723b0c82
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32135
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
%lx is the right format string for printing longs.
Found-by: Coverity Scan, CID 1229686, 1229687
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: Ib7ab54dc039bdd60969c79f3c881d69fc68f0d2a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32008
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Follow thermal table for second tunning.
BUG=b:129509918
TEST=Built and tested on sarien system
Change-Id: I64844b84891dc3ab7abe9378cdca5dcf57b3e433
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32118
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
When invoking 'make menuconfig' with gcc 4.9.2 an error is thrown:
ld: build/util/kconfig/lxdialog/checklist.o: undefined reference
to symbol 'acs_map'
This happens with ld version 2.24 and newer when menuconfig is
executed for the first time after make clean. This does not happen
with ld 2.20 (part of gcc 4.4.7).
It can be fixed with the flag -ltinfo in HOST_LOADLIBES.
Change-Id: I6216bb4d276d4bf98aa4ec06457b809fdcd73235
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If using a commit/branch which doesn't use a boot logo,
we don't want the build to fail unnecessarily
Test: build with upstream Tianocore commit hash,
avoid failure after successful compilation.
Change-Id: Ic41bacbb97926e9538f434aecc0f0eebc5f6326f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32133
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Skipping display init on normal-mode boot is a vboot feature, not
specific to Chrome OS. Fix the code in display_init_required() and
pci_dev_init() to check CONFIG_VBOOT rather than CONFIG_CHROMEOS now
that the two aren't always the same anymore.
Also add a check to guarantee at compile time that
CONFIG_VBOOT_OPROM_MATTERS is enabled on all platforms that make a check
to this function (when CONFIG_VBOOT is also enabled). The whole display
skipping mechanism is based on the oprom_needed NVRAM flag, and skipping
display init without enabling the option to tell vboot that it needs to
pay attention to that flag would make the whole thing not work right.
Change-Id: I5d6421509bdcdaa61b78015af3fa6241fe75bb7f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The sku ids are updated for Pantheon.
Sync'ing the sku_ids list in the master sku sheet for Pantheon.
BUG=b:121207221
BRANCH=firmware-nami-10775.B
TEST=emerge-nami coreboot chromeos-bootimage
Change-Id: Ibf683ca8219b2980ea9d9c40b06db264d58440b0
Signed-off-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32098
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
For HW require to change GPIO_E1.
Change GOIO_E1 setting from NF2(SATAGP1) to NF1(SATAPCIE1).
BUG=b:123730924
TEST=flash BIOS and make sure hatch boots up properly
Change-Id: I0f5569e13b17a2dc713be5031a63436e8f31f911
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32099
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GPP_A12 has a Native3 (SX_EXIT_HOLDOFF#) mode, which allows to delay
resuming to S0. If this pad is not locked and platform was not initially
designed for this functionality, malware could reconfigure this pads
setting under OS (switch to Native3), which would make platform not able
to resume until G3 is applied. To prevent misuse of this pad,
re-configure this pad before entering S3 and S5 to guarantee that the
pad configuration is correct.
BUG=b:128686027
Change-Id: I1e7979baa491acf2c56d223afb4618f0f6429e37
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32111
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch ensures to have same stack base for FSP and coreboot.
Feature added in FSP2.1
- Remove stack swapping from FSP.
- Stack will be shared between coreboot and FSP.
TEST=Build and boot FSP2.1 enable platform like dragonegg, iclrvp.
No car global variable corruption seen after enabling
this feature.
Change-Id: I673b4216d991d8ccad725c3931006a694184106c
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32079
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Opens a binary file to extract DDR SPDs using known bits.
At the moment only DDR4 SPDs are supported.
Dumps the found SPDs into the current folder, as either
binary or hex encoded file.
Works with python2 and python3.
Change-Id: I26dd73d43b724ea6891bb5b6e96856c42db8577c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
This fixes a memory leak, which was partially resolved in
2d1e0eb (payloads/coreinfo: Free buffer before returning).
Found-by: Coverity Scan, CID 1373370 (RESOURCE_LEAK)
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I0efe94b9dfb27746828055427029c01c7f407ec2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32094
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The dead_code() macro can be used to ensure that a certain code path is
compile-time eliminated (e.g. if you want to make sure it's never
executed for certain Kconfig combinations). Unfortunately, the current
implementation via __attribute__((error)) hits only at the GCC level.
This can catch code that can be compile-time eliminated based on state
within the same file, but it cannot be used in cases where a certain
library function is built but then garbage collected at link time.
This patch improves the macro by relying solely on the linker finding an
undefined reference. Unfortunately this makes the error message a little
less expressive (can no longer pass a custom string), but it is still
readable and one can add code comments next to the assertion to
elaborate further if necessary
Change-Id: I63399dc484e2150d8c027bc0256d9285e471f7cc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32113
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enables CONFIG_VBOOT_OPROM_MATTERS in a few more cases where
I think(?) it should be. Haswell, Broadwell and Baytrail Chromebooks
have this enabled in their old depthcharge firmware branches -- we
presumably just forgot to move it over when vboot2 migrated the option
to coreboot. Braswell didn't, but it seems like this requirement was
added when it was migrated to FSP 1.1...? (Not very sure about that one,
but it does call load_vbt() right now which executes things based on
display_init_required().) Additionally, it seems to make sense to enable
it whenever the user explicitly selects VGA_ROM_RUN in menuconfig (like
one of the Intel defconfigs does).
Once we have all this, one could take a step back and ask whether this
option still makes sense at all anymore. It's enabled for almost all
devices (that work with vboot at all), it will presumably be enabled for
all future devices, and it seems that most devices that don't enable it
use libgfxinit, which as far as I can tell isn't gated on
display_init_required() but probably should be. Realistically, whatever
kind of display init a board needs to do (native or option ROM), it's
probably expensive enough that it's worth skipping on a normal mode
vboot boot, and we'd want to have this enabled by default on everything
except boards that actually don't have a display. So maybe we should
flip it around to CONFIG_VBOOT_OPROM_DOESNT_MATTER, but doing that would
probably lead to nobody ever selecting it at all.
Not sure what the best solution there is yet, but I think this patch
at least moves things in the more correct direction.
Change-Id: Id96a88296ddb9cfbb58ea67d93e1638d95570e2c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32114
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add bluetooth Rfkill function to recover the Bluetooth controller in
cases where itself has entered a bad state and needs to be recovered.
Bug=b:129375810
TEST=Boot up into OS and dump SSDT table, check there's _DSD entry under
Bluetooth devices with GPIO in. Also confirm bluetooth itself is
functional.
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Change-Id: I79a310a55d94d7d20d1705afc11fe47cbb81abc1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Replace occurences of 'unsigned' with 'unsigned int' to fix
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
Signed-off-by: Daniel Lim Wee Soong <weesoong.lim@gmail.com>
Change-Id: I94665e8fcb4719521d143774aa84f630b10ee68a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32119
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
GPP_A12 is being used as FPMCU_RST in hatch. This GPIO is being padlocked in
FSP and cannot used in kernel. Hence unlock the GPIO pads to export this pin
in kernel to be used as FPMCU_RST.
BUG=b:128686027
BRANCH=None
TEST=Read Pad Configuration Lock (PADCFGLOCK_GPP_A_0) register.
localhost /sys/class/gpio # iotools mmio_read32 0xfd6e0080
0x00000000
localhost /sys/class/gpio # echo 212 > export
Change-Id: Ie0439956e6c8e386435e535665ccaf2ab82adeb0
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32126
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
FSP has a UPD to unlock all GPIO pads. This parameter is disabled by
default. Add a chip parameter so that GPIO pads can be unlocked on mainboard
level in devicetree and therefore this feature can be used if needed.
BUG=b:128686027
Change-Id: Iad9e8a209dc3f8ca0c994e8c1da329918409a1d4
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32110
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Select support in Kconfig and configure device in devicetree
Tested with ASUS addon TPM modules, v1.2 (ASUS TPM-L FW3.19 rev1.02H) and v2.0 (ASUS TPM-L R2.0 rev1.00) using SeaBIOS and Linux OS
Change-Id: Icdad9a41b61221b536f2ac695f44319f6b0599e7
Signed-off-by: Simon Newton <simon.newton@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32080
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Ignore integrated GBE controller LTR setting to make it wake up from
s0ix with 10/100M cable attached.
BUG=b:122435844
TEST= Test on sarien platorm, after the changes sytem can wake by WOL,
and also checked SLP_S0 residency can increase with 10/100M cable
and battery connected.
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Change-Id: Iec7dd197b8a456751f8e4dcb19e3e153f5888613
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Touchscreen lost function after boot with stylus
touching the screen
BUG=b:128554235
Signed-off-by: Mike Hsieh <mike_hsieh@wistron.corp-partner.google.com>
Change-Id: I692fc6f245b7fade67862da4986a83d11a2cd51f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32100
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Deassert EN_PP3300_WWAN to turn the WWAN module completely off when
entering S5. This is the same fix in commit eeb475c5c for coral board.
BUG=none
BRANCH=none
TEST=On hatch, Perform a quick system power cycle, verify that the modem
is powered cycle and the SIM with PIN lock enabled requests unlocking.
Change-Id: I3ec8ccb7618189b9e8586f5571a68d3309597ee7
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This was flagged as CID 1229647 (MISSING_BREAK). It was
originally fixed in e211bd9, but then reverted in 1c8ee21.
Hopefully fix it for good now.
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: Ib25b07b633ed02c466391050df15eaf9c36a3199
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Failure to find an edid or header is more serious than the spew
log level and should be an error.
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I660218f8b5f5e7f0b01daef0739db79418941515
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32084
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ports CB:30717 changes from CNL to ICL.
This structure is declared as a static CAR_GLOBAL in the common
PMC library code and in the SOC specific code. Remove the SOC
specific version and instead get the chipset_power_state pointer
from the PMC library.
This fixes events that were recorded in chipset_power_state at
boot but were reading as all zero when it was time to parse the
structure when logging events to flash.
Change-Id: I1152d0e882e1acf475072d1553b74f9161e2f485
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32095
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I added a method to fill out the _BIX package structure but never
hooked it up to the expected _BIX method that the OS uses.
This change adds _BIX method and uses the existing method to fill
it out. It also adds ^ before the _UID in _BIF to match _BIX as
the _UID is one level above the method.
Change-Id: I0de91369b6780fd9432990732c1078a73f6a3419
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32093
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When in romstage call into the EC init function so it can send a
progress code to the EC before memory training starts.
BUG=b:127875364
TEST=boot with FSP debug and ensure EC does not try to turn off the
system while it is still booting.
Change-Id: I5d99fb16bae250a82b652c530c13977e74c3378b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When using FSP with debug enabled it takes too long to get to ramstage
and send the first progress code to the EC. The same thing has been
reported to happen when 2x16GB memory is installed.
BUG=b:127875364
TEST=boot with FSP debug and ensure EC does not try to turn off the
system while it is still booting.
Change-Id: I5676354f5e53540273a9029411507f91864735a1
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Enable USB support for mistral in romstage.
TEST=build & run
Change-Id: I5c2bbe16aa3601e014a2b77d192565402ed23794
Signed-off-by: Nitheesh Sekar <nsekar@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32063
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add required changes for USB host mode for
USB disk enumeration.
TEST=build & run
Change-Id: I35ec549b49b9789389c80843f6103e7243d52aac
Signed-off-by: Nitheesh Sekar <nsekar@codeaurora.org>
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@partner-android.googlesource.com>
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Nitheesh Sekar <nsekar@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As part of chromium:942901, physical dev switch functionality
is being deprecated.
Remove remaining references as well as helper macros.
BUG=chromium:942901
TEST=Build locally
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ib4eec083eb76d41b47685701f9394c684ddc6b37
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32064
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The policy to identify and log the XHCI wake events is similar between
skylake and apollolake. Hence move the similar parts to a common
location.
BUG=b:123429132
BRANCH=None
TEST=Ensure that the system boots to ChromeOS. Ensure that the wake up
events due to USB are logged into the event logs.
6 | 2019-03-21 09:22:18 | S0ix Enter
7 | 2019-03-21 09:22:22 | S0ix Exit
8 | 2019-03-21 09:22:22 | Wake Source | PME - XHCI (USB 2.0 port) | 9
9 | 2019-03-21 09:22:22 | Wake Source | GPE # | 13
10 | 2019-03-21 09:23:20 | ACPI Enter | S3
11 | 2019-03-21 09:23:30 | Wake Source | PME - XHCI (USB 2.0 port) | 9
12 | 2019-03-21 09:23:30 | ACPI Wake | S3
13 | 2019-03-21 09:23:30 | Wake Source | GPE # | 13
Change-Id: Ia6643342e3292984e422ff3c3fcd4bc0d99f947e
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31999
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This adds DPTF based Fan speed control for CML based Hatch system.
BUG=None
BRANCH=None
TEST=Built and tested fan speed with different temperatures
Change-Id: I3c2a679dc67eecb17098ce0f0c9703c679473a2d
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31980
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Rowan board is dead, dissect it out of Oak.
Signed-off-by: Evan Green <evgreen@chromium.org>
BUG=chromium:840888
BRANCH=none
TEST=emerge-oak coreboot chromeos-bootimage
CQ-DEPEND=CL:1538915,CL:*1087044
Change-Id: Ifb19fa0cd814853270847bc14fc21c841d905146
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32061
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the latest hatch schematics, BOOT1 for the FP MCU is now connected
to the AP. Configuring it to be the same as BOOT0.
BUG=b:126455006
BRANCH=None
TEST=./util/abuild/abuild -p none -t google/hatch -x -a -c max
Change-Id: Ibb451983674a7d812dc562cb8addb1dc50fb155c
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The following is the FSP logic: as long as the Cpu Ratio input in
coreboot is different with CpuStrapSet, system will force to follow
input from coreboot. But CpuStrapsetting is floating, it will be 0
from the first cold boot before memory training and set to 0x1c (or
max CPU ratio for the installed CPU) after first memory training.
The previous fix was attempting to ensure settings were cleared
when FSP was called in recovery mode, but only when coming from S5
which caused issues if recovery mode is requested by the OS and
is only followed by a warm reset.
BUG=b:129412691
TEST=Boot up sarien platform and force recovery, check there's no reset
in the path of recovery.
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Change-Id: I959188be46343bc6f2cb3cc149097b4d449802aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32089
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set tcc_offset value to 10C. It configures the Thermal Control Circuit (TCC)
activation value to 90C. This prevents any abrupt thermal shutdown by taking
early thermal throttling action when CPU temperature goes above 90C.
Change-Id: Ifee0fcc326530622b04e60af0f3b9cb9e3aea7ea
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31984
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For systems that integrate GbE controllers, following parameters should be configured:
SlpS0WithGbeSupport: enable PchPmSlpS0VmRuntimeControl: disable,
PchPmSlpS0Vm070VSupport: disable, PchPmSlpS0Vm075VSupport: disable.
TEST=boot on any GbE supported WHL platform
Change-Id: I02aaf0b77b8fc1555a3a424c02acfada21707d0e
Signed-off-by: Krzysztof Sywula <krzysztof.m.sywula@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32026
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Move the actual graphics init provided by libgfxinit into a sub package
`GMA.GFX_Init`. This way it can be compiled in individually.
Change-Id: Ib413a0d70c8dc305f4476c1d5aee6b81ff880bec
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31456
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We might want to make use of libgfxinit functions without using it for
actual graphics init.
Change-Id: I29c3b19989acb678d0d447e83d38bad9d584caa9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31455
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Joel Kitching