DRAM Part Name ID to assign
H58G66CK8BX147 1 (0001)
Yavilla use three memory strap pins for RAM_ID definition and it's consumed.
Since the MT62F1G32D4DR-031 WT:B was never used so it's safe to remove.
This CL make the H58G66CK8BX147 to set for RAM_ID1.
BUG=b:425545256
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot
Change-Id: I9df2710ceb77e4ace6de8976adc1285ef9784c03
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88121
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Wisley Chen <wisley.chen@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Qualcomm's latest SoC, the x1p42100, lacks upstreamed blobs. This
prevents coreboot builds because the default setting marks
CONFIG_USE_QC_BLOBS=y. As a result, build errors occur when the new
Qualcomm SoC blobs aren't in the upstream.
This change introduces `QC_BLOBS_UPSTREAM` Kconfig and set to default
`N` to build QC platform without relying on upstream blob support.
This is necessary for bringing up a new QC SoC-based platform, as
public QC blobs won't be available until later in the year. This
ensures that early QC development can proceed for QC SoC based
without depending on upstream blobs.
Override this Kconfig when QC blobs are available in upstream for
latest X1P42100 SoC.
TEST=Able to build google/bluey.
Change-Id: I04fde6e8917fb3f88c58eb2b55b47de1c2d33518
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit refactors the `soc_load_logo_by_coreboot()` function by
extracting common logo rendering logic into a new helper function:
`render_logo_to_framebuffer()`.
The `render_logo_to_framebuffer()` helper is responsible for:
- Loading the BMP image (by type).
- Checking the image size.
- Converting the BMP to GOP BLT format.
- Calculating the appropriate logo coordinates based on vertical
or horizontal alignment, considering panel orientation for the
footer logo.
- Copying the logo data to the framebuffer.
- Releasing the allocated logo buffer.
This refactoring significantly reduces code duplication within
`soc_load_logo_by_coreboot()`, making it more concise and readable.
It also centralizes the logo rendering process, improving
maintainability and simplifying future modifications.
The `soc_load_logo_by_coreboot()` function now focuses on
higher-level orchestration: graphics info initialization, MTRR
setup, panel orientation adjustment, and sequential calls to
`render_logo_to_framebuffer()` for the main and optional footer logos.
Error handling for MTRR and logo rendering failures is streamlined
with a `cleanup` goto label.
BUG=b:423591644
TEST=Able to show OEM splash screen on google/fatcat at center of the
screen.
Change-Id: I10f84fd1c2081efcf787d00ab7cfc6bb24feca21
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88032
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When a ChromeOS device has `SPLASH_SCREEN_FOOTER` Kconfig enabled and
provides a logo path for an OEM-defined boot splash logo in the footer,
it indicates that the device doesn't need to render
`cb_plus_logo.bmp` logo (hence, avoid packing this bitmap for platforms
that select `SPLASH_SCREEN_FOOTER` Kconfig).
In such cases, only the main OEM logo should be displayed at the center
of the splash screen along with custom bitmap at footer of the splash
screen.
BUG=b:423591644
TEST=Able to show OEM splash screen on google/fatcat.
Change-Id: Ie5085babe2f8373058ce1aa18b7071260f2aef7f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88099
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit removes the explicit `logo_valignment` setting from the
`common_soc_config` for all Fatcat mainboard variants (fatcat, felino,
francka, and kinmen).
The default vertical alignment for the splash screen logo is
`FW_SPLASH_VALIGNMENT_CENTER`, which is the desired behavior for these
boards (in presence of footer logo).
BUG=b:423591644
TEST=Able to show OEM splash screen on google/fatcat at center of the
screen.
Change-Id: I3a9e86a928cdd76f13157eff2a29f209167613a8
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This commit adds horizontal alignment support for splash screen
logos into the existing helper function `calculate_logo_coordinates()`.
Updated helper function determines the X-coordinate for
logo placement based on specified horizontal alignment (left, right,
or center).
The `soc_load_logo_by_coreboot()` function is updated to utilize this
helper for footer logo placement when the panel orientation is
rotated (`LB_FB_ORIENTATION_RIGHT_UP`, `LB_FB_ORIENTATION_LEFT_UP`,
or `LB_FB_ORIENTATION_BOTTOM_UP`).
A new enum, `fw_splash_horizontal_alignment`, is defined in
`intelblocks/cfg.h` to explicitly represent these horizontal alignment
options, complete with descriptive comments and ASCII art.
This enhancement provides greater flexibility in positioning splash
screen elements, especially useful for rotated displays (for the footer
firmware splash screen).
BUG=b:423591644
TEST=Able to rotate the firmware splash screen (including footer logo)
while using portrait panel.
Change-Id: I23ae6d06e1df9cad1b2907a5c02b619dc831d468
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88030
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit refines the comments for the fw_splash_vertical_alignment
enum members in src/soc/intel/common/block/include/intelblocks/cfg.h.
The redundant enum member names (e.g., FW_SPLASH_VALIGNMENT_CENTER:)
have been removed from the start of each comment block. This makes
the comments cleaner and more direct, focusing on the explanation of
the alignment behavior rather than re-stating the enum member's name.
Change-Id: Ife7a39622df1981adc09db82fecb5adc72d52d8d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88157
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch modifies the low-battery shutdown logic to bail out early
when the system is in a low-power state. This prevents the display of
the OEM footer logo, ensuring power conservation and avoiding
unnecessary rendering alongside the low-battery icon.
BUG=b:423591644
TEST=Boot platform with `CONFIG(USE_COREBOOT_FOR_BMP_RENDERING)`
and low battery. Verify splash appears before shutdown w/o OEM
footer logo.
Change-Id: Ie9a23c0fe9d6b7d314cf4bbe8a8a90eb5689568e
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88015
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit introduces the `SPLASH_SCREEN_FOOTER` Kconfig option,
enabling a custom footer image or logo on the firmware splash screen.
This provides an additional branding opportunity for device
manufacturers.
`soc_load_logo_by_coreboot()` now conditionally loads and renders
`footer_logo.bmp` when this option is enabled. The footer logo is
positioned at the bottom of the screen.
A new `SPLASH_SCREEN_FOOTER_LOGO_PATH` Kconfig option is added to
define the footer logo's file path. It defaults to a mainboard-specific
location. `Makefile.mk` is updated to ensure this logo is included in
the CBFS.
This additional branding is made possible by rendering bitmaps using
coreboot's native implementation (`USE_COREBOOT_FOR_BMP_RENDERING`).
FSP currently lacks the necessary callbacks to support this feature.
Currently, the OEM footer branding will appear even when the
system is booting in low-battery mode. A planned update will fix this
by exiting early from the boot process, preventing the footer from
showing and conserving power.
BUG=b:423591644
TEST=Able to display custom footer logo on boot.
Change-Id: I57f8af910e8b8f56e8a4a88f8cca6d60fad380b6
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch introduces `bmp_load_logo_by_type()` to allow loading a
specific BMP logo from CBFS based on `enum bootsplash_type`.
Now, bmp_load_logo() leverages bmp_load_logo_by_type() with the
system-determined logo type. The new bmp_load_logo_by_type() function
provides a direct interface to load any specified BMP by `enum
bootsplash_type`, which is beneficial for scenarios requiring explicit
logo selection.
BUG=b:423591644
TEST=Able to build and boot google/fatcat. Ensure FW splash screen looks
proper.
Change-Id: I2473f7d48ca2d196ced89d81391cf387627a2f86
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88013
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>
This commit introduces an enumerated type `bootsplash_type` to
differentiate between various bootsplash logos, such as
`BOOTSPLASH_LOW_BATTERY` and `BOOTSPLASH_CENTER`.
A `bootsplash_list` array is added to map these types to their
corresponding default filenames. A new function,
`bmp_get_logo_filename`, is provided to retrieve the correct logo
filename based on the specified bootsplash type. This function also
handles overriding the `BOOTSPLASH_CENTER` logo name if
`CONFIG(HAVE_CUSTOM_BMP_LOGO)` is enabled.
The `bmp_load_logo` function is updated to utilize the new
`bootsplash_type` and `bmp_get_logo_filename` to dynamically select the
appropriate logo for display. This change streamlines logo management
and improves flexibility for different boot scenarios.
BUG=b:423591644
TEST=Able to build and boot google/fatcat. FW splash screen looks
proper.
Change-Id: I882deda56b5d30bb15cc7def408c4ea479ffd6ba
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88052
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit refactors the bitmap handling in the FSP2.0 driver to
enhance flexibility. Previously, `fsp_convert_bmp_to_gop_blt()`
directly called `bmp_load_logo()`, tying it to specific, predefined
bitmaps like low-battery or OEM splash logos. This prevented its
use for dynamic bitmap files (e.g., brand logos) at runtime.
To address this, `fsp_convert_bmp_to_gop_blt()` no longer handles
bitmap loading. Instead, a new unified API,
`fsp_load_and_convert_bmp_to_gop_blt()`, is introduced for scenarios
where FSP needs to load and convert a bitmap in a single step
(e.g., via its entrypoint).
This change makes `fsp_convert_bmp_to_gop_blt()` a generic API capable
of converting any provided bitmap into a BLT buffer. SoC layers
(like Alder Lake, Meteor Lake, Panther Lake) can now explicitly load
bitmaps and then pass them to `fsp_convert_bmp_to_gop_blt()`, or use
the new `fsp_load_and_convert_bmp_to_gop_blt()` for combined
operations.
Before:
- `soc_load_logo_by_coreboot()` -> `fsp_convert_bmp_to_gop_blt()`
(loads logo internally)
- `soc_load_logo_by_fsp()` -> `fsp_convert_bmp_to_gop_blt()`
(loads logo internally)
**After:**
- `soc_load_logo_by_coreboot()` -> loads logo
-> `fsp_convert_bmp_to_gop_blt()`
- `soc_load_logo_by_fsp()` -> `fsp_load_and_convert_bmp_to_gop_blt()`
BUG=b:423591644
TEST=Able to build and boot google/fatcat. FW splash screen looks
proper.
Change-Id: Ia20e8d42bca6f40c4eb652eb69e3fce84409fc35
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88014
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit introduces PCI device details specific to Wildcat Lake
within the Panther Lake ACPI code, using conditional compilation
to differentiate configurations.
Key changes:
- Create separate ASL files for Panther Lake (`ptl_pcie.asl`) and
Wildcat Lake (`wcl_pcie.asl`) PCIe port configurations.
- Introduce conditional compilation to include Panther Lake or
Wildcat Lake ASL files.
- Wildcat Lake-specific changes compared to Panther Lake:
- Remove following
- PCIe RP : 00:1c.4 to 00:1c.7
: 00:06.2 & 00:06.3
References:
- Wildcat Lake Processor EDS Volume 1 (#842271)
- Wildcat Lake External Design Specification (EDS) Volume 2 (#829345)
BUG=b:394208231
TEST=Build Ocelot and Fatcat and verify it compiles without any error.
Change-Id: I7f6c4f80a811c596824734d749b8d1c4864ccb9b
Signed-off-by: Appukuttan V K <appukuttan.vk@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88109
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Support memory of Micron MT62F512M32D2DR-031 WT:B in mem_parts_used list, and generate SPD ID for this part.
DRAM Part Name Vendor Model Spec ID to assign
MT62F512M32D2DR-031 WT:B Micron LPDDR5 6400 16GB 3 (0011)
BUG=424688292
BRANCH=firmware-nissa-15217.B
TEST=Run command "go run ./util/spd_tools/src/part_id_gen/part_id_gen.go ADL lp5 src/mainboard/google/brya/variants/guren/memory/ src/mainboard/google/brya/variants/guren/memory/mem_parts_used.txt"
Change-Id: I310e48a8f240646ec631f0cbc8c0ad0b57e26e0d
Signed-off-by: Brian Hsu <Brian_Hsu@pegatron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88091
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Skywalker board with MT8189 uses software calibration for ulposc1 (ultra
low power oscillator) and does not support hardware calibration. Remove
the hardware calibration code accordingly.
BUG=b:423516707
BRANCH=none
TEST=build pass and boot up normally.
Signed-off-by: Zhigang Qin <zhigang.qin@mediatek.corp-partner.google.com>
Change-Id: Iea4a0fd8f2c41b54880cef6647e90e0dd1d2bcf1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88151
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Right now dptx_hal_v2 has defined its own
dptx_hal_phy_set_swing_preemphasis, without utilizing the existing
dptx_hal_setswing_preemphasis defined in dptx_hal_common.h.
dptx_hal_v2.c also implements dptx_hal_setswing_preemphasis, but it's
never used.
To reduce duplicate code, rename dptx_hal_setswing_preemphasis in the
common API to dptx_hal_set_swing_preemphasis, and use it for the
dptx_hal_v2 code. Also fix the type for the `lane_count` argument, and
change variable names to make dptx_hal_v1 and dptx_hal_v2 more
consistent.
BUG=none
TEST=emerge-rauru coreboot
BRANCH=none
Change-Id: Id252d29fd1205a949c903d5560f44efc2ff7f477
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88150
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Refactor the MT8196 eDP driver to improve code reusability:
- Move common parts of dp_intf.h to dp_intf_v2.h
- Move common parts of dptx_hal.h to dptx_hal_v2.h
- Move common parts of dptx_reg.h to dptx_v2.h
- Extract shared code from dptx.c to dptx_v2.c
- Extract shared code from dptx_hal.c to dptx_hal_v2.c
- Rename dp_intf.c to dp_intf_v2.c
SoC-specific parts remain in its respective .c and .h files.
BUG=b:400886838
BRANCH=none
TEST=Check the display function on Navi
Signed-off-by: Vince Liu <vince-wl.liu@mediatek.corp-partner.google.com>
Change-Id: Ia41f62c0f5f7b5a38d7c5650e6f3a06963cc84a7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88149
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
The host must initialize necessary settings before
accessing the Realtek EC via EMI.
BUG=b:414474440
TEST=FW_NAME=brox_rtk_ec emerge-brox coreboot chromeos-bootimage
flash to brox board with realtek rts5915
Boot normally and got those message from ap console:
[DEBUG] Google Chrome EC uptime: 107.108 seconds
[DEBUG] Google Chrome AP resets since EC boot: 2
[DEBUG] Google Chrome most recent AP reset causes:
[DEBUG] 10.479: 32775 shutdown: entering G3
[DEBUG] 92.102: 8 reset: during EC initialization
[DEBUG] Google Chrome EC reset flags at last EC boot: watchdog | sysjump
[DEBUG] PNP: 0c09.0 init finished in 81 msecs
Change-Id: I85ad210ccd40097dff552f7e72fe712e33cfd95f
Signed-off-by: Elmo Lan <elmo_lan@realtek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Generate RAM ID for Kingston B3221XM3BDGVI
DRAM Part Name ID to assign
B3221XM3BDGVI 2 (0010)
BUG=b:420797833
BRANCH=firmware-brya-14505.B
TEST=emerge-constitution coreboot
Change-Id: Ic4f92cb7d597a877b693906dee23e1b277fcf122
Signed-off-by: Shon Wang <shon.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Vbt extracted from coreboot-Google_Pujjoga.15217.834.0.bin.
Pujjoga/Pujjogatwin both use same variant dir/same VBT.
TEST=build/boot pujjoga
Change-Id: Ie2054f53563372e9ce7e6692513340a53c35b565
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88094
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Because the pujjolo motherboard p-sensor could not recognize, so
I modify the below changes.
1. Update P-sensor I2C bus from 2 to 3.
2. Copy P-sensor parameters from pujjocento.
BUG=b:395763555
BRANCH=none
TEST=Build and verify on pujjolo
Device list:
cat /sys/bus/iio/devices/iio\:device0/name
sx9324
The value of register 01 when away:
i2cget -f -y 13 0x28 01
0x00
The value of register 01 when approaching:
i2cget -f -y 13 0x28 01
0x01
Change-Id: Ia5685ad790949001da7ba793759eb286b8cce1e8
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88104
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable USB3 related functions like usb-a, wwan, wlan.
BUG=b:395763555
BRANCH=none
TEST=Boot to OS and verify output of lsusb contains:
us 004 Device 002: ID 8564:4100 Transcend Information, Inc. USB3.1 Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 33f8:01a2 Rolling Wireless S.a.r.l. Rolling RW101R-GL Module
Bus 003 Device 005: ID 093a:2516 Pixart Imaging, Inc. USB OPTICAL MOUSE
Bus 003 Device 004: ID 258a:002a SINO WEALTH Thunderobot KG3089
Bus 003 Device 002: ID 8564:4100 Transcend Information, Inc. USB2.1 Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Change-Id: Ia9cb6a394169530eb660023998dd92d8691a1607
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88062
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add Ax211 wifi card setting to let wifi function work.
BUG=b:395763555
BRANCH=none
TEST=Insert Ax211 wifi card to MB and boot to OS to connect wifi
successfully.
Change-Id: I061ca0ad54bef23861ad8c937cece72902afff47
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88092
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Pujjolo project is going to have single RAM devices,so add single
ram configuration.
BUG=b:395763555
BRANCH=none
TEST=Build and boot to OS. Verify functions work.
Change-Id: I92b0bd1e05276c170d35ce20508cc6f439104442
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88027
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Set the default MFG MUX OPP (Operating Performance Point) from 0
(mfg_sel) to 1 (mfgpll), as mfgpll is used in normal operation and
mfg_sel is only needed during DVFS transitions. Also enable glitch-free
configuration for mfgpll to improve PLL stability.
BUG=b:399571996
BRANCH=none
TEST=Change GPU DVFS by below commands:
echo 880000000 > /sys/devices/platform/soc/13000000.gpu/devfreq/13000000.gpu/min_freq
echo 880000000 > /sys/devices/platform/soc/13000000.gpu/devfreq/13000000.gpu/max_freq
And then check PLL and MUX register values are correct.
Signed-off-by: Irving-CH lin <irving-ch.lin@mediatek.corp-partner.google.com>
Change-Id: I285cc5f07facbb23a448151ceb6c1d037753432c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88090
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add shrm_meta and cpucp_meta as raw files to the CBFS.
BUG=b:419213272
TEST=Verify presence of metadata files in the CBFS.
Change-Id: If97e2d6395ef108f405a3b66727fb19648ddf03d
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87889
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varadarajan Narayanan <vnarayan@qualcomm.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Create a new script to extract
- ELF header
- Program header table (PHT)
- A given segment number
- Hash table segment with type as NULL and p_flags as 0x02000000
from an ELF.
Usage:
```
elf_segment_extractor.py [--eh] [--pht] [--segment <index>] [--hashtable] <elf_file> <output_file>
```
BUG=b:419213272
TEST=Extract first segment alongwith ELF header and PHT.
TEST=Extract a segment with an index number.
TEST=Extract the last segment if index is 'N'.
TEST=Extract hash table segment alongwith ELF header and PHT.
e.g.
elf_segment_extractor.py --eh --pht --segment 0 cpucp.elf cpucp_meta
elf_segment_extractor.py --segment 0 cpucp.elf cpucp_meta
elf_segment_extractor.py --segment N cpucp.elf cpucp_meta
elf_segment_extractor.py --eh --pht --hashtable cpucp.elf cpucp_meta
Change-Id: I1ea58d0ca17ad66463ffe7345a27e91dc0d22d2f
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87888
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In some panels, the power supply for the display and the I2C touch
screen comes from the same source. As a result, if the display is not
powered on, the I2C bus will also be unpowered. This leads to a problem
: if the Intel DRM driver has not yet reached the stage where it powers
on the display, the I2C touch screen device integrated into the panel
will remain unpowered as well. A similar issue can also occur after
resuming from s0ix.
In Linux-like systems, the Intel DRM driver and the generic I2C driver
operate independently, so their execution order in the kernel cannot be
guaranteed.
Kernel patchsets link:
https://lore.kernel.org/all/cover.1749199013.git.jani.nikula@intel.com/
Due to the required kernel changes mentioned above, an ACPI device LCD0
needs to be declared under GFX0, and a _DSD declaration must be added
to the I2C touch screen device.
An example that clearly illustrates the required ACPI change:
Scope (\_SB.PCI0.GFX0)
{
...
Device (LCD0)
{
Name (_STA, 0x0F) // _STA: Status
...
}
}
Scope (\_SB.PCI0.I2C1)
{
....
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x02)
{
...
Package (0x02)
{
"panel",
\_SB.PCI0.GFX0.LCD0
}
}
})
}
BUG=b:398703068
TEST=Extracted SSDT contains a required _DSD entry within the I2C1
touchscreen device scope
Cq-Depend: chromium:6626797
Change-Id: I73058851c35a7190d70a51a554cccf21253fc59b
Signed-off-by: Simon Yang <simon1.yang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This reverts commit 4199351c1b which
originally reverted aedc177f00.
Reason for revert: CB:88063 fixed the bug that this patch exposed.
Change-Id: Ic7a798b4b9236b8c0c7ad8568562d11071ae96a9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This patch creates a new variant `felino4es`.
The new variant will support PTL ES1 samples. This existing `felino`
variant will support ES2 and QS samples.
BUG=b:424355826
TEST=Able to build google/felino4es
Change-Id: I9da7ad9fcdd4467d5b7ab5c31ffba6f3c8b3a943
Signed-off-by: Pranava Y N <pranavayn@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88096
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch creates a felino model Kconfig `BOARD_GOOGLE_MODEL_FELINO`
so that different variants can easily select the configs without any
duplication.
This change is made to support `felino` and `felino4es` variants.
BUG=b:424355826
TEST=Able to build google/felino
Change-Id: I38d72eada28734ed26427dbd85ab603cddab258c
Signed-off-by: Pranava Y N <pranavayn@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88095
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now we face the suspend could not enter s0ix issue.
So according to the schematics 627075_TWL PCH GPIO_Pujjolo_1th version
_20250527.xlsx to change gpio setting and hook up the SD card reader
via fwconfig to fix the issue.
Change :
1. gpio GPP_D8(SD_CLKREQ_ODL) to native function 1
2. add probe sd card.
BUG=b:422600523
BRANCH=none
TEST=Build and boot to OS. Verify powerd_dbus_suspend could enter S0ix
Change-Id: Iaa5a653608316ca8cb1e34429d30a2ebfdf7a1e9
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88050
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These boards only have 2 DMIC physically connected, and attempting to
record from 4 channels vs 2 results in a large amount of background
noise which drowns out the recording. Selecting the 2 channel DMIC
shows audio on both channels and no noise.
TEST=build/boot octopus variants, test built-in mic under Windows
and Linux.
Change-Id: I70c4b3a8f1ece16cb1c134c6b4c786eb4a685bc5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
These boards only have 2 DMIC physically connected, and attempting to
record from 4 channels vs 2 results in a large amount of background
noise which drowns out the recording. Selecting the 2 channel DMIC
shows audio on both channels and no noise.
TEST=build/boot poppy variants, test built-in mic under Windows
and Linux.
Change-Id: I30d97fa1a25e8cefe05cedac5176bb74dad7f318
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
This board only has 2 DMIC physically connected, and attempting to
record from 4 channels vs 2 results in a large amount of background
noise which drowns out the recording. Selecting the 2 channel DMIC
shows audio on both channels and no noise.
TEST=build/boot fizz/karma, test built-in mic under Windows and Linux.
Change-Id: I48162ff25d8c7f413e651c07a7f8e9604bee224c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
These boards only have 2 DMIC physically connected, and attempting to
record from 4 channels vs 2 results in a large amount of background
noise which drowns out the recording. Selecting the 2 channel DMIC
shows audio on both channels and no noise.
TEST=build/boot reef variants, test built-in mic under Windows
and Linux.
Change-Id: Ie7c422f4bd205b0388ee8efea7cf4f3cfa83ef05
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88080
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These boards only have 2 DMIC physically connected, and attempting to
record from 4 channels vs 2 results in a large amount of background
noise which drowns out the recording. Selecting the 2 channel DMIC
shows audio on both channels and no noise.
TEST=build/boot glados variants, test built-in mic under Windows
and Linux.
Change-Id: I68b7d1425c18d070dd75bc42d40ee30701f9704a
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This commit fixes a bug in the conditional logic for determining
Connectivity Integrated (CNVi) readiness in the `cnvw_fill_ssdt()`
function. The comparison previously checked if `LOCAL3_OP` was equal to
`1`, but it should instead verify if `LOCAL3_OP` equals
`CNVI_READY`. This adjustment ensures the accurate assessment of CNVI's
readiness state.
TEST=Running the following "acpidbg -b 'set N \_SB.PCI0.CNVW.RSTT 1'",
"acpidbg -b 'evaluate \_SB.PCI0.CNVW.CNVP._RST'" and "acpidbg -b
'evaluate \_SB.PCI0.CNVW.PRRS'" commands result in PRRS being read
as 2 (expected) instead of 1.
Change-Id: Ia6db833f3118e6975298aff4bd7c40657e4fcff7
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88088
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Connectivity Integrated (CNVi) sideband port ID or Platform-Level
Device Reset (PLDR) register are specific to each SoC platform,
necessitating its relocation to respective SoC codebases. This change
enhances maintainability and readability by ensuring the port IDs are
defined within the context of the SoC they pertain to, removing
redundancy and potential misconfigurations across different SoCs.
Change-Id: I6ef1e077b8ffc076b7dc33ea90cc6ea92e819438
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88087
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enhance the readability and maintainability of the code by adding
detailed comments for the ACPI names "PRRS" and "RSTT" in the
`cnvw_fill_ssdt` function. These comments clarify the possible status
values for "PRRS" and the reset types for "RSTT", aiding developers in
understanding the function's logic and expected behavior.
Change-Id: I94486476cf2f95b8e1744ee369a9d9d6c734bba8
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88086
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
The commit leverages the \_SB.PCI0.BASE() ACPI method to remove the
hardcoded offset in the definition of the ACPI OperationRegion for CNVI
devices. Instead of using a fixed memory address addition, the code now
dynamically calculates the RegionOffset using the device's base address
(_ADR). This change enhances flexibility and adaptability for different
configurations and devices.
TEST=acpidbg -b 'evaluate \_SB.PCI0.CNVW.VDID' returns 0xE4408086 on a
Fatcat device.
Change-Id: Ia329aef0291c31862d002cb9bfa35930dab83fe5
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The BASE method, previously located within USB Type-C Subsystem (TCSS)
ASL (ACPI Source Language) scope across multiple Intel System on Chip
(SoC) files, has been moved to the northbridge module. This refactoring
allows the BASE method to be utilized beyond the USB Type-C Subsystem
use-case.
The BASE method calculates the PCIe device base address using function
and device numbers.
Note: the BASE method is now under the \SB.PCI0 scope. It used to be
under the \_SB scope while only consumed by devices under the \SB.PCI0
scope.
TEST=On a Fatcat board, we verified that the BASE method returns
0xE00A3000 for the "./acpidbg -b 'evaluate \_SB.PCI0.BASE
0x140003'" command. We performed a non-regression test as well on
the TCSS DMA TDM0 device, which uses the BASE method, by verifying
that "./acpidbg -b 'evaluate \_SB.PCI0.TDM0.DMAD'" and "./acpidbg
-b 'evaluate \_SB.PCI0.TDM0.VDID'" return 0x22 and 0xE4338086,
respectively.
Change-Id: I431206e9f38a2a5695c90d4ae6d823fb231814aa
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Subrata Banik <subratabanik@google.com>
