This commit fixes memory corruption observed during stress
suspend-resume tests on the Fatcat board using Panther Lake U and H
SoCs. The issue stemmed from incorrect routing in the SPCO ACPI method
due to the use of SOC_INTEL_COMMON_BLOCK_IOE_P2SB, which was not
suitable as these SoCs lack an IOE die.
To address this, the commit switches from the IOE driver to the P2SB2
driver, aligning with the appropriate SOC_INTEL_COMMON_BLOCK_P2SB2
selection. The related function calls in the Panther Lake codebase have
been updated to use P2SB2-specific operations.
Panther Lake H and U SoC identifiers have been moved from the IOE driver
to the P2SB2 driver.
BUG=b:422284273
TEST=Memory corruption does not reproduce on the Fatcat board.
Change-Id: If678846b6285aea8cd53b0f7aebe3e75812a9330
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87931
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit introduces a driver for a second P2SB (Primary to SideBand)
device to support certain Intel SoC configurations. The new driver
offers new functions, such as p2sb2_enable_bar(), p2sb2_sbi_read(), and
p2sb2_sbi_write(), for accessing and managing the second P2SB
interface (P2SB2). This interface is essential for managing sideband
communications in some Intel SoCs, such as Panther Lake.
BUG=b:422284273
TEST=Successful communication with the P2SB2 device during Fatcat board
boot.
Change-Id: I33941c85243e2529d1dd931b2afd7ab4814d9549
Signed-off-by: Sowmya Aralguppe <sowmya.aralguppe@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87929
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit addresses a compilation error in the PCIe ClkReq SPCO method
due to incorrect conditional compilation logic. The previous
implementation lacked the necessary preprocessor directives to
differentiate between configurations when
SOC_INTEL_COMMON_BLOCK_IOE_P2SB is not defined.
BUG=b:422284273
Change-Id: Ie7b70babd279f7241f6e76113a6694a5bd0d782d
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87930
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Enable POSTPONE_SPI_ACCESS to back up CMOS data and ELOG data in the
later boot phase to avoid flash access delay by another boot controller.
TEST=
1. Enable DEBUG_BOOT_STATE
2. Check time
BS: callback (0x7386f908) @ src/security/vboot/vbnv_cmos.c:120 (0 ms)
BS: callback (0x7386d3e8) @ src/soc/intel/pantherlake/elog.c:213 (0 ms)
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I6b1b091dc60e6b20d39b90feebc8309306d6493e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87739
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Use POSTPONE_SPI_ACCESS to handle elog data later boot phase to avoid
flash access delay by other boot controllers.
Intel has pre-CPU boot controllers (e.g. CSE) which load non-CPU
firmwares. Boot-critical firmwares are loaded before CPU reset and
non-boot-critical firmwares are loaded during CPU boot. If another
controller accesses SPI to load firmwares, reading SPI by CPU is ok,
but writing to SPI for saving elog data can take ~32ms sometimes.
Saving elog data usually takes less than 1ms.
There are three elog handling sequences that need to move together
under the Kconfig:
- Soc folder
- Elog driver folder
- ChromeOS folder
Before this change, sometimes it delays like below:
BS: callback (0x7386d428) @ src/soc/intel/pantherlake/elog.c:216 (32 ms)
After this change, the delay is less than 1 ms:
BS: callback (0x7386d3e8) @ src/soc/intel/pantherlake/elog.c:213 (0 ms)
TEST
1. Enable DEBUG_BOOT_STATE
2. Check time
BS: callback (0x7386d3e8) @ src/soc/intel/pantherlake/elog.c:213 (0 ms))
Change-Id: I3f5e7acf5204e213179664d0d77151d415d00896
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87740
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Introduce POSTPONE_SPI_ACCESS to save CMOS data in a later boot phase
to avoid flash access delay by other boot controllers.
Intel has pre-CPU boot controllers (e.g. CSE) which load non-CPU
firmwares. Boot-critical firmwares are loaded before CPU reset and
non-boot-critical firmwares are loaded during CPU boot. If another
controller accesses SPI to load firmwares, reading SPI by CPU is ok,
but writing to SPI for saving CMOS data can take ~30ms sometimes.
Saving CMOS data usually takes less than 1ms.
Before this change, sometimes it delays like below:
BS: callback (0x7386f908) @ src/security/vboot/vbnv_cmos.c:122 (32 ms)
After this change, the delay is less than 1 ms:
BS: callback (0x7386f908) @ src/security/vboot/vbnv_cmos.c:122 (0 ms)
TEST
1. Enable DEBUG_BOOT_STATE
2. Check time
BS: callback (0x7386f908) @ src/security/vboot/vbnv_cmos.c:120 (0 ms)
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I8836c14601beb56c614605b9840c8506d6d8536c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87738
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This provides entries in the SSDT for all display devices, which
allows the kernel to enumerate them.
Change-Id: Idfa688c3497aa91a9fa5c7923cff04a7ec4892ed
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87947
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is not used, so remove it.
Change-Id: I5d576833c634cc4d2e9eb01627f9bdb61d764b13
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87944
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This provides entries in the SSDT for all display devices, which
allows the kernel to enumerate them.
Change-Id: Ic6c5578d6995aacfff548d10083a712a0faca622
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87943
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Put the GPIOs into groups with clear comments.
Change-Id: I7246fee8bdf111bc08c1335a90609e94356fc611
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
GPIOs, like the USB overcurrent ones, are not used so configure them accordingly.
Change-Id: If5138ccd6048f006408d5335439e7a0143c9cc28
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Configure all strap GPIOs as outputs, rather than some being not
connected. This doesn't change anything, but is more explicit.
Set these all to sample on RSMRST.
Change-Id: I693cfecdb73a20b76fa040500eed5d904b857710
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87937
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Remove the configuration for the vGPIOs, as it is not needed because
FSP handles it.
Change-Id: I8831379ffd8c9df00736cb62512e023592d0d301
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The Byte Mk III is the same, apart from using the Twin Lane N355 instead
of the N200, which means 99.99% of the code is the same.
Change-Id: Ia31f905bea7a6efdad1ed4e36361059ceea2a1ed
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This version of the VBT works for Alder Lake N and Twin Lake.
Change-Id: Ia2161a04018ec3e222a2751b42fe63637b05e6dd
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87895
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When using CONFIG_CONSOLE_SERIAL prevent the OS from putting the
debug uart into D3 state. In the D3 state it's not operating any
more, and the user cannot read debug messages on early kernel boot
or on shutdown any more.
For release builds CONFIG_CONSOLE_SERIAL should not be set and the
device can be put into powersave mode.
Change-Id: Id6b6a4d0a053a5e14e54cf623974376992f0abd8
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87803
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In TWL, Type-C0 corresponds to TCSS port1, and Type-C1 corresponds
to TCSS port0. In order for the DP functions of the two Type-C ports
to operate normally, the corresponding relationship needs to be
configured correctly.
BUG=b:418106736
TEST=DP function of Type-C0/C1 workable
Change-Id: I4aa406e72d1e5f0434866b105f20df6362f3d304
Signed-off-by: Jianeng Ceng <cengjianeng@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87899
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: hualin wei <weihualin@huaqin.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch removes the power limit override code from google/ocelot until the power limits for WCL are known. It is left as a TODO till then.
Change-Id: I15bd1a1c8397957df96a97b4f9f3de0fd5f5c7f6
Signed-off-by: Avi Uday <aviuday@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87911
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
This commit updates `ec/google/chromeec/Makefile.mk` to properly
include source files for SPI and I2C Embedded Controller (EC)
communication in the bootblock.
Previously, essential APIs (e.g., `google_chromeec_command` and
`crosec_command_proto`) were missing during EC code compilation
in the bootblock, leading to linker errors.
This patch resolves these compilation issues by ensuring:
* `ec_spi.c` is included when `CONFIG_EC_GOOGLE_CHROMEEC_SPI` is
enabled.
* `ec_i2c.c` is included when `CONFIG_EC_GOOGLE_CHROMEEC_I2C` is
enabled.
* `crosec_proto.c` is included if either
`CONFIG_EC_GOOGLE_CHROMEEC_SPI` or `CONFIG_EC_GOOGLE_CHROMEEC_I2C`
is enabled.
This ensures all required EC communication components are part of the
bootblock, allowing systems like `google/quenbi` that use the SPI EC
interface to build successfully.
Change-Id: I1d05f582a1685503118797e1788c9bc2ac191168
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87904
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the storage type from fw_config to determine which types of storage
need to be set up in the payload.
BUG=b:379008996
BRANCH=none
TEST=input "cbi set 6 0x40000000 4" in ec console, and see the
following log:
fw_config match found: STORAGE=STORAGE_UFS2X
storage_setup: eMMC: no, UFS: yes
Signed-off-by: Vince Liu <vince-wl.liu@mediatek.corp-partner.google.com>
Change-Id: Ieada3c56b0f69cc1ea3dab4e64641bfc2ba2a0fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87923
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Skywalker reference design supports multiple storage types, such as UFS
and eMMC. We only need to configure eMMC if the board storage type is
eMMC.
BUG=b:379008996
BRANCH=none
TEST=build pass
Signed-off-by: Vince Liu <vince-wl.liu@mediatek.corp-partner.google.com>
Change-Id: I7c3a2e3f7acf75d57d72cda3c9d2e83b77c72f0e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87922
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 method for reading AUXDAC on mt8189 differs from previous methods.
To enhance code modularity and maintain compatibility, the differing
parts are moved to auxad_v1.h to supports legacy platforms.
BUG=b:379008996
BRANCH=none
TEST=emerge-geralt coreboot -j
Change-Id: Ib4bf0f593cab0480b7c78df7916f721f2e0833c7
Signed-off-by: Yidi Lin <yidilin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add the initialization in romstage.
BUG=b:410763782
BRANCH=none
TEST=Check the CPU frequencies are changing and not fixed values by
using the following commands in kernel:
1) set policy*/scaling_governor as "ondemand"
"echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor"
"echo ondemand > /sys/devices/system/cpu/cpufreq/policy6/scaling_governor"
2) Check the CPU frequencies by repeating the command
"grep . /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq"
The result is like
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:650000
/sys/devices/system/cpu/cpufreq/policy6/scaling_cur_freq:2350000
Signed-off-by: Hope Wang <hope.wang@mediatek.corp-partner.google.com>
Change-Id: Ie64ebd1b78096c38c4398572cbed3e2e9ac6b8b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87917
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Add the initialization code for CPU Dynamic Voltage and Frequency
Scaling (DVFS) for MCUPM.
BUG=b:410763782
BRANCH=none
TEST=Check the CPU frequencies are changing and not fixed values by
using the following commands in kernel:
1) set policy*/scaling_governor as "ondemand"
"echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor"
"echo ondemand > /sys/devices/system/cpu/cpufreq/policy6/scaling_governor"
2) Check the CPU frequencies by repeating the command
"grep . /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq"
The result is like
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:650000
/sys/devices/system/cpu/cpufreq/policy6/scaling_cur_freq:2350000
Signed-off-by: Hope Wang <hope.wang@mediatek.corp-partner.google.com>
Change-Id: I001d7a02d86892478b456f1c5ab3a6433434a19b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87916
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This are a bit illogical, so tidy them up.
Change-Id: Idd4f616181949780c042142344b3bbbccc4f15f6
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87894
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To sync with the dramc_param_common.h change [1] from MediaTek's DRAM
blob, change the u32 config_dvfs field to u16 and add a new field
data_version. As all MediaTek SoCs using the structure are little endian
and currently only bit 0 is used for the config_dvfs field, this change
is backward compatible. Therefore, each SoC's DRAMC_PARAM_HEADER_VERSION
doesn't need to be bumped.
[1] commit a39b473a0a7d ("common/cros: Support storing data version in
full-k cached data")
FIXED=415715491
TEST=emerge-skywalker coreboot
BRANCH=none
Change-Id: Ifcda7d360aefe083fc08c974e6dc62d1c9c12b5e
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87912
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
1. Add serial_io_i2c_mode to fix can not boot up to OS issue.
2. Change level from low to high to fix parade touchscreen issue.
BUG=b:395763555
BRANCH=none
TEST=Build and boot to pujjolo. Verify functions work.
Change-Id: Ic0a02daa39f4d1d0287115ecab12f45201704227
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87909
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The bootblock size for the Google Bluey mainboard has been increased
from 96KB to 120KB.
This change is necessary to accommodate the growing size of the
bootblock image, which now exceeds the previous 96KB limit. This
expansion ensures that the complete bootblock code, including critical
initialization routines and potentially new features, fits within its
allocated flash region.
TEST=Able to build google/quenbi.
Change-Id: I7bf2c8c6c540327f1b4233ee5ba4e0703d1200f9
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87903
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Derive the audio amplifier from FW_CONFIG, and set up I2C and I2S for
RT1019.RT1019 and RT9123 use the same GPIOs on the Skywalker reference
design, so the same function is used to improve code reusability. Also
pass the corresponding GPIO to the payload.
BUG=b:417083722
BRANCH=none
TEST=Build pass and test with Depthcharge change:
https://chromium-review.googlesource.com/c/chromiumos/platform/depthcharge/+/6437675
Check audio cmd in depthcharge with:
firmware-shell: AUDIO CMD=audio 500 100 1
Change-Id: I512cd5c8635d08c6b6c54f04d11bf87c64d1b843
Signed-off-by: Rui Zhou <zhourui@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87887
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Derive the audio amplifier from FW_CONFIG, and set up I2C and I2S
for ALC5645. Also pass the corresponding GPIO to the payload.
BUG=b:359705470
BRANCH=none
TEST=build ok and test audio cmd ok
AUDIO CMD=audio 500 100 1
Signed-off-by: Cyril Chao <cyril.chao@mediatek.corp-partner.google.com>
Change-Id: Ib53175f559eecb3d8b5104b12dabfd4793f65d08
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Modify USB related settings according to the proto schematic diagram.
BUG=b:409254508
BRANCH=none
TEST=emerge-nissa coreboot chromeos-bootimage,tested USBA and TYPEC function is ok.
Change-Id: I48ec269b612602578b35eeaedffd1a3d311bb97e
Signed-off-by: Kun Liu <liukun11@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87834
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit populates the `board_id()` and `sku_id()` functions
for the Google Bluey mainboard, replacing the previous placeholder
implementations.
- The Board ID (`board_id()`) is now determined by reading a set of
four GPIO pins (GPIO138 as MSB, GPIO137, GPIO136, GPIO135 as LSB)
and interpreting their states as a base-3 encoded value using
the `gpio_base3_value()` helper.
- The SKU ID (`sku_id()`) is retrieved from the Google ChromeEC
by calling `google_chromeec_get_board_sku()` when a ChromeEC
is configured (`CONFIG(EC_GOOGLE_CHROMEEC)`).
Both ID values are cached after their initial determination to
avoid redundant reads.
BUG=b:404985109
TEST=Able to build google/bluey
Change-Id: Ic5a084e35b33a82fef76f33c2663aba7a48c16a7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
This commit updates the devicetree for the Google Bluey mainboard
to include entries for the WLAN and SSD PCI devices.
These devices are located on the x1p42100 SoC's PCI domain 0:
- WLAN: device pci 04.0
- SSD: device pci 06.0
BUG=b:404985109
TEST=Able to build google/bluey.
Change-Id: If0a9491f4178ee9a44c04aea1330b6522dfd9bf0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87859
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit introduces initial support for PCI Express on the
Qualcomm x1p42100 SoC.
Key changes include:
- Selecting `CONFIG_PCI` in Kconfig to enable general PCI subsystem
support for this SoC.
- Selecting `CONFIG_NO_ECAM_MMCONF_SUPPORT`, indicating that this
platform will not use the standard MMCONFIG ECAM for PCI
configuration space access. An alternative mechanism will be required.
- Adding `../common/pcie_common.c` to the ramstage build if `CONFIG_PCI`
is enabled, incorporating common PCIe helper functions.
BUG=b:404985109
TEST=Able to build google/bluey.
Change-Id: I53e8bb3ce8551e8fa8c4b1cd39d89e12226c32f1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87858
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit introduces `bootblock_soc_early_init` API for early SoC
initialization sequence in the bootblock.
- `bootblock_soc_early_init()`: This function now handles very early
initialization steps (before console init), specifically
`soc_mmu_init()` when the bootblock is not compressed.
- `bootblock_soc_init()`: This function retains the subsequent
initialization tasks including `clock_init()`, `quadspi_init()`,
and `qupv3_fw_init()`.
This change ensures MMU setup to occur before other peripheral and
clock initializations.
TEST=Able to get bootblock console log in proper.
Change-Id: I8bbcdb9c39e13fac81ef6a34647c4f343a619561
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87857
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This commit adds the `clock_init()` function for the Qualcomm x1p42100
SoC. This function is now called at the beginning of
`bootblock_soc_init()` to enable SoC-specific clock setup early in the
boot process.
The `clock_init()` function definition is currently a placeholder
and will be populated with the required clock configurations in
subsequent changes.
BUG=b:404985109
TEST=Able to build google/bluey
Change-Id: Ifb856ea4132def9cd3a36b081d24037a1a4efaba
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87850
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
