Prevent the FSP from writing its default SVID SDID values of 8086:7270
for internal devices as this locks most of the registers. Allows the
subsystemid values set in devicetree to be used.
A description of this SSID table override behavior, along with example
code, is provided in the TigerLake FSP Integration Guide, section
15.178 ("SI_CONFIG Struct Reference").
The xHCI and HDA devices have RW/L registers rather than RW/O registers.
They can be written to multiple times but cannot be modified after
being locked, which happens during FspSiliconInit. Because coreboot
populates subsystem IDs after SiliconInit, these devices specifically
must be written beforehand or will otherwise be locked with their
default values of 0:0.
TGL also introduces parameters for customizing the default SVID:SSID.
These must be set or it will still use the FSP defaults.
Tested by checking lspci output on System76 darp7 (TGL-U).
References:
- b1fa231d76 ("soc/intel/cnl: Allow setting PCIe subsystem IDs after FSP-S")
- TigerLake FSP Integration Guide
- Intel Document #631120-001
Change-Id: I391b9fd0dc9dda925c1c8fe52bff153fe044d73e
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Make use of deterministic cache helper functions from Alder Lake
SoC code to print useful information during boot as below:
Cache: Level 3: Associativity = 12 Partitions = 1 Line Size=64 Sets=16384
Cache size = 12 MiB
Change-Id: I30a56266015d69abccb885b3f230689488ee0360
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55654
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch creates helper function that internally detects the CPU
type (AMD or Intel) and pick the leaf to send CPUID instruction with
different cache level to retrieve deterministic cache parameters.
Lists of helper functions generated as part of this CL :
1. cpu_check_deterministic_cache_cpuid_supported => if CPU has support
for deterministic cache using CPUID instruction.
2. cpu_get_cache_ways_assoc_info => Get cache ways for associativity.
3. cpu_get_cache_type => Get cache type.
4. cpu_get_cache_level => Get cache level.
5. cpu_get_cache_phy_partition_info => Get cache physical partitions.
6. cpu_get_cache_line_size => Get cache line size.
7. cpu_get_cache_sets => Get cache number of sets.
8. cpu_is_cache_full_assoc => Check if cache is fully associative.
9. cpu_get_max_cache_share => Cores are sharing this cache.
10. get_cache_size => Calculate the cache size.
11. fill_cpu_cache_info => Fill cpu_cache_info structure.
Change-Id: I0dd701fb47460092448b64c7fa2162f762bf3095
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55965
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
TSR2 thermal sensor doesn't define in cret. Fix DPTF passive and
critical policies for getting negative temperatures in OS.
BUG=b:195868075
BRANCH=dedede
TEST=Build and boot to OS in cret. Ensure that the DPTF entries look
correct in both static.c and SSDT tables i.e. passive and critical
policies for applicable devices only are present.
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Change-Id: I849662cbb3adc8e528d65af2c90e7c8e4880d607
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56870
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
For mainboard devicetree, it always have definition for enabling
cpu_cluster 0 which is required for all the variants.
Since it is SoC related settings, it's better to keep in chipset.cb
as a common setting for all the mainboards using the same SoC.
BUG=None
BRANCH=None
TEST=Change has no functional impact on the brya board.
Change-Id: I8f7c3184b62f8d84ca4605fb9f2a1cc569f1f964
Signed-off-by: MAULIK V VAGHELA <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56853
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot always assumes that BSP APIC ID will be 0 and core enumeration
logic will look for lapic id from the mainboard.
As per Intel 64 and IA-32 Architectures Software Developer’s Manual
Volume 3: 8.4.1 BSP and AP Processors, this assumption might
not hold true and we may have any other core as BSP. To handle this,
we need to remove hardcoding of APIC ID 0 from mainboard.
BUG=None
BRANCH=None
TEST=Check if there is no functional impact on the board.
Change-Id: Ibc60494b0032a3139c1e6c79251fb2da750c8de8
Signed-off-by: MAULIK V VAGHELA <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56852
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Keep the clock source for PCIe slots as always on. Also turn off the
unused (0/1/5/6) clock sources. Currently bilby only uses clock sources
2, 3 and 4, out of which clock source 3 and 4 are routed for PCIe
external slot. And clock source 2 is routed for M.2 PCIe slot.
TEST:Verify end devices enumerate on D:F 1.1/1.2 RPs over warm reboot.
Signed-off-by: Aamir Bohra <aamirbohra@gmail.com>
Change-Id: Ida485b06279b0a8659c8d00873c3d6023d1e542f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56826
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch extends mocks functionality to allowing wrapping of mocked
functions. Original function name will be prefixed with `__real_`.
Example:
- Mocked function: cbfs_lookup()
- New function name: __real_cbfs_lookup()
- Mock name: cbfs_lookup()
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I7cd0d66a17029955cbf75c8b155a7ebb7f5513aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56719
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set power limits for brya0 variant board based on CPU SKUs
which is detectable at runtime.
BUG=b:194745919
BRANCH=None
TEST=Build FW and test on brya0 variant board with below messages,
On brya (282):
Overriding DPTF power limits PL1 (3000, 15000) PL2 (39000, 39000)
On brya (482):
Overriding DPTF power limits PL1 (4000, 28000) PL2 (43000, 43000)
Change-Id: I4c07319af756b10e5d22f320e97ff956fb4a14c6
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56622
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to support wake from D3cold, most devices require extra
circuitry and possibly out-of-band communications to the host.
Therefore, assume that most UARTs that do have wake capabilities support
wake from D3hot rather than D3cold.
BUG=b:187228954
TEST=compile
Change-Id: I24d6d0e81d980fc9c910d8f47f557c88990b6400
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to support wake from D3cold, most devices require extra
circuitry and possibly out-of-band communications to the host.
Therefore, assume that most SPI peripherals that do have wake
capabilities support wake from D3hot rather than D3cold.
This also allows coreboot to expose a power resource to perform power
sequencing for a SPI peripheral that is intended to retain power in
S3/S0ix.
If support for a device with d3cold wake support is needed, it could be
added in later as an option.
BUG=b:187228954
TEST=compile
Change-Id: I1d739b49c1a43007eb0199fe39b3b7d7375e6577
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add dynamic power limits selection mechanism for brya board based on
CPU SKUs which is detectable at runtime.
BUG=b:194745919
BRANCH=None
TEST=Build FW and test on brya with below messages,
On brya (282):
Overriding DPTF power limits PL1 (3000, 15000) PL2 (39000, 39000)
On brya (482):
Overriding DPTF power limits PL1 (4000, 28000) PL2 (43000, 43000)
Change-Id: I86619516adeec13642f02ba7faf9fc4945ad774e
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
coreboot always assumes that BSP APIC ID will be 0 and core enumeration
logic will look for lapic id from the mainboard.
As per Intel 64 and IA-32 Architectures Software Developer’s Manual
Volume 3: 8.4.1 BSP and AP Processors, this assumption might
not hold true and we may have any other core as BSP. To handle this,
we need to remove hardcoding of APIC ID 0 from mainboard.
BUG=None
BRANCH=None
TEST=Check if there is no functional impact on the board.
Change-Id: I726d70b4ffc35a28a654abbd20c866f1410e1aee
Signed-off-by: MAULIK V VAGHELA <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
coreboot always assumes that BSP APIC ID will always be 0 but as
per Intel 64 and IA-32 Architectures Software Developer’s Manual
Volume 3: 8.4.1 BSP and AP Processors, it says that BSP can
be any processor whose index/APIC ID might not be 0.
To handle this situation, init_cpu call is required to modify to
handle dynamic detection of APIC ID from BSP instead of hardcoding
always through devicetree. Function has been updated to create
a new node with actual BSP APIC ID when devicetree doesn't contain
APIC ID defined. In case APID ID is defined, function will use a
node with the APIC ID defined in devicetree.
Changes also requires to remove "lapic 0" hardcoding from devicetree
to allow code to fill BSP APIC ID dynamically. Otherwise coreboot
will create an extra node for CPU with APIC ID 0 and it'll show as a
extra node in kernel. This will cause kernel to report wrong (extra)
core count information then actually present.
BUG=None
BRANCH=None
TEST=Boot the JSL system and observe there is no functional impacts.
Without this CL kernel core count in `lscpu` = 3
With this CL, kernel core count is corrected to 2.
Change-Id: Ib14a5c31b3afb0d773284c684bd1994a78b94445
Signed-off-by: MAULIK V VAGHELA <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
