On some older platforms (eg, google/link), setting the wake mask
before clearing the pending events will result in an immediate
wake from S3 sleep, so swap the ordering to ensure that doesn't
happen.
TEST=build/boot google/link, verify S3 sleep works properly.
Change-Id: I483dcfabd37a1f55fd0e56eed895f5b813f018d7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Update VBTs for both sarien and arcada variants from v221 to v228.
The current public CFL FSP uses/expects v228, and the older v221
causes a 180* rotation of the display at boot. Updating the VBT
to v228 fixes the issue. Also disable the fixed mode at boot
setting, so that the native panel resolution can be used by
the payload.
Settings were exported from the v221 VBTs using the Intel BMP tool,
and imported/applied to the sample VBT provided in the FSP repo.
TEST=build/boot google sarien w/edk2 payload, verify screen orientation
correct and native panel resolution used.
Change-Id: Ib6669fc535a197f961abdfcd10616c97a0573df2
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87619
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch enhances the forced CSE sync mechanism by eliminating the
boot partition check for RO. It uses the persistent CMOS flags to
preserve the forced CSE update status across boots.
This patch also replaces the CSE status boolean variable with a bit
field to optimize CMOS memory utilization. Consequently, the remaining
bits can potentially be utilized for additional CSE states in future.
BUG=b:380220737
TEST=Verified forced CSE sync on google/rex0.
Change-Id: If1e4180cb5fec3990fdee2b0e412173b1c8c6ded
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86153
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves pvmfw cbmem implementation to chromeos directory and
under CHROMEOS kconfig. The kconfigs have been renamed accordingly and
with this change CHROMEOS_PVMFW_CBMEM is enabled by default for
CHROMEOS.
BUG=b:410735713
TEST=The build with CONFIG_CHROMEOS=y allocates buffer for pvmfw, the
depthcharge adds the location and size of the buffer to the kernel
command line
Change-Id: I024f21ceee1334ebd7ae9bf1b897ad670ddc9ef9
Signed-off-by: Bartłomiej Grzesik <bgrzesik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87763
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Resolve the issue that DP can only display on one side.
BUG=b:416842915
BRANCH=none
TEST=Build and boot to pujjocento. Verify typec works.
Change-Id: I55f2f28a0bdb052cafa05a98f51c8483fb343b8c
Signed-off-by: Kun Liu <liukun11@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87757
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On arm64 device libpayload reserves 32MB of space for the DMA allocator.
DMA allocators are usually just used for small bounce buffers or DMA
descriptors for SPI, I2C or USB transfers, nothing that should get
anywhere near the size of megabytes.
Presumably the original number was just made arbitrarily large because
it didn't matter. But more recently we have had security applications
(guarding secrets that get received over SPI/I2C from firmware and must
not be visible to the OS after handoff) that made us want to erase the
entire DMA heap just to be sure no driver left a copy of any secret
lying around there. This means the size is no longer fully harmless
because erasing a larger heap takes more time.
Change the default to 1MB which should still be more than more than
enough for any real applications, but should bring the time required to
erase it back into negligible territory.
BUG=b:418942992
TEST=Booted Trogdor from USB.
Change-Id: Id56486203c512d7ff08909cac1a016adc44d8e68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Weak symbols don't work as expected when you want to override them from
within the same static library. This patch changes the arch_ndelay()
function so that instead of having a weak generic implementation, the
choice between generic implementation and an arch-specific override is
explicitly made by Kconfig. Let's also drop the "arch_" prefix and just
call this ndelay().
Change-Id: Ie4fe2734e0683fa3537e2ebcabfe067e7499463a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87776
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jakub "Kuba" Czapiga <czapiga@google.com>
Our mechanism to override the default (pure C) memory function
implementations (memset, memcpy, memmove) with architecture-specific
optimized assembly versions doesn't actually work: it turns out that
weak functions don't work as you'd naively expect when you pack them
together with a strong definition from a different object into a static
library. When a linker tries to resolve a symbol from a static library,
it just picks the first one it finds, even if it is weak. It doesn't
evaluate all objects in the library to see if there are other strong
definitions.
To fix this, this patch gets rid of the weak symbols and uses Kconfigs
instead. It adds an optimized memmove() implementation for x86 because
that makes things easier (then all architectures either override all
three functions or none of them). Also remove memcmp() from the
functions that can be overridden for now because nobody ever needed that
anyway.
Change-Id: Iedf9898247f1999e56fde3233fad8b7cb36b1269
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87766
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Secure System Power Manager (SSPM) provides power control in secure
domain. The initialization flow is to load SSPM firmware to its SRAM
space and then enable it. It takes 19 ms to load sspm.bin.
coreboot logs:
CBFS: Found 'sspm.bin' @0x26740 size 0x645b in mcache @0xfffdd1ec
mtk_init_mcu: Loaded (and reset) sspm.bin in 19 msecs (59392 bytes)
BUG=b:379008996
BRANCH=none
TEST=build pass and see SSPM firmware loading log
Signed-off-by: Hailong Fan <hailong.fan@mediatek.corp-partner.google.com>
Change-Id: I9be0e7ee3d003b5ee9e07e4f136795755a11c5bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87761
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add MCUPM loader for mt8189.
It takes 36 ms to load mcupm.bin.
coreboot logs:
CBFS: Found 'mcupm.bin' @0x10d00 size 0x7fd6 in mcache @0xffffeb20
mtk_init_mcu: Loaded (and reset) mcupm.bin in 36 msecs (84124 bytes)
BUG=b:379008996
BRANCH=none
TEST=build pass and we can see the mcupm logs after reset releases.
Signed-off-by: Justin Yeh <justin.yeh@mediatek.corp-partner.google.com>
Change-Id: I4f3a4eb63d801df123e45f46fc715c39d858c377
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87758
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Per discussion in CB:87660, this is another approach to fix duplicate
ACPI device GFX0.
The following GFX ACPI device is already declared in nissa/devicetree
by CB:83071, it declare a ACPI gfx device as below:
device ref igpu on
register "panel_cfg" = "{
.up_delay_ms = 200,
.down_delay_ms = 50,
.cycle_delay_ms = 500,
.backlight_on_delay_ms = 1,
.backlight_off_delay_ms = 200,
.backlight_pwm_hz = 200,
}"
register "gfx" = "GMA_DEFAULT_PANEL(0)"
end
It will generate an ACPI \_SB.PCI0.GFX0 device.
However, some Nissa projects re-select DRIVERS_GFX_GENERIC in their
overridetree, which results in the generation of a second
\_SB.PCI0.GFX0. This duplication causes iasl to fail when disassembling
the SSDT table.
Error message from iasl:
File appears to be binary: found 7485 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file SSDT, Length 0x4A03 (18947) bytes
ACPI: SSDT 0x0000000000000000 004A03 (v02 COREv4 COREBOOT 00000000 CORE 20230628)
Pass 1 parse of [SSDT]
Firmware Error (ACPI): Failure creating named object [\_SB.PCI0.GFX0._DOD], AE_ALREADY_EXISTS (20200925/dswload-387)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20200925/psobject-264)
Could not parse ACPI tables, AE_ALREADY_EXISTS
BUG=none
TEST=disassembling SSDT on pujjoniru successfully
Change-Id: I16e9875c12b4e8e42214da5972bed6a02c5567f4
Signed-off-by: Simon Yang <simon1.yang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87745
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This commit introduces support for LP5 and DDR5 memory configurations
on ocelot. It adds board IDs for ocelot and integrates new memory
settings within the variant parameters. The new memory configuration
includes settings related to early command training and LP5/DDR5
specific training parameters.
LP5 memory configuration includes detailed DQ and DQS mapping for
different DDR channels. This facilitates accurate routing of signals
and initialization of memory. Additionally, SPD information retrieval
is adapted to accommodate DDR5-specific settings, such as DIMM module
topology and SMBus addresses.
BUG=b:394208231
TEST=Build Ocelot and verify it compiles without any error.
Change-Id: I828b1944d5a0d7f58aa8f545d567b1bb1b0da5ae
Signed-off-by: P, Usha <usha.p@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87684
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Fn key on pujjocento emits a scancode of 94 (0x5e).
BUG=b:417141058
TEST=Flash Pujjocento, boot to Linux kernel, and verify that KEY_FN is
generated when pressed using `evtest`.
Change-Id: If8ad29fccbd7c088ee793f3261df0b0999f25765
Signed-off-by: lizheng <lizheng@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87752
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
RTL8111 was occasionally not detected after reboot. This change
moves the configuration of the ISOLATE_ODL pin to high earlier
in the sequence to ensure the device is properly visible during
PCIe bus enumeration.
BUG=b:407469351
TEST=Verified that the Ethernet NIC is enumerated after reboot.
before:
[DEBUG] PCI: 00:1c.0 scanning...
[SPEW ] do_pci_scan_bridge for PCI: 00:1c.0
[DEBUG] PCI: pci_scan_bus for bus 01
[INFO ] PCI: Static device PCI: 01:00.0 not found, disabling it.
[DEBUG] GENERIC: 0.0 enabled
[WARN ] PCI: Leftover static devices:
[WARN ] PCI: 01:00.0
[WARN ] PCI: Check your devicetree.cb.
[DEBUG] scan_bus: bus PCI: 00:1c.0 finished in 34 msecs
after:
[DEBUG] PCI: 00:1c.0 scanning...
[SPEW ] do_pci_scan_bridge for PCI: 00:1c.0
[DEBUG] PCI: pci_scan_bus for bus 01
[SPEW ] PCI: 01:00.0 [10ec/0000] ops
[DEBUG] PCI: 01:00.0 [10ec/8168] enabled
[DEBUG] GENERIC: 0.0 enabled
[INFO ] Enabling Common Clock Configuration
[INFO ] L1 Sub-State supported from root port 28
[INFO ] L1 Sub-State Support = 0xf
[INFO ] CommonModeRestoreTime = 0x96
[INFO ] Power On Value = 0xf, Power On Scale = 0x1
[INFO ] ASPM: Enabled L1
[INFO ] PCIe: Max_Payload_Size adjusted to 128
[INFO ] PCI: 01:00.0: Enabled LTR
[INFO ] PCI: 01:00.0: Programmed LTR max latencies
[DEBUG] scan_bus: bus PCI: 00:1c.0 finished in 68 msecs
Change-Id: Idc0eb453c342828e0e8886ca5cacea8d7efcc437
Signed-off-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87734
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
The FW_CONFIG feature is not used on mc_rpl. Delete the related source
file and the reference to it in Makefile.
Change-Id: Ifec1efc239801205f1aec2095082c8f744f84a55
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Since this board comes with a fixed SoC (Raptor Lake with ADL-P PCH),
there is no need to have multiple different gpio configuration files and
devicetree files. This patch deletes the unneeded files and adopts
Makefile.mk to not use them.
Change-Id: Iced9d695e3f21dec260795bb651109ff9b2beb59
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This mainboard neither uses Chrome OS nor has any embedded controller
available. This patch removes all references from the build in this
regard. This also requires some refactoring in board_id.c.
Change-Id: If834480fbdac4b4843c265a257d3a77678f56aab
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87666
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename chromeos.fmd to mc_rpl.fmd and adjust the flash layout settings
to match the needs of this board. There is e.g. no A/B scheme used and
CSME stitching is done externally, therefore no detailed CSME partitions
are required at all.
Change-Id: I6389960d816c5f1a4690a965961301d3797305ff
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87665
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This patch adds a new mainboard called 'mc_rpl' which is based on the
Intel Alder Lake RVP. Only the needed changes are made in this patch in
order to make it compile with proper names. Follow-up patches will
tailor it more towards the real mainboard hardware.
Change-Id: Ic0caa621350848d459def6044ca0a6dfd88f873f
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87664
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I am using a pair of Winbond W25Q64JVSSIM SPI flash chips for
coreboot development. While working on Asus P8x7x Series
autonomous soft strap update support, aka CB:85413 and CB:87334,
I found that without its signature (mfgr 0xef, dev 0x7017) added,
rdev_writeat() would fail to get anything into the flash chip
even though it reports success. Its other parameters are copied
from W25Q64_V as the two are almost the same.
Change-Id: I4af6268a2a1bde4d2ff9c76879c3bc59b91a916d
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
update GPP_R4/GPP_R5 setting based on pujjocento proto schematic.
BUG=b:409752486
TEST=emerge-nissa sys-boot/coreboot sys-boot/chromeos-bootimage
Change-Id: I5a2926a074e801162972d950c62002352fb5cf6e
Signed-off-by: Lei Cao <caolei6@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87756
Reviewed-by: Kun Liu <liukun11@huaqin.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Enabling MMCONF is simple and should be done first to allow bootblock
code to access the PCI config space. Required to cache ROM3 in
early_cache_setup() that is now called directly after enabling MMCONF.
Change-Id: I5d5f533258985211afafd9bf748f8e26f6128bd4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86619
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On x86_64 use the ROM3 window to access the SPI flash. Use the
same mechanism as on Intel, where the lower 16Mbyte are mapped
using ROM2 window and the upper pages are mapped using the ROM3
window. By default the ROM3 window resides in high MMIO and thus
needs 1024GiB of the address space to be identity mapped in the
page tables.
This allows legacy 32-bit code to work on mappings in the lower
16MiB of the flash chip.
Introduces new messages in coreboot log:
[INFO ] ROM2 Decode Window: SPI flash base=0x0, Host base=0xff000000, Size=0x1000000
[INFO ] ROM3 Decode Window: SPI flash base=0x1000000, Host base=0xfd01000000, Size=0x3000000
TEST: Disabled ROM2 mapping and booted from ROM3 mapping in x86_64
on amd/birman+.
Change-Id: I8976273cfb31765d7f893b3fc137f117c63b6553
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86584
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
The E7240 actually has a 8MiB + 4MiB flash configuration, not 8MiB.
Change-Id: I14f0c8f6f0c0dfebf41294812b1f4e131eaa18d0
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This commit overrides the `logo_valignment` setting in the
`common_soc_config` for the Ocelot board variant, similar to
https://review.coreboot.org/c/coreboot/+/87453.
The vertical alignment for the firmware splash screen logo is now set to
`FW_SPLASH_VALIGNMENT_MIDDLE`, which places the top edge of the logo at
the vertical midpoint of the screen.
Change-Id: I29f08d31d325304f7532ed37f9cf3d5ef0bb88ff
Signed-off-by: Avi Uday <aviuday@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
This commit removes the `device ref npk on end` from the
`overridetree.cb` files for ocelot, similar to -
commit 85c65b0c20 (mb/google/fatcat: Remove NPK device from fatcat and francka variants)
This effectively disables the NPK device for these configurations
(because `npk` is default set to disable).
Change-Id: Iee1509f44f6543c23f9633ccd8d35d4a7e37b89e
Signed-off-by: Avi Uday <aviuday@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87753
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the number of eFuse reads exceeds a certain limit (with a maximum
of 20 million), a bit flip from 1 to 0 may happen. When that happens,
the bit flip will be automatically corrected by the eFuse hardware via
ECC (Error Correction Code), and the EFUSE_ECC_ERR register bit will be
set for the software to decide how to handle that.
Therefore, this patch adds a check for the EFUSE_ECC_ERR register bit.
If it's set due to a bit flip instead of a real error, we simply clear
it to avoid triggering a WDT reset.
BUG=b:379008996
BRANCH=none
TEST=build passed and check the WDT status debug log. This log is added
in local for test only.
[INFO ] mtk_wdt_clear_efuse_ecc: wdt_sta = 0x0
Signed-off-by: Zexin Wang <ot_zexin.wang@mediatek.corp-partner.google.com>
Change-Id: Idd2763688c7ab6992a7c185e9e52b60bda88c94c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87744
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
crrev/c/5828162 introduced vccin_aux_imon_iccmax parameter for each variant to override the VccInAuxImonIccImax FSP parameter to follow its VCCANA power rail design.
Since meliks adopts external VR design for VCCANA power rail, set it to 25A to follow the guidance in RDC#646929 Power Map.
BUG=b:409205469
TEST=Built and boot
Verified maximum 5% of 3D mark score improvement on N250 SKU
Change-Id: I58786493098c787d402c85ce7167319285af7488
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87704
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, it was found that the GPP_D2 and GPP_D18 pins affect power
consumption during S0ix. After discussion with the hardware team,
since the motherboard is shared across different platforms and these
two pins are unused on the Chrome platform, they will be set to NC.
Measurements have shown that this change effectively improves power
consumption.
Due to some pins changes for next phase, the modifications are listed
below for reference.
Follow the GPIO table updated on 05/19.
GPP_D2 : GPO -> NC
GPP_D14:
Current phase: GPO -> NC
Next phase : FUNC1 (UART0_ISH)
GPP_D18:
Current phase: FUNC2 (UART1_ISH)
Next phase : GPO -> NC
BUG=b:411554553
TEST=improve 375mW-->143mW
Change-Id: I3c788ed4e2ff3e5d49008c03a895d13549d5c79b
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87709
Reviewed-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit removes an unnecessary space in the Kconfig name
for BOARD_GOOGLE_FELINO.
Change-Id: I49044a49fcef914b2e11d3c2eeefe6b6b082d8c1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87749
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move `post_cpus_init` to execute at the entry of the `BS_DEV_ENABLE`
boot state. This function is responsible for synchronizing
and finalizing MTRR (Memory Type Range Registers) settings across all threads.
This change ensures that MTRR configuration occurs at the correct
point in the boot sequence:
- After main DRAM resources are determined and finalized (typically
by the `BS_DEV_RESERVE_RESOURCES` state). MTRRs define
attributes for these physical memory ranges.
Previously, `post_cpus_init` was hooked at `BS_WRITE_TABLES` (on exit)
or `BS_OS_RESUME` (on entry). Relocating to `BS_DEV_ENABLE` (on entry)
provides a more robust and correctly sequenced execution point for this
essential multi-processor (MP) MTRR setup.
BUG=b:413638298
TEST=Successfully built and booted google/fatcat. Verified that
MTRR programming, which depends on DRAM resource determination
(finalized by BS_DEV_RESERVE_RESOURCES), now correctly
executes at BS_DEV_ENABLE, prior to full device initialization.
Change-Id: I1d2b3f11e4ac268c5b35bf9a8062a77a48a0601a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87703
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Update header files for FSP for Panther Lake platform to version
3144_01, with the previous version being 3071_00.
Changes include:
- Update UPD Offset in FspmUpd.h and FspsUpd.h.
- Update MemInfoHob.h:
- Update MEMORY_INFO_DATA_HOB, child structures and their data for
SMBIOS type 16/17 design change.
- Add new variable PprFailingChannelBitMask to
MEMORY_INFO_DATA_HOB.
- Update soc/intel/pantherlake/romstage/romstage.c: Refactor coreboot
to match MEMORY_INFO_DATA_HOB data structure.
BUG=b:414734316
TEST=Able to build google/fatcat. Verify that the updates to
MEMORY_INFO_DATA_HOB and its child structures for SMBIOS type 16/17
design changes are correctly integrated from FSP 3144_01 onwards.
Change-Id: I054e419ef23ada67347750e7a68014c2bb112199
Signed-off-by: Alok Agarwal <alok.agarwal@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87000
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: <srinivas.kulkarni@intel.com>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.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>
Add initialization of DPM driver for DRAM low power mode.
BUG=b:379008996
BRANCH=none
TEST=Boot up pass and see log
3200 LPDDR5 chan0(x16) rank0: memory test pass
3200 LPDDR5 chan0(x16) rank1: memory test pass
3200 LPDDR5 chan1(x16) rank0: memory test pass
3200 LPDDR5 chan1(x16) rank1: memory test pass
Signed-off-by: Mike Lin <mike.lin@mediatek.corp-partner.google.com>
Change-Id: I3b72b892d56623e7f3ec2dccfad073a908b51119
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87663
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
MT8189 equips DPM hardware which is similar to MT8196.
Therefore, we use the same DPM v2 loader to run the blob.
BUG=b:379008996
BRANCH=none
TEST=Make & Boot up pass and see log
mtk_init_mcu: Loaded (and reset) dpm.dm in 19 msecs (1004 bytes)
mtk_init_mcu: Loaded (and reset) dpm.pm in 19 msecs (36588 bytes)
mtk_init_mcu: Loaded (and reset) dpm.dm in 7 msecs (1004 bytes)
mtk_init_mcu: Loaded (and reset) dpm.pm in 19 msecs (36588 bytes)
Signed-off-by: Mike.Lin <mike.lin@mediatek.corp-partner.google.com>
Change-Id: I616cc0880d2db3f94b2a960b11d04974af1e94ef
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87662
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
MT8196 DPM uses broadcast mode for loading DPM bin files. This means
that both dpm.dm and dpm.pm files only need to be loaded once, and
all channels will apply them.
In contrast, MT8189 DPM uses non-broadcast mode, which requires
loading the dpm.dm and dpm.pm files for each channel individually.
The original dpm_v2.c only supports broadcast mode. In this commit,
add support for non-broadcast mode to increase code reusability.
BUG=b:379008996
BRANCH=none
TEST=build passed.
Signed-off-by: Mike Lin <mike.lin@mediatek.corp-partner.google.com>
Change-Id: I599f06c5669f5fd8623966a1c03767ea02b6bd15
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87736
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>