A UPD HybridStorageMode allows a platform to dynamically configure the
PCIe strap configuration required if an Optane device is connected.
The strap configuration is done by HECI commands between FSP and CSE to
override the default PCIe strap value, and the updated strap value is
stored in SPI RW data to be used on the next boot.
CSE Lite supports the strap override when running on CSE RW partition,
while CSE RO partition does not support it because CSE RO is not allowed
to access SPI RW data. The strap override failure on CSE RO causes FSP
not initializing PCH Clkreq and PCIe port mapping and this results NVMe
and Optane initialization failure.
By disabling HybridStorageMode in case of CSE RO boot, NVMe detection is
done by the default PCIe configuration and Optane is detected as a
single NVMe storage device on CSE RO boot in recovery mode. Both NVMe
and Optane devices detection as well as OS installation to these storage
devices are verified on CSE RO boot in recovery mode.
BUG=b:158643194
TEST=boot and verified with tglrvp and volteer in recovery mode
Cq-Depend: chrome-internal:3100721
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Change-Id: I5397cfc007069debe3701bf1e38e81bd17a29f0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42282
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id c531000f:
2020-05-18 20:55:55 +0000 - (vboot: Add recovery reason code for CSE Lite SKU errors)
to commit id 68de90c7:
2020-07-02 11:31:05 +0000 - (Allow building for non-CrOS environments)
This brings in 59 new commits.
Change-Id: I7f3c30511ff4acc60e3581bdab89d685dc7beaa5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43008
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The eSPI polarity macros were reversed. Those are fixed so adjust
the corresponding values related to the correct expectations of
the IRQ path: eSPI virtual wire IRQs are active level high. The EC
sends active level high virtual wire IRQs. The default interrupt
encodings in ACPI for P2/S devices are active edge high. Therefore,
there is no need to override anything.
BUG=b:157984427
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia28d82cd9e432df98839f68bac4eae4447455e53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
eSPI interrupts are active level high. The eSPI polarity register
in the chipset inverts incoming signals if the corresonding bit
is 0 in the register. Therefore, all active high (edge or level)
virtual wire interrupts need to ensure they are not inverted.
And really the sender of the interrupts should be conforming to the
the eSPI spec. As such inverting any signals should not be necessary,
but this register in the chipset allows for fixing up those misbehaviors.
BUG=b:157984427
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I7346bb0484506d96d7ab2e6d046ffa0571683a48
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The Time Window Tau bits are only supported by Comet Lake/Cannon Lake
onwards, so skip setting those bits for earlier SoCs.
Change-Id: Iff899ee8280a9b9bbcea57d4e98b92d5410be21d
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42979
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
V.2: Spare USB routed internally to another peripheral and so
no plug event hook needed.
BUG=b:1603699358,b:157479891
BRANCH=none
TEST=none
Change-Id: Ideacac417a46b96f3e82b53bbb341ecce79ee420
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42994
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Originally, there was problem with PC Engines apu1 platform
which returned serial number value as -64. It was caused by wrong
value of dev->bus->secondary.
Source of the problem is in Porting.h header file. It contains
'#pragma pack(1)' which affects struct device. As mainboard.c
uses different binary layout because of this attribute,
reference dev->bus->secondary lands at wrong memory address.
This patch reorder includes and put <AGESA.h> and <AMD.h>
at the end of list, making struct device consistent.
As a result bus number value in device's structure is correct
and hence serial number.
TEST=`dmidecode -t 2` command in Linux Debian
Signed-off-by: Piotr Kleinschmidt <piotr.kleinschmidt@3mdeb.com>
Change-Id: I5e8690d100b38ac7889395d375c0ff32bdefda0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42512
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reflow lines, correct coding style and align struct members, among
other things. As raminit is very large, handle it on a follow-up.
Tested with BUILD_TIMELESS=1, packardbell/ms2290 does not change.
Change-Id: I343edf1bc2a5ac20ff0aa6de4486e685ce430737
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42701
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves the generation of I2SM ACPI device from static asl
file to runtime generation by ACP device driver. dmic_select_gpio is
set to match version 3+ of Trembyle and Dalboz schematics. In order to
maintain backward compatibility, dmic_select_gpio is updated at
runtime using variant_audio_update for board versions that are prior
to version 3 of reference schematics.
The only difference from static generation is that the device I2SM is
added under ACPD (i.e. ACP device) instead of CREC (Chrome EC
device). It does not make any functional difference from the kernel
perspective.
BUG=b:157603026
TEST=Verified that the following device gets generated in SSDT:
Scope (\_SB.PCI0.PBRA.ACPD)
{
Device (I2SM)
{
Name (_HID, "AMDI5682") // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
Name (_DDN, "I2S machine driver") // _DDN: DOS Device Name
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x000D
}
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x01)
{
Package (0x02)
{
"dmic-gpios",
Package (0x04)
{
\_SB.PCI0.PBRA.ACPD.I2SM,
Zero,
Zero,
Zero
}
}
}
})
}
}
Verified audio via speakers and mic input.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I5d1602c7f719eef9487ddea68e429d27408f9a76
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2253638
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds support in ACP device driver to generate I2S machine
device (AMDI5682) in SSDT. It expects mainboard to provide chip config
`dmic_select_gpio` that can be passed as `dmic-gpios` in _DSD for the
device.
BUG=b:157603026
TEST=Verified that I2S machine device is correctly generated for
trembyle.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I22ab53d7d68c6e042e467e598d688e360d28586f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2252557
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42970
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As per ACPI spec, GpioIo does not have any polarity associated with
it. Linux kernel uses `active_low` argument within GPIO _DSD property
to allow BIOS to indicate if the corresponding GPIO should be treated
as active low. Thus, if GPIO has active high polarity or if it does
not have any polarity associated with it, then the `active_low`
argument is supposed to be set to 0.
Having a `polarity` field in acpi_gpio seems confusing because GPIOs
might not always have polarity associated with them. Example, in case
of DMIC-select GPIO where 0 means select DMIC0 and 1 means select
DMIC1, there is no polarity associated with the GPIO. Thus, it would
be clearer for mainboard to use macros without having to specify a
particular polarity. In order to enable mainboards to provide GPIO
information without polarity for GpioIo usage, this change also adds
`ACPI_GPIO_OUTPUT` and `ACPI_GPIO_INPUT` macros.
BUG=b:157603026
Change-Id: I39d2a6ac8f149a74afeb915812fece86c9b9ad93
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42968
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds helper macros for initializing acpi_gpio fields
for GpioIo/GpioInt objects. This allows dropping some redundant code
for each macro to set the structure fields.
Change-Id: Id0a655468759ed3035c6c1e8770e37f1275e344e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42967
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Proposal for gpio_regulator usage in ACPI never got accepted upstream
for Linux kernel. So, the gpio_regulator driver in coreboot remains
unused. This change drops this unused driver.
Change-Id: Ia1e0ae4f955b9ffc8346d957f755499419d8cbc7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Sonora Pass server program was terminated.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I5354ea1e912fd25f0ac9851edf0461413ad8bb21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42948
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ACPI code was not masking off the correct bits for publishing
the SPI bar to the OS.
It resulted in a dmesg messagelike:
system 00:00: [mem 0xfec10002-0xfec11001] has been reserved
And /proc/iomem entry
fec10002-fec11001 : pnp 00:00
These addresses are wrong because they are including bits of a
register that are not a part of the address.
Moreover, the code does not publish the eSPI register area either.
The eSPI registers live at 0x10000 added to the SPI bar. Lastly,
both regions are less than a page so only report a page of usage
for each.
Stoney Ridge's SPI bar register defines the address as 31:6 while
Picasso's SPI bar register defines the address as 31:8. Use Picasso's
valid mask for both cases because no one is assigning addresses
that are aligned to less than 256 bytes.
With the fixes, dmesg reports:
system 00:00: [mem 0xfec10000-0xfec10fff] has been reserved
system 00:00: [mem 0xfec20000-0xfec20fff] has been reserved
And /proc/iomem indicates:
fec10000-fec10fff : pnp 00:00
fec20000-fec20fff : pnp 00:00
BUG=b:160290629
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I130b5ad26d9e13b44c25fbb35a05389f9e8841ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42959
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Modify DPTF parameters for faffy from thermal team.
BUG=b:160292247
BRANCH=None
TEST=emerge-puff coreboot chromeos-bootimage
verify the parameters are correct
Change-Id: Ie8290f5460838f785a587c85b2ab7dd171dd0a54
Signed-off-by: Tim Chen <tim-chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42977
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
* Add support for Sphinx 3.0+
* Add backward support for Sphinx 1.8 and older
* Make sphinxcontrib ditaa an optional extension
* Allow SPHINXOPTS to be set from command line
* Add sphinx and sphinx-lint to top level Makefile
Change-Id: If10aef51dc426445cb742aad13b19ee7fe169c51
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41492
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Just call the called function directly.
Change-Id: I0c997a63cbbd2b1029f94c23685847df910f8a0e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Currently, EC wake signal (GPIO_24) is configured early on in
romstage. However, there is no need for that since EC wake is not
really required to be configured until ramstage. This change moves
GPIO_24 configuration to happen in ramstage.
BUG=b:159832123
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I6949dcd7c866df2fa028c7b2e7f347cec988e309
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42952
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates the pad configurations for wake lines as
follows:
1. Pen eject wake signal needs to be configured as PAD_WAKE i.e. wake
using GPIO controller block. This is because pen eject signal is not
dual routed and the trigger filtering is set by the kernel driver
differently for S0 and S3 wake. Hence, it cannot use SCI GEVENT and
instead has to fall back to using GPIO controller wake.
2. All other wake signals (EC, trackpad, fingerprint) need to be
configured as SCI. This allows OS to enable/disable wake from these
sources if required. Example: powerd disables wake from trackpad when
in tablet mode. Hence, all other wake sources use SCI.
BUG=b:159832123
TEST=Verified wake using pen eject and EC.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Id8cd5926f223db51a689ed8948040b8070cf1680
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42951
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set tcc_offset value to 10 in devicetree for Thermal Control
Circuit (TCC) activation feature.
BUG=None
BRANCH=None
TEST=Built for dedede platform and verified the MSR value
Change-Id: I53d1bd413c64643cf8bdaef266bde25a2f3a97ee
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42906
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, northbridge BARs are 32-bit values. We don't have any use
case for BARs above 4 GiB in early stages, so handling possibly 64-bit
values seems unnecessary, which currently is a noisy way to write zero.
Tested with BUILD_TIMELESS=1, packardbell/ms2290 remains identical.
Change-Id: I93d1740b961f6a5962757d9a1e960b3f1014a0c6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This function was copy-pasted, comments included, from Sandy Bridge.
However, it is only called with 0x0044 as the northbridge's PCI ID.
Therefore, `bridge_silicon_revision() & BASE_REV_MASK` will always
evaluate to 0x40, which never equals `BASE_REV_SNB`, that is, 0x00.
As the condition is always false, treat this code as dead and drop it.
Following a similar reasoning, all direct comparisons against SNB
steppings will always be true, because `bridge_silicon_revision()`
returns at least 0x40 which is always larger than either `SNB_STEP_D0`
or `SNB_STEP_D1`. So, drop all but the code path that is actually used.
Change-Id: I5219a6af3df98ed77c9c4abfb9a63c2ebf8171bb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When building a configuration that requires futility (e.g. Chrome OS
builds), pkg-config and libcrypto are required. Since vboot's build
system isn't the most helpful about it, test ourselves and fail out
with some actionable message.
Tested:
- configs that don't need futility don't test for pkg-config, so it's
not required for them.
- failing pkg-config test leads to the message
- working pkg-config test leads to a successful build
Fixes https://ticket.coreboot.org/issues/242
Change-Id: I103ce5115284352e0a3a7fdcf8b427f56ce15ba7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Vboot determines openssl through pkgconfig, so pointing its build
system to /bin/true makes the build not break unless it needs to use
valid information about openssl.
Vboot's use of openssl is only for some special features, mostly around
PKCS key format parsing and not needed by cbfstool. While cbfstool
can link vboot, it can't link with openssl because openssl's license
is deliberately incompatible with the GPL.
Change-Id: Ia3825f9625a1964d7cefc47ab3c3a8250ceefafb
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This change adds support for pen insert/eject operations in S0 and
wake on pen eject from S3 for morphius.
BUG=b:158814699,b:158719244
Change-Id: I3530a0aa83ec69559436687205c64524b862799b
Signed-off-by: Kevin Chiu <kevin.chiu@quanta.corp-partner.google.com>
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change drops macros for GPIOs which are unused or don't really
require extra indirection (same across all variants).
BUG=b:159283649
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I1a94327103a419f26b1d7feda4c995363ada7281
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Board version 3 for Ezkinil follows Trembyle reference v3.51
schematics and hence GPIO_86 does not need a variant specific override.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I7e04baad976f94d0d94e7196f0408c3c3237b2da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42940
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
A late change went into v3+ of reference schematics which inverted
EN_PWR_WIFI to meet PCIe reset/power timings for WiFi device. This is
incorporated into v3.51+ for Trembyle reference and v3.2+ for Dalboz
reference. However, some variants are built with v3+ reference
schematics, but without the inversion of EN_PWR_WIFI polarity. Thus,
we need to add support for following combinations:
1. Pre-v3 Schematics
2. V3+ Schematics
3. V3+ Schematics + Active low wifi power
This change adds a new Kconfig
`VARIANT_MIN_BOARD_ID_WIFI_POWER_ACTIVE_LOW` that sets the minimum
board ID that has EN_PWR_WIFI active low in hardware. Variants that
missed this change in V3+ integration (berknip and vilboz) have board
IDs set to VARIANT_MIN_BOARD_ID_V3_SCHEMATICS + 1. For others, this
defaults to VARIANT_MIN_BOARD_ID_V3_SCHEMATICS.
BUG=b:159749536
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib8da7fba5f4a518a51b203d6a01a9551e261d8b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change moves variant_sleep_gpio_table() definition to dalboz and
trembyle references to allow each to make their own changes.
BUG=b:159749536, b:159453643
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I15b19cea05f1a540c56b6bc0507306d2348ac17f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42937
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change moves PCIE_RST1_L deassertion to happen as part of
variant_pcie_power_reset_configure() instead of
variant_romstage_entry() since romstage is guaranteed to run 100ms+
after PP3300_NVME is enabled. This is one of the first things that
coreboot on x86 does as part of early mainboard configuration.
Additionally, this change also drops deassertion of PCIE_RST0_L on bid
1 for dalboz since PCIE_RST0_L is already deasserted much earlier in
the boot flow.
BUG=b:152582706
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib734aa6ff664268e68388b1997ddce676504f8d2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2261996
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit-Queue: Aaron Durbin <adurbin@google.com>
Tested-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change configures GPIO_40 (NVME_AUX_RESET_L) as drive low in
sleep path so that the PERST# to NVMe device keeps asserted until
coreboot reconfigures it as high on S3 resume path. This is similar to
the earlier change for PCIE_RST1_L but helps platforms that use
NVME_AUX_RESET_L instead of PCIE_RST1_L. GPIO_40 lives in S5 domain,
hence it retains state across S3 entry/exit.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ie79e946eee8f393863630226ae2183e653030415
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2261117
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42935
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change configures PCIE_RST1_L as GPO driven low on the sleep
path. This is required to keep PERST# asserted to devices until
coreboot deasserts it on S3 resume path. Without this change, on S3
resume, PCIE_RST1_L gets deasserted sooner than required resulting in
violation of PCIe reset timings.
With this change, the behavior of PCIE_RST1_L is as follows:
1. GPIO27 is configured as NF (PCIE_RST1_L) in coreboot
bootblock/romstage and driven high.
2. On S3 entry, GPIO27 is configured as GPO driven low.
* Boot out of G3: Timing should be met since GPIO_27 is pulled down by
default until coreboot configures it.
* S3 resume: Timing should be met since GPIO_27 is configured as GPO
low and it retains state across S3 entry/exit. So, should be low
until coreboot configures it.
* Warm reset: Timing should be met since it is configured as NF. So,
hardware guarantees the reset timing as seen in "warm reset.jpg" in
#46.
BUG=b:152582706
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ia0ad1522edc438fd054d927ef4a2ab5c27329c00
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2261116
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Jamie Ryu