| Age | Commit message (Collapse) | Author |
|---|
|
This change only enables the IOMMU device. We still require the IVRS
table to take advantage of the IOMMU. This will happen when the picasso
IVRS code is moved into common.
BUG=b:190515051
TEST=lspci shows IOMMU device
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 1631
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I5c7cae3d25af5a45d48658ffa948a2856adc4346
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This patch increases PRERAM_CBMEM_CONSOLE_SIZE from 5KB to 8KB to fix
cbmem buffer overflow issue.
Test=Boot ADLRVP and check cbmem -c | grep 'CBFS: Found'
lists all stages.
Change-Id: I38fd74c2edd71ce9f6c08db9dacb18e553745877
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
|
The Majolica UEFI ACPI tables have this listed as shared. It's already a
level interrupt, so no reason it shouldn't be shared.
This change makes it so Windows can correctly initialize the GPIO
controller.
BUG=b:186212501
TEST=Boot guybrush to windows and see GPIO controller functional. Also
boot guybrush to windows and verify GPIO controller still works.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I48c6d548a2a8d67599f25e37eeafc90764d9e2d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Previously, irq_program_non_pch() was only programming the IRQ line, but
the pin is required as well.
BUG=b:176858827
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I2a2823c183a3495721a912de285cddb4a9444c55
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56174
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There were some devices missing from pci_devs.h:
1) GNA
2) I2C6 and I2C7
3) UART3, UART4, UART5, UART6
4) UFS
5) GSPI4, GSPI5, GSPI6
BUG=b:176858827
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I2b9f8cceb4bd0c77fc43ef2e48190dd736a84ad8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56172
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ib74ff1d585f8ef54960e6a1eafd5a280907f8675
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56180
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch configures max Pkg C-state to Auto which limits the max
C-state to deep C-state
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: Iab92eaadad3f17ed8dddc4f383d6eeaab8c9ea6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55706
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Update IO driving setting for pmif spi.
Signed-off-by: James Lo <james.lo@mediatek.corp-partner.google.com>
Change-Id: I48268cda8845a591592d8ca828ffe492e6dfe0ce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56166
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Coverity detects dereference pointers req and res that are NULL when
calling the pmc_send_ipc_cmd function. This change prevents NULL
pointers dereference.
Found-by: Coverity CID 1458077, 1458078
TEST=None
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I151157e7a9a90c43075f431933ac44f29fd25127
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
The dramc_param.h defines the header version,
structure and APIs for the DRAM calibration parameters
stored on the flash, and should be platform independent.
Signed-off-by: Ryan Chuang <ryan.chuang@mediatek.corp-partner.google.com>
Change-Id: Ib8a6ea1b6cf1538854890b653d5d9a934f7f687e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56098
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Enable DCM settings on the MT8195 platform.
DCM means dynamic clock management, and it can dynamically
slow down or gate clocks during CPU or bus idle.
Change-Id: Ib431a0334c157d440d6e89dcb154241d980d97ce
Signed-off-by: Garmin Chang <garmin.chang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Allow hot plug devices to subscribe to IOMMU services. Currently the
IOMMU end range is limited to device B:0 D:1f F:6. This prevents the
devices on bus 1 and higher to subscribe to IOMMU services. As per AMD
IOMMU spec v3 section 5.2.2.1 all possible device IDs must be defined,
whether the device ID is actually populated or not. Device entries are
used to report ranges when hot-plug and SR-IOV devices are possible.
With this change the hot plug devices can now bind to IOMMU services
(as tested on kernel v5.4), and below errors are not seen in dmesg.
AMD-Vi: Event logged [IO_PAGE_FAULT device=04:00.3 domain=0x0000]
AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x0000]
AMD-Vi: Event logged [IO_PAGE_FAULT device=04:00.4 domain=0x0000]
TEST= Verify dGPU can enumerate on hotplug. No IO page fault errors seen.
The hot plug devices can successfully bind to IOMMU services in
kernel.
Signed-off-by: Aamir Bohra <aamirbohra@gmail.com>
Change-Id: I256c0f8032662674a4d75746de49c250e341c579
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55816
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-by: ritul guru <ritul.bits@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Tested on Intel Sandybridge x86_64 and x86_32.
Change-Id: I152483d24af0512c0ee4fbbe8931b7312e487ac6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This patch adds the supports to update the optimal FIVR
configurations for external voltage rails via devicetree.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: Icf6c74bda5a167abf63938ebed6affc6b31c76f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55702
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Correct Bus and Device for THC0 and THC1
Signed-off-by: Varshit B Pandya <varshit.b.pandya@intel.com>
Change-Id: I41858ea156c8258ea0e7be9e2f67fb0e24144c80
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
|
|
BUG=none
TEST=Boot with CONSOLE_LOGLEVEL_3 and no longer see the message printed.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I0bdb92f547ceb8be624521211f4a3b94a91dae22
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55972
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
We are currently reading the uCode for each CPU. This is unnecessary
since the uCode never changes.
BUG=b:177909625
TEST=Boot guybrush and see "microcode: being updated to patch id" for
each CPU. I no longer see CBFS access for each CPU. This drops device
initialization time by 32 ms.
Also boot Ezkinil and verify microcode was also updated.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I98b9d4ce8290a1f08063176809e903e671663208
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Start using the custom boot device.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4ae7272677f563e8827ba154fe5177c8c01155c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This is a copy of mmap_boot.c and mem_rdev_ro_ops. I split it up so it
was easier to review.
The next patches will add support for the SPI DMA controller. This will
provide a minor speed up vs using mmap reads. It will also provide the
facilities to perform asynchronous SPI loading.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Id26e2a69601d0f31e256d0010008904a447c8e21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
In order to disable X86_TOP4G_BOOTMEDIA_MAP it requires the definition
to be overridden. This makes it a little less ergonomic to use. Instead
introduce the inverse option that can be selected. I chose to leave
X86_TOP4G_BOOTMEDIA_MAP since it keeps the Makefiles simple.
BUG=b:179699789
TEST=none
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I65bbc118bde88687a7d7749c87acf1cbdc56a269
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Introduce the `ARCH_ALL_STAGES_X86` Kconfig symbol to automatically
select the per-stage arch options. Subsequent commits will leverage
this to allow choosing between 32-bit and 64-bit coreboot where all
stages are x86. AMD Picasso and AMD Cezanne are the only exceptions
to this rule: they disable `ARCH_ALL_STAGES_X86` and explicitly set
the per-stage arch options accordingly.
Change-Id: Ia2ddbae8c0dfb5301352d725032f6ebd370428c9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
BUG=b:191362590
TEST=on brya, cbmem -t:
942:before sending EOP to ME 2,628,446 (5,879)
943:after sending EOP to ME 2,631,177 (2,730)
Change-Id: I0376610c5cbae7df1bf1a927b3bc99b1022de4cb
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
|
|
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>
|
