This patch adds the support for Kabylake Celeron base SKU
with PCH ID 0x9d50.
BRANCH=none
BUG=b:65709679
TEST=Ensure coreboot could recognize the Kabylake Celeron base
SKU and boot into OS.
Change-Id: I9c6f7bf643e0dbeb132fb677fcff461244101a55
Signed-off-by: Tsai, Gaggery <gaggery.tsai@intel.com>
Reviewed-on: https://review.coreboot.org/21617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: David Wu <david_wu@quantatw.com>
Reviewed-by: T.H. Lin <T.H_Lin@quantatw.com>
Unlike Chromebooks, Purism laptops are only sold under one vendor name,
so MAINBOARD_VENDOR only needs to be set in src/mainboard/purism/Kconfig.
Change-Id: If0b33df01ff3327272d089b7efb8e64fa1233fdf
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/21591
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Youness Alaoui <snifikino@gmail.com>
Generating a project file list used to do a rebuild of the project.
Instead, just make sure there's a coreboot.rom file present and if
it is, generate the list.
Change-Id: I9cc12ef3d1990c3422625630451b2a7b8d77829c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/21585
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add support for google/celes (Samsung Chromebook 3) as
a variant of the cyan Braswell baseboard.
- Add board-specific code as the new celes variant
- Add new trackpad I2C device to the baseboard for potential
reuse by other variants
Sourced from Chromium branch firmware-celes-7287.92.B,
commit 9f0760a: Revert "Revert "soc/intel/braswell: Populate NVS SCC BAR1""
Change-Id: Id52d3c523bae7745b3dc04da012ab65c1fb37887
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21572
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Add support for google/banon (Acer Chromebook 15 CB3-531) as
a variant of the cyan Braswell baseboard.
- Add board-specific code as the new banon variant
Sourced from Chromium branch firmware-strago-7287.B,
commit 02dc8db: Banon: 2nd source DDR memory (Micro-MT52L256M32D1PF)
Change-Id: If29e95deee88b79522547e16fc80c2d5378da7c7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Add support for google/terra (Asus Chromebook C202SA/C300SA) as
a variant of the cyan Braswell baseboard.
- Add board-specific code as the new terra variant
- Add code to the baseboard to handle terra's unique thermal management
- Add new shared SPD files to baseboard
Sourced from Chromium branch firmware-terra-7287.154.B,
commit 153f08a: Revert "Revert "soc/intel/braswell: Populate NVS SCC BAR1""
Change-Id: Ib2682eda15a989f2ec20c78317561f5b6a97483a
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Gardenia (with Stoney Processor) has a single memory channel, not two.
This corrects DMI type 17 reporting and the memory clear functions.
Change-Id: If49b6a9f37b2687ea2f64105fb9e476a89aa87ed
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/21602
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a macro to shift a value to the left by a specified number of bits.
Change-Id: Ib3fb43b620f31fee2a41f00ddf7294edc81a60f6
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/21601
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Once w83627hf_set_clksel_48() is unified into
winbond/common/early_init.c by /c/21331 (Unify w*_set_clksel_48()),
this file is no longer needed and can be dropped.
Build tested on select affected mainboards.
Change-Id: I6a5e27fdd48c6e002c3a39dc92fef77e85aea209
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/21474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
It is already using winbond_enable_serial(). Once
w83697hf_set_clksel_48() is unified into winbond/common/early_init.c,
this file is no longer needed and can be dropped.
Change-Id: I7424233b5d70e143721038493f194760f07346a1
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/21332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This function is identical throughout all Winbond superios in
the tree, so move it into superio/winbond/common/early_init.c,
renamed from early_serial.c because it now does more than just
early serial.
Change all affected mainboards to use the unified function.
Change-Id: If05e0db93375641917e538d83aacd1b50fbd033b
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/21331
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
IRQ 9 is used for different purpose on this mainboard so move SCI away
to IRQ 10.
Change-Id: I7f055447f5d92bc4696b38e8103a7aebde95d9d3
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/21586
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The System Control Interrupt is routed per default to IRQ 9. Some
mainboards use IRQ 9 for different purpose. Therefore it is necessary to
make the SCI configurable on Apollo Lake.
Change-Id: Ib4a7ce7d68a6f1f16f27d0902d83dc8774e785b1
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/21584
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable LTR for Root port 0, where wifi card is connected.
BUG=b:65570878
TEST=After enbaling LTR on port 0 on the MB devicetree, No errors reported
by AER driver for root port 0.
Change-Id: I222a87fe2094c8424760ccf578e32b9ac042f014
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/21548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
There are a lot errors reported by AER driver for root port 0.
The erors are being caused by an unsupported request from the
device to the upstream port. Enabling LTR on the root port stops
these errors, it is because LTR is enabled on the device side but
not on the root port and hence root port was logging the LTR messages
from the device as unsupported.
The PCIe base spec (v3.1a) section 6.18 also states that:
LTR support is discovered and enabled through reporting and control
registers described in Chapter 7. Software must not enable LTR in an
Endpoint unless the Root Complex and all intermediate Switches indicate
support for LTR. Note that it is not required that all Endpoints support
LTR to permit enabling LTR in those Endpoints that do support it. When
enabling the LTR mechanism in a hierarchy, devices closest to the
Root Port must be enabled first.
If an LTR Message is received at a Downstream Port that does not
support LTR or if LTR is not enabled, the Message must be treated
as an Unsupported Request. FSP has a UPD for enabling/disabling
LTR on root port, use the same for configuring LTR on PCIe root ports.
BUG=b:65570878
TEST=After enbaling LTR on port 0 on the MB devicetree, No errors reported
by AER driver for root port 0.
Change-Id: Ica97faa78fcd991dad63ae54d2ada82194b4202a
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/21547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In coreboot commit bcd0bdabed (soc/intel/cannonlake: add rtc failure
checking), the function soc_get_rtc_failed was supposed to be moved,
but the old function was not removed, causing a build error.
BUG=b:63054105
Change-Id: I31c1966af413df3f5a5492a5dd891a6eb26a1fc4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/21616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There's an occasional issue on machines which use CMOS for their
vbnv storage. The machine that just powers up from complete G3
would have had their RTC rail not held up. The contents of vbnv
in CMOS could pass the crc8 though the values could be bad. In
order to fix this introduce two functions:
1. vbnv_init_cmos()
2. vbnv_cmos_failed()
At the start of vboot the CMOS is queried for failure. If there
is a failure indicated then the vbnv data is restored from flash
backup or reset to known values when there is no flash backup.
BUG=b:63054105
Change-Id: I8bd6f28f64a116b84a08ce4779cd4dc73c0f2f3d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
It's helpful to use the common vbnv_reset() function to
initialize the vbnv contents when backing store failures occur.
Therefore, allow that to happen.
BUG=b:63054105
Change-Id: I990639e8c163469733fdab0d3c72e064acc9f8d8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to early_pch_common.c and
add a helper function to determine if failure occurred.
BUG=b:63054105
Change-Id: I710d99551cfb6455244f66b47fcbecc790ae770f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21558
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I368c31b9935c0fa9e8a1be416435dd76f44ec1ec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21557
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: Ic4bf99dc3a26fbc3bd508e484963b9298ef1b24b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21556
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I1d90cc557225ddbba1787bf95eae0de623af487e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I88bf9bdba8c1f3a11bc8301869e3da9f033ec381
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21554
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred. In addition actually
provide soc_get_rtc_failed() which properly indicates to the common
code that RTC failure did occur in the cmos_init() path.
BUG=b:63054105
Change-Id: I9dcb9377c758b226ee7bcc572caf11b7b2095425
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: Ia0a38f00d2a5c7270e24bdd35ecab7fbba1016d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21552
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I1b02028a1830ff9b28b23da7a4a1fd343f329f0d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21551
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add vbnv_init() which is responsible for doing any vbnv initialization
and reading the vbnv contents. Having this function allows for
putting vbnv backing store specific support in the main vboot logic
path.
BUG=b:63054105
Change-Id: Id8f0344e5de5338417ae2e353ae473d6909c860a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21550
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of having each potential caller deal with the differences
of cmos_init() and init_vbnv_cmos() when VBOOT is enabled put the
correct logic within the callee, cmos_init(), for handling the
vbnv in CMOS. The internal __cmos_init() routine returns when the
CMOS area was cleared.
BUG=b:63054105
Change-Id: Ia124bcd61d3ac03e899a4ecf3645fc4b7a558f03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21549
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Linux Pstore area must not be cleared on a reboot. Set the option
to not clear the memory in AGESA.
BUG=b:64193190
BRANCH=none
TEST=Memory clear isn't called in AGESA.
Change-Id: I9b8286ade718fa80bf3badd478ab9a7df643ab98
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/21596
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Kahlee has a single memory channel, not two. This corrects DMI type 17
reporting and the memory clear functions.
BUG=b:65403853, b:64193190
BRANCH=none
TEST=AGESA DMI reports the correct number of DIMMs.
Change-Id: Ic263d2677a480448beaf3850391b1a3d4ed38657
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/21595
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
vboot images come with multiple regions carrying CBFS file systems. To
expedite hashing (from slow flash memory), the FW_MAIN_* regions are
truncated since they typically have pretty large unused space at the
end that is of no interest.
For test purposes it can be useful to re-engage that space, so add a
command that creates a new empty file entry covering that area (except
for the last 4 bytes for the master header pointer, as usual).
BUG=b:65853903
BRANCH=none
TEST=`cbfstool test.bin expand -r FW_MAIN_A` creates a new empty file of
the expected size on a Chrome OS firmware image.
Change-Id: I160c8529ce4bfcc28685166b6d9035ade4f6f1d1
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/21598
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Fix typo in comment
- Aphabetize package list and put each package on a single line
- Add environment variables into coreboot user's .bashrc file
- Add openssl, qemu, and shellcheck to installed packages
Change-Id: I37771be5d3ecaa61d76d99e689b422144a6d7dc6
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/21582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Chris Ching <chingcodes@chromium.org>
- Update checkpatch.pl to version 0547fa58
(checkpatch: add 6 missing types to --list-types)
- Update spelling.txt to version d9f91f8
(scripts/spelling.txt: add a bunch more spelling mistakes)
- Fix an additional unescaped left brace in a regex - causes warnings
in new versions of perl.
Change-Id: Ic443099e90a46280f18d58799afc72d00dc83793
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/21581
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Chris Ching <chingcodes@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch outputs decoding errors with BIOS_WARNING instead of
depending on CONFIG_DEBUG_RAM_SETUP.
Returns SPD_STATUS_INVALID on invalid settings for tRR, bcd and tCK
and doesn't try to create a valid setting if an invalid setting is
detected.
Change-Id: Iee434d1fa1a9d911cc3683b88b260881ed6434ea
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/21480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This simplifies computing dram timings a lot.
This removes computation of rank size based on columns, rows,
banks,... and uses the information in SPD byte 31. The result of this
is that dimms with multiple asymmetric ranks are not supported
anymore. These however are very rare and most likely never tested on
this platform.
This also uses i2c block read instead of byte read to speed up the
raminit. The result is less time is being spend reading SPDs.
It still keeps smbus read byte as a backup if i2c block read were to
fail.
Change-Id: I97c93939d11807752797785dd88c70b43a236ee3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
If results are uploaded the temporary directory in which they are
stored gets deleted, yet we currently point to the deleted directory in
the output.
This patch fixes it so that we point to the actual location in the local
repository where uploaded results are found.
Change-Id: I1f42c3296ec1d19fcfa4911307e07e67de289895
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/21415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Add PMC pci driver on top of PMC common code, also include pmc init code
reference from skylake.
Change-Id: I95895a3e26cdebd98a4e54720bd4730542707d7e
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/21251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ACPI spec requires devices with children to have an HID,
and Windows enforces this strictly. Without the SIO device
having an HID, Windows will not detect the attached PS2 keyboard
and trackpad. Therefore, add the proper HID.
TEST: boot Windows on google/stout, observe PS2 keyboard and
trackpad detected and functional.
Change-Id: I61d7341c15483f8e1fe0e485a25591ceb92eaae1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21580
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
ToString() requires the input buffer data to be null-terminated,
but the data returned by the EC is not, leading Windows to fail
to report any battery data at all. Correct this by concatenating
a null terminator (0x00) to the end of the buffer data before
inputting to ToString() where needed
TEST: boot Windows on google/stout, observe battery data
reported correctly.
Change-Id: I974afcd6ff1c617301d0897d6bd1fe14200aa3b9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
EC ACPI code is calculating the drain rate, but does not store it
in the battery status package before returning it. Correct this
omission, and set the drain rate to a preset minimum if calculated
value is less. Taken from vendor firmware ACPI dump.
Change-Id: I52837d5879112ab3103976bda28906fac8f880ec
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Youness Alaoui <snifikino@gmail.com>
me_cleaner now allows setting a bit in the PCH straps - AltMeDisable
tells the ME to stop execution after BUP - disabling the 30 minute
watchdog - but also "breaking" the ME. The ME reports opmode = 2.
This means the ME will not respond when we wait for an acknowledgement
about the DRAM being ready. The current code waits 5 seconds for a
response, that in this case, never comes.
If the ME is reporting opmode 2, don't delay or wait for a response
from the ME.
Tested on my X220, this patch fixed the five seconds before the payload
executed. Verified using the timestamp patch.
Change-Id: Ifdda6b2dbb8ae3a650be6d5df6c60475a3fa74aa
Signed-off-by: Nathaniel Roach <nroach44@gmail.com>
Reviewed-on: https://review.coreboot.org/21466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Bora Guvendik