Some devices, such as cameras, can implement a physical switch to
disable the input on demand. Think of it like the typical privacy
sticker on the notebooks, but more elegant.
In order to notify the system about the status this feature, a GPIO is
typically used.
The map between a GPIO and the feature is done via ACPI, the same way as
the reset_gpio works.
This patch implements an extra field for the described privacy gpio.
This gpio does not require any extra handling from the power management.
BUG=b:169840271
Change-Id: Idcc65c9a13eca6f076ac3c68aaa1bed3c481df3d
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Allow a USB device to define PowerResource in its SSDT AML code.
PowerResouce ACPI generation expects SoC to define the callbacks for
generating AML code for GPIO manipulation.
Device requiring PowerResource needs to define following parameters:
* Reset GPIO - Optional, GPIO to put device into reset or take it out
of reset.
* Reset delay - Delay after reset GPIO is asserted (default 0).
* Reset off delay - Delay after reset GPIO is de-asserted (default 0).
* Enable GPIO - Optional, GPIO to enable device.
* Enable delay - Delay after enable GPIO is asserted (default 0).
* Enable off delay - Delay after enable GPIO is de-asserted (default 0).
BUG=b:163100335
TEST=Ensure that the Power Resource ACPI object is added under the
concerned USB device.
Change-Id: Icc1aebfb9e3e646a7f608f0cd391079fd30dd1c0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46713
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Peichao Wang <pwang12@lenovo.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From Tigerlake FSP v3373 onwards vbt binary size changed from 8KiB
to 9KiB. Commit cf5d58328f had changed
the size from 8 to 9 Kib. This change adds Kconfig option to choose
vbt data size based on platform.
BUG=b:171401992
BRANCH=none
TEST=build and boot delbin and verify fw screen is loaded
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: Ia294fc94ce759666fb664dfdb910ecd403e6a2e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47151
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create SOC_INTEL_COMMON_FSP_RESET Kconfig to have IA common code block
to handle platform reset request raised by FSP. The FSP will use the
FSP EAS v2.0 section 12.2.2 (OEM Status Code) to indicate that a reset
is required.
Make FSP_STATUS_GLOBAL_RESET depends on SOC_INTEL_COMMON_FSP_RESET.
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: I934b41affed7bb146f53ff6a4654fdbc6626101b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change drops the PCI IDs for Jefferson Peak and Harrison Peak
CNVi modules from wifi/generic drivers as well as pci_ids.h. These IDs
actually represent the CNVi WiFi controller PCI IDs and are now
supported by intel/common/block/cnvi driver.
The only ID that is being dropped without adding support in
intel/common/block/cnvi driver is
PCI_DEVICE_ID_HrP_6SERIES_WIFI(0x2720) since this was not found in the
list of PCI IDs for any SoC.
Change-Id: I82857a737b65a6baa94fb3c2588fe723412a7830
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46866
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change reorganizes drivers/wifi/generic to add a new
device_operations structure for dummy CNVi device. This is done to
make the organization of CNVi PCI device in devicetree consistent
with all the other internal PCI devices of the SoC i.e. without a chip
around the PCI device.
Thus, with this change, CNVi entry in devicetree can be changed from:
```
chip drivers/wifi/generic
register "wake" = "xxyyzz"
device pci xx.y on end # CNVi PCI device
end
```
to:
```
device pci xx.y on
chip drivers/wifi/generic
register "wake" = "xxyyzz"
device generic 0 on end # Dummy CNVi device
end
end # CNVi PCI device
```
The helper functions for ACPI/SMBIOS generation are also accordingly
updated to include _pcie_ and _cnvi_ in the function name.
Change-Id: Ib3cb9ed9b81ff8d6ac85a9aaf57b641caaa2f907
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46862
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change splits `wifi_generic_fill_ssdt()` into following two
functions:
1. `wifi_ssdt_write_device()`: This function writes the device, its
address, _UID and _DDN.
2. `wifi_ssdt_write_properties()`: This function writes the properties
for WiFi device like _PRW, regulatory domain and SAR.
This split is done so that the device write can be skipped for
CNVi devices in follow-up CLs. It will allow the SoC controller
representation for CNVi PCI device to be consistent with other
internal PCI devices in the device tree i.e. not requiring a
chip driver for the PCI device.
Because of this change, _PRW and SAR will be seen in a separate
block in SSDT disassembly, but it does not result in any functional
change.
Observed difference:
Before:
Scope (\_SB.PCI0.PBR1)
{
Device (WF00)
{
Name (_UID, 0xAA6343DC)
Name (_DDN, "WIFI Device")
Name (_ADR, 0x0000000000000000)
Name (_PRW, Package() { 0x08, 0x03 })
}
}
After:
Device (\_SB.PCI0.PBR1.WF00)
{
Name (_UID, 0xAA6343DC)
Name (_DDN, "WIFI Device")
Name (_ADR, 0x0000000000000000)
}
Scope (\_SB.PCI0.PBR1.WF00)
{
Name (_PRW, Package() { 0x08, 0x03 })
}
Change-Id: I8ab5e4684492ea3b1cf749e5b9e2008e7ec8fa28
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change reorganizes the WiFi generic driver to move the ACPI
functions to a separate file. This change is done to reduce the noise
in generic.c file and improve readability of the file.
Change-Id: If5fafb5452fb5bad327be730fcfc43d8a5d3b8ec
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change reorganizes the WiFi generic driver to move the SMBIOS
functions to a separate file. This change is done to reduce the noise
in generic.c file and improve readability of the file.
Change-Id: I38ed46f5ae1594945d2078b00e8315d9234f36d7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
`mrc_cache_needs_update` is comparing the "new size" of the MRC data
(minus metadata size) to the size including the metadata, which causes
the driver to think the data has changed, and so it will rewrite the
MRC cache on every boot. This patch removes the metadata size from
the comparison.
BUG=b:171513942
BRANCH=volteer
TEST=1) Memory training data gets written the on a boot where the data
was wiped out.
2) Memory training data does not get written back on every subsequent
boot.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I7280276f71fdaa492c327b2b7ade8e53e7c59f51
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
SMMSTORE version 2 is a complete redesign of the current driver. It is
not backwards-compatible with version 1, and only one version can be
used at a time.
Key features:
* Uses a fixed communication buffer instead of writing to arbitrary
memory addresses provided by untrusted ring0 code.
* Gives the caller full control over the used data format.
* Splits the store into smaller chunks to allow fault tolerant updates.
* Doesn't provide feedback about the actual read/written bytes, just
returns error or success in registers.
* Returns an error if the requested operation would overflow the
communication buffer.
Separate the SMMSTORE into 64 KiB blocks that can individually be
read/written/erased. To be used by payloads that implement a
FaultTolerant Variable store like TianoCore.
The implementation has been tested against EDK2 master.
An example EDK2 implementation can be found here:
eb1127744a
Change-Id: I25e49d184135710f3e6dd1ad3bed95de950fe057
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40520
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
With TGL FSP v3373 onwards vbt binary size changed from 8KiB
to 9KiB. Due to which cbfsf_decompression_info check failed
when trying to load vbt binary from cbfs because vbt
decompressed_size was greater than vbt_data size. This caused
Graphics init and fw screen issues. Increase the vbt_data to
9KiB to accommodate new vbt binary.
BUG=b:170656067
BRANCH=none
TEST=build and boot delbin and verify fw screen is loaded
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: If6ffce028f9e8bc14596bbc0a3f1476843a9334e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dossym Nurmukhanov <dossym@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When MRC_SAVE_HASH_IN_TPM is selected, we can just use the TPM hash to
verify the MRC_CACHE data. Thus, we don't need to calculate the
checksum anymore in this case.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami
Change-Id: I1db4469da49755805b541f50c7ef2f9cdb749425
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Pull selection of tpm hash index logic into cache_region struct. This
CL also enables the storing of the MRC hash into the TPM NVRAM space
for both recovery and non-recovery cases. This will affect all
platforms with TPM2 enabled and use the MRC_CACHE driver.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami and lazor
Change-Id: I1a744d6f40f062ca3aab6157b3747e6c1f6977f9
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46514
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
We need to extend the functionality of the mrc_cache hash functions to
work for both recovery and normal mrc_cache data. Updating the API of
these functions to pass in an index to identify the hash indices for
recovery and normal mode.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami
Change-Id: I9c0bb25eafc731ca9c7a95113ab940f55997fc0f
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This CL would remove these calls from fsp 2.0. Platforms that select
MRC_STASH_TO_CBMEM, updating the TPM NVRAM space is moved from
romstage (when data stashed to CBMEM) to ramstage (when data is
written back to SPI flash.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami
Change-Id: I3088ca6927c7dbc65386c13e868afa0462086937
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use this config to specify whether we want to save a hash of the
MRC_CACHE in the TPM NVRAM space. Replace all uses of
FSP2_0_USES_TPM_MRC_HASH with MRC_SAVE_HASH_IN_TPM and remove the
FSP2_0_USES_TPM_MRC_HASH config. Note that TPM1 platforms will not
select MRC_SAVE_HASH_IN_TPM as none of them use FSP2.0 and have
recovery MRC_CACHE.
BUG=b:150502246
BRANCH=None
TEST=emerge-nami coreboot chromeos-bootimage
Change-Id: Ic5ffcdba27cb1f09c39c3835029c8d9cc3453af1
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46509
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
As ongoing work for generalizing mrc_cache to be used by all
platforms, we are pulling it out from fsp 2.0 and renaming it as
mrc_cache_hash_tpm.h in security/vboot.
BUG=b:150502246
BRANCH=None
TEST=emerge-nami coreboot chromeos-bootimage
Change-Id: I5a204bc3342a3462f177c3ed6b8443e31816091c
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This chip driver adds ACPI identifiers for multiplexed I2C bus that are
selected using GPIO. The multiplexed bus device defines the address
to select the I2C lines. These ACPI identifiers are consumed by the
i2c-mux-gpio kernel driver:
https://www.kernel.org/doc/html/latest/i2c/muxes/i2c-mux-gpio.html
BUG=b:169444894
TEST=Build and boot to OS in waddledee. Ensure that the ACPI identifiers
are added in appropriate context.
Scope (\_SB.PCI0.I2C3.MUX0)
{
Device (MXA0)
{
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_ADR, Zero) // _ADR: Address
}
}
Scope (\_SB.PCI0.I2C3.MUX0)
{
Device (MXA1)
{
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_ADR, One) // _ADR: Address
}
}
Change-Id: If8b983bc8ce212ce05fe6b7f01a6d9092468e582
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46144
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add identifiers in ACPI tables for GPIO based I2C multiplexer. The
multiplexer device defines the GPIO resource used to select the
adapter/bus lines. The multiplexer adapter device defines the address
to select the adapter/client lines. These ACPI identifiers are consumed
by the i2c-mux-gpio kernel driver:
https://www.kernel.org/doc/html/latest/i2c/muxes/i2c-mux-gpio.html
BUG=b:169444894
TEST=Build and boot waddledee to OS. Ensure that the ACPI identifiers
are added for I2C devices multiplexed using I2C MUX under the
appropriate scope. Here is the output SSDT:
Scope (\_SB.PCI0.I2C3)
{
Device (MUX0)
{
Name (_HID, "PRP0001") // _HID: Hardware ID
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.PCI0.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0125
}
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x02)
{
Package (0x02)
{
"compatible",
"i2c-mux-gpio"
},
Package (0x02)
{
"mux-gpios",
Package (0x04)
{
\_SB.PCI0.I2C3.MUX0,
Zero,
Zero,
Zero
}
}
}
})
}
}
Change-Id: Ib371108cc6043c133681066bf7bf4b2e00771e8b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45911
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The USB4 retimer device needs to declare a _DSM with specific functions
that allow for GPIO control to turn off the power when an external
device is not connected. This driver allows the mainboard to provide
the GPIO that is connected to the power control.
BUG=b:156957424
Change-Id: Icfb85dc3c0885d828aba3855a66109043250ab86
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44918
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DP link rates are reported in an array of LE16 values. The current code
tries to parse them as 8-bit which doesn't get very far, causing us to
always drop into the fallback path. This patch should fix the issue
(+minor whitespace cleanup).
BUG=b:170630766
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1e03088ee2d3517bdb5dcc4dcc4ac04f8b14a391
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46318
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
CBFS SAR and SAR tables in ACPI are currently supported only by Intel
WiFi devices. This change adds a check in `emit_sar_acpi_structures()`
to ensure that the PCI vendor for the device is Intel before
generating the SAR tables.
BUG=b:169802515
BRANCH=zork
Change-Id: Ibff437893a61ac9557cff243a70230f101089834
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46040
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change limits the scope of `wifi_generic_fill_ssdt()` and
`wifi_generic_acpi_name()` to generic.c since they are not used
outside of this file anymore. Also, since there is no need to split
SSDT generator into two separate functions,
`wifi_generic_fill_ssdt_generator()` is dropped and `.acpi_fill_ssdt`
directly points to `wifi_generic_fill_ssdt()`.
BUG=b:169802515
BRANCH=zork
Change-Id: I2cbb97f43d2d9f9ed6d3cf8f0a9b13a7f30e922e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46038
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, drivers/intel/wifi is a PCI driver (provides `struct
pci_driver`) as well as a chip driver (provides `struct
chip_operations`). However, there is no need for a separate chip
driver for the WiFi device since drivers/wifi/generic already provides
one.
Having two separate chip drivers makes it difficult to multi-source
WiFi devices and share the same firmware target without having to add
a probe property for each of these devices. This is unnecessary since
the WiFi driver in coreboot is primarily responsible for:
1. PCI resource allocation
2. ACPI SSDT node generation to expose wake property and SAR tables
3. SMBIOS table generation
For the most part, coreboot can perform the above operations without
really caring about the specifics of which WiFi device is being used
by the mainboard. Thus, this change drops the driver for intel/wifi
and moves the PCI driver support required for Intel WiFi chips into
drivers/wifi/generic. The PCI driver is retained for backward
compatibility with boards that never utilized the chip driver to
support Intel WiFi device. For these devices, the PCI driver helps
perform the same operations as above (except exposing the wake
property) by utilizing the same `wifi_generic_ops`.
This change also moves DRIVERS_INTEL_WIFI config to
wifi/generic/Kconfig.
BUG=b:169802515
BRANCH=zork
Change-Id: I780a7d1a87f387d5e01e6b35aac7cca31a2033ac
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46036
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change drops the dependency of DRIVERS_WIFI_GENERIC on
HAVE_ACPI_TABLES as the driver provides operations other than the ACPI
support for WiFi devices. Since the dependency is now dropped, ACPI
operations in generic.c are guarded by CONFIG(HAVE_ACPI_TABLES).
BUG=b:169802515
BRANCH=zork
Change-Id: I16444a9d842a6742e3c97ef04c4f18e93e6cdaa9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46037
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds support in generic WiFi driver in coreboot to
generate SMBIOS data for the WiFi device. Currently, this is used only
for Intel WiFi devices and the function is copied over from Intel WiFi
driver in coreboot. This change is done in preparation for getting rid
of the separate chip driver for Intel WiFi in coreboot.
BUG=b:169802515
BRANCH=zork
Change-Id: If3c056718bdc57f6976ce8e3f8acc7665ec3ccd7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46034
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The patch allows to configure sensors with a remote diode connected
and a on-chip local temperature sensor from the devicetree for the
board that uses this HWM. According to the documentation [1], this is
done by setting the corresponding bits in the Mode Selection Register
(22h). It is necessary for some Intel processors (Apollo Lake SoC)
that do not support PECI and the CPU temperature is taken from the
thermistor.
TEST = After loading the nct7802 module on the Kontron mAL-10 [2] with
Linux OS, we can see configuration of the HWM with one sensor in
the thermistor mode:
user@user-apl:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +41.0°C (high = +110.0°C, crit = +110.0°C)
Core 0: +40.0°C (high = +110.0°C, crit = +110.0°C)
Core 1: +40.0°C (high = +110.0°C, crit = +110.0°C)
Core 2: +41.0°C (high = +110.0°C, crit = +110.0°C)
Core 3: +41.0°C (high = +110.0°C, crit = +110.0°C)
nct7802-i2c-0-2e
Adapter: SMBus CMI adapter cmi
in0: +3.35 V (min = +0.00 V, max = +4.09 V)
in1: +1.92 V
in3: +1.21 V (min = +0.00 V, max = +2.05 V)
in4: +1.68 V (min = +0.00 V, max = +2.05 V)
fan1: 0 RPM (min = 0 RPM)
fan2: 868 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
temp1: +42.5°C (low = +0.0°C, high = +85.0°C)
(crit = +100.0°C) sensor = thermistor
temp4: +44.0°C (low = +0.0°C, high = +85.0°C)
(crit = +100.0°C)
temp6: +0.0°C
[1] page 30, section 7.2.32, Nuvoton Hardware Monitoring IC NCT7802Y
with PECI 3.0 interface, datasheet, revision 1.2, february 2012
[2] https://review.coreboot.org/c/coreboot/+/39133
Change-Id: I28cc4e5cae76cf0bcdad26a50ee6cd43a201d31e
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39766
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change drops maxsleep parameter from chip config and instead
hardcodes the deepest sleep state from which the WiFi device can wake
the system up from to SLP_TYP_S3. This is similar to how other device
drivers in coreboot report _PRW property in ACPI. It relieves the
users from adding another register attribute to devicetree since all
mainboards configure the same value. If this changes in the future, it
should be easy to bring the maxsleep config parameter back.
BUG=b:169802515
BRANCH=zork
Change-Id: I42131fced008da0d51f0f777b7f2d99deaf68827
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46033
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change adds a call to `pci_dev_is_wake_source()` to determine and
log WiFi wake source to event log just like the Intel WiFi driver
does. This is done in preparation to merge the generic and Intel WiFi
drivers in follow-up changes.
BUG=b:169802515
BRANCH=zork
Change-Id: I20528ae1f72ca633da31e01d777c46fd5f4a337f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46032
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change uses the newly added `pci_dev_is_wake_source()` helper function
to determine and log WiFi wake source instead of assuming a hard-coded
register value to check. This is done in preparation to merge the
generic WiFi and Intel WiFi drivers in coreboot in follow-up changes.
BUG=b:169802515
BRANCH=zork
Change-Id: I9bdb453092b4ce7bdab2969f13e0c0aa8166dc0a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
HPD on this bridge chip is a bit useless. This is an eDP bridge so the HPD is
an internal signal that's only there to signal that the panel is done powering up.
But the bridge chip debounces this signal by between 100 ms and 400 ms (depending on process,
voltage, and temperate). One particular panel asserted HPD 84 ms after it was powered on
meaning that we saw HPD 284 ms after power on. Assume that the panel driver will have the
hardcoded delay in its prepare and always disable HPD.
Change-Id: Iea7dd75b57fa55ec182c0bee09b0f35208357892
Signed-off-by: Vinod Polimera <vpolimer@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45706
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Modify mrc_cache_load current to return the size of the mrc_cache
entry so that caller will know what the actual size of the data
returned is. This is needed for ARM devices like trogdor, which need
to know the size of the training data when populating the QcLib
interface table.
BUG=b:150502246
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_NAMI -x -a
Change-Id: Ia314717ad2a7d5232b37a19951c1aecd7f843c27
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46110
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
`pci_dev_init()` is used to load and run option ROM on VGA class
devices (PCI_CLASS_DISPLAY_VGA). WiFi device is not a VGA class device
and hence the call to `pci_dev_init()` is not required. This change
drops the call to `pci_dev_init()` from `wifi_pci_dev_init()` in Intel
WiFi driver.
BUG=b:169802515
BRANCH=zork
Change-Id: I6588ea0a5c848904088d05fd1cbdf677b2dc8ea9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
WiFi devices supported by the generic WiFi driver are PCIe devices
which need to be managed using the standard pci_dev_* operations to
read, set and enable resources. This change updates the
device_operations structure `wifi_generic_ops` to use the standard
pci_dev_* operations for these devices.
BUG=b:169802515
BRANCH=zork
Change-Id: I8b306259e205ecb963c0563000bd96ec6b978b8b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46028
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Previously, we were writing to cbmem after memory training and then
writing the training data from cbmem to mrc_cache in ramstage. We
were doing this because we were unable to read/write to SPI
simultaneously on older x86 chips. Now that newer chips allow for
simultaneously reads and writes, we can move the mrc_cache update into
romstage. This is beneficial if there is a reboot for some reason
after memory training but before the previous mrc_cache_stash_data
call originally in ramstage. If this happens, we would lose all the
mrc_cache training data in the next boot even though we've already
performed the memory training.
Added new config BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES to accomodate
older x86 platforms that don't do mmapping but still want to use the
cbmem to store the mrc_cache data in order to write the mrc_cache data
back at a later time. We are maintaining the use of cbmem for these
older platforms because we have no way of validating the earlier write
back to mrc_cache at this time.
BUG=b:150502246
BRANCH=None
TEST=reboot from ec console. Make sure memory training happens.
reboot from ec console. Make sure that we don't do training again.
Signed-off-by: Shelley Chen <shchen@google.com>
Change-Id: I3430bda45484cb8c2b01ab9614508039dfaac9a3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44196
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Added new config BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES to accomodate
older x86 platforms that don't allow writing to SPI flash when early
stages are running XIP from flash. If
BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES is not selected,
BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY will get auto-selected if
BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y. This allows for current platforms
that write to flash in the earlier stages, assuming that they have
that capability.
BUG=b:150502246
BRANCH=None
TEST=diff the coreboot.rom files resulting from running
./util/abuild/abuild -p none -t GOOGLE_NAMI -x -a --timeless
with and without this change to make sure that there was no
difference. Also did this for GOOGLE_CANDY board, which is
baytrail based (and has BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES
enabled).
Change-Id: I3aef8be702f55873233610b8e20d0662aa951ca7
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45740
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
APEI (ACPI Platform Error Interface) defines BERT (Boot Error Record
Table) memory region:
* Bootloader (firmware) generates UEFI CPER (Common Platform Error
Record) records, and populates BERT region.
* OS parses ACPI BERT table, finds the BERT region address, inteprets
the data and processes it accordingly.
When CONFIG_ACPI_BERT is defined, update FSP UPD BootLoaderTolumSize,
so FSP allocates memory region for it. The APEI BERT region is placed
on top of CBMEM, for the size of CONFIG_ACPI_BERT_SIZE.
Apart from APEI BERT region, we also have plan to add APEI HEST region
which holds OS runtime hardware error record, based on firmware
first hardware error handling model. HEST region will be reserved
same way as BERT region.
Note that CBMEM region can not be used for such purpose, the OS
(bert/hest) drivers are not able to access data held in CBMEM region,
as CBMEM is set as type 16 (configuration table).
An option considered was to reserve the BERT region under CBMEM.
However, we do not know the size of CBMEM till acpi tables are set up.
On the other hand, BERT region needs to be filled up before ACPI BERT
table is finalized.
Change-Id: Ie72240e4c5fa01fcf937d33678c40f9ca826487a
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
