Adapt implementation from skylake to prepare for removal of
HIGH_MEMORY_SAVE and moving on to RELOCATABLE_RAMSTAGE.
With this change, CBMEM region is set early-on as WRBACK
with MTRRs and romstage ram stack is moved to CBMEM.
Change-Id: Idee5072fd499aa3815b0d78f54308c273e756fd1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15791
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fill in the NHLT ACPI OEM header fields to differentiate
different audio solutions on a per board basis. This handles
boards that share a firmware that are differentiated by
the SKU id and boards that have their own firmware. For the
latter, the Oem Table ID uses the VARIANT_DIR to differentiate.
"reef" is always used for Oem ID which is treated as more of
family in this case.
iasl -d shows the following on reef:
[00Ah 0010 6] Oem ID : "reef"
[010h 0016 8] Oem Table ID : "reef"
[018h 0024 4] Oem Revision : 00000008
BUG=chrome-os-partner:60494
BRANCH=reef
Change-Id: I5daa6f0306bc05e812a8737ce61ee37177a36b76
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17772
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
There are 2 gpios on reef-like boards that can be composed
into a SKU. Add support for identifying the SKU value using
the base 3 gpio logic. Also export the SKU information to the
SMBIOS type 1 table.
BUG=chrome-os-partner:59887,chrome-os-partner:60494
BRANCH=reef
Change-Id: I8bb94207b0b7833d758054a817b655e248f1b239
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17771
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There is ongoing work to link SPI bus and devices in to the devicetree
so this can be generated, but for now put in the raw ASL code to
describe this controller so it can be used by the factory.
BUG=chrome-os-partner:55538
TEST=successfully load fpc1020 kernel module on eve board
Change-Id: I6641664e60fcf2c0bad4b3506c77513b26d7be2e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17776
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Simplify set_power_led() by consolidating switch and setting values
as needed inline based on LED state. Remove unnecesary function
param, includes for Tidus.
Change-Id: I28e6fac5f8d7e2ff419002db714ce88697895faf
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17744
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Simplify set_power_led() by consolidating switch and setting values
as needed inline based on LED state.
Fix non-off LED polarity for Tricky using correct value from Chromium source
TEST: power on Tricky, observe LED lit / solid
Change-Id: I8bc7c4ae3f83d3f37b76fd5c90a4faed7057ebee
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17719
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Doing PCI config operations via MMIO window by default is a
requirement, if supported by the platform. This means chipset
or CPU code must enable MMCONF operations early in bootblock
already, or before platform-specific romstage entry.
Platforms are allowed to have NO_MMCONF_SUPPORT only in the
case it is actually not implemented in the silicon.
Change-Id: Id4d9029dec2fe195f09373320de800fcdf88c15d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Drastically reduced RW_MRC_CACHE size to hold one update. Now
that this area isn't changing after every S5 entry there's no
need make it so large.
- ELOG area reduced by 4KiB for subsequent area alignment. In practice
this doesn't matter because the elog library only uses 4KiB bytes.
16KiB->12KiB is a nop.
- Moved RW_NVRAM for subsequent alignment.
- Most importantly, RW_SECTION_(A|B) are aligned to 64KiB boundaries
and sized to 64KiB multiples. This ensures updates don't need a
read-modify-write that could force a system into recovery if
an inopportune power event occurred.
BUG=chrome-os-partner:60492
BRANCH=reef
Change-Id: I2a2e2797897c934db1a3f9627c6c13a9b2aad540
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17727
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We may support different sdram sizes on one board in future, so
we need to calculate sdram sizes from sdram drvier.
BRANCH=None
BUG=None
TEST=boot kevin
Change-Id: I43e8f164ecdb768c051464b4dbc7d890df8055d0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3c4d8b3cb647b2f9cebc416c298817c16d49330e
Original-Change-Id: I95d5ef34de9d79ebca3600dc7a4b9e14449606ff
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/411600
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17629
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Gru only uses USB 2.0 in firmware to avoid all the madness associated
with Type-C port orientation and USB 3.0 tuning. We do this by isolating
the SuperSpeed lines in the Type-C PHY so it looks like they aren't
connected to the device.
Unfortunately, some devices seem to already get "locked" into SuperSpeed
mode as soon as they detect Rx terminations once, and can never snap out
again on their own. Since the terminations are already connected during
power-on reset we cannot disable them fast enough to prevent this, and
the only solution we found to date is to power-cycle the whole USB port.
Now, Gru's USB port power is controlled by the EC, and unfortunately we
have no direct host command to control it. We do however have a command
to force a certain USB PD "role", and forcing our host into "sink" mode
makes it stop sourcing power to the port. So for lack of a saner
solution we'll use this to work around our problem.
BRANCH=gru
BUG=chrome-os-partner:59346
TEST=Booted Kevin in recovery mode, confirmed that my "problem stick"
gets detected immediately (whereas previously I had to unplug/replug
it). Booted Kevin to OS in both developer and normal mode and confirmed
that USB still seems to work.
Change-Id: Ib3cceba9baa170b13f01bd5c01bd413be5b441ba
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cd695eda33299e50362f1096c46f2f5260c49036
Original-Change-Id: I2db3d6d3710d18a8b8030e94eb1ac2e931f22638
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/413031
Reviewed-on: https://review.coreboot.org/17628
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
MMCONF was explicitly used here to avoid races of 0xcf8/0xcfc access
being non-atomic and/or need to access 4kiB of PCI config space.
All these platforms now have MMCONF_SUPPORT_DEFAULT.
Change-Id: I943e354af0403e61263f1c780f02c7b463b3fe11
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17529
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Do not abort the initialization of PTN3460 if HW-ID could not be
retrieved and just assume that the HW-ID does not match 7.9.2.0.
In this case PTN3460 will be setup to a working condition even
if this field is missing.
This makes this driver more robust with faulty blocks.
Change-Id: I301fb165a7924768e44182d92be820294beb0280
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/17671
Tested-by: build bot (Jenkins)
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
These headers & comments indicating a lack of functionality don't help
anything. We discourage copyrights and licenses on empty files, so
just clear these.
Change-Id: Id2ab060a2726cac6ab047d49a6e6b153f52ffe6d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17657
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Combine existing boards google/falco and google/peppy with new
ChromeOS devices leon and wolf, using their common reference board
(slippy) as a base.
Chromium sources used:
firmware-falco_peppy-4389.81.B d7703cac [falco: Add support for Samsung...]
firmware-leon-4389.61.B ea1bf55 [haswell: Enable 2x Refresh Mode]
firmware-wolf-4389.24.B 7c5a9c2 [Wolf: haswell: Add small delay before...]
Additionally, some minor cleanup/changes were made:
- I2C devices set to use ACPI (vs PCI) mode
- I2C device ACPI entries adjusted as per above
- I2C devices set to use level (vs edge) interrupt triggering
- XHCI finalization enabled in devicetree
- HDA verb entries use simplified macro entry format
Existing google/falco and google/peppy boards will be removed in a
subsequent commit.
Variant setup modeled after google/beltino
Change-Id: I087df5f98c1bb4ddd0ab24ee9ff786a9d38d87be
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17621
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
No need for these boards to exist separately once included as
variants under google/slippy
Change-Id: I52a476ceaadf50487d6fe21e796d7844f946d8b3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17622
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add support for Kaby Lake RVP7 board
* Add RVP7 board support in Kconfig
* Override default descriptor and ME binary paths in Kconfig
since those binaries will differ for RVP3 and RVP7
* Add RVP7 board name in board_info.txt and Kconfig.name
* Add devicetree.cb for RVP7 in the variants path
* Add gpio.h for RVP7 in variants/include/variant path
* Made board specific code for retrieving spd, i.e., in RVP7
there is non-soldered DIMMs, so SPD is read through smbus,
unlike RVP3 where memory DIMMs are soldered down with board.
Hence for RVP3, the spd binaries will be fixed and can be
kept as binary file in cbfs.
BUG=none
BRANCH=none
TEST=Built and boot Kaby Lake RVP7
Change-Id: I6f3d17d857bad1b5cf39f0bc900c760fee72da48
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/17637
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide the rise and fall times for the i2c buses and let the
library perform the necessary calculations for the i2c
controller registers instead of manually tuning the values.
BUG=chrome-os-partner:58112
BRANCH=master
TEST=emerge-pyro coreboot
Change-Id: I68be9b96dc731eb0084ee5e15921866818637e73
Signed-off-by: Kevin Chiu <Kevin.Chiu@quantatw.com>
Reviewed-on: https://review.coreboot.org/17652
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Independent of Board DMIC configuration, add all DMIC points
i.e. add DMIC-1ch, DMIC-2ch, DMIC-4ch endpoints.
This allows flexibility to userspace to open capture devices as needed.
This is a temporary fix; once upper layers support choosing
particular channels from 4-ch PCM stream, we will limit exposing only
DMIC-4ch endpoint.
BUG=chrome-os-partner:60444
BRANCH=none
TEST=Verify All DMIC blobs are included
Change-Id: I9729a3570c0668f3da4e7986291ebad6fe1de47a
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-on: https://review.coreboot.org/17660
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to mirror the full flexibility of the NHLT library that
allows a caller to set the OEM revision field in the ACPI header
modify the variant callback to override the value.
Change-Id: I16e539b350a50e3c163be1439c8637b82e53a759
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17651
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
In the ACPI header there's an OEM revision field that was previously
just being implicitly set to 0. Allow for a board to provide a
non-zero value for this field.
Change-Id: Icd40c1c162c2645b3990a6f3361c592706251f82
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17650
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of putting all the functions inline just put the
current implementation into a C file. That way all the implementation
innards are not exposed.
Lastly, fix up the fallout of compilation units not including the
headers they actually use.
Change-Id: I01fd25d158c0d5016405b73a4d4df3721c281b04
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17648
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Vendorcode always does PCI MMCONF access once it is
enabled via MSR.
In coreboot proper, we don't give opportunity to make
pci_read/write calls before PCI MMCONF is enabled via MSR.
This happens early in romstage amd_initmmio() for all cores.
Change-Id: Id6ec25706b52441259e7dc1582f9a4ce8b154083
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17534
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vendorcode always does PCI MMCONF access once it is
enabled via MSR.
In coreboot proper, we don't give opportunity to make
pci_read/write calls before PCI MMCONF is enabled via MSR.
This happens early in romstage amd_initmmio() for all cores.
Change-Id: If31bc0a67b480bcc1d955632f413f5cdeec51a54
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17533
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support of Variant board model for existing intel/kblrvp,
since there might be more RVP board supports under
intel/kblrvp. Existing is for KBL RVP3 board.
BUG=none
BRANCH=none
TEST=Built and boot Kaby Lake RVP3
Change-Id: I041a07a273dbb77e422d48591f06b5f1011cd9f7
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/17630
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Use common lib spd_bin to get spd.
Change-Id: If94413fc36a98f7694f560955bbb80abefe32166
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17435
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With commit 2c3054c1(soc/intel/skylake: Add USB Port Over
Current (OC) Pin programming) USB OC pin programming is already
initiated from devicetree.cb, hence remove it from ramstage.c.
BUG=none
BRANCH=none
TEST=Built and booted KBLRVP from USB device
Change-Id: Icb47533aa57f208d5a52560db924169b908c7a88
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/17635
Tested-by: build bot (Jenkins)
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
tune i2c devices clk for snappy:
I2C0: audio
I2C2: TPM H1
I2C3: elan touchscreen
I2C4: elan touchpad
I2C5: wacom digitizer
BUG=chrome-os-partner:59034
BRANCH=master
TEST=emerge-snappy coreboot chromeos-bootimage, and measured on EVT.
audio:
Freq. 393.7kHz
Rise Time 58.8ns
Fall time 12.11ns
TPM H1:
Freq. 398.8kHz
Rise Time 31.71ns
Fall time 13.28ns
elan touchscreen:
Freq. 390.5kHz
Rise Time 235.7ns
Fall time 37.64ns
elan touchpad:
Freq. 393.7kHz
Rise Time 288.8ns
Fall time 51.67ns
wacom digitizer:
Freq. 388.8kHz
Rise Time 124.1ns
Fall time 21.10ns
Change-Id: Ib2be9e1575d4962476423eafa80f9bb10ba40e17
Signed-off-by: Wisley Chen <wisley.chen@quantatw.com>
Reviewed-on: https://review.coreboot.org/17634
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Chop off 4kb block from RW_MRC_CACHE to store variable MRC cache.
BUG=chrome-os-partner:57515
TEST=with patch series applied: cold reboot, make sure MRC is not
updated. Do S3 suspend/resume cycle.
Change-Id: I3e19fff9c9b20d6c73cbb13bfeec49e9a274bb72
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/17235
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These three files were added as symbolic links to the other files in
the same directory. Delete the links, and copy the real files
into their places.
Because of the varied environments that coreboot is built in, we don't
want to have symbolic links in the tree.
These three files were the only cases of symbolic links.
Change-Id: If69f40c2c4cdcabc4fdfc1d6026a91c0791756da
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17632
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This mainboard is identical to ga-945gcm-s2l except for NIC
which is a Realtek RTL 8101E chip (10/100 Mbit).
The schematics of ga-945gcm-s2l mention multiple NICs and ga-945gcm-s2c
and ga-945gcm-s2l have a common manual further indicating that those
boards are close to identical.
Change-Id: Iba3d401efcf208154e639c3237b201830a5151aa
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17416
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When testing USB 2.0 compatibility with different kinds
of USB 2.0 devices on Kevin board, we find that some
USB HDDs (e.g. seagate SRD00F1 1TB HDD) and some smart
phones (e.g. galaxy A5 smart phone) can't be detected.
And according to the error log, this issue is related
to USB 2.0 PHY signal problem.
For the USB HDD, error log is:
[ 592.557724] usb 5-1: new high-speed USB device number 2 using xhci-hcd
[ 592.847735] usb 5-1: new high-speed USB device number 3 using xhci-hcd
[ 593.473720] usb 5-1: new high-speed USB device number 6 using xhci-hcd
[ 594.187717] usb 5-1: new high-speed USB device number 9 using xhci-hcd
[ 595.020717] usb 5-1: new high-speed USB device number 13 using xhci-hcd
[ 595.284730] usb 5-1: new high-speed USB device number 14 using xhci-hcd
[ 595.574816] usb 5-1: new high-speed USB device number 15 using xhci-hcd
The log shows that HDD failed to high-speed handshake.
For the smart phone, error log is:
[ 1145.661625] usb 5-1: new high-speed USB device number 2 using xhci-hcd
[ 1145.771674] usb 5-1: device descriptor read/64, error -71
[ 1145.979752] usb 5-1: device descriptor read/64, error -71
[ 1146.187721] usb 5-1: new high-speed USB device number 3 using xhci-hcd
[ 1146.301754] usb 5-1: device descriptor read/64, error -71
[ 1146.509750] usb 5-1: device descriptor read/64, error -71
[ 1146.717722] usb 5-1: new high-speed USB device number 4 using xhci-hcd
[ 1146.724393] usb 5-1: Device not responding to setup address.
[ 1146.930795] usb 5-1: Device not responding to setup address.
[ 1147.137720] usb 5-1: device not accepting address 4, error -71
[ 1147.246644] usb 5-1: new high-speed USB device number 5 using xhci-hcd
[ 1147.253336] usb 5-1: Device not responding to setup address.
[ 1147.459786] usb 5-1: Device not responding to setup address.
[ 1147.665712] usb 5-1: device not accepting address 5, error -71
[ 1147.671789] usb usb5-port1: unable to enumerate USB device
The log shows that smart phone failed to read device
descriptor, error -71 may be caused by PHY signal problem.
This patch aims to tune USB 2.0 PHY with the following
parameters to support USB HDD, smart phone and some other
potential USB 2.0 devices.
1. Disable the pre-emphasize in chirp state to avoid
high-speed handshake failure.
2. Bypass ODT auto compensation to enable set max driver
strength manually. (Bit[42] of usbphy_ctrl register is
1'b1 for bypass, and Bit[41:37] of usbphy_ctrl register
is 5'b10000 for max driver strength).
3. Bypass ODT auto refresh, and set the max bias current
tuning reference. (Bit[57] of usbphy_ctrl register is
1'b1 for bypass, and Bit[52:50] of usbphy_ctrl register
is 3b'100 for max bias current tuning reference).
We have done the USB 2.0 compliance test and compatibility test
with this patch, it works well.
BRANCH=gru
BUG=chrome-os-partner:59623
TEST=plug/unplug USB HDD or smart phone in Type-C port,
check if they can be detected successfully.
Change-Id: I275c2236b8e469bfd04e9184d007eb095657225e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7735c514d4136978133c2299f2f58da8320bb89f
Original-Change-Id: I4e6c10faa1c03af9880a89afe4731a7065eb1e4e
Original-Signed-off-by: William wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/409856
Original-Commit-Ready: Eddie Cai <eddie.cai.rk@gmail.com>
Original-Tested-by: Cindy Han <cindy.han@samsung.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17566
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This pach sets the DPTF passive temperature trip point for CPU back to
95 degree celsius from 61 degree celsius as per previous thermal
optimizations (https://review.coreboot.org/#/c/16766/).
BUG=chrome-os-partner:60038
BRANCH=master
TEST=built, booted on Reef and verified the passive trip point
funtionality.
Change-Id: I83ce69b19a94e4ea8ebedfc06f259579ed6dd5d3
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/17598
Tested-by: build bot (Jenkins)
Reviewed-by: Venkateswarlu V Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Kyösti Mälkki