| Age | Commit message (Collapse) | Author |
|---|
|
In order to detect USB Type C device port as Super Speed, we need to set
corresponding bit in UPD UsbTcPortEn. This patch will use device path
to determine which port should be enabled.
BUG=b:184324979
Test=Boot board, USB Type C must be functional and operate at Super Speed.
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com>
Change-Id: I7da63f21d51889a888699540f780cb26b480c26d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55361
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
This patch enables the energy efficiency turbo mode.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: I2d76c948bdc9c208f5728e305b3034fcede6f4bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55705
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The same pattern appears on all `xdci_can_enable()` call sites. Move the
logic inside the function and take the xDCI devfn as parameter.
Change-Id: I94c24c10c7fc7c5b4938cffca17bdfb853c7bd59
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55790
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
By enabling the flag alderlake platform will use hardware sha
instruction instead of software implementation for sha256.
This will speed up firmware verification especially on low-performance
device.
Change-Id: Ie8ab02360fdceafab257e9a301e6a89d3a22c3ae
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55612
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
This is done to ensure the CSE will not execute any pre-boot commands
after it receives this command. Verified EOP and error recovery sequence
from Intel doc#619830.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I36fe448ff279ba054ad5e79e71c995dc915db21e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55633
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This is done to ensure the CSE will not execute any pre-boot commands
after it receives this command. Verified EOP and error recovery sequence
from Intel doc#612229
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Iae6b2eac11c065749e57c5337d81ed20044fc903
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This is done to ensure the CSE will not execute any pre-boot commands
after it receives this command. Verified EOP and error recovery sequence
from Intel doc#627331.
TEST=on brya, autotest firmware_CheckEOPState confirms ME is in
post-boot state
Change-Id: Iee8c29f81d5d04852ae3f16dc8a9ff0fa59f056a
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55596
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This patch adds functionality to attempt to allow booting in a secure
configuration (albeit with potentially reduced functionality) when the
CSE EOP message fails in any way. These steps come from the CSME BWG
(13.5, 15.0, 16.), and tell the CSE to disable the MEI bus, which
disables further communication from the host. This is followed by
requesting the PMC to disable the MEI devices. If these steps are
successful, then the boot firmware can continue to boot to the
OS. Otherwise, die() is called, prefering not to boot over leaving the
insecure MEI bus available.
BUG=b:191362590
TEST=Set FSP UPD to disable sending EOP; called this function from a
BS_PAYLOAD_LOAD, ON_ENTRY entry; observed that with just
cse_mei_bus_disable() called, Linux can no longer communicate over MEI:
[ 16.198759] mei_me 0000:00:16.0: wait hw ready failed
[ 16.204488] mei_me 0000:00:16.0: hw_start failed ret = -62
[ 16.210804] mei_me 0000:00:16.0: H_RST is set = 0x80000031
[ 18.245909] mei_me 0000:00:16.0: wait hw ready failed
[ 18.251601] mei_me 0000:00:16.0: hw_start failed ret = -62
[ 18.257785] mei_me 0000:00:16.0: reset: reached maximal consecutive..
[ 18.267622] mei_me 0000:00:16.0: reset failed ret = -19
[ 18.273580] mei_me 0000:00:16.0: link layer initialization failed.
[ 18.280521] mei_me 0000:00:16.0: init hw failure.
[ 18.285880] mei_me 0000:00:16.0: initialization failed.
Calling both error recovery functions causes all of the slot 16 devices
to fail to enumerate in the OS
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I06abf36a9d9d8a5f2afba6002dd5695dd2107db1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55675
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Enable PCH GBE with following changes:
1. Configure PCH GBE related FSP UPD flags
2. Use EHL own GBE ACPI instead of common code version due to
different B:D.F from the usual GBE
3. Add kconfig PMC_EPOC to use the PMC XTAL read function
Due to EHL GBE comes with time sensitive networking (TSN)
capability integrated, EHL FSP is using 'PchTsn' instead of the
usual 'PchLan' naming convention across the board.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: I6b0108e892064e804693a34e360034ae7dbee68f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
1. Remove 'PCH_EPOC_XTAL_FREQ(__epoc)' macro since it only be used
in 1 place.
2. Transform macro into more readable C code.
3. Add additional case check to make sure the returned value is
defined in the 'pch_pmc_xtal' enum.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: If57a99bf8e837a6eb8f225297399b1f5363cfa85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55587
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Move PMC EPOC related code to intel/common/block because it is
generic for most Intel platforms and ADL, TGL & EHL use it.
Add a kconfig 'PMC_EPOC' to guard this common EPOC code.
The PMC EPOC register indicates which external crystal oscillator is
connected to the PCH. This frequency is important for determining the
IP clock of internal PCH devices.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: Ib5fd3c4a648964678ee40ed0f60ca10fe7953f56
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55565
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
To generalise the choice of 32-bit or 64-bit coreboot on x86 hardware,
have platforms select `ARCH_X86` directly instead of through per-stage
Kconfig options, effectively reversing the dependency order.
Change-Id: If15436817ba664398055e9efc6c7c656de3bf3e4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
With two versions of *speed_mhz_to_reported_mts() we need to call the
correct one based on the reported memory type.
BUG=b:184124605
TEST="dmidecode --type 17" in OS on Guybrush
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Change-Id: I92e834097546e3ef7130830444a80f818bdea3d5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55852
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since GPIO IO-APIC IRQs are fixed in hardware (RO registers), this patch
allows tigerlake boards to dynamically assign PCI IRQs. This means not
relying on FSP defaults, which eliminates the problem of PCI IRQs
interfering with GPIO IRQs routed to the same IRQ, when both have
selected IO-APIC routing.
BUG=b:171580862
TEST=on delbin, grep 'IO-APIC' /proc/interrupts (compressed to fit)
0: 6 0 0 0 IO-APIC 2-edge timer
1: 0 35 0 0 IO-APIC 1-edge i8042
8: 0 0 0 0 IO-APIC 8-edge rtc0
9: 0 601 0 0 IO-APIC 9-fasteoi acpi
14: 1 0 0 0 IO-APIC 14-fasteoi INT34C5:00
20: 0 0 0 516 IO-APIC 20-fasteoi idma64.6, ttyS0
28: 0 395 0 0 IO-APIC 28-fasteoi idma64.0, i2c_design
29: 0 0 1654 0 IO-APIC 29-fasteoi idma64.1, i2c_design
30: 0 0 0 0 IO-APIC 30-fasteoi idma64.2, i2c_design
31: 0 0 0 0 IO-APIC 31-fasteoi idma64.3, i2c_design
32: 0 0 0 0 IO-APIC 32-fasteoi idma64.4, i2c_design
33: 0 0 14469 0 IO-APIC 33-fasteoi idma64.5, i2c_design
35: 0 18494 0 0 IO-APIC 35-edge cr50_spi
36: 95705 0 0 0 IO-APIC 36-fasteoi idma64.7, pxa2xx-spi
37: 0 0 1978 0 IO-APIC 37-fasteoi idma64.8, pxa2xx-spi
51: 1865 0 0 0 IO-APIC 51-fasteoi ELAN9008:00
59: 0 0 422 0 IO-APIC 59-fasteoi ELAN0000:00
116: 0 0 0 23 IO-APIC 116-fasteoi chromeos-ec
abbreviated _PRT dump:
Method (_PRT, 0, NotSerialized) // _PRT: PCI Routing Table
If (PICM)
Package () {0x0002FFFF, 0x00, 0x00, 0x10},
Package () {0x0004FFFF, 0x00, 0x00, 0x11},
Package () {0x0005FFFF, 0x00, 0x00, 0x12},
Package () {0x0006FFFF, 0x00, 0x00, 0x13},
Package () {0x0007FFFF, 0x00, 0x00, 0x14},
Package () {0x0007FFFF, 0x01, 0x00, 0x15},
Package () {0x0007FFFF, 0x02, 0x00, 0x16},
Package () {0x0007FFFF, 0x03, 0x00, 0x17},
Package () {0x000DFFFF, 0x00, 0x00, 0x10},
Package () {0x000DFFFF, 0x01, 0x00, 0x11},
Package () {0x000DFFFF, 0x02, 0x00, 0x12},
Package () {0x0010FFFF, 0x00, 0x00, 0x13},
Package () {0x0010FFFF, 0x01, 0x00, 0x14},
Package () {0x0011FFFF, 0x00, 0x00, 0x18},
Package () {0x0012FFFF, 0x00, 0x00, 0x19},
Package () {0x0012FFFF, 0x01, 0x00, 0x1A},
Package () {0x0013FFFF, 0x00, 0x00, 0x1B},
Package () {0x0014FFFF, 0x00, 0x00, 0x15},
Package () {0x0015FFFF, 0x00, 0x00, 0x1C},
Package () {0x0015FFFF, 0x01, 0x00, 0x1D},
Package () {0x0015FFFF, 0x02, 0x00, 0x1E},
Package () {0x0015FFFF, 0x03, 0x00, 0x1F},
Package () {0x0016FFFF, 0x00, 0x00, 0x16},
Package () {0x0016FFFF, 0x01, 0x00, 0x17},
Package () {0x0016FFFF, 0x02, 0x00, 0x10},
Package () {0x0016FFFF, 0x03, 0x00, 0x11},
Package () {0x0017FFFF, 0x00, 0x00, 0x12},
Package () {0x0019FFFF, 0x00, 0x00, 0x20},
Package () {0x0019FFFF, 0x01, 0x00, 0x21},
Package () {0x0019FFFF, 0x02, 0x00, 0x22},
Package () {0x001CFFFF, 0x00, 0x00, 0x10},
Package () {0x001CFFFF, 0x01, 0x00, 0x11},
Package () {0x001CFFFF, 0x02, 0x00, 0x12},
Package () {0x001CFFFF, 0x03, 0x00, 0x13},
Package () {0x001DFFFF, 0x00, 0x00, 0x10},
Package () {0x001DFFFF, 0x01, 0x00, 0x11},
Package () {0x001DFFFF, 0x02, 0x00, 0x12},
Package () {0x001DFFFF, 0x03, 0x00, 0x13},
Package () {0x001EFFFF, 0x00, 0x00, 0x14},
Package () {0x001EFFFF, 0x01, 0x00, 0x15},
Package () {0x001EFFFF, 0x02, 0x00, 0x24},
Package () {0x001EFFFF, 0x03, 0x00, 0x25},
Package () {0x001FFFFF, 0x01, 0x00, 0x17},
Package () {0x001FFFFF, 0x02, 0x00, 0x14},
Package () {0x001FFFFF, 0x03, 0x00, 0x15},
Package () {0x001FFFFF, 0x00, 0x00, 0x16},
Else
Package () {0x0002FFFF, 0x00, 0x00, 0x0B},
Package () {0x0004FFFF, 0x00, 0x00, 0x0A},
Package () {0x0005FFFF, 0x00, 0x00, 0x0B},
Package () {0x0006FFFF, 0x00, 0x00, 0x0B},
Package () {0x0007FFFF, 0x00, 0x00, 0x0B},
Package () {0x0007FFFF, 0x01, 0x00, 0x0B},
Package () {0x0007FFFF, 0x02, 0x00, 0x0B},
Package () {0x0007FFFF, 0x03, 0x00, 0x0B},
Package () {0x000DFFFF, 0x00, 0x00, 0x0B},
Package () {0x000DFFFF, 0x01, 0x00, 0x0A},
Package () {0x000DFFFF, 0x02, 0x00, 0x0B},
Package () {0x0010FFFF, 0x00, 0x00, 0x0B},
Package () {0x0010FFFF, 0x01, 0x00, 0x0B},
Package () {0x0014FFFF, 0x00, 0x00, 0x0B},
Package () {0x0016FFFF, 0x00, 0x00, 0x0B},
Package () {0x0016FFFF, 0x01, 0x00, 0x0B},
Package () {0x0016FFFF, 0x02, 0x00, 0x0B},
Package () {0x0016FFFF, 0x03, 0x00, 0x0A},
Package () {0x0017FFFF, 0x00, 0x00, 0x0B},
Package () {0x001CFFFF, 0x00, 0x00, 0x0B},
Package () {0x001CFFFF, 0x01, 0x00, 0x0A},
Package () {0x001CFFFF, 0x02, 0x00, 0x0B},
Package () {0x001CFFFF, 0x03, 0x00, 0x0B},
Package () {0x001DFFFF, 0x00, 0x00, 0x0B},
Package () {0x001DFFFF, 0x01, 0x00, 0x0A},
Package () {0x001DFFFF, 0x02, 0x00, 0x0B},
Package () {0x001DFFFF, 0x03, 0x00, 0x0B},
Package () {0x001EFFFF, 0x00, 0x00, 0x0B},
Package () {0x001EFFFF, 0x01, 0x00, 0x0B},
Package () {0x001FFFFF, 0x01, 0x00, 0x0B},
Package () {0x001FFFFF, 0x02, 0x00, 0x0B},
Package () {0x001FFFFF, 0x03, 0x00, 0x0B},
Package () {0x001FFFFF, 0x00, 0x00, 0x0B},
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ieb241f2b91af52a7e2d0efe997d35732882ac463
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49409
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since GPIO IO-APIC IRQs are fixed in hardware (RO registers), this patch
allows ADL boards to dynamically assign PCI IRQs. This means not relying
on FSP defaults, which eliminates the problem of PCI IRQs interfering
with GPIO IRQs routed to the same IRQ, when both have selected IO-APIC
routing.
BUG=b:176858827
TEST=brya0, grep 'IO-APIC' /proc/interrupts (compressed to fit)
0: 36 0 0 0 0 0 0 0 IO-APIC 2-edge time
1: 0 0 9 0 0 0 0 0 IO-APIC 1-edge i804
8: 0 0 0 0 0 0 0 0 IO-APIC 8-edge rtc0
9: 0 21705 0 0 0 0 0 0 IO-APIC 9-fasteoi acpi
14: 0 0 0 0 0 0 0 0 IO-APIC 14-fasteoi INTC
18: 0 0 0 0 0 0 0 0 IO-APIC 18-fasteoi inte
20: 0 0 0 0 0 0 0 394 IO-APIC 20-fasteoi idma
23: 2280 0 0 0 0 0 0 0 IO-APIC 23-fasteoi idma
26: 0 0 26 0 0 0 0 0 IO-APIC 26-fasteoi idma
27: 0 0 0 6 0 0 0 0 IO-APIC 27-fasteoi idma
28: 0 0 0 0 0 0 0 0 IO-APIC 28-fasteoi idma
29: 0 0 0 0 25784 0 0 0 IO-APIC 29-fasteoi idma
30: 0 0 0 0 0 0 0 0 IO-APIC 30-fasteoi idma
31: 0 0 0 0 0 0 226 0 IO-APIC 31-fasteoi idma
77: 0 0 0 0 0 2604 0 0 IO-APIC 77-edge cr50
100: 0 0 0 0 0 0 0 0 IO-APIC 100-fasteoi ELAN
103: 0 0 0 0 0 0 0 0 IO-APIC 103-fasteoi chro
abbreviated _PRT dump:
If (PICM)
Package (){0x0002FFFF, 0, 0, 0x10},
Package (){0x0004FFFF, 0, 0, 0x11},
Package (){0x0005FFFF, 0, 0, 0x12},
Package (){0x0006FFFF, 0, 0, 0x13},
Package (){0x0006FFFF, 1, 0, 0x14},
Package (){0x0007FFFF, 0, 0, 0x15},
Package (){0x0007FFFF, 1, 0, 0x16},
Package (){0x0007FFFF, 2, 0, 0x17},
Package (){0x0007FFFF, 3, 0, 0x10},
Package (){0x000DFFFF, 0, 0, 0x11},
Package (){0x0012FFFF, 0, 0, 0x18},
Package (){0x0012FFFF, 1, 0, 0x19},
Package (){0x0014FFFF, 0, 0, 0x12},
Package (){0x0014FFFF, 1, 0, 0x13},
Package (){0x0015FFFF, 0, 0, 0x1A},
Package (){0x0015FFFF, 1, 0, 0x1B},
Package (){0x0015FFFF, 2, 0, 0x1C},
Package (){0x0015FFFF, 3, 0, 0x1D},
Package (){0x0016FFFF, 0, 0, 0x14},
Package (){0x0016FFFF, 1, 0, 0x15},
Package (){0x0016FFFF, 2, 0, 0x16},
Package (){0x0016FFFF, 3, 0, 0x17},
Package (){0x0017FFFF, 0, 0, 0x10},
Package (){0x0019FFFF, 0, 0, 0x1E},
Package (){0x0019FFFF, 1, 0, 0x1F},
Package (){0x0019FFFF, 2, 0, 0x20},
Package (){0x001CFFFF, 0, 0, 0x10},
Package (){0x001CFFFF, 1, 0, 0x11},
Package (){0x001CFFFF, 2, 0, 0x12},
Package (){0x001CFFFF, 3, 0, 0x13},
Package (){0x001DFFFF, 0, 0, 0x10},
Package (){0x001DFFFF, 1, 0, 0x11},
Package (){0x001DFFFF, 2, 0, 0x12},
Package (){0x001DFFFF, 3, 0, 0x13},
Package (){0x001EFFFF, 0, 0, 0x14},
Package (){0x001EFFFF, 1, 0, 0x15},
Package (){0x001EFFFF, 2, 0, 0x16},
Package (){0x001EFFFF, 3, 0, 0x17},
Package (){0x001FFFFF, 1, 0, 0x15},
Package (){0x001FFFFF, 2, 0, 0x16},
Package (){0x001FFFFF, 3, 0, 0x17},
Package (){0x001FFFFF, 0, 0, 0x14},
Else
Package (){0x0002FFFF, 0, 0, 0x0B},
Package (){0x0004FFFF, 0, 0, 0x0A},
Package (){0x0005FFFF, 0, 0, 0x0B},
Package (){0x0006FFFF, 0, 0, 0x0B},
Package (){0x0006FFFF, 1, 0, 0x0B},
Package (){0x0007FFFF, 0, 0, 0x0B},
Package (){0x0007FFFF, 1, 0, 0x0B},
Package (){0x0007FFFF, 2, 0, 0x0B},
Package (){0x0007FFFF, 3, 0, 0x0B},
Package (){0x000DFFFF, 0, 0, 0x0A},
Package (){0x0014FFFF, 0, 0, 0x0B},
Package (){0x0014FFFF, 1, 0, 0x0B},
Package (){0x0016FFFF, 0, 0, 0x0B},
Package (){0x0016FFFF, 1, 0, 0x0B},
Package (){0x0016FFFF, 2, 0, 0x0B},
Package (){0x0016FFFF, 3, 0, 0x0B},
Package (){0x0017FFFF, 0, 0, 0x0B},
Package (){0x001CFFFF, 0, 0, 0x0B},
Package (){0x001CFFFF, 1, 0, 0x0A},
Package (){0x001CFFFF, 2, 0, 0x0B},
Package (){0x001CFFFF, 3, 0, 0x0B},
Package (){0x001DFFFF, 0, 0, 0x0B},
Package (){0x001DFFFF, 1, 0, 0x0A},
Package (){0x001DFFFF, 2, 0, 0x0B},
Package (){0x001DFFFF, 3, 0, 0x0B},
Package (){0x001EFFFF, 0, 0, 0x0B},
Package (){0x001EFFFF, 1, 0, 0x0B},
Package (){0x001EFFFF, 2, 0, 0x0B},
Package (){0x001EFFFF, 3, 0, 0x0B},
Package (){0x001FFFFF, 1, 0, 0x0B},
Package (){0x001FFFFF, 2, 0, 0x0B},
Package (){0x001FFFFF, 3, 0, 0x0B},
Package (){0x001FFFFF, 0, 0, 0x0B},
dmesg shows no GSI or PCI errors, TPM & touchpad IRQs still work
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I1e7a708183ac4170b28da9565137fa2f5088a7eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54683
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since GPIO IO-APIC IRQs are fixed in hardware (RO registers), this patch
allows cannonlake boards to dynamically assign PCI IRQs. This means not
relying on FSP defaults, which eliminates the problem of PCI IRQs
interfering with GPIO IRQs routed to the same IRQ, when both have
selected IO-APIC routing.
Also prodrive/hermes (intel/cannonlake) was the only user of
uart_acpi_write_irq(), therefore use the allocated IRQ instead of the
fixed IRQ number in that function to preserve behavior.
BUG=b:130217151
TEST=on dratini, grep 'IO-APIC' /proc/interrupts (compressed to fit)
0: 11 0 0 0 IO-APIC 2-edge timer
1: 0 661 0 0 IO-APIC 1-edge i8042
8: 0 0 0 0 IO-APIC 8-edge rtc0
9: 0 874 0 0 IO-APIC 9-fasteoi acpi
14: 0 0 1 0 IO-APIC 14-fasteoi INT34BB:00
17: 0 10633 0 0 IO-APIC 17-fasteoi mmc1
19: 0 0 0 0 IO-APIC 19-fasteoi mmc0
22: 0 0 0 0 IO-APIC 22-fasteoi i801_smbus
26: 153738 0 0 0 IO-APIC 26-fasteoi idma64.0, i2c_designwar
27: 0 8 0 0 IO-APIC 27-fasteoi idma64.1, i2c_designwar
30: 0 0 227 0 IO-APIC 30-fasteoi i2c_designware.2
33: 0 0 0 0 IO-APIC 33-fasteoi idma64.3
35: 43107 0 0 0 IO-APIC 35-fasteoi idma64.4, pxa2xx-spi.4
36: 0 0 2039 0 IO-APIC 36-fasteoi idma64.5, pxa2xx-spi.5
45: 0 0 9451 0 IO-APIC 45-edge ELAN0000:00
85: 0 0 0 0 IO-APIC 85-fasteoi chromeos-ec
93: 0 7741 0 0 IO-APIC 93-edge cr50_spi
abbreviated _PRT dump:
If (PICM)
Package () {0x0001FFFF, 0x00, 0x00, 0x10},
Package () {0x0001FFFF, 0x01, 0x00, 0x11},
Package () {0x0001FFFF, 0x02, 0x00, 0x12},
Package () {0x0002FFFF, 0x00, 0x00, 0x13},
Package () {0x0004FFFF, 0x00, 0x00, 0x14},
Package () {0x0005FFFF, 0x00, 0x00, 0x15},
Package () {0x0008FFFF, 0x00, 0x00, 0x16},
Package () {0x0012FFFF, 0x01, 0x00, 0x17},
Package () {0x0012FFFF, 0x02, 0x00, 0x10},
Package () {0x0012FFFF, 0x00, 0x00, 0x18},
Package () {0x0013FFFF, 0x00, 0x00, 0x19},
Package () {0x0014FFFF, 0x00, 0x00, 0x11}
Package () {0x0014FFFF, 0x01, 0x00, 0x12},
Package () {0x0014FFFF, 0x02, 0x00, 0x13},
Package () {0x0014FFFF, 0x03, 0x00, 0x14},
Package () {0x0015FFFF, 0x00, 0x00, 0x1A},
Package () {0x0015FFFF, 0x01, 0x00, 0x1B},
Package () {0x0015FFFF, 0x02, 0x00, 0x1C},
Package () {0x0015FFFF, 0x03, 0x00, 0x1D},
Package () {0x0016FFFF, 0x00, 0x00, 0x15},
Package () {0x0016FFFF, 0x01, 0x00, 0x16},
Package () {0x0016FFFF, 0x02, 0x00, 0x17},
Package () {0x0016FFFF, 0x03, 0x00, 0x10},
Package () {0x0017FFFF, 0x00, 0x00, 0x11},
Package () {0x0019FFFF, 0x00, 0x00, 0x1E},
Package () {0x0019FFFF, 0x01, 0x00, 0x1F},
Package () {0x0019FFFF, 0x02, 0x00, 0x20},
Package () {0x001AFFFF, 0x00, 0x00, 0x12},
Package () {0x001CFFFF, 0x00, 0x00, 0x10},
Package () {0x001CFFFF, 0x01, 0x00, 0x11},
Package () {0x001CFFFF, 0x02, 0x00, 0x12},
Package () {0x001CFFFF, 0x03, 0x00, 0x13},
Package () {0x001DFFFF, 0x00, 0x00, 0x10},
Package () {0x001DFFFF, 0x01, 0x00, 0x11},
Package () {0x001DFFFF, 0x02, 0x00, 0x12},
Package () {0x001DFFFF, 0x03, 0x00, 0x13},
Package () {0x001EFFFF, 0x00, 0x00, 0x21},
Package () {0x001EFFFF, 0x01, 0x00, 0x22},
Package () {0x001EFFFF, 0x02, 0x00, 0x23},
Package () {0x001EFFFF, 0x03, 0x00, 0x24},
Package () {0x001FFFFF, 0x01, 0x00, 0x15},
Package () {0x001FFFFF, 0x02, 0x00, 0x16},
Package () {0x001FFFFF, 0x03, 0x00, 0x17},
Package () {0x001FFFFF, 0x00, 0x00, 0x14},
Else
Package () {0x0001FFFF, 0x00, 0x00, 0x0B},
Package () {0x0001FFFF, 0x01, 0x00, 0x0A},
Package () {0x0001FFFF, 0x02, 0x00, 0x0B},
Package () {0x0002FFFF, 0x00, 0x00, 0x0B},
Package () {0x0004FFFF, 0x00, 0x00, 0x0B},
Package () {0x0005FFFF, 0x00, 0x00, 0x0B},
Package () {0x0008FFFF, 0x00, 0x00, 0x0B},
Package () {0x0012FFFF, 0x01, 0x00, 0x0B},
Package () {0x0012FFFF, 0x02, 0x00, 0x0B},
Package () {0x0014FFFF, 0x00, 0x00, 0x0A},
Package () {0x0014FFFF, 0x01, 0x00, 0x0B},
Package () {0x0014FFFF, 0x02, 0x00, 0x0B},
Package () {0x0014FFFF, 0x03, 0x00, 0x0B},
Package () {0x0016FFFF, 0x00, 0x00, 0x0B},
Package () {0x0016FFFF, 0x01, 0x00, 0x0B},
Package () {0x0016FFFF, 0x02, 0x00, 0x0B},
Package () {0x0016FFFF, 0x03, 0x00, 0x0B},
Package () {0x0017FFFF, 0x00, 0x00, 0x0A},
Package () {0x001AFFFF, 0x00, 0x00, 0x0B},
Package () {0x001CFFFF, 0x00, 0x00, 0x0B},
Package () {0x001CFFFF, 0x01, 0x00, 0x0A},
Package () {0x001CFFFF, 0x02, 0x00, 0x0B},
Package () {0x001CFFFF, 0x03, 0x00, 0x0B},
Package () {0x001DFFFF, 0x00, 0x00, 0x0B},
Package () {0x001DFFFF, 0x01, 0x00, 0x0A},
Package () {0x001DFFFF, 0x02, 0x00, 0x0B},
Package () {0x001DFFFF, 0x03, 0x00, 0x0B},
Package () {0x001FFFFF, 0x01, 0x00, 0x0B},
Package () {0x001FFFFF, 0x02, 0x00, 0x0B},
Package () {0x001FFFFF, 0x03, 0x00, 0x0B},
Package () {0x001FFFFF, 0x00, 0x00, 0x0B},
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I914ac65470635f351d6311dc9b65e8e4d8d8ecfc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55968
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
BUG=b:130217151
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: If535ad0bdd46d3315493155e64968d305aa34799
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55967
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The IRQ for a single device may be required elsewhere, therefore provide
get_pci_devfn_irq.
BUG=b:130217151, b:171580862, b:176858827
Change-Id: Ibebd821767a2698c9e60b09eeeff3bb596359728
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55826
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The results of the PCI IRQ assignments are used in several places, so
it makes for a nicer API to cache the results and provide simpler
functions for the SoCs to call.
BUG=b:130217151, b:171580862, b:176858827
Change-Id: Id79eae3f2360cd64f66e7f53e1d78a23cfe5e9df
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55825
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Because the FSP interface for PCI IRQs only includes the PCH devices,
this function is the complement to that, taking the list of irq entries,
and programming the PCI_INTERRUPT_LINE registers.
BUG=b:130217151, b:171580862, b:176858827
TEST=boot brya with patch train, verify with `lspci -vvv` that for all
the north PCI devices, their IRQ was either the one programmed by this
function, or an MSI was used.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I81cf7b25f115e41deb25767669b5466b5712b177
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55817
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add a new function to fill out the data structures necessary to generate
a _PRT table.
BUG=b:130217151, b:171580862, b:176858827
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I21a4835890ca03bff83ed0e8791441b3af54cb62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51159
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The Intel FSP provides a default set of IO-APIC IRQs for PCI devices, if
the DevIntConfigPtr UPD is not filled in. However, the FSP has a list of
rules that the input IRQ table must conform to:
1) One entry per slot/function
2) Functions using PIRQs must use IOxAPIC IRQs 16-23
3) Single-function devices must use INTA
4) Each slot must have consistent INTx<->PIRQy mappings
5) Some functions have special interrupt pin requirements
6) PCI Express RPs must be assigned in a special way (FIXED_INT_PIN)
7) Some functions require a unique IRQ number
8) PCI functions must avoid sharing an IRQ with a GPIO pad which routes
its IRQ through IO-APIC.
Since the FSP has no visibility into the actual GPIOs used on the board
when GpioOverride is selected, IRQ conflicts can occur between PCI
devices and GPIOs. This patch gives SoC code the ability to generate a
table of PCI IRQs that will meet the BWG/FSP rules and also not conflict
with GPIO IRQs.
BUG=b:130217151, b:171580862, b:176858827
TEST=Boot with patch series on volteer, verify IO-APIC IRQs in
`/proc/interrupts` match what is expected. No `GSI INT` or
`could not derive routing` messages seen in `dmesg` output.
Verified TPM, touchpad, touchscreen IRQs all function as expected.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I0c22a08ce589fa80d0bb1e637422304a3af2045c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49408
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This makes structs that contain an `enum pirq` field that is
default-initialized have the value PIRQ_INVALID
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Idb4c7d79de13de0e4b187a42e8bdb27e25e61cc1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55281
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When initializing espi early, there may be mainboard requirements to
configure the bus properly. This allows the mainboard to do that.
BUG=192100564
TEST=Build along with next patch, eSPI works on guybrush
Change-Id: Icc02877a09b8f8ed20fd1b04f3cee0509f1a85c5
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
The `soc_read_pmc_base()` function returns an `uintptr_t`, which is then
casted to a pointer type for use with `read32()` and/or `write32()`. But
since commit b324df6a540d154cc9267c0398654f9142aae052 (arch/x86: Provide
readXp/writeXp helpers in arch/mmio.h), the `read32p()` and `write32p()`
functions live in `arch/mmio.h`. These functions use the `uintptr_t type
for the address parameter instead of a pointer type, and using them with
the `soc_read_pmc_base()` function allows dropping the casts to pointer.
Change-Id: Iaf16e6f23d139e6f79360d9a29576406b7b15b07
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55840
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
|
|
This is needed for ifdtool -p to detect CPX and SKX Lewisburg PCH as IFDv2.
Change-Id: I21df9f700aedf131a38a776e76722bf918e6af84
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55746
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Make use of the retry macro intruduced in CB:55778:
helpers: Introduce retry macro
(Change-Id: I421e4dcab949616bd68b3a14231da744b9f74eeb)
BUG=none
TEST=emerge-cherry coreboot
BRANCH=none
Change-Id: Ieaec95e20e5bb54fcd145007cc46f21c8b7e26d2
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Select DISPLAY_FSP_VERSION_INFO_2 for Jasper Lake soc.
BUG=b:153038236
BRANCH=None
TEST=Verify JSLRVP build with all the patch in relation chain
and verify the version output prints no junk data observed.
couple of lines from logs are as below.
Display FSP Version Info HOB
Reference Code - CPU = 8.7.16.10
uCode Version = 0.0.0.1
Change-Id: If68b704c4304357b0046a510545fc213d7ed5887
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45907
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It looks like the 'clear_car' code does not properly fill the required
cachelines so add code to fill cachelines explicitly.
Change-Id: Id5d77295f6d24f9d2bc23f39f8772fd172ac8910
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55791
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christopher Meis <christopher.meis@9elements.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The `xdci_can_enable()` function is called earlier to configure FSP-S
UPDs. If it returned false, then the xDCI device will be disabled and
the second `xdci_can_enable()` call will never be evaluated.
Change-Id: I4bd08e3194ffccc79c8feaf8f34b2bb4077f760a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55789
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch fixes the typo introduced in commit b03cadf for renaming
FSP_S_CONFIG param name to s_cfg.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: I0a9b500e528c68033008f3f8955d6c9c9ba8a737
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
|
|
The `dev` parameter already points to the xDCI device.
Change-Id: I122cc642c86b30804dd1176f77f4e2e1ebea4aa0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55788
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Done for consistency with other Intel SoCs. This allows moving the
pattern inside a helper function.
Change-Id: If95c4b6c1602e56436150a931210692f14630694
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55787
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use the `is_devfn_enabled()` function for the sake of brevity.
Change-Id: Ic848767799e165200f26c2d5a58fbd3b72b9c240
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55786
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The CSE expects the boot firmware to send it an End-of-Post message
before loading the OS. This is a security feature, and is done to ensure
that the CSE will no longer perform certain sensitive commands that are
not intended to be exposed to the OS.
If processing the EOP message fails in any way on a ChromeOS build, (and
not already in recovery mode), recovery mode will be triggered,
otherwise the CSME BWG will be followed, which is in the following
commit.
BUG=b:191362590
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I6f667905f759cc2337daca4cc6e09694e68ab7e8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55631
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Cstate C7 is not supported in ADL, replacing this unsupported state
with C6 in the s0ix cstate table.
BUG=None
TEST=Boot device to OS.
Print supported CStates and latencies.
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com>
Change-Id: I471f71481d337e3fafa4acab7fe8a39677c8710c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55734
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Intel Apollolake does not support the bootguard MSRs 0x139 MSR_BC_PBEC
and 0x13A MSR_BOOT_GUARD_SACM_INFO.
Change-Id: Ief40028a1c85084e012a83db8080d478e407487b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
Change-Id: I3867fce29d23b647fad9845b9a5c08bb949fa354
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55783
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch updates mainboard_memory_init_params() function argument from
FSPM_UPD to FSP_M_CONFIG. Ideally mainboard_memory_init_params()
function don't need to override anything other than FSP_M_CONFIG UPDs
hence passing config block alone rather passing entire FSP-M UPD
structure.
Change-Id: I238870478a1427918abf888d71ba9c9fa80d3427
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55785
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
This patch create separate helper functions to fill-in required
FSP-S UPDs as per IP initialization categories.
This would help to increase the code readability and in future
meaningful addition of FSP-S UPDs is possible rather adding UPDs randomly.
TEST=FSP-S UPD dump shows no change without and with this code change.
Change-Id: Iba51aebc74456449e24e51e2f309f14f951464a0
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55233
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Align FSP-S UPD structure (FSP_S_CONFIG) variable name (s_cfg) as FSP-M
UPD structure variable (m_cfg).
TEST=Able to build and boot ADLRVP to ChromeOS. FSP-S UPD dump shows
no change in UPD values with this CL.
Change-Id: I795f733f5f0cc64d3a556a1cd401323b35ba5a23
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Align platform_fsp_silicon_init_params_cb() function implementation
with romstage/fsp_params.c file platform_fsp_memory_init_params_cb() as:
|- Override FSP-S Arch UPD(s) using arch_silicon_init_params().
|- Override FSP-S SoC UPDs using soc_silicon_init_params().
|- Override FSP-S Mainboard UPDs using mainboard_silicon_init_params().
TEST=FSP-S UPD dump shows no change without and with this code change.
Change-Id: I4cf0b8423fb4038a7feddd97ff585027b3012605
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55293
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Signed-off-by: Ryan Chuang <ryan.chuang@mediatek.corp-partner.google.com>
Change-Id: If2e9d8a4dcfad28c48a2b5fa7c92f70fae879e67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55749
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
In order to support Audio Co-processor (ACP) DMIC hardware runtime
detection on the platform, ACPI _WOV method is populated on the
concerned ACP device. This method returns the ACPI Integer value as 1
if ACP DMIC exists on the platform.
BUG=b:182960979
TEST=Build and boot to OS in guybrush. Ensure that the _WOV ACPI method
is populated under the scope of ACP device.
Scope (\_SB.PCI0.GP41.ACPD)
{
Method (_WOV, 0, NotSerialized)
{
Return (One)
}
}
Change-Id: Ide84f45f5ea2ae42d5efe71ac6d1595886157045
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55029
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
If the NO_EARLY_BOOTBLOCK_POSTCODES config option is enabled, configure
eSPI as early as possible in the x86 boot sequence.
We found that there are situations that can cause the system to hang if
there are any port80h postcodes sent out before eSPI is initialized.
BUG=b:191370340
TEST=Build & Boot with and without NO_EARLY_BOOTBLOCK_POSTCODES enabled.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I0badb1c529e96ee4f81134287db53ce32473de6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55732
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The original reason the BERT table was moved out of CBMEM was because
the OS was not able to access the region. This happened because the
CBMEM region was marked as type 16 in the e820 table. The OS isn't aware
of this type, so it prevents any drivers from accessing it. Depthcharge
now correctly labels the CBMEM region as reserved in the e820 table so
we can move the BERT table into CBMEM.
TEST=BERT ACPI table generation still works on AMD/Mandolin with SeaBIOS
as payload and BERT region inside CBMEM is inside a BIOS-e820 reserved
range. BERT generation also works on Zork with depthcharge.
Link: https://crrev.com/c/2939677
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie640e91c19ae5f9b275cc333284b4be34211fbf6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
For X2APIC mode, replicate the APIC NMI entry flags and
intention to address all the logical processors.
Change-Id: I9c0537a3efba942329f80d7cfdbd910b8958516f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55182
Reviewed-by: Lance Zhao
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
1. Replace pcidev_path_on_root() and is_dev_enabled() functions
combination with is_devfn_enabled() while enabling Thermal config.
2. Remove unused local variable of device structure type (struct device *).
Change-Id: Icc2a44d6d3f1a78bf47354049dd9e2a0ed2282ba
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55728
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I5e10e5d0b80986e1e73573a86a957985840fe0b3
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55727
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I64ab77bc49d93aca1da0126d849e69ff75b182a3
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55726
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I8ca0813e18da0f95eb9293b6d0bbdf933a1e7039
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55725
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I568cd39792eba1bbace4901e96d708d80f73c60a
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55724
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I038e43deead70d598cf26f320dd9993f17591b88
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55723
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I0e400ded7ba268a5f289b0ac568598e0dad1899a
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55722
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
1. Replace all pcidev_path_on_root() and is_dev_enabled() functions
combination with is_devfn_enabled().
2. Remove unused local variable of device structure type
(struct device *).
3. Replace pcidev_path_on_root() and dev->enabled check with
is_devfn_enabled() call.
4. Leave SATA, eMMC controller FSP UPDs at default state if
controller is not enabled and FSP UPDs are set to disable.
TEST=Able to build and boot without any regression seen on ICLRVP.
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: Id6861af3b5d1ce4f44b6d2109301bd4f5857f324
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55721
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Add DPM_FOUR_CHANNEL option for 4 channel configuration for DPM.
Publicize reset_dpm() as dpm_reset() for external reference.
Signed-off-by: Ryan Chuang <ryan.chuang@mediatek.corp-partner.google.com>
Change-Id: If6e0d5c4d16a7ddd69c4a427488f8899870db327
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55719
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Signed-off-by: Ryan Chuang <ryan.chuang@mediatek.corp-partner.google.com>
Change-Id: I51e8ebf5a75ac629bed51665e12bafa740b4b81d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55711
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Signed-off-by: Andrew SH Cheng <andrew-sh.cheng@mediatek.com>
Change-Id: Ieaf234f35f2b7d440bdf1e6ec4c455af7b311623
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55710
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Our existing native function gpio configuration macro (PAD_NF) only sets
the pull. For PCIe reset, we now need to be able to set it to its
native function (PCIE_RST_L), and drive it low, then high.
BUG=b:182805349
TEST=Configure GPIO, see correct behavior.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I636371517c99f94f76834abc4575795d51aa0368
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55652
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Commit 54b03569c moved a call to cse_trigger_recovery () around, and
commit 09635f418 renamed the function, but was tested before the first
commit was submitted, thus breaking the tree. Fix it.
Change-Id: If21ea0c1ebf9ce85c59ee25ec7f879abde2e3259
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55766
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This function could be applicable in situations other than just for the
CSE Lite SKU, therefore move this from cse_lite.c to cse.c
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ibc541f2e30ef06856da10f1f1219930dff493afa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55673
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
One of the reason FSP-T support had to be kept in place was for
Intel Bootguard. This now works with native CAR code, so there is no
reason to keep FSP-T as an option for these platforms.
APL did not even build with FSP_CAR and finding FSP-T using walkcbfs
was only recently fixed using FMAP, so there can be no doubt that this
option was never used with coreboot master.
Change-Id: I0d5844b5a6fd291a13e5f467f4fc682b17eafa63
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Bootguard sets up CAR/NEM on its own so the only thing needed is to
find free MTRRs for our own CAR region and clear that area to fill in
cache lines.
TESTED on prodrive/hermes with bootguard enabled.
Change-Id: Ifac5267f8f4b820a61519fb4a497e2ce7075cc40
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Add a macro to clear CAR which is replicated 3 times in this code.
TEST: with BUILD_TIMELESS=1 the resulting binary is identical.
Change-Id: Iec28e3f393c4fe222bfb0d5358f815691ec199ae
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This adds a macro to find an available MTRR(s) to set up CAR.
This added complexity is not required on bootpaths without bootguard
but with bootguard MTRR's have already been set up by the ACM so
we need to figure out at runtime which ones are available.
Change-Id: I7d5442c75464cfb2b3611c63a472c8ee521c014d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
The patch moves CSE Lite RW status check out of CSE RW update logic as
the RW sanity check has to be done irrespective of CSE RW update logic
is enabled or not. If coreboot detects CSE Lite RW status is not good,
the coreboot triggers recovery.
TEST=Verified boot on Brya
Signed-off-by: Sridahr Siricilla <sridhar.siricilla@intel.com>
Change-Id: I582b6cf24f8894c80ab461ca21f7c6e8caa738bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55619
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Pass the info if the non-graphics HD audio controller device is enabled
or disabled in the board's devicetree via a UPD to the FSP so that it
knows if it should enable or disable the corresponding device.
TEST=When adding "device ref hda on end" to the devicetree of
amd/majolica the non-graphics HD Audio controller shows up in lspci and
when that line isn't added the PCIe device doesn't show up.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9f5e164d308906bfc788e5c2674c13c7b2ebf471
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Currently the FSP only has one switch to disable both AHCI controllers.
If at least one of the two AHCI controller devices is enabled in the
board's devicetree, set the SATA enable UPD to 1 and otherwise set it to
0. Setting the UPD value to 0 when both AHCI controllers are disabled
saves around 60ms in boot time.
BUG=b:191385289
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I84e7c8bf2ab08c8254271ddfefd2e4e7d8c2e87b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55669
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Matt Papageorge <matthewpapa07@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:15.1: enabled 0`.
Change-Id: I449beae59d2f578c027d8110c03fa79f516c3fe9
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Tested on HP 280 G2, SMMSTORE v1 and v2 still work.
Other tests:
- If one does not set BIOS_CONTROL bit WPD, SMMSTORE breaks.
- If one does not write the magic MSR `or 1`, SMMSTORE breaks.
Change-Id: Ia90c0e3f8ccf895bfb6d46ffe26750393dab95fb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51796
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
On platforms where the boot media can be updated externally, e.g.
using a BMC, add the possibility to enable writes in SMM only. This
allows to protect the BIOS region even without the use of vboot, but
keeps SMMSTORE working for use in payloads. Note that this breaks
flashconsole, since the flash becomes read-only.
Tested on Asrock B85M Pro4 and HP 280 G2, SMM BIOS write protection
works as expected, and SMMSTORE can still be used.
Change-Id: I157db885b5f1d0f74009ede6fb2342b20d9429fa
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40830
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
This decodes and logs the CBnT status and error registers.
Change-Id: I8b57132bedbd944b9861ab0e2e0d14723cb61635
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54093
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
List of changes:
1. Add new GFx ID 0x46B3 into device/pci_ids.h
2. Update new GFx ID into common graphics.c
3. Add new GFx ID description into report_platform.c
TEST=Build and boot brya
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Change-Id: I4343c7343875eb40c2955f6f4dd98d6446852dc0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55662
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
|
|
Elkhart Lake provides a feature called "In-Band ECC" which uses a piece
of system DRAM to store the ECC information in. There are a few
parameters in FSP-M to set this feature up as needed.
This patch adds code to expose these parameters to the devicetree so
that they can be configured on mainboard level as needed.
Change-Id: I7a4953d7b35277de01daff04211450e3d1bd8103
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55668
Reviewed-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
CSE error codes may be applicable to move than just CSE Lite SKU errors,
therefore move this enum to the intelblocks/cse.h file so that it can be
used in other CSE-related code. While copying, remove `LITE_SKU` from a few
of the enum values that are not necessarily CSE Lite SKU-specific.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I0351587c67ce12f781c536998ca18a6a804d080a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55672
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This commit adds a method called `mainboard_smi_finalize` which provides
a mechanism for a mainboard to execute some code as part of the finalize
method in the SMM stage before SoC does its finalization.
BUG=b:191189275
BRANCH=None
TEST=Implement `mainboard_smi_finalize` on lalala and verify that the
code executes in SMM.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: If1ee63431e3c2a5831a4656c3a361229acff3f42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55649
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
This commit simply adds the offset for the PADCFGLOCK register for the
Intel Jasper Lake platform. This enables pads to be locked.
BUG=b:191189275
BRANCH=None
TEST=Enable pad locking on lalala by calling `gpio_lock_pad` and verify
that the pad configuration is locked and cannot be manipulated from the
OS.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: Iccfe536b4a881f081f22bcc258a375caad3ffcb3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55648
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This commit adds a method for locking a GPIO pad configuration and its
TX state. When the configuration is locked, the following registers
become Read-Only and software writes to these registers have no effect.
Pad Configuration registers
GPI_NMI_EN
GPI_SMI_EN
GPI_GPE_EN
Note that this is only effective if the pad is owned by the host (set in
the PAD_OWN register).
Intel platforms that wish to leverage this function need to define the
PADCFGLOCK offset for their platform.
BUG=b:191189275
BRANCH=None
TEST=With some other code, call gpio_lock_pad() against a pad and verify
that the pad configuration is locked and the state of the pad cannot be
changed from the OS.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: Id3c0da2f6942099c0289ca1e33a33c176f49d380
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55557
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Ports are enabled according to devicetree.
BUG=none
TEST=Boot device, TBT should be functional
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com>
Change-Id: I57e8eb13484014c17d24ad564643f0d03d11bc58
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Per the Intel External Design Specification (doc #618876), the opcode
for GPIO_LOCK_UNLOCK is 0x13. This commit fixes a bug where the opcode
was defined as 13 decimal instead of hexadecimal. Additionally, it
fixes another issue where the `pcr_execute_sideband_msg()` function
doesn't actually write the data when this opcode is selected.
BUG=b:191189275
BRANCH=None
TEST=With additional code that uses this opcode, verify that the lock
functionality works by locking a pad in firmware and attempting to
modify the configuration of the pad from the OS.
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: Ie14fff595474cdfd647c2b36f1eeb5e018f67375
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55556
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Using existing defines instead of magic values improves readability of
the code. Also add comments to the MADT IRQ overrides to make it clearer
what those actually do.
TEST=Timeless build results in identical binary for amd/gardenia
(Stoneyridge), amd/mandolin (Picasso) and amd/majolica (Cezanne)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I224ffbe8eb65bcdd5fc70c0ff8b15d55b3f6be01
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55613
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add mt6691 buck control for DRAM to run fast calibration test.
It is needed to get and set voltage during testing.
Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Change-Id: I4fb9f7245d44383a6a3a0cf8d00f7f503cbdeb06
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55575
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
BUG=b:189985956
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Change-Id: I37326ad053295aa4944c8291e4e7a7d69c8f3f63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55573
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch fixes the storage size to reflect the proper bits instead
of bytes. It was a bug in the initial HEST patch
(https://review.coreboot.org/c/coreboot/+/52090), and commit ID d4db36e672644ac7f528d12c5ce3539725456085 . Also fixed the
comments to properly reflect the range being used.
Change-Id: I9e968bb09f1c9cd805ff1d0849551b9c2ce2e2b6
Signed-off-by: Rocky Phagura <rphagura@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55393
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add FSP_ARRAY_LOAD macro for checking and loading array type
configs into array type UPDs to increase readability.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: Ia20cabcaf9724882c68633eb9b510230e993768c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
Use FSP_ARRAY_LOAD macro for checking and loading array type
configs into array type UPDs to increase readability.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: I2562977e55f8909038697f7e19b82ec6b5e47fae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
Change-Id: Ia91dbda44f60388324cf58dbccdbd2172dbff21d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55561
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Factoring out those defines brings the Stoneyridge SoC code a bit more
in line with the Cezanne and Picasso SoC code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifba7f13cc926ac28376233aa0bf317164ca9bbd6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55588
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
"corredsponding" --> "corresponding"
Change-Id: I0b0e5d461de29583c269896911167f8a44d84c2a
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55555
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since the default state of the MMIO UART devices in the chipset
devicetree is off, the mainboard devicetree entries that disable MMIO
UART devices are removed.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I913a587802020ce4e182b48632cdde1104c2a6e6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55545
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
pmc_set_power_failure_state() is usually called twice, once upon boot
(with `target_on == true`) and once from SMM when the system is shut
down (with `target_on == false`). Assuming settings didn't change
between these calls, there is only one case where we actually need
to write the register value: when updating the state for the
MAINBOARD_POWER_STATE_PREVIOUS feature.
This suits us well as we want to avoid unnecessary writes so we
don't clobber the value set upon boot from within SMM. Due to
inaccessible option backends, SMM might not know the current
option state.
The assumption above, that the option value didn't change, may not
be true if the user changed the option on purpose. In the future,
one would have to reboot the machine for option changes to take
effect. However, this doesn't seem to make a huge difference: One
already needed a controlled shutdown for the update to take effect
before. A reboot doesn't seem much more expensive.
Change-Id: I58dd74b8b073f4f07db090bf7fddb14b5df8239a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55539
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch create separate helper functions to fill-in required
FSP-M UPDs as per IP initialization categories.
This would help to increase the code readability and in future
meaningful addition of FSP-M UPDs is possible rather adding UPDs randomly.
TEST=FSP-M UPD dump shows no change without and with this code change.
Change-Id: I5f23292fd1bd44d0cd55fbefd490b090ccd48365
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55225
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Updating the APOB takes a considerable amount of time. I decided to be
granular and split out the operations so we know when we read vs read +
erase + write.
BUG=b:179092979
TEST=Boot guybrush and dump timestamps
3:after RAM initialization 3,025,425 (44)
920:starting APOB read 3,025,430 (5)
921:starting APOB erase 3,025,478 (48)
922:starting APOB write 3,027,727 (2,249)
923:finished APOB 3,210,965 (183,238)
4:end of romstage 3,210,971 (6)
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I08e371873112e38f623f452af0eb946f5471c399
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
APIC Serial Bus pins were removed with ICH5 already, so a choice
'irq_on_fsb = 0' would not take effect. The related register BOOT_CONFIG
0x3 is also not documented since ICH5.
For emulation/qemu-q35 with ICH9 the choice INTERRUPT_ON_APIC_BUS was
wrong and ignored as BOOT_CONFIG register emulation was never implemented.
For ICH4 and earlier, the choice to use FSB can be made based on the
installed CPU model but this is now just hardwired to match P4 CPUs of
aopen/dxplplusu.
For sb/intel/i82371eb register BOOT_CONFIG 0x3 is also not defined
and the only possible operation mode there is APIC Serial Bus, which
requires no configuration.
Change-Id: Id433e0e67cb83b44a3041250481f307b2ed1ad18
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55257
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6deb2a4c632d39112dcce71f076742a1b62ee89b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I06102f4fcc3bf9de332c71a52c632241b95cde19
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
In acpi_soc_get_bert_region after the bert_errors_region call is was
checked if the region parameter is NULL after the call; since region is
a parameter of acpi_soc_get_bert_region, it's non-NULL. What we should
be checking here is if region points to a non-NULL pointer.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reported-by: Coverity (CID:1457506)
Change-Id: I0523504d65725ab2d2df4db28a5dedd90697b917
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie97bd6ad076f0ce35fc997d954a003a1252184e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55536
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7edae2142120dec9e11ef823b561401b7e0bc208
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Even though the code is currently commented out, replace the magic
numbers with the existing defines.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id0dbbadf71f2e5a4d23ee998e2aa0a8b67205845
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55534
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
