Linux complains in dmesg as a firmware bug that BSP is not the first
entry.
NetBSD hangs and OpenBSD panics early on boot.
With this patch I was able to boot NetBSD and OpenBSD on darp10-b when
loaded in GRUB.
Note: vanilla bootloaders for NetBSD and OpenBSD still result in an
apparent hang for an unknown reason.
Change-Id: I520a2e080c9f07a5866729ae2283990d20c0d691
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This prevents Windows from displaying the IOM device in Device Manager
as an unknown device with no driver available, and brings Alderlake
and Tigerlake in line with Meteorlake and Pantherlake.
TEST=build/boot Win11 on starlabs/starlite_adl, verify IOM device
not shown as unknown device in Device Manager.
Change-Id: Ib31018173126737b36a6e0d822eba2ebc9c42306
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86257
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This prevents Windows from displaying the PMC device in Device Manager
as an unknown device with no driver available, and brings Alderlake
and Tigerlake in line with Meteorlake and Pantherlake.
TEST=build/boot Win11 on starlabs/starlite_adl, verify PMC device
not shown as unknown device in Device Manager.
Change-Id: I4bd62d113455fab7fcb272d85f70e6a185e53b74
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86256
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Previously only the '06-37-03' and '06-37-09' microcode files were provided
but '06-37-08' was missing.
Linux on my '06-37-08' SOC was segfaulting in various unpredictable ways without
this patch.
Signed-off-by: Mate Kukri <km@mkukri.xyz>
Change-Id: I1a66a8ba980f4fd43f5f54d446edbcd5029e33a0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86217
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
PcieRpLtrEnable[] is a boolean, so use true false.
Change-Id: I4b557683b7897487dedfef0bf77e60b0dab9cbcf
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86193
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MSEC_TO_USEC(cse_perf_data.timestamp[i]) does overflow.
Here is an example, if cse_perf_data.timestamp[i] value is
4304903 milliseconds. When multiplied by 1000 to convert to
microseconds, the value becomes 0x979B58 instead of 0x100979B58.
TEST=Boot to OS
Change-Id: I09cc00aa595a821a57a34c38a4435e433e935ad3
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86215
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Remove the memcpy_s function as it is not used.
Additionally, the function did not return the expected values:
0: If the memory copy is successful.
EINVAL: If dest or src is a null pointer, or if count is greater
than RSIZE_MAX.
ERANGE: If count is greater than destsz.
Change-Id: I0d32c838e94ae760907efe55ed00bab3faaaa8c5
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86233
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Have two comments, then two blocks of code makes it hard to read.
Seperate them.
Change-Id: I32d6b7c389f64305e8357f52b063628cd99816d6
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86196
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently after UFS is disabled, if the device is coming out of S5 sleep
state then a warm reset is triggered such that PMC samples the UFS
function disable bit and disables the UFS controller accordingly.
Sometimes during the boot flow, an additional kind of reset gets
triggered - Power cycle Reset through CMoff. Hence initiate a warm reset
when the host comes out of S5 sleep state or Power cycle Reset through
CMoff.
BUG=b:391449110
TEST=Build Brox BIOS image and boot to OS. Ensure that when the device
switches from normal mode to developer mode an extra warm reset is
triggered such that the UFS controller is disabled.
Change-Id: I85cad1a1eb00a2a7f520a57cda789ad6737fcb97
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86170
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Introduce an API to read the Converged Security and Management Engine
(CSME) host firmware status register to obtain the current Power
Management event and compare it with a specified input event.
BUG=b:391449110
TEST=Build Brox BIOS image and boot to OS.
Change-Id: Ie9a49382ee2c1a8f59da6233e510cf2e38ac32ad
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86169
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
The message printed when duplicate GPE DW register values are
detected was previously logged at the INFO level. This commit
changes the log level to WARNING, as duplicate DW values indicate
a potential misconfiguration and warrant closer attention. While
the system falls back to the default GPE route (as per MISCCFG
register), this situation should be investigated to ensure correct
platform configuration.
This change ensures that developers are more clearly notified of
potential GPE routing issues.
TEST=Built and booted on a platform using PMC GPE routing. Verified
that the message is printed at the WARNING level when duplicate DW
values are present.
Change-Id: I7804ddfa6e067014e034364bd8efbf6efe746cd7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The `pmc_gpe_init` function's check for duplicate GPE DW register values
was incomplete. It only checked for duplicates between DW0 and DW1, and
DW1 and DW2, but failed to check if DW0 and DW2 were the same.
This could lead to incorrect GPE routing if DW0 and DW2 happened to have
the same value, even if DW1 was different.
This commit corrects the check to ensure that all three DW registers
(DW0, DW1, and DW2) are compared against each other. If any two
registers have the same value, a message is printed indicating that
the default GPE route will be used.
Change-Id: I0a52e6aeee619fbc2f712c9c976b067d080ca591
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86173
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The `pmc_gpe0_different_values` function previously asserted if any
two of the GPE0 DW registers (DW0, DW1, DW2) had the same value, as
introduced in commit 640a41f3ee ("soc/intel: Assert if
`pmc_/gpe0_dwX` values are not unique"). This prevented platforms from
configuring GPE routing via PMC as per default register (MISCCFG) value.
This commit modifies the check to allow all DW registers to be zero.
This enables platforms that rely on MISCCFG register for
PMC-controlled GPE routing to boot without triggering the assertion.
The change was verified by testing the following scenarios:
- All DWs zero: The system boots using the default GPE route.
No assertion occurs.
- Duplicate DWs (e.g., DW0=1, DW1=2, DW2=2): The existing assertion
is triggered as expected.
- Unique DWs (e.g., DW0=1, DW1=2, DW2=3): No errors occur.
TEST=Built and booted normally. No assertion failure observed.
Change-Id: Ie66d6dbcf49d5400b3fc3e4da113a569fe52dd51
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86164
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Refactor to factor out and route ACPI calls through the openSIL driver
interface to separate main SoC code from vendorcode.
Change-Id: I9fa4f60164333ec7a268702fa3e94979a1b83594
Signed-off-by: Nicolas Kochlowski <nickkochlowski@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
If S0ix is not enabled, then it should not be reported that it
is supported.
TEST=boot linux on starlabs boards, check s2idle isn't
listed under `/sys/power/mem_sleep`.
Change-Id: Ifcf70d127cdea64bdf42cbc9a60dfc4ec740615a
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86133
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Set mcufw_reserved region to non-cacheable and remove cache operation in
dvfs.c.
TEST=Build pass, boot ok.
Check MMU List by CVD (Codeviser):
0x00113000--0x00123FFF = I:non-cacheable O:non-cacheable
BUG=b:390334489
Change-Id: I886effd59006e5ad4bfe5bdbc14f057520304835
Signed-off-by: Jarried Lin <jarried.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86159
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
This commit adds the Panther Lake Intel Dynamic Tuning
Technology (Intel DTT) PCI Device ID to the list of supported devices
in the ACPI Common Block DTT driver.
The Panther Lake Intel DTT PCI ID is defined in document #815002,
"Panther Lake U/H Processor - External Design Specification - Volume
1".
TEST=The SSDT ACPI table includes the DPTF device definition on
fatcat board.
Change-Id: Ia8dbe86efdf341a629de037d37750b79395ec3e8
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86118
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
This will configure CpuCrashLogEnable regardless of Tracehub
configuration as Crashlog feature does not have a dependency
with Tracehub.
TEST=Build fatcat and check Crashlog is enabled without enabling
Tracehub.
Change-Id: I6f37e9f4a1f55ffc576af955c92d4073068eb97a
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85614
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Not every board will use CNVi, so move this out of the chipset.cb
and into devicetree.
Change-Id: Ie12e828b2f0a65e46a526746bc06af288270d0d1
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
If S0ix is not enabled, then it should not be reported that it
is supported.
TEST=boot linux on starlabs/starlite_adl, check s2idle isn't
listed under `/sys/power/mem_sleep`.
Change-Id: Ia31fbfd0b9795990b0ca98220bb002bf2c3857b2
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86089
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This allows controlling the FSP debug log level using CBFS RAW binary
files, providing more flexibility in debugging silicon firmware issues
with a debug AP FW binary.
The following CBFS files are used to determine the log levels:
- fsp_pcd_debug_level: For the overall FSP debug log level.
- fsp_mrc_debug_level: For the MRC (Memory Reference Code) debug log
level.
This capability is particularly useful when debugging issues that
require examining both silicon and MRC logs simultaneously.
BUG=b:227151510
TEST=Able to control the FSP debug log based on CBFS options
To inject the fsp_pcd_debug_level and fsp_mrc_debug_level CBFS files
with the desired log level, run:
```
cbfstool image-fatcat.serial.bin add-int -i 5 -n option/fsp_pcd_debug_level
cbfstool image-fatcat.serial.bin add-int -i 5 -n option/fsp_mrc_debug_level
```
Change-Id: Ia2fc07188afde34d61ce8d50d3d722de48228e37
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86002
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Adjust the allocated region size for mcufw_reserved from 52K to 68K.
TEST=Build pass.
BUG=b:390334489
Change-Id: I1c17c1492d5568f4d51ff45e1fb90e067eae5cb1
Signed-off-by: Jarried Lin <jarried.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This default configuration caused a problem where USB devices connected
behind a powered hub and/or Servo v4.1 were not detected.
Reverting this change restores the previous behavior where Trace Hub
and DCI are disabled by default, resolving the USB detection issue.
BUG=b:384453901
TEST=Able to boot google/fatcat using USB storage behind servo v4.1
This reverts commit 1ed186fbff84386e0196dd30dd7bc89b8fec2cec.
Change-Id: I1a0f66d7ddf84622820f82c559d7d6b846ba3a7d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86105
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Gaggery Tsai <gaggery.tsai@intel.com>
Previously, DCI was enabled unconditionally, which could interfere with
the USB data path when connected behind a powered hub and/or servo v4.1
debug connector.
This patch sets DciEn parameter based on the selected platform debug
option. If TraceHub is enabled, DciEn is set to 1. Otherwise, it is
set to 0.
BUG=b:384453901
TEST=Able to boot google/fatcat.
Change-Id: Ie77a4cc8073fdffb1b26f92597c67465e15e21d8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86104
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
When the CFLR method was added, it was inadvertently put outside of the
scope of the CNVW device. Move CFLR under CNVW, and adjust the method/
variable references as needed.
TEST=boot linux, dump ACPI, verify no unknown methods or objects
related to the CNVW device.
Change-Id: I7065e24626b2f763868909b8f85a8f18b4cc229b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86092
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
This method is used in the Intel/AMI reference code to verify
that the device is present (vendor ID != 0xFFFFFFFF), but that's
neither used nor needed here, as coreboot only generates SSDT
code for devices which are actually present.
TEST=build/boot Linux, verify no ACPI issues after dropping
Change-Id: Ib60c48852923e965620f4eee6a886c8c0f5c1783
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86091
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
The Zynq 7000 family of SoCs integrates up to two Cortex-A9 processor
cores with FPGA fabric using Xilinx's 7-series architecture. This commit
adds the bare minimum support code to compile a rom successfully when
the SoC is selected by a board. This code was loosely based on the TI
AM335x code, especially the memlayout.ld file.
In its current state valid Zynq boot images cannot be produced. CBFS
media is not yet supported so only the bootblock is able to run. The
easiest way to run this code is to manually load the bootblock ELF into
memory over JTAG using OpenOCD.
Change-Id: I45aa4e3a11074fa447d4008ac3c96d44f891831c
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: coreboot org <coreboot.org@gmail.com>
Adds new macros to configure the pad in bidirectional mode when both
(Tx/Rx) buffers are enabled in the configuration register DW0. This
corresponds to FSP's < GpioDirInOut > parameter for port direction
(for example see config for SOUTH_GROUP0_DFX_SPARE2 pad in
src/mainboard/intel/harcuvar/gpio.h).
This macro is used in the pad configuration for some boards:
CB:43456 - mb/intel/cedarisland_crb;
CB:39133 - mb/kontron/mal10;
CB:43410 - mb/51nb/x210;
CB:43411 - mb/razer/blade_stealth_kbl.
Change-Id: I7b65f4da7616f2eefcd33a728d4d3ae5a79b014e
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42914
Reviewed-by: coreboot org <coreboot.org@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to Intel's recommendation for Time Coordinated Computing (TCC)
the FSP-S parameter PchLegacyIoLowLatency should be set to 'Enabled'
in order to promote low latencies on the PCH.
With the previous setting 'Disabled' low latencies on the PCH for
I/O operations are not enhanced.
Change-Id: I009cc10fee1f2cf2e2d7e6329cf98d2f95ea77b5
Signed-off-by: Johannes Hahn <johannes-hahn@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86068
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On x86_32 the xHCI BAR isn't reachable as it's mapped in high MMIO.
Currently this is not a problem since the code is unused.
Add a check and return NULL instead of cutting of the higher bits
and thus do not return an invalid pointer. On x86_64 it's working
when the extended page-tables are installed.
Change-Id: I00496ad476c33e0984d7cb0019f27154302edda5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85809
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
On Xeon Skylake-SP with dual sockets the platforms make use of 46bit of
the address space. Most of the PCI BARs reside in high MMIO, not
reachable by x86_32 coreboot.
Add support for x86_64 coreboot and confirm that all supported boards
are booting without errors. This is done by:
- converting all occurrences of VOID * to UINT32 to make sure that
FSP UPDs do not change when pointers are 8byte wide.
- Drop SetupStructPtr as it's unused within FSP and coreboot
TEST: Booted on ocp/tiogapass to Linux. No errors were observed.
Change-Id: I8adac99e7600a708b596fd74b00669f4cb4e041b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85805
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
This patch adds device id for Crashlog and Telemetry. CPU crashlog
record is stored in punit SRAM.
Source: EDS 815002
BUG=None
TEST=Build fatcat and boot with Panther Lake SoC with added
device id.
Signed-off-by: Sowmya Aralguppe <sowmya.aralguppe@intel.com>
Change-Id: I2959623986108a2c5e3dce16e892913a42d71755
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85372
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
We should be writing to the address of reg[i], instead of the address
whose value is reg[i].
Change-Id: I4fb78f974155725a91aad3a5450733d24b57af15
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Change the maximum C state allowed when S0ix isn't used to C8
from C7S to solve the following error:
MWAIT C-state 0x33 not supported by HW (0x1010)
This is a result of copy-pasta from older SOCs, as C7 is not
supported on Alder Lake.
Tested on `starbook_adl` with Ubuntu 24.04 by booting, and
performing multiple S3 cycles.
Change-Id: Idb3e4d34361c8ac25ef144c0d1cda9f801ed0c54
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84622
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
If the modem is not completely disabled, it will cause issues with
suspend to RAM. Update the condition check in MD1_PWR_STA and increased
the MAX_RETRY_COUNT from 200 to 4000 to make sure that the modem has
sufficient time to completely disable before proceeding.
TEST=Measure the power and ensure that the DRAM enters self-refresh
mode.
BUG=b:377628718
Change-Id: I6e915d26e5b3caee36f4726bc2fc1c53cfc17bfc
Signed-off-by: Jarried Lin <jarried.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
