It was confusing to have this defined while there was another
symbol bootblock_protected_mode_entry that was not really used
as an entry point.
Change-Id: I3da07ba9c0a9fc15b1515452adfb27f963659951
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48404
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to FSP_INFO_HEADER structure in FSP EAS v2.0-v2.2,
BIT1 indicates an "official" build.
Change-Id: I94df6050a1ad756bbeff60cda0ebac76ae5f8249
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49650
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There's no need to repeat the same code on every board.
Change-Id: I2e19decfe8609fa644e609673a56ee5109bafefa
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49831
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the "ERROR:" tag so that it ease debug effect.
TEST=Test tools like "suspend_stress_test" (specific to Chrome OS) can
identify the obvious coreboot ERROR prior running S3 resume test.
Change-Id: I64717ce0412d43697f42ea2122b932037d28dd48
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49798
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to update the BB retimers for usb4/tbt they need to be turned
on and into TBT mode. Expand the current DSM to allow for the use of an
EC RAM byte RFWU to get the current state of each port and whether or
not it has a retimer. It also allows Kernel to issue state transitions
for the retimer to be put into TBT mode for firmware update.
BUG=b:162528867
TEST=Along with work in progress kernel and EC patches, the Retimer
firmware update is verified under device attached and no device attached
scenarios.
Change-Id: I768cfb56790049c231173b0ea0f8e08fe6b64b93
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48630
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The `clear` command for SMMSTORE version 1 does not require a parameter.
Change-Id: I992b7ce5962bf7ee62b7e1970ae7aa1b975ef42e
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49724
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
prog_locate() will load FSP, before CBMEM is initialized.
The vboot workbuffer is used for loading, but
CBMEM_ID_VBOOT_WORKBUF is not available.
A NULL pointer is returned as workbuffer resulting in error
'Ramstage was not loaded!' at second boot.
Initialize CBMEM before calling prog_locate().
BUG = N/A
TEST = Build and boot on Facebook FBG1701
Change-Id: I2f04a326a95840937b71f6ad65a7c011268ec6d6
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This will remove "CONFIG_FRU_DEVICE_ID=0" from ".config" when unused.
Change-Id: Ic50de165c1f3de3886d3cd1ae66853c9fad35ed2
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Having some symmetry with <soc/nvs.h> now allows to reduce
the amount of gluelogic to determine the size and cbmc field
of struct global_nvs.
Since GNVS creation is now controlled by ACPI_SOC_NVS,
drivers/amd/agesa/nvs.c becomes obsolete and soc/amd/cezanne
cannot have this selected until <soc/nvs.h> exists.
Change-Id: Ia9ec853ff7f5e7908f7e8fc179ac27d0da08e19d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49344
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lance Zhao
By default, the HS400 mode of GL9763E is slow mode (150MHz).
Therefore, the slow mode is disabled for HS400 running at 200MHz.
For eMMCs such as Hynix (H26M74002HMR) on HS400, adjust the internal
Rx latch dealy of HS400 to have better compatibility.
Signed-off-by: Ben Chuang <benchuanggli@gmail.com>
Change-Id: I84844c2432d4223d9929182c5c430915e52875b7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Booting on Kingston (EMMC64G-TA29/TX29-HP) and Hynix (H26M74002HMR) eMMC
currently fails due to R/W error. This is a workaround to finetune the
data latch timing by verdor-specific setting of GL9763E. For improving
the compatibility of GL9763E with these two eMMC.
Signed-off-by: Renius Chen <reniuschengl@gmail.com>
Change-Id: Iddb145ed6a9edb2d7a50248e64659cda78b88ae6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Allocation now happens prior to device enumeration. The
step cbmem_add() is a no-op here, if reached for some
boards. The memset() here is also redundant and becomes
harmful with followup works, as it would wipe out the
CBMEM console and ChromeOS related fields without them
being set again.
Change-Id: I9b2625af15cae90b9c1eb601e606d0430336609f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48701
Reviewed-by: Lance Zhao
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For arch/x86 the realmode part has to be located within the same 64
KiB as the reset vector. Some older intel platforms also require 4 KiB
alignment for _start16bit.
To enforce the above, and to separate required parts of .text without
matching *(.text.*) rules in linker scripts, tag the pre-C environment
assembly code with section .init directive.
Description of .init section for ELF:
This section holds executable instructions that contribute to the
process initialization code. When a program starts to run, the
system arranges to execute the code in this section before calling the
main program entry point (called main for C programs).
Change-Id: If32518b1c19d08935727330314904b52a246af3c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47599
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add functions to read the system and mainboard serial numbers
from VPD tables stored in flash.
Remove board-specific implementations for google/drallion and
google/sarien and select the new Kconfig instead.
Test: build/boot google/akemi with RO_VPD region persisted from
stock Google firmware, verify system/mainboard serial numbers
present via dmidecode.
Change-Id: I14ae07cd8b764e1e22d58577c7cc697ca1496bd5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49050
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, use of the VPD driver to read VPD tables from flash
requires the use of a custom FMAP with one or more VPD regions.
Extend this funtionality to boards using the default FMAP by
creating a dedicated VPD region when the driver is selected.
Test: build qemu target with CONFIG_VPD selected, verify entry
added to build/fmap.fmd.
Change-Id: Ie9e3c7cf11a6337a43223a6037632a4d9c84d988
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add a new macro `GMA_DEFAULT_PANEL(ssc)` as shortcut for specifying one
internal panel at port A (0) in the devicetree.
Change-Id: I5308b53667657d0b255ae5bc543f1a00431f5818
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There are multiple different devicetree setting formats for graphics
panel settings present in coreboot. Replace the ones for the platforms
that already have (mostly) unified gma/graphics setup code by a unified
struct in the gma driver. Hook it up in HSW, BDW, SKL, and APL and adapt
the devicetrees accordingly.
Always ensure that values don't overflow by applying appropriate masks.
The remaining platforms implementing panel settings (GM45, i945, ILK and
SNB) can be migrated later after unifying their gma/graphics setup code.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I445defe01d5fbf9a69cf05cf1b5bd6c7c2c1725e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48885
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
which select INTEL_GMA_ACPI. Rework brightness level includes and
platform-level asl files to avoid duplicate device definition for GFX0.
Include gfx.asl for Skylake/Kabylake, since all other soc/intel/common
platforms already do. Adjust mb/51nb/x210 to prevent device redefinition.
Some OSes (e.g. Windows, MacOS) require/prefer the ACPI device for
the IGD to exist, even if ACPI brightness controls are not utilized.
This change adds a GFX0 ACPI device for all boards whose platforms
select INTEL_GMA_ACPI without requiring non-functional brightness
controls to be added at the board level.
Change-Id: Ie71bd5fc7acd926b7ce7da17fbc108670fd453e0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Add the right register values for backlight control to CNL's Kconfig.
To make iasl happy about the reversed register order, split the field.
Change-Id: I05a06cc42397c202df9c9a1ebc72fb10da3b10ec
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some server boards like OCP Tiogapass and X11-LGA1151 boards use a gpio
for signalling "POST complete" to BMC/IPMI. Add a new driver devicetree
option to set the gpio and configure a callback that pulls the gpio low
right before jumping to the payload.
Test: Check that sensor readings appear in BMC web interface when the
payload gets executed.
Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with
CB:48711 and OCP DeltaLake with CB:48672.
Change-Id: I34764858be9c7f7f1110ce885fa056591164f148
Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Tested-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48096
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Some boards, like the Supermicro X11SSM-F, have a jumper for enabling or
disabling the BMC and IPMI. Add a new devicetree driver option to set
the GPIO used for the jumper and enable or disable IPMI according to its
value.
This gets used in a follow-up change by Supermicro X11SSM-F.
Test: Boot with jumper set to each enabled and disabled and check debug
log if IPMI gets enabled/disabled accordingly.
Successfully tested on Supermicro X11SSM-F with CB:48095.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: Icde3232843a7138797a4b106560f170972edeb9c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The register `ESR` conflicts with the `Exception syndrome register` in
UDK2017. To resolve the conflict, drop the unused `ESR` register from
gma registers. It can be readded and prefixed or renamed if it's
required at a later point.
Change-Id: Icfdd834aea59ae69639a180221f5e97170fbac15
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We missed that Cannon Point, the PCH usually paired with Coffee, Whiskey
and Comet Lake, differs a bit from its predecessors. Hence, libgfxinit
now has a new Kconfig setting for the PCH.
Change-Id: I1c02c0d9abb7340aabe94185ee5e17ef4c2b0d36
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add a new driver for OEM commands and select it from x11-lga1151-series.
The driver communicates the BIOS version and date to the BMC using OEM
commands. The command should be supported on all X11 series mainboards,
but might work with older BMC, too.
Tested on X11SSH-TF:
The BIOS version strings are updated on boot and are visible in the
BMC web UI.
Change-Id: I51c22f83383affb70abb0efbcdc33ea925b5ff9f
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/+/38002
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The latest version defined by TCG is 1.3.
Change-Id: Idb12e2212d6d38c720c8fe989678724c871af6ef
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45569
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Implement the ACPI PPI interface as described in
"TCG PC Client Physical Presence Interface Specification" Version 1.3.
Add a new Kconfig that allows to use the full PPI instead of the stub
version compiled in.
This doesn't add code to execute the PPI request, as that's up to the
payload with graphical UI support.
Tested on GNU/Linux 5.6 using the sysfs interface at:
/sys/class/tpm/tpm0/ppi/
Change-Id: Ifffe1d9b715e2c37568e1b009e86c298025c89ac
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45568
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When a different FSP binary was chosen in menuconfig, the split fd files
do not get updated. Thus, make them depend on `.config` to trigger a
rebuild when the config changes.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I54739eae50fa1a47bf8f3fe2e79334bc7f7ac3d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48663
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently it's not possible to add multiple graphics driver into
one coreboot image. This patch series will fix this issue by providing
a single API that multiple graphics driver can use.
This is required for platforms that have two graphic cards, but
different graphic drivers, like Intel+Aspeed on server platforms or
Intel+Nvidia on consumer notebooks.
The goal is to remove duplicated fill_fb_framebuffer(), the advertisment
of multiple indepent framebuffers in coreboot tables, and better
runtime/build time graphic configuration options.
Replace set_vbe_mode_info_valid with fb_add_framebuffer_info or
fb_new_framebuffer_info_from_edid.
Change-Id: I95d1d62385a201c68c6c2527c023ad2292a235c5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39004
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Currently it's not possible to add multiple graphics drivers into
one coreboot image. This patch series will fix this issue by providing
a single API that multiple graphics drivers can use.
This is required for platforms that have two graphic cards, but
different graphic drivers, like Intel+Aspeed on server platforms or
Intel+Nvidia on consumer notebooks.
The goal is to remove duplicated fill_fb_framebuffer(), the advertisment
of multiple independent framebuffers in coreboot tables, and better
runtime/build time graphic configuration options.
Replace all duplications of fill_fb_framebuffer and provide a single one
in edid_fill_fb.c. Should not change the current behaviour as still only
one graphic driver can be active at time.
Change-Id: Ife507f7e7beaf59854e533551b4b87ea6980c1f4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39003
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some former commits (e.g. Ieb41771c75aae902191bba5d220796e6c343f8e0)
blindly assume that dev->chip_info is capable to be dereferenced,
making at least compilers complain about potential null pointer
dereference. They might cause crash if truly (dev->chip_info == NULL).
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I1d694b12f6c42961c104fe839d4ee46c0f111197
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Configure the CFG2 register to set the latency to <64us in order
to ensure the L1 exit latency is consistent across devices and that
L1 ASPM is always enabled.
This moves the setup code from device init to device enable so it
executes before coreboot does ASPM configuration, and removes the
call to pci_dev_init() as that is just for VGA Option ROMs.
BUG=b:173207454
TEST=Verify the device and link capability and control for L1:
DevCap: Latency L1 <64us
LnkCap: Latency L1 <64us
LnkCtl: ASPM L1 Enabled
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ie2b85a6697f164fbe4f84d8cd5acb2b5911ca7a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Stack is set up for bootblock.
Tested on Facebook FBG1701.
Change-Id: I0dd3fc91c90bf76e0d93925da35dc197d68d3e88
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47802
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds details about the memory map windows to translate
addresses between SPI flash space and host address space to coreboot
tables. This is useful for payloads to setup the translation using the
decode windows already known to coreboot. Until now, there was a
single decode window at the top of 4G used by all x86
platforms. However, going forward, platforms might support more decode
windows and hence in order to avoid duplication in payloads this
information is filled in coreboot tables.
`lb_spi_flash()` is updated to fill in the details about these windows
by making a call to `spi_flash_get_mmap_windows()` which is
implemented by the driver providing the boot media mapping device.
BUG=b:171534504
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I00ae33d9b53fecd0a8eadd22531fdff8bde9ee94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48185
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DRIVER_I2C_TPM_ACPI is used to enable the "driver" needed for coreboot
to present a TPM node in the devicetree. It would usually only do so,
if coreboot itself is communicating with the TPM via I2C (I2C_TPM).
However, technically, there is no dependency.
In order to not show the ACPI option in menuconfig if the board is not
using I2C, a dependency was declared in Kconfig. However, the same can
be achieved without making it an error to manually declare
DRIVER_I2C_TPM_ACPI without I2C_TPM.
For Volteer, we have just such a need, since it has two "sub-variants"
sharing the same overridetree.cb, one having SPI TPM and another having
I2C TPM. The former will have a disabled ACPI node representing the I2C
TPM, while its Kconfig is such that coreboot itself does not have I2C
TPM support.
In order to export even a disabled ACPI node representing the I2C
connected TPM, coreboot needs DRIVER_I2C_TPM_ACPI. Hence, that will
have to be enabled in a case where coreboot does not have I2C_TPM (for
one of the two sub-variants, namely volteer2).
BUG=b:173461736
TEST=Tested as part of next CL in chain
Change-Id: I9717f6b68afd90fbc294fbbd2a5b8d0c6ee9ae55
Signed-off-by: Jes Bodi Klinke <jbk@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48222
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use a wrapper code that does nothing on x86_32, but drops to protected
mode to call into FSP when running on x86_64.
Tested on Intel Skylake when running in long mode. Successfully run the
FSP-M which is compiled for x86_32 and then continued booting in
long mode.
Change-Id: I9fb37019fb0d04f74d00733ce2e365f484d97d66
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48202
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Export all registers that driver is looking for. And put in alphabetic order.
The missing registers for kernel v5.4 sx93xx are:
reg_irq_msk
reg_irq_cfg0
reg_irq_cfg2
reg_afe_ph0/1/2/3
BUG=b:172397658
BRANCH=zork
TEST=Build passed
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Ic9d7a959b1769b6846bba302e3aeab9a3a1cedac
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47866
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When FSP-T is used, the first thing done in postcar is to call FSP-M
to tear down CAR. This is done before cbmem is initialized, which
means CBFS_MCACHE is not accessible, which results in FSP-M not being
found, failing the boot.
TESTED: ocp/deltalake boots again.
Change-Id: Icb41b802c636d42b0ebeb3e3850551813accda91
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48282
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Once the console's FMAP region is full, we stop clearing the line
buffer and `line_offset` is not reset anymore. Hence, sanity check
`line_offset` everytime before writing to the buffer.
The issue resulted in boot hangs and potentially a brick if the
log was very verbose.
Change-Id: I36e9037d7baf8c1ed8b2d0c120bfffa58c089c95
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48074
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces two new CBFS API functions which are equivalent to
cbfs_map() and cbfs_load(), respectively, with the difference that they
always operate on the read-only CBFS region ("COREBOOT" FMAP section).
Use it to replace some of the simple cases that needed to use
cbfs_locate_file_in_region().
Change-Id: I9c55b022b6502a333a9805ab0e4891dd7b97ef7f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39306
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Looks like the option is generally not compatible with
garbage collections.
Nothing gets inlined, for example is_smp_boot() no longer
evaluates to constant false and thus the symbols from
secondary.S would need to be present for the build to pass
even if we set SMP=n.
Also the addresses of relocatable ramstage are currently
not normalised on the logs, so util/genprof would be unable
dress those.
Change-Id: I0b6f310e15e6f4992cd054d288903fea8390e5cf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The current location for the sensor initialization procedure was chosen
by mistake. Move this into a separate function in nct7802y.c .
Change-Id: I093ae75db5f0051bff65375b0720c86642b9148a
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This pollutes the log on all platforms not implementing an override.
Change-Id: I0d8371447ee7820cd8e86e9d3d5e70fcf4f91e34
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48128
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit bd31642ad8 (intel/i210: Set bus master bit in command register)
is only necessary because a buggy OS expects Bus Master to be set, not
because the hardware requires Bus Master during initialization. It is
thus safe to defer the Bus Master request into the .final callback.
Change-Id: Iecfa6366eb4b1438fd12cd9ebb1a77ada97fa2f6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47401
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested-by: siemens-bot
Define and use the MAC_ADDR_LEN macro in place of the `6` magic value.
Change-Id: Icfa2ad9bca6668bea3d84b10f613d01e437ac6a2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47404
Tested-by: siemens-bot
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Move the FSP FD PATH option down, so it gets shown in place of the split
FD files, when the users chooses to use a full FD binary.
Change-Id: Ie03a418fab30a908d020abf94becbaedf54fbb99
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47999
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently, setting a custom FSP binary is only possible by using split
FSP-T/M/S FD files. This change introduces the possibility to pass a
combined FD file (the "standard" FSP format).
This is done by adding a new boolean Kconfig FSP_FULL_FD, specifying
that the FSP is a single FD file instead of split FSP-T/M/S FD files,
and making FSP_FD_PATH user-visible when the option is chosen. In this
case, the other options for split files get hidden.
When the user chooses to use a full FD file instead of the split ones,
the FD file gets split during build, just like it is done when selecting
the Github FSP repo (FSP_USE_REPO).
Test: Supermicro X11SSM-F builds and boots fine with custom FSP FD set.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I1cb98c1ff319823a2a8a95444c9b4f3d96162a02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
As preparation to a full PPI implementation move the acpi code out
of the pc80/tpm/tis driver into the generic tpm driver folder.
This doesn't change any functionality.
Change-Id: I7818d0344d4a08926195bd4804565502717c48fa
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Follow model of drivers/i2c/generic and use user-supplied device
name if specified in the chip config.
Change-Id: Ia783bac2797e239989c03a3421b9293a055db3d0
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47782
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DDN field isn't required, no point in writing an empty string to it.
Change-Id: Ifea6e48c324598f114178e86a79f519ee35f5258
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47781
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a new driver for the SX9324 proximity detector device.
Follow SX9324 datasheet Rev3.
BUG=b:172397658
BRANCH=zork
TEST=Test sx9324 is working as expected.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Ifd582482728a2f535ed85f6696b2f5a4529ba421
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47640
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows to compare the FSP-T output in %ecx and %edx to coreboot's
CAR symbols.
Tested on Facebook FBG1701
Change-Id: Ice748e542180f6e1dc1505e7f37b6b6c68772bda
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Whole car region is cleared, while only small part needs to be done.
Clear .bss area only
Tested on Facebook FBG1701
Change-Id: I021c2f7d3531c553015fde98d155915f897b434d
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Only need to check this once so check it at romstage where
the console is usually ready. Also define union fsp_revision
to avoid code duplication.
Change-Id: I628014e05bd567462f50af2633fbf48f3dc412bc
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Top of Temp RAM is used as bootloader stack, which is the
_car_region_end area. This area is not equal to CAR stack area as
defined in car.ld file.
Use _ecar_stack (end of CAR stack) as starting stack location.
Tested VBOOT, Vendorboot security and no security on Facebook FBG1701.
Change-Id: I16b077f60560de334361b1f0d3758ab1a5cbe895
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47737
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot might not store wifi SAR values in VPD and may store it in
CBFS. Logging the message with 'error' severity may interfere
with automated test tool.
Lowering severity to BIOS_DEBUG avoids this issue.
BUG=b:171931401
BRANCH=None
TEST=Severity of message is reduced and we don't see it as an error
Change-Id: I5c122a57cfe92b27e0291933618ca13d8e1889ba
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The current HID "RX6110SA" does not comply with the ACPI spec in terms
of the naming convention where the first three caracters should be a
vendor ID and the last 4 characters should be a device ID. For now
there is a vendor ID for Epson (SEC) but there is none for this
particular RTC. In order to avoid the reporting of a non ACPI-compliant
HID it will be dropped completely for now.
Once Epson has assigned a valid HID for this RTC, this valid HID will be
used here instead.
Change-Id: Ib77ffad084c25f60f79ec7d503f14731b1ebe9e2
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47706
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This Kconfig option was just added incorrectly, so would never add
the verstage.c file.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I4c39dca9d429ed786ea42c0d421d6ee815e8c419
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47368
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The CONFIG_TPM_I2C_BURST_LIMITATION was never added, so this has never
been turned on. The Kconfig linter generates three warnings about this
block:
Warning: Unknown config option CONFIG_TPM_I2C_BURST_LIMITATION
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I53fa8f5b4eac6a1e7efec23f70395058bad26299
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47367
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is a trivial patch to fix some comments that were generating
notes in the kconfig lint test.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I26a95f17e82910f50c62215be5c29780fe98e29a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47366
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the host sends data in i2c bus, device might not send ACK. It means
that data is not processed on the device side, but for now we don't
check for that condition thus wait for the response which will not come.
Designware i2c detect such situation and set TX_ABORT bit. Checking for
the bit will enable other layers to immediately retry rather than
wait-timeout-retry cycle.
BUG=b:168838505
BRANCH=zork
TEST=test on zork devices, now we see "Tx abort detected" instead of I2C
timeout for tpm initializtion.
Change-Id: Ib0163fbce55ccc99f677dbb096f67a58d2ef2bda
Signed-off-by: Kangheui Won <khwon@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Currently the decision of whether or not to use mrc_cache in recovery
mode is made within the individual platforms' drivers (ie: fsp2.0,
fsp1.1, etc.). As this is not platform specific, but uses common
vboot infrastructure, the code can be unified and moved into
mrc_cache. The conditions are as follows:
1. If HAS_RECOVERY_MRC_CACHE, use mrc_cache data (unless retrain
switch is true)
2. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_BOOTBLOCK, this
means that memory training will occur after verified boot,
meaning that mrc_cache will be filled with data from executing
RW code. So in this case, we never want to use the training
data in the mrc_cache for recovery mode.
3. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_ROMSTAGE, this
means that memory training happens before verfied boot, meaning
that the mrc_cache data is generated by RO code, so it is safe
to use for a recovery boot.
4. Any platform that does not use vboot should be unaffected.
Additionally, we have removed the
MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN config because the
mrc_cache driver takes care of invalidating the mrc_cache data for
normal mode. If the platform:
1. !HAS_RECOVERY_MRC_CACHE, always invalidate mrc_cache data
2. HAS_RECOVERY_MRC_CACHE, only invalidate if retrain switch is set
BUG=b:150502246
BRANCH=None
TEST=1. run dut-control power_state:rec_force_mrc twice on lazor
ensure that memory retraining happens both times
run dut-control power_state:rec twice on lazor
ensure that memory retraining happens only first time
2. remove HAS_RECOVERY_MRC_CACHE from lazor Kconfig
boot twice to ensure caching of memory training occurred
on each boot.
Change-Id: I3875a7b4a4ba3c1aa8a3c1507b3993036a7155fc
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46855
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The defines for RX6110SA_SLAVE_ADR and RX6110SA_I2C_CONTROLLER are not
used anymore and can be deleted.
Change-Id: I3cddf7a9e2f757a22c729ae0f0ff767d55909b9c
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested-by: siemens-bot
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
This patch adds basic ACPI support for the RTC so that the OS is able to
use this RTC via the ACPI interface.
If the Linux kernel is able to find the RTC in ACPI scope, you should
see the following lines in dmesg, where [n] is an enumerated number:
rx6110 i2c-RX6110SA:00: rtc core: registered RX6110SA:00 as rtc[n]
rtc rtc[n]: Update timer was detected
Change-Id: I9b319e3088e6511592075b055f8fa3e2aedaa209
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
CB:46865 ("mb, soc/intel: Reorganize CNVi device entries in
devicetree") reorganized the devicetree entries to make the
representation of CNVi device consistent with other internal PCI
devices. Since a dummy generic device is added for the CNVi device,
`emit_sar_acpi_structures()` needs to first check if the device is PCI
before checking the vendor ID. This ensures that SAR table generation
is skipped only for PCIe devices with non-Intel vendor IDs and not for
the dummy generic device.
BUG=b:165105210
Change-Id: I3c8d18538b94ed1072cfcc108552f3a1ac320395
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47364
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
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>
Individual drivers check whether the concerned device is enabled before
filling in the SSDT. Move the check before calling acpi_fill_ssdt() and
remove the check in the individual drivers.
BUG=None
TEST=util/abuild/abuild
Change-Id: Ib042bec7e8c68b38fafa60a8e965d781bddcd1f0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47148
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
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 allows to compare the FSP-T output in %ecx and %edx to coreboot's
CAR symbols:
Change-Id: I8d79f97f8c12c63ce215935353717855442a8290
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change replaces the checks for dev->enabled with the helper
function `is_dev_enabled()`.
Change-Id: Iacceda396c9300bbfa124e76fb9c99d86313ea0f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46904
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Move CPX and SKX read_msr_ppin() to common util.c file.
Update drivers/ocp/smbios #include to match.
Change-Id: I4c4281d2d5ce679f5444a502fa88df04de9f2cd8
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jay Talbott <JayTalbott@sysproconsulting.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Bug=None
Test=Enabled the device on TGLY RVP and tested that the codec is
reflected in SSDT. Checked sound card binding works
and soundwire drivers are enabled in kernel.
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: Ia7358927fe8531e609ebe070bef259a2bbc09093
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
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>
Provide a way to get BMC revision.
Tested=On OCP Delta Lake, function can get BMC revision well.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: Iaaa4e8bf181a38452b53c83a762c7b648e95e643
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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 moves the addition of CBFS SAR file from
intel/wifi/Makefile.inc to wifi/generic/Makefile.inc to keep it in the
same sub-directory as the Kconfig definition.
BUG=b:169802515
BRANCH=zork
Change-Id: I7ee33232b6a07bbf929f3a79fabe89130fb6fa6f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
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>
To avoid confusion with `flashconsole` (CONSOLE_SPI_FLASH), prefix this
option with `EM100Pro`. Looks like it is not build-tested, however.
Change-Id: I4868fa52250fbbf43e328dfd12e0e48fc58c4234
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45973
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
Remove #include "chip.h", which is not needed and causes a build
problem in a later change. Alphabetise the #includes. Add <types.h>.
Change-Id: If19ccd144bd352a196adccd75f9f6f139eae4e4a
Signed-off-by: Marc Jones <marcjones@sysproconsulting.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45968
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
The kernel guys have found that automatic link training from this bridge
can occasionally fail and needs to be retried. They have added up to 10
retries just to be sure, so let's do the same in coreboot.
BUG=b:169535092
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I713b6851bd51d3527ed4c6e6407dee6b42d09955
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45882
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`option.c` was already linked into verstage but needs `mc146818rtc.c`
to work. While we are at it, also make use of the `all` target.
Change-Id: I8f545e036962ed0716bcd3b9a5b5d06e18a367f6
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45802
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Coverity detects calling function spi_sdcard_do_command without checking
return value. Fix this issue by checking return value for error
handling.
Found-by: Coverity CID 1407737
TEST=None
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ie0d28806b5c0b4c6d509e583d115358864eeff80
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45620
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add CONFIG_FSP_STATUS_GLOBAL_RESET Kconfig to get correct FSP global
reset type from respective SoC Kconfig.
Supported value: 0x40000003-0x40000008, These are defined in FSP EAS
v2.0 section 11.2.2 - OEM Status Code
Unsupported value: 0xFFFFFFFF
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: Idc04eb3a931d2d353808d02e62bd436b363600d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Coverity detects variable dsd going out of scope leaks the storage it
points to. Move dsd resource allocation after sanity check for
config->nvm_compact to avoid leak.
Found-by: Coverity CID 1432727
TEST=Built and boot up to kernel on Volteer.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I86af322dc78845b8b312b6815135336c2c56b4dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The device is a PCIe Gen2 to SD 4.0 card reader controller to be
used in the Chromebook. The datasheet name is GL9755S and the revision
is 05.
The patch sets LTR value.
Signed-off-by: Ben Chuang <benchuanggli@gmail.com>
Change-Id: I16048dde348be248c748d50ca4a8a62c8a781430
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45062
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add compatible field for NVM
Make PRP0001 as default HID if device type is INTEL_ACPI_CAMERA_NVM
Signed-off-by: Pandya, Varshit B <varshit.b.pandya@intel.com>
Change-Id: Iad7afa7b3170982eb5d6215e766f3e98f7a89213
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
This adds error checking in paths that previously ignored TPM
communication errors. We hit this case occasionally during "Checking
cr50 for pending updates"; previously we would go down this path and
eventually time out using MAX_STATUS_TIMEOUT, which is 2 minutes.
Now, we detect the failure and return with an error indication instead
of timing out after a long time. The root cause of the communication
error is an open issue.
BUG=b:168090038
TEST=booted on volteer, observed error handling when
"Checking cr50 for pending updates" fails.
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Change-Id: Ia8a1202000abce1857ee694b06b1478e6b045069
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jes Klinke <jbk@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Servers often run headless, so a missing EDID isn't a problem. However,
we still need to initialize a framebuffer for the BMC's KVM function.
Reduce the log level to BIOS_INFO to avoid confusion.
Change-Id: Ice17bf6fdda0ce34e686dbf8f3a1fa92ba869d7c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This change is being done for the following reasons:
1. The CONFIG_ELOG_PRERAM is unused.
2. We need to pull in elog.c into romstage because we are pulling the
mrc_cache_stash_data function into romstage.
3. Furquan says that we can rely on the linker to optimize out the
unused 4KiB buffer in the early stages of boot, which allows us to
get rid of the ELOG_PRERAM config.
BUG=b:117884485, b:150502246
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_NAMI -x -a -v
Change-Id: Id76cabc38e41e9bf79e1580a530c871a4ecef4ec
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45303
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The UART index is never negative, so make it unsigned and drop the
checks for the index to be non-negative.
Change-Id: I64bd60bd2a3b82552cb3ac6524792b9ac6c09a94
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add sn65dsi86 bridge driver to enable the eDP bridge.
Datasheet used : https://www.ti.com/lit/ds/sllseh2b/sllseh2b.pdf
Changes in V1:
- fix the dp lanes using mask
- separate out the refclk and hpd config to init function
Change-Id: I36a68f3241f0ba316c261a73c2f6d30fe6c3ccdc
Signed-off-by: Vinod Polimera <vpolimer@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
With the current timeout of 1000 cycles of 100 microsecond would see
timeout occurs on OCP Delta Lake if the log level is set to values
smaller than 8. Because the prink(BIOS_SPEW, ..) in ipmi_kcs_status()
creates delay and avoid the problem, but after setting the log level
to 4 we see some timeout occurs.
The unit is millisecond and the default value is set to 5000 according
to IPMI spec v2.0 rev 1.1 Sec. 9.15, a five-second timeout or greater
is recommended.
Tested=On OCP Delta Lake, with log level 4 cannot observe timeout
occurs.
Change-Id: I42ede1d9200bb5d0dbb455d2ff66e2816f10e86b
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45103
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This ports Linux commit 71f677a91046599ece96ebab21df956ce909c456
"Handle configuration without P2A bridge".
Quote:
The ast driver configures a window to enable access into BMC
memory space in order to read some configuration registers.
If this window is disabled, which it can be from the BMC side,
the ast driver can't function.
Closing this window is a necessity for security if a machine's
host side and BMC side are controlled by different parties;
i.e. a cloud provider offering machines "bare metal".
P2A stands for primary to AHB.
Tested on Prodrive Hermes, which uses an AST2500. The machine still
boots, has a high resolution framebuffer working in EDK2, and its
boot time has been reduced by 2.5 seconds as it no longer runs into
a timeout due to disabled P2A bridge.
Change-Id: I3293dc35ae89c010154e02eff904ec3a68c96683
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
On autogenerated FMAPs, there's no `UNIFIED_MRC_CACHE` region. The
current code will print a spurious error message about it, though.
Reduce the log level to BIOS_INFO to avoid confusion.
Change-Id: I0961bb2a7d2d81dc5c0d28f6e6c29b320421fc3e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45076
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We need to pull update_mrc_cache into mrc_cache_stash_data, so moving
to end of the file to make sure update_mrc_cache is defined before.
BUG=b:150502246
BRANCH=None
TEST=Testing on a nami (x86) device:
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: I9e14fec96e9dabceafc2f6f5663fc6f1023f0395
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44195
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Create two new functions to fetch mrc_cache data (replacing
mrc_cache_get_current):
- mrc_cache_load_current: fetches the mrc_cache data and drops it into
the given buffer. This is useful for ARM platforms where the mmap
operation is very expensive.
- mrc_cache_mmap_leak: fetch the mrc_cache data and puts it into a
given buffer. This is useful for platforms where the mmap operation
is a no-op (like x86 platforms). As the name mentions, we are not
freeing the memory that we allocated with the mmap, so it is the
caller's responsibility to do so.
Additionally, we are replacing mrc_cache_latest with
mrc_cache_get_latest_slot_info, which does not check the validity of
the data when retrieving the current mrc_cache slot. This allows the
caller some flexibility in deciding where they want the mrc_cache data
stored (either in an mmaped region or at a given address).
BUG=b:150502246
BRANCH=None
TEST=Testing on a nami (x86) device:
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: I259dd4f550719d821bbafa2d445cbae6ea22e988
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44006
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a helper to get the cached cr50 firmware version. This
information is in turn used to identify the strap configuration
supported by Cr50.
BUG=None
TEST=Ensure that Drawcia board boots to OS. Ensure that the version
cached cr50 firmware version is returned.
Change-Id: Id84b152993f253878a6c133cc433a0da2c990cf2
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44653
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For Volteer (and future Tiger Lake boards) we can enable mode S0i3.4
only if we know that the Cr50 is generating 100us interrupt pulses.
We have to do so, because the SoC is not guaranteed to detect pulses
shorter than 100us in S0i3.4 substate.
A new Kconfig setting CR50_USE_LONG_INTERRUPT_PULSES controls new code
running in verstage, which will program a new Cr50 register, provided that
Cr50 firmware is new enough to support the register.
BUG=b:154333137
TEST=util/abuild/abuild -t GOOGLE_VOLTEER -c max -x
Signed-off-by: Jes Bodi Klinke <jbk@chromium.org>
Change-Id: If83188fd09fe69c2cda4ce1a8bf5b2efe1ca86da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Value stored to 'size' is never read.
Also drop unused parameter.
Change-Id: If3e96ac90f06966ee408964e0748730bc237ec19
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Coverity detects that value assigned to variable "ret" is overwritten
before it is used. Fix the issue by returning right value.
Found-by: Coverity CID 1255942, 1241836
TEST=None
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I2e1fb5400ff64c6178bb30601896780f8d67b5c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44185
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
soc/amd/picasso selected FSP_USES_CB_STACK even though it is FSP 2.0
based, so it doesn't reuse coreboot's stack, but sets up its own stack.
In contrast to all other FSP 2.0 based platforms, this stack isn't in
the CAR region, since AMD Picasso doesn't support CAR and the DRAM is
already available when the x86 cores are released from reset. Selecting
FSP_USES_CB_STACK ended up doing the right thing, but is semantically
wrong. Instead of wrongly selecting FSP_USES_CB_STACK in soc/amd/picasso
we take the corresponding code path if ENV_CACHE_AS_RAM is false which
is only the case for non-CAR platforms.
BUG=b:155501050
TEST=Timeless build results in an identical binary for amd/mandolin,
asrock/h110m-dvs and intel/coffeelake_rvp11 which cover all 3 cases
here.
Change-Id: Icd0ff8e17a535e2c247793b64f4b0565887183d8
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Latest EDK2 code inside
"UefiCpuPkg\Library\RegisterCpuFeaturesLib\CpuFeaturesInitialize.c"
is now looking for EFI_CPU_PHYSICAL_LOCATION structure variables hence
coreboot need to fill required information (package, core and thread
count).
TEST=Able to see package, core and thread information as part of FSP
debug log.
Change-Id: Ieccf20a116d59aaafbbec3fe0adad9a48931cb59
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
This patch ensures that coreboot is able to take control of APs back
by doing a full AP re-initialization after FSP-S is done.
TEST=Able to see all cores available after booting to OS using below command
when coreboot is built with USE_INTEL_FSP_MP_INIT enable.
> cat /proc/cpuinfo
Without this CL :
shows only 1 core (only BSP)
With this CL :
shows all possible cores available (BSP + APs)
Change-Id: I247d8d1166c77bd01922323b6a0f14ec6640a666
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44077
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Includes changes in mipi_camera driver to fix following issues related
to SSDT generation for IPU devices.
1. acpigen_write_device was not getting called for IPU devices
2. acpigen_pop_len was called for a generic devices without calling
acpigen_write_device
Change-Id: I309edd065719cb8250f1241898bb5854004d2a9f
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44025
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The device is a PCIe to eMMC bridge controller to be used in the
Chromebook as the boot disk. The datasheet name is GL9763E and
the revision is 02.
The patch sets single request AXI, disables ASPM L0s and enables SSC.
Signed-off-by: Ben Chuang <benchuanggli@gmail.com>
Change-Id: I158c79f5ac6e559f335b6b50092469c7b1646c56
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43751
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change updates the mipi_camera driver to handle shared power
resource between multiple cameras. This is achieved by adding a guard
variable and methods to manipulate the guard variable before calling
the actual platform method which enables or disables the resource.
PowerResource will call these guarded methods to enable or disable the
resource. This protects the shared resource from being enabled or
disabled multiple times while the other camera is using the resource.
Example:
Consider a platform where two cameras are sharing a GPIO resource 0xXX
and both the cameras calls enable and disable guarded methods for this
GPIO. Actual platform disable method for the GPIO is called only after
the last camera using the GPIO calls DSBx method and RESx becomes 0.
Scope (\_SB.PCI0)
{
Name (RESx, Zero)
Method (ENBx, 0, Serialized)
{
If ((RESx == Zero))
{
\_SB.PCI0.STXS (0xXX)
}
RESx++
}
Method (DSBx, 0, Serialized)
{
If ((RESx > Zero))
{
RESx--
}
If ((RESx == Zero))
{
\_SB.PCI0.CTXS (0xXX)
}
}
}
Change-Id: I1468459d5bbb2fb07bef4e0590c96dd4dbab0d9c
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43003
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add driver for OCP specific ipmi commands. With this driver, OCP
specific ipmi command can be used after implementing functions here.
TEST=Build with CB:42242 on Delta Lake, select Kconfig option:
IPMI_OCP and add device in devicetree to open this function.
Use ipmi-util in OpenBMC to dump raw data and check if this
function work.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I2efa85978ec4ad3d75f2bd93b4139ef8059127ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43996
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a missing newline to a printk in the max98373 driver.
BUG=none
TEST=verified BIOS boot log is properly formatted on volteer.
Change-Id: I1c989729bdc71736975901566023e0057a6d0556
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Re-organize the existing generic wifi driver into a generic wifi chip
driver. This allows generic wifi chip information to be added to the
devicetree.
BUG=None
TEST=./util/abuild/abuild
Change-Id: I63f957a008ecf4a6a810c2a135ed62ea81a79fe0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43768
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The prompts for the DPTF Kconfig options were not necessary, they should
be selected based on what DPTF implementation is being used, ASL files
or generated at runtime. It's not really meant to be fiddled with at
build-time. Also rewrite the help text for the _HID selection, to try
and make it more clear when to use y or n.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I6edcabd28426916d9586d501b95b510dfc163fc1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43830
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix the scan-build warning below:
CC romstage/drivers/mrc_cache/mrc_cache.o
src/drivers/mrc_cache/mrc_cache.c:450:26: warning: Value stored to 'flash' during its initialization is never read
const struct spi_flash *flash = boot_device_spi_flash();
^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
The function can return early before the value is read. Fix this, by
getting rid of the variable, as the value is only read once.
Change-Id: I3c94b123f4994eed9d7568b63971fd5b1d94bc09
Found-by: scan-build (clang-tools-9 1:9.0.1-12)
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42798
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
BOOL type Kconfig values should be used through the CONFIG() macro.
These instances were not, so update them.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ie4706d82c12c487607bbf5ad8059922e0e586858
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43825
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The Kconfig lint tool checks for cases of the code using BOOL type
Kconfig options directly instead of with CONFIG() and will print out
warnings about it. It gets confused by these references in comments
and strings. To fix it so that it can find the real issues, just
update these as we would with real issues.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5c37f0ee103721c97483d07a368c0b813e3f25c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Coverity detects dereferencing pointers that might be "NULL" when
calling acpigen_write_scope and acpigen_write_device. Add sanity
check for both of scope and name to prevent NULL pointer dereference.
Found-by: Coverity CID 1430454
TEST=Built and boot up to kernel on Volteer.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I8ece3831bbd2641ceafbd71b9dc3db7e04a8eae4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43449
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Missed one other scope operator in the DPTF cleanup. This one is for the
fan device, and without this fix, the kernel isn't able to properly
control the fan (it gets confused about whether it's ACPI 4+ compatible
or not).
BUG=b:149722146
TEST=verify /sys/class/thermal/cooling_zone0/max_state returns > 1,
and /sys/class/thermal/cooling_zone0/cur_state is writable, and writing
the value of `max_state` causes the fan to spin faster.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I7bd83967ace761ddd17eaeae9c25abb0b2cbe413
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43840
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Unconditionally selecting `GFX_GMA_IGNORE_PRESENCE_STRAPS` creates a
hard dependency on `MAINBOARD_USE_LIBGFXINIT`, which is undesired. Move
it out of the `if GFX_GMA` block to break this unwanted dependency.
TEST=Build for Librem 13v4 with no graphics init successfully.
Change-Id: I53e132c209c065068f20959fa1a6f5195f5fe766
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The previous DPTF patch train missed the proper scope operator around
all of the TSR options. Without this, the optional GTSH and/or _STR
Methods end up in the wrong scope.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I9298c442c047c5f7f606574d900057a7c004b47f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43458
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the initial DPTF refactor, the scope of the TCPU device was
incorrectly set as \_SB, instead of \_SB.PCI0. However, because of the
way that the acpi_inject_dsdt() callback currently works (it injects
contents before the dsdt.aml file), the Scope where the TCPU
device lives (\_SB.PCI0) doesn't exist yet. Therefore, to avoid playing
games with *when* things are defined in the DSDT, switch to defining all
of the DPTF devices in the SSDT.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ia4922b4dc6544d79d44d39e6ad18c6ab9fee0fd7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43529
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds a new driver for AMD I2S machine device. Currently,
this device is added as part of `acp_fill_ssdt()` in Picasso, but with
addition of this driver, this device can be added just like any other
device in the devicetree.
BUG=b:157708581
Change-Id: I49d1a867d7941397acca1054632b6ad855a021de
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch converts the current DPTF policies from static ASL files into
the new SSDT-based DPTF implementation. All settings are intended to be
copied exactly.
Change-Id: I964c53afbd503d47a07b982672425f0e7a986a3f
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41895
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We only want to return an ACPI name for a USB port if the controller
physically has the port. This has the desired side effect of making the
usb_acpi driver skip generating an ACPI node for a device which has
no port. This prevents writing an invalid SSDT table which the OS then
complains about.
BUG=b:154756391, b:158096224
TEST=Boot picasso trembyle and verify HS05, HS06 and SS05 are no longer
generated. Also checked the logs and saw the devices being ignored.
\_SB.PCI0.LPCB.EC0.CREC.TUN0: Cros EC I2C Tunnel at GENERIC: 0.0
\_SB.PCI0.LPCB.EC0.CREC.MSTH: Cros EC I2C Tunnel at GENERIC: 1.0
\_SB.PCI0.LPCB.EC0.CREC.ECA0: Cros EC audio codec at GENERIC: 0.0
\_SB.PCI0.PBRA.XHC0.RHUB.HS01: Left Type-C Port at USB2 port 0
\_SB.PCI0.PBRA.XHC0.RHUB.HS02: Left Type-A Port at USB2 port 1
\_SB.PCI0.PBRA.XHC0.RHUB.HS03: Right Type-A Port at USB2 port 2
\_SB.PCI0.PBRA.XHC0.RHUB.HS04: Right Type-C Port at USB2 port 3
xhci_acpi_name: USB2 port 4 does not exist on xHC PCI: 03:00.3
xhci_acpi_name: USB2 port 5 does not exist on xHC PCI: 03:00.3
\_SB.PCI0.PBRA.XHC0.RHUB.SS01: Left Type-C Port at USB3 port 0
\_SB.PCI0.PBRA.XHC0.RHUB.SS02: Left Type-A Port at USB3 port 1
\_SB.PCI0.PBRA.XHC0.RHUB.SS03: Right Type-A Port at USB3 port 2
\_SB.PCI0.PBRA.XHC0.RHUB.SS04: Right Type-C Port at USB3 port 3
xhci_acpi_name: USB3 port 4 does not exist on xHC PCI: 03:00.3
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia645380bea74f39fd94e2f9cbca3fcd4d18a878e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43354
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There's no need to use ugly preprocessor here when regular C conditional
statements will work just fine.
Change-Id: I5abd445a335b43fb95e4df087d44e82c3f44349b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
