Use a variable to store if the FSP should be responsible for the chipset
lockdown and use it for setting related configuration options. Thus, get
rid of that if-clause and adjust comments.
This changes behavior since now related options are always set,
depending on if coreboot or the FSP should be responsible for the
chipset lockdown. This ensures a defined state independent from the
default configuration of the FSP.
Change-Id: I0c43a11a40a474de4af22aa5506b1d387809bda2
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52843
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Use a variable to store if the FSP should be responsible for the chipset
lockdown and use it for setting related configuration options. Thus, get
rid of that if-else-clause and adjust comments.
Change-Id: I202c212ec8e9ac63f5512c2e74040c23e1562b9a
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52842
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
This patch updates the VccIn Aux Imon IccMax for ADL-P to SOC SKU
specific values from the FSP default value 160.
* ADL-P 682(45W) = 137.
* ADL-P 482(28W) = 128.
* ADL-P 282(15W) = 128.
These config values are generated iPDG application with ADL-P platform
package tool and supports 15W/28W/45W SKU's.
RDC Kit ID for the iPDG tools,
* Intel(R) Platform Design Studio Installer: 610905.
* Intel(R) Platform Design Studio - Platform ADL-P (Partial): 627345.
* Intel(R) Platform Design Studio - Platform ADL-P (Full): 630261.
BUG=b:195033556
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: I6c159035cba781d3661a0a0cef16f9591a583912
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56176
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Originally we use rank_density=0 to mean disable the channel, but actually
rank_density=0 means 4Gb density in the FSP.
This patch changes the LPDDR4 enum values to the real density number and
adds a switch statement to mapping the density define in the FSP.
BUG=b:178665760
BRANCH=NONE
TEST=build fw and flash to the dut, the dut can boot up successfully.
Change-Id: I36dba2cef130211e7aea9e2a4f82c5db78f82a83
Signed-off-by: Jamie Chen <jamie.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56805
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
System76 uses several custom CMOS values downstream. Reduce our diff by
providing a generic layout with the defaults:
boot_option=Fallback
debug_level=Debug
power_on_after_fail=Enable
Tested on galp3-c, gaze15, oryp5, oryp6. All boards boot multiple times
with USE_OPTION_TABLE selected.
Change-Id: Ie57b0e5713bba8ad46e1a4123a3ddd43e0eea964
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
