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>
This commit updates the fill_tme_params() function to utilize the
CACHE_TMP_RAMTOP constant instead of hardcoded values for calculating
the TME exclusion range.
Change-Id: I199182de8b8b219b0c45b27746b7415527cb9976
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87868
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This commit addresses the GPIO configuration for DDR5 on Intel's
PTLRVP mainboard. Specifically, it extends support for the DDR5
configuration by adding a case for PTLP_DDR5_RVP in the GPIO
differential table function. This modification ensures proper handling
of GPIO settings when DDR5 memory is configured, thereby improving
system stability and compatibility.
BUG=none
TEST=Boot with DDR5 configuration.
Change-Id: I3745c0a25e84a0f41dced44613cfd638c12fb1d3
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87872
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhixing Ma <zhixing.ma@intel.com>
Extracted from coreboot-Google_Craask.15217-841-0.bin
Change-Id: I07d4e7fe63ff6ad43806d73d9e31ffe0aa8807c5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87867
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Extracted from coreboot-Google_Teliks.15217.734.0.bin
Change-Id: Ib9f077cdd0536e6315b05775337bf30555562cc8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87866
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Remove GPP_D16, GPP_D17, and GPP_B25 as they aren't used in ocelot.
Change GPP_A08 polarity in gpio_table and rom_gpio_table.
BUG=b:412736286
BRANCH=None
TEST=`emerge-ocelot coreboot` and verify it compiles without error.
Change-Id: Ife444cef816ca2b69db466661c63935f72836554
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87870
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Avi Uday <aviuday@google.com>
The DPTF parameters were defined by the thermal team.
Based on thermal table in b:419161631#comment1
BUG=b:419161631
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: If79e58fa52ecb4626fdd6a25e8e3bf6e3c556c6b
Signed-off-by: Kun Liu <liukun11@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87878
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some eMMCs need 80+ms for CMD1 to complete. And the payload may need to
access eMMC in the very early stage (for example, depthcharge needs it
20ms after started) so we have to start initialization in coreboot.
BUG=b:379008996
BRANCH=none
TEST=build pass and run "storage init" in depthcharge shell on MTK EVB
firmware-shell: storage init
* 0: mtk_mmc
1 devices total
Signed-off-by: Mengqi Zhang <mengqi.zhang@mediatek.corp-partner.google.com>
Change-Id: I82f2a155b810a8b9608d70fe0c015e6054d0be00
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87862
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Modify pujjolo vairant codes for type-c port1 display, parade
touch screen, especially for gpio to fit Trulo. Follow the setting of pujjocento.
BUG=b:395763555
BRANCH=none
TEST=Build and boot to pujjolo. Verify functions work.
Change-Id: I285cd33de6e18a2ffb30eb6401c03f6a4b20dc4a
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87843
Reviewed-by: Talal Sadak <tsadak@google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
WWAN_FCPO == GPP_D6
WWAN_RST == GPP_E17
spec reuqest: 0 < toff <10ms
LTE is controlled by bits 14 and 15 in fw_config, and P sensor
and LTE modules exist at the same time, so we use the same bit
to control whether to load the driver.
BUG=b:419325064,b:417105553
TEST=Confirm the measured WWAN power sequence
Change-Id: Ia978aef2cc721b65618ac78c13930447d1557797
Signed-off-by: Zhaoxiong Lv <lvzhaoxiong@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87841
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MT8189 chipset comes in two variants: MT8189G and MT8189H. The
MT8189G variant uses a single PMIC IC (MT6315), whereas the MT8189H
variant uses two PMIC ICs. To ensure driver compatibility, we utilize
the CPU ID and segment ID to accurately determine the required number
of SPMIF instances.
BUG=b:379008996
BRANCH=none
TEST=build pass and boot up normally.
Signed-off-by: Zhigang Qin <zhigang.qin@mediatek.corp-partner.google.com>
Change-Id: I07bc21a2026803e76861b27a178d229deca2090a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87854
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
In some SoCs, such as MT8189G/H, different numbers of PMICs are
required. To ensure code reusability and compatibility, it is
necessary to dynamically set this variable. Therefore, spmi_dev_cnt
is changed to a function.
BUG=b:379008996
BRANCH=none
TEST=build passed
Signed-off-by: Vince Liu <vince-wl.liu@mediatek.corp-partner.google.com>
Change-Id: Ib8d6306a81c276dceb021ddadec40803fd85019b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87853
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
There is no powering-on control in the fingerprint kernel driver.
Follow Rauru to power-on FP MCU in the FW.
BUG=b:401396071
BRANCH=none
TEST=ectool --name=cros_fp version can get the FP FW version.
Signed-off-by: Haikun Zhou <zhouhaikun5@huaqin.corp-partner.google.com>
Change-Id: I20ff175ee4874c4188b7d07ee57330a9275dcb3d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87852
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Unit tests should always use a mock ndelay() defined within each test.
Therefore, select ARCH_HAS_NDELAY for ARCH_MOCK.
Change-Id: I2680e37034d4d13058b3e778d72e63fc6ed18313
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This ensures that bridge windows allocate enough space to cover
SR-IOV BARs. Without this Linux will print messages, these messages
may differ depending on the kernel version used.
Debian GNU/Linux 12 (kernel 6.1.0-28-amd64):
pci 0000:06:00.0: BAR 7: no space for [mem size 0x00200000 64bit pref]
pci 0000:06:00.0: BAR 7: failed to assign [mem size 0x00200000 64bit
pref]
Ubuntu 22.04.5 LTS (kernel 6.8.0-52-generic):
pci 0000:06:00.0: VF BAR 0 [mem size 0x00200000 64bit pref]: can't
assign; no space
pci 0000:06:00.0: VF BAR 0 [mem size 0x00200000 64bit pref]: failed to
assign
TEST=Raptorlake-P
Change-Id: Ib169efe5a6b998a8342a895f1456a280669c719d
Signed-off-by: Stephen Douthit <stephend@silicom-usa.com>
Signed-off-by: Harrie Paijmans <hpaijmans@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34620
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There doesn't seem to be much reason to use absolute paths to the
submodules, other than that it's not needed to change to the original
directory.
In preparation for CB:87824, make use of relative paths and change to
the original directory at the start of each iteration.
Change-Id: Ic74b589d933e6acd882fb9a09461bf7c01952a6f
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87823
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
These variants were missing VBTs necessary for display init, so add
them. VBT files taken from the stock firmware images:
coreboot-Google_Moonbuggy.13324.803.0.bin
coreboot-Google_Scout.13324.645.0.bin
Since all variants now have VBTs, move the selection of
INTEL_GMA_HAVE_VBT to the baseboard.
TEST=build/boot various puff variants, including scout.
Change-Id: I2bb06894fc4df358cc38a4627de9f95289c2c5e0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87779
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This was kept around to avoid build issues back when the NRI patches
were awaiting review. It is no longer used and to-be-upstreamed code
does not use this define either, so now is a good time to get rid of
it.
Change-Id: Id10d81774b0d679b54d5dc4a15dab5996e3a68c5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87832
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The REUT subsequence control register had a different layout in the
Haswell A0 stepping, so it was initially programmed using bitmasks.
However, NRI does not implement support for the A0 stepping because
it is early pre-production silicon that no one should be using, but
the code kept using the bitmasks approach. But we can do better.
Introduce a bitfield for the REUT subsequence control register, and
use it instead of bitmasks. Put the enum for subsequence types next
to the code using it (no reason to have it in the common header, it
is not used anywhere else). And make a helper function that encodes
the number of cachelines in the format expected by the REUT (7 bits
of value, 1 bit for exponential/linear).
Change-Id: I1609ad010e714b0fc47403df7a71e5fc5ae0f5ac
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87829
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that the CPU code exports these PCODE mailbox functions, there is no
reason to retain a copy of them in NRI.
Change-Id: Ic9853cfd6793ecdadf8d2bd15b268f9cf95ba32d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87828
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCODE mailbox is primarily used by CPU code in ramstage. However,
it is also used as part of enabling DDR 2x refresh rate, which is now
implemented in coreboot as part of NRI (native RAM init).
The PCODE mailbox functions in CPU code were not exported at the time
NRI was being developed, so I chose to temporarily copy the functions
into NRI code to make it easier to rebase NRI patches since it avoids
potential merge conflicts. After a few years of rebasing patches, NRI
finally got submitted, so there's no reason to keep duplicate code in
the tree anymore.
Put the relevant PCODE functions into a new file, which gets compiled
for both ramstage (CPU init) and romstage (NRI). The BCLK calibration
function is only used in ramstage so there's no need to move it.
Change-Id: I340625fabc072139b8def254f1ce6b19f360adcd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Group entries by stage and sort groups by stage execution order.
Change-Id: I6e2a53d6555700b48fd3aececdfdb8983554a75a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Ocelot does not support GEN5 NVME Storage. However since ocelot code
was forked from fatcat, these configs exist in coreboot.
Furthermore, the GEN4 NVME GPIOs have changed for ocelot -
1. GPP_B10 to GPP_H18 - GEN4_SSD_PWREN renamed to EN_PP3300_SSD
2. GPP_B09 to GPP_A08 - M2_GEN4_SSD_RESET_N renamed to SSD_PERST_L
BUG=b:419731962
Change-Id: I005d1188138ac7b4bbffa1437bba9aea39aff117
Signed-off-by: Avi Uday <aviuday@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87804
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Update gpio configuration for GPP_A08, GPP_E17, and GPP_F18 to
match ocelot schematic.
Change GPP_H16 (WWAN_PWR_EN) to GPP_E01 (EN_WWAN_PWR) in fw_config.c.
Change GPP_V06 and GPP_V11 to "No Connect" as they are test points.
Change trace names from "SNDW3_" to "SDW3_" to match names on ocelot
schematic.
BUG=b:412736286
BRANCH=None
TEST=`emerge-ocelot coreboot` and verify it compiles without error.
Change-Id: I8996dc1b2b0f85490d55a86dc2ca6a90c1604638
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87750
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
