Meteor Lake TME bits [42-45] are reserved regardless of if the part
supports TME or not.
On a device with TME fused off, we noticed some reboot hangs which
have been narrowed down to internal IP routing issues when the IA
accesses the Input Output Manager (IOM) which is mapped at
0x3fff0aa0000 (0x3ff upper 32 bits).
It turns out since TME is fused off, coreboot uses the full physical
address size reported by CPUID MAXPHYADDR (46 bits). Therefore, it
allocates thunderbolt memory range on 46 bits (0x3fff upper 32 bits).
Since 4 of these bits are actually reserved, it seems that this
address range is "stripped down" to 42 bits (=> 0x3ff upper 32 bits)
resulting in potential conflict with other devices such as IOM.
BUG=b:288978352
TEST=No reboot issue on rex with TME fused off
Change-Id: I96ba23ab304257003c0413243d3ac8129ce31743
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78452
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According the Intel Software Developer Manual,
CPUID.80000008H:EAX[15:8] reports the physical-address width supported
by the processor. Unfortunately, it does not necessarily reflect the
physical-address space the system can actulally use as some of those
bits can be reserved for internal hardware use.
It is critical for coreboot to know the actual physical address size.
Overestimating this size can lead to device resource overlaps due to
the hardware ignoring upper reserved bits. On rex for instance, it
creates some reboot hangs due to an overlap between thunderbolt and
Input Output Manager (IOM) address space.
As some SoCs, such as Meteor Lake, have physical address reserved bits
which cannot be probed at runtime, this commit introduces
`CPU_INTEL_COMMON_RESERVED_PHYS_ADDR_BITS' Kconfig to set the number
of physical address reserved bits at compilation time for those SoCs.
A runtime detection by hardware probing will be attempted if the value
is 0 (default).
BUG=b:288978352
Change-Id: I8748fa3e5bdfd339e973d562c5a201d5616f813e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78451
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This reverts commit 55b7dee278.
Reason for revert: accidentally submitted out of order / breaks tree
Change-Id: Ic15d0e3688cd54f7d678998341263e7bd30e75f2
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78525
Tested-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This reverts commit bb5fa6419d.
Reason for revert: accidentally committed out of order; reverting to
unbreak tree
Change-Id: I36aa1fd3a0befe49b7e9e34198676f16fb08cf73
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78524
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: Martin L Roth <gaumless@gmail.com>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `RAMSTAGE_CBFS_CACHE_SIZE' Kconfig to
set a ramstage CBFS cache size. A cache size of zero disables the
CBFS cache feature. The default size is 16 KB which seems a
reasonable minimal value large enough to satisfy basic needs such as
the decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
To support S3 suspend/resume use-case, the CBFS cache memory cannot be
released to the operating system. There are two options to meet this
requirement:
1. Define a static CBFS cache buffer (located in the .bss section)
2. Create a new CBMEM entry
Option #2 seems more powerful but considering that:
1. The CBFS cache is actually not a cache but just a scratch pad
designed to be isolated between stages
2. postcar is a very short stage not really needing CBFS cache
3. The static initialization of the `cbfs_cache' global
variable (cf. src/lib/cbfs.c) offers a simple and robust design
=> It is simpler to use a static buffer and limit the support to
ramstage.
Since some AMD SoCs (cf. `SOC_AMD_COMMON_BLOCK_NONCAR' Kconfig) define
a `_cbfs_cache' region, an extra `POSTRAM_CBFS_CACHE_IN_BSS' Kconfig
must be set to enable the use of a static buffer as the CBFS cache
scratchpad.
TEST=Decompression of vbt.bin in ramstage on rex using cbfs_map()
Change-Id: I7fbb1b51cda9f84842992e365b16c5ced1010b89
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77885
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `PRERAM_CBFS_CACHE_SIZE' Kconfig to set
the pre-memory stages CBFS cache size. A cache size of zero disables
the CBFS cache feature. The default value is 16 KB which seems a
reasonable minimal value enough to satisfy basic needs such as the
decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
We have set this size to zero for all the platforms without enough
space in Cache-As-RAM to accommodate the default size.
TEST=Decompression of vbt.bin in romstage on rex using cbfs_map()
Change-Id: Iee493f9947fddcc57576f04c3d6a2d58c7368e09
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The linker can make relocation entries of a symbol which has a value
of zero point to the undefined symbol entry. It is permitted since
when the symbol value is zero as the documentation of the relocation
entry `r_info' field states:
"If the index is STN_UNDEF, the undefined symbol index, the relocation
uses 0 as the symbol value."
The ELF binary does not really have any missing symbols. It is an
optimization as the symbol points to the undefined symbol because its
value is zero.
A typical way to hit this cbfstool limitation is to define an empty
region using the REGION macro in the linker script. Here is an
example if we assume `CONFIG_MY_REGION' is set to 0:
.car.data {
[...]
REGION(my_region, CONFIG_MY_REGION_SIZE)
[...]
}
A region is defined as follow:
#define REGION_SIZE(name) ((size_t)_##name##_size)
#define DECLARE_REGION(name) \
extern u8 _##name[]; \
extern u8 _e##name[]; \
extern u8 _##name##_size[];
So the size of the region is actually the address of the
`_##name##_size' symbol. Therefore, the `_my_region_size' symbol
address is zero and the linker can make the relocation entry of this
symbol point to the undefined symbol index.
In such a situation, cbfstool hits a segmentation fault when it
attempts to relocate the symbol in `parse_elf_to_xip_stage()'
function. We resolves this issue by making cbfstool skips relocation
entries pointing to the undefined symbol similarly to the way it skips
relocation relative to absolute symbols. A symbol which value is zero
can be considered an absolute symbol and therefore should not be
relocated.
Of course, we could argue that we could just prevent the declaration
of an empty region as illustrated in the following example:
.car.data {
[...]
#if CONFIG_MY_REGION_SIZE > 0
REGION(my_region, CONFIG_MY_REGION_SIZE)
#endif
[...]
}
However, this is not a satisfying solution because:
1. It requires to add unnecessary code in the linker script as an empty
region is a valid declaration. Such a workaround requires the code
using it to mark the region symbols as weak symbols to handle the
situation where the region is not defined.
2. There could be other situations which have yet to be uncovered which
would lead the same cbfstool crash.
3. A binary with an empty region is a valid ELF file and cbfstool
should not crash when it is asked to create an eXecute-In-Place stage
out of it.
Change-Id: I2803fd3e96e7ff7a0b22d72d50bfbce7acaeb941
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This fixes assembling with clang which complains about fpu instructions.
TEST: BUILD_TIMELESS=1 remains the same.
Change-Id: I175b8e749fafde5fb7ffb8101fc0dc892d9b4e0d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74539
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As per PPR, Genoa supports up to 96 core, that is 192 threads.
It also supports dual socket.
Change-Id: I817fea7c41477f476794e9e5c16451037d01f912
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78402
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Update SaGv gears and frequency values as per recommendation
from power and performance team. This change doesn't cause
negative impact on firmware boot time performance.
BUG=b:274137879
TEST=Verified the settings on google/rex using debug FSP logs.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: Ie8a81c05f25b1cdab1008d09c606d1debea6e6e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78268
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Crypto Engine in PSP prefers the buffer from Static RAM (SRAM). Hence if
a buffer comes from within SRAM address range, then it is passed
directly to Crypto Engine. Otherwise a bounce bufer from the stack is
used. But on SoCs like Picasso where PSP Verstage stack is mapped to a
virtual address space this check fails causing a bounce buffer to be
used and hence a stack overflow. Fix this issue by assuming that the
buffer comes from the SRAM always in such SoCs and pass the buffer
directly to crypto engine.
BUG=b:259649666
TEST=Build and boot to OS in Dalboz with unsigned PSP verstage.
Change-Id: I2161c8f0720c770efa5c05aece9584c3cbe7712a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78426
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The Bayhub BH720 eMMC bridge is a fixed internal device, and needs to
me marked as non-removable in order for Windows to properly recognize/
utilize the device. Add the necessary ACPI to be generated at runtime.
TEST=build/boot/install Win11 on google/kahlee (liara)
Change-Id: I0815abf1d2dc5cfe785dc04670ab91f2a6a1af23
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Windows does not use these devices for audio. Hide these so they don't
clutter device manager.
Change-Id: Ic85eff7f7ff68e25cc005bbb822bf99374c96532
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78418
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On all targets the domain works as a host bridge. Xeon-sp code intends
to feature multiple host bridges below a domain, hence rename the
function to pci_host_bridge_scan_bus.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4e65fdbaf0b42c5f4f62297a60d818d299d76f73
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78326
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
AMD Audio CoProcessor handles I2S audio on AMD SoC's. Prior to AMD
Ryzen platforms (e.g. STONEY) it is located on the Integrated GFX
device. As the proprietary AMD driver does not support accessing this
easily, reserve a custom ACPI ID from the coreboot namespace so that
another driver can be attached in Windows device manager.
Change-Id: I855b81908ed9ad0587b6367b052c726c36350208
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Use 2 gpio for stylus detect and wake function.
GPP_E04 is the IRQ source, and GPP_E09 is the wake source.
BUG=b:304680060
TEST=Build and test on karis, stylus detect function works
Change-Id: I7a83326f76932c8e501e6369bb845fc7236291b4
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78336
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This Kconfig option is used as a failback when `get_uint_option`
fails. It will fail after coreboot is flashed, as the cfr code has
not yet setup the options.
Change the default to OFF, so when it does fallback, it's the correct
behaviour.
Change-Id: I5d06047fe23322520e9c84ded8f1941f6d716a51
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78223
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This is required for the HDA device to work.
Change-Id: I5fd3617c4cb1e69b7e0ecf6cddf4c143da99b927
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78201
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds support for the Librem 11 tablet, using the ME 13.50.15.1436
binary from the original BIOS (version 28.D8.E1.021) and FSP binaries
from a Jasper Lake Chromebook.
The following features were tested with PureOS:
* Audio (speakers, microphone, headset jack)
* Cameras
* Display
* Touchscreen and pen
* Keyboard cover, with tablet/laptop mode switch indicated via ACPI
* Power and volume buttons
* USB-C ports (USB 2/3, DP alt mode, PD charging)
* SD card reader
* WLAN
* Bluetooth
* NVMe SSD (socketed)
* Battery state information from EC
* Accelerometer
A UART is accessible with soldering via test points on the mainboard,
documented in the mainboard Kconfig with a toggle to enable it for
coreboot logging.
Change-Id: I545994889ddfb41f56de09b3a42840bccbd7c4aa
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Based on schematics and confirm with EE to remove TOF function.
BUG=b:290891557
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot
Change-Id: I1ae6a6562d87f8da5f41691a7606a1aa10989443
Signed-off-by: Rex Chou <rex_chou@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78147
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The next board revision of Librem 14 (v1-02) has replaced the ALC256
codec with ALC269. Add verbs for it.
Two GPIOs were changed from SMBus native functions to NC for this
revision. They are not used on either revision, change to NC.
Change-Id: I43b6265d2f502c05d5539ff3abf53ade0da6d706
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78347
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
New Librem 14s have a newer CPU stepping, which changes them from CML
v1 to v2. The product is not significantly different and remains v1,
specifically "v1-02".
Select SOC_INTEL_COMETLAKE_1_2 to support all CPU steppings.
Change-Id: Iab37208b81e973714a2c088d2346eda518bf1214
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Define SOC_INTEL_COMETLAKE_1_2, which creates a build supporting both
Comet Lake v1 and v2 by including both sets of FSP binaries and
selecting one based on the CPUID.
A mainboard can select this instead of SOC_INTEL_COMETLAKE_1 or ..._2
to support all CML-U steppings in one build.
Change-Id: Ic8bf444560fd6b57064c47faf038643fabde010e
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78345
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Support embedding a second FSP-M/FSP-S binary for an SoC that can
select one at runtime.
Comet Lake v1 and v2 are different steppings of the same SKUs, but they
require different FSP binaries. Supporting both in a single build
requires embedding both FSPs and selecting one at runtime based on the
CPUID. This is desirable for a product that may have different CPU
steppings but is not otherwise differentiated enough for a separate
firmware build.
An SoC can select PLATFORM_USES_SECOND_FSP to indicate that two FSP-M/
FSP-S binaries are required. Implement soc_select_fsp_m_cbfs() and
soc_select_fsp_s_cbfs() to choose one based on platform-specific
criteria. For Comet Lake, the first FSP is CML v1 and the second is
CML v2, but in principle a platform could define any meaning for the
first and second FSP.
FSP-T is not affected, only one FSP-T can be embedded if FSP_CAR is
used.
Only one set of FSP headers is used, which is sufficient for Comet Lake
v1/v2; their headers are equivalent.
ADD_FSP_BINARIES, FSP_USE_REPO, and FSP_FULL_FD are supported for both
sets of FSP-S/FSP-M but cannot be configured separately, both use the
same configuration.
Change-Id: Ied4c6c49a6bdf278238272edd47a2006258be8e5
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78344
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
XFS is barely used. In order to save some space, drop it from the
package list.
Change-Id: Ic1cc567eb3f555bdf5567f3d036c84ce58691128
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78400
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Bump to 23.05 and also rename settings in order to compliant with newest
namespaces and names.
Change-Id: I4a23466bef5c45ebb82d92038ec2595103c984d3
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78399
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Within TBT PCIe, following register offsets have been updated for
production silicon. Update ASL with new offsets.
1. MPC - Miscellaneous Port Configuration Register
2. RPPGEN - Root Port Power Gating Enable
3. SMSCS - SMI/SCI Status Register
BUG=306026121
TEST= Check TBT PCIe Tunnel creation and device enumration.
Change-Id: I0497f7108ef5046c2694aece232263582514a0c5
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78163
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Commit bd9c562a9e ("acpi: Configure
slp-s0 residency counter frequency in LPIT table") led to jenkins
reporting the following error:
!!!!! Error: defined(CONFIG_ACPI_SOC_INTEL_SLP_S0_FREQ_HZ)
used at src/include/acpi/acpi.h:457. Symbols of type 'hex'
are always defined.
Since hex Kconfig are always defined there is no need to test it being
defined but also no need to handle zero or non-zero values.
In addition:
1. This config was defined in Meteor Lake specific Kconfig file while
it should actually be define closer to where it is being used (here
soc/intel/common/block/acpi/Kconfig) and only set by the SoC Kconfig.
2. Once moved and under control of `SOC_INTEL_COMMON_BLOCK_ACPI_LPIT'
gating (lpit.c), the Kconfig name needed to be adjusted to better fit
its use.
3. Make Meteor Lake Kconfig sets the config but does not define it
anymore.
TEST=LPIT ACPI table Counter Frequency field is set to 0x2005 on rex
Change-Id: I2083c9209e61be6180cca2c9f74097e2f4b4ce9a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78458
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The microcode for RPL-S C0 and H0 is actually available, however, the
name of the file contained a typo: 06-b7-05 vs 06-bf-05. Fix the typos
in the comments.
Moreover, the ADL-S C0/H0 microcode file 06-97-05 has the same sha256
sum as the equivalent RPL-S C0/H0 microcode file 06-bf-05. The sha256
sum of ADL-S/RPL-S C0/H0 microcode on intel-microcode tag
microcode-20230808:
5d8d4a4d5456c43b7cc04937c80aec094ccbf3bd89f34ffa5182913ef944a9f9
Update the comments to correctly indicate supported CPU steppings.
Change-Id: I4c848e0dfc40f6c8e26a9b31e7c4cf4c5a09128f
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78413
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SCI handler for the GPE associated with the Super I/O did not clear
the respective PME status bits resulting in the SCI reoccurring
endlessly. The /proc/interrupts reported millions of ACPI interrupts
generated in just a few minutes of uptime. The flood of interrupts
caused some units to be unusable in extreme cases once attempted to
boot Qubes OS for example. On systems like Qubes OS it had a huge
impact on performance due to many IPCs the SCIs caused under Xen.
Clear the PME bits of devices that report a PME event. Then clear
the global PME status bit at the end of SCI handler to prevent the SCI
from asserting again until a new event occurrs. With this change
the number of ACPI interrupts generated in the first minutes of uptime
settles at a few thousands.
TEST=Boot Qubes OS R4.1.2 on Dell OptiPlex 9010 SFF and check
/proc/interrupts in dom0 if the number of ACPI interrupts is only
a few thousands.
Change-Id: I64e03d268138a62b46084be41343ef7fb089dfc3
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Remove the existing FSP 4221.00 headers subdirectory called
4221.00_google, and have Google vendor devices use FSP 4301.01.
BUG=b:306181828
TEST=`emerge-brya coreboot chromeos-bootimage`, flash and boot skolas to kernel.
Change-Id: Ic64b3aec62f0d6302278393bf06d090f43c0d592
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: <srinivas.kulkarni@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Package C-state auto demotion feature allows hardware to determine lower
C-state as per platform policy. Since platform sets performance policy
to balanced from hardware, auto demotion can be disabled without
performance impact.
Also, disabling this feature results soc to enter below PC8 state and
additional power savings ~30mW in Local-Video-Playback scenario.
Change-Id: I6ff408280178a24686180f72f79522d2741607a1
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78278
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
System sleep time (SLP_S0 signal asserted) is measured in ticks, for
Meteor Lake soc in 122us (i.e. ~8197Hz) granularity/ticks.
Change-Id: I1e95cd69e941d4d72d5c36a07660ca07ee2499ba
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Intel platforms use Low Power Idle Table (LPIT) to enumerate platform
Low Power Idle states. There are two types of low power residencies
a) CPU PKG C10 - read via MSR (Function fixed hardware interface)
b) Platform Controller Hub (PCH) SLP_S0 - read via memory mapped
Ref. https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
System sleep time (SLP_S0 signal asserted) is measured in ticks,
varies in every platform and based on PMC clock.
BUG=b:300440936
TEST=check kernel cpuidle sysfs for non-zero residency after s0ix cycle
and both must match
cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
Change-Id: I401dd4a09a67d81a9ea3a56cd22f1a681e2a9349
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78164
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the IGD joins the MBUS when the firmware splash
screen feature is enabled (aka BMP_LOGO config is enabled).
For ChromeOS platform, it prevents the i915 driver from reinitializing
the display, which can save up to 75ms-80ms of boot time and eliminate
a brief period of blank screen between the firmware splash screen and
the OS login prompt.
BUG=b:284799726
TEST=Able to build and boot google/rex.
Change-Id: I36af167afa902053a987602d494a8830ad9b1b1a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch implements `.final` hooks for the IGD device to perform the
required operations before handing the control to the payload or OS.
The MBUS (Memory Bus) is a high-speed interface that connects the
graphics controller to the system memory. It provides a dedicated data
path for graphics data, which helps to improve graphics performance.
The MBUS is a key technology that helps to make the Intel i915 driver
powerful and versatile graphics drivers available. It provides the
high-speed data transfer capabilities that are essential for smooth
and responsive graphics performance.
Enable this config to ensure that the Intel GFX controller joins the
MBUS before the i915 driver is loaded. This is necessary to prevent
the i915 driver from re-initializing the display if the firmware has
already initialized it. Without this config, the i915 driver will
initialize the display to bring up the login screen although the
firmware has initialized the display using the GFX MMIO registers and
framebuffer.
Kernel graphics driver can avoid redundant display init by firmware,
which can optimize boot time by ~15ms-30ms.
Ensures hashing mode is 1x4 to enable a single pipe between Pipe A or B.
Typically, internal display is on Pipe-A, so 1x4 restricts MBUS joining
to internal display alone.
BUG=b:284799726
TEST=Able to build and boot google/rex
Change-Id: I60ae76dc783383e027e66edbcdeeb535472caeb1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78385
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enabling support of WiFi SAR table for all rex variants by
setting the option at baseboard level.
BUG=b:290689824
TEST=emerge-rex coreboot
Change-Id: I17709cb5d75b56c6c1f386ab527c5c8730011bed
Signed-off-by: YH Lin <yueherngl@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78308
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
WiFi SAR table for karis will be place into the CBFS later on and
as a result adding the hook in coreboot to make use of the SAR
table once the table is available.
BUG=b:290689824
TEST=emerge-rex coreboot
Change-Id: Ic989024ab9eb0fc439fc701c335a85986c4cfec5
Signed-off-by: YH Lin <yueherngl@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78260
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update default fan settings(FAN_SETTING_1) in FAN field.
Bit 6-7, FAN, 0 --> FAN_SETTING_1
BUG=b:290689824, b:294155897
TEST=Dump ssdt table and check fan settings is existed
Change-Id: Id69ec67202b5d769cd3a9a68344a6d8913ebd78b
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78216
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Jeremy Compostella