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>
This change turns off power to camera and pen devices when entering
sleep since they do not act as wake sources in S3. Power to trackpad
and WiFi is left enabled since they are wake sources for S3.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I21bcdd53370372c7d43c3b685abb2a9171e42d22
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2261115
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/+/42933
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds support to configure GPIOs on the sleep path. This is
required to turn off power to devices that do not act as wake sources
and to assert reset to devices.
Currently, variant_sleep_gpio_table() returns an empty table by
default. In the following changes, entries will be added to
gpio_sleep_table.
BUG=b:152582706
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I7286cbf165024bdd81f8748e525542dce8dd8702
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+/2253642
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42932
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These were copied from gm45, but are not used. Drop them.
Change-Id: I85ca37516272a2c1af88a65df2682e92d7579050
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42695
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This function isn't defined anywhere for Pineview. Drop its declaration.
Change-Id: I38a01d6ba5aaa91de08702c1eb8a2e8c70688192
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42694
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is a W/A to avoid a communication issue with CSE Lite over Heci
interface. This will help to avoid boot failures with CSE Lite until
the permanent fix is available.
BUG=b:159884143
TEST=build and boot volteer with serial and non-serial image
Change-Id: Ib136a2154b36c63c7147bbcfbf1ca7beac3a5685
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42790
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Override VBT for nightfury SKU_ID = 2 to support different panel.
BUG=b:159051021
BRANCH=firmware-hatch-12672.B
TEST=Built and verified using different VBT by SKU_ID
Change-Id: I9450814aadc43cc7991457c3793f109b889186b9
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bob Moragues <moragues@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Update fixes build issues with host GCC 10.
Other changes:
https://acpica.org/node/177https://acpica.org/node/178https://acpica.org/node/179https://acpica.org/node/181
acpinames utility removed:
"Removed support for the acpinames utility. The acpinames was a simple
utility used to populate and display the ACPI namespace without executing
any AML code. However, ACPICA now supports executable opcodes outside of
control methods. This means that executable AML opcodes such as If and
Store opcodes need to be executed during table load. Therefore, acpinames
would need to be updated to match the same behavior as the acpiexec
utility and since acpiexec can already dump the entire namespace (via the
'namespace' command), we no longer have the need to maintain acpinames."
Change-Id: Ibd995561ca53458b04f87cee5693850c0d90d3d6
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38907
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
in some m/b+BOE panel(G2 TS), G2 TS may still have chance to lost even
rst delay time already meets spec definition: 10us (minimum).
Restore G2 TS RST delay time to 50ms, we could have G2 TS working fine
on those specific m/b+BOE(G2 TS) panel.
BUG=b:159510906
BRANCH=master
TEST=emerge-zork coreboot
boot with G2 TS, make sure G2 TS is functional
Change-Id: Ic629c6c61572ab564def8893ce8d78dfb37d4590
Signed-off-by: Kevin Chiu <kevin.chiu@quantatw.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Configure sataHotPlug in devicetree, as this functionality
is now available for this soc.
Change-Id: If462e33d1bbef8036d598970fb2774d0fda1fbb1
Signed-off-by: Jonas Loeffelholz <Jonas.Loeffelholz@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42804
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Hook up the FSP UPD
Change-Id: I6b479bfc83492440eac97cdc8dcc560b6abf4fdf
Signed-off-by: Jonas Loeffelholz <Jonas.Loeffelholz@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42803
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Many previous versions of this function would return early if tcc_offset
is 0. This adds that logic back in.
Change-Id: Ibc529520a4e74608cb5d20e5a6e8fc2c727c903c
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Edward O'Callaghan