To support the MTK firmware support package (FSP), reserve a 2MB region
in DRAM for loading `mtk_fsp_ramstage.elf` during ramstage.
BUG=b:379008996
BRANCH=none
TEST=build passed
Signed-off-by: Vince Liu <vince-wl.liu@mediatek.corp-partner.google.com>
Change-Id: If153d9746bea8c7faa8f9787029b44192c18899d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87813
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Currently Francka cannot boot up immediately by pressing power button
when its power state is S5.
This patch fixes the power on process for this scenario.
BUG=b:419406610
BRANCH=none
TEST=Francka boots up immediately by pressing power button in S5.
Change-Id: I52fba7f58faa890955cd07728a6790520df29321
Signed-off-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87807
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-by: Ian Feng <ian_feng@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Weak symbols don't work as expected when you try to override them from
within the same static library. Static libraries are just archives of
individual objects, and when the linker tries to resolve a symbol
against it it simply uses the implementation from the first object that
has one, weak or not. It does not search through all remaining objects
to see if there's also a strong implementation.
We've had multiple cases in libpayload where builds were incorrectly
using the default implementation rather than an optimized arch-specific
implementation for years due to this issue. To prevent it from
recurring, this patch adds some postprocessing script to the Makefile
that checks for this situation and makes the build fail if it creeps in
again.
Change-Id: I9fcbc9b873901d126322b12954c349c08300369f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
For better readability of the log output, add an empty line between each
iteration of the submodules.
Change-Id: I626b609e9833bffde0f7a5eb101877c6cd83a173
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87822
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This modification sets the HDA GPIO pin to NC by default.
Different audio configurations can be enabled via fw_config.
BUG=b:417133565
TEST=emerge-fatcat coreboot, HDA sound cards can be detected.
Change-Id: I0090a68d86de1067697d7efbb64c4638476c64ca
Signed-off-by: Ian Feng <ian_feng@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87810
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enables CPU_SUPPORTS_INTEL_TME and TME_KEY_REGENERATION_ON_WARM_BOOT
for Panther Lake, providing hardware memory encryption capabilities.
TEST=Able to build and boot google/francka. Verified TME related
settings inside FSP are now enabled with this patch.
Change-Id: Iedc0d72d00e7e3c5b85916e2de4f020efd5ef024
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87801
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This commit moves the TME configuration into its own static function,
`fill_tme_params`, which is then called from
`fill_fspm_security_params`.
The `TME_KEY_REGENERATION_ON_WARM_BOOT` option is now supported,
allowing a new TME key to be generated on warm reboots.
This feature leverages the `SOC_INTEL_COMMON_BASECODE_RAMTOP`
configuration to determine a memory exclusion range for the new key.
Additionally, disable the `BIOS Guard` UPD as part of security FSP
UPD configuration.
TEST=Able to build and boot google/fatcat. S0ix also works with this
patch.
Change-Id: I1030a25262f1c3c24cf9f4886718689ee2c8155e
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87808
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds a new timestamp, `TS_FIRMWARE_SPLASH_RENDERED`
(ID 557), to precisely mark the moment the firmware splash screen has
finished displaying.
The timestamp is recorded in `src/drivers/intel/fsp2_0/silicon_init.c`
within the `do_silicon_init` function. It's conditionally added based on
the platform's configuration:
- For platforms using FSP's native BMP rendering (prior to FSP 2.2, with
`CONFIG(BMP_LOGO)` and without
`CONFIG(USE_COREBOOT_FOR_BMP_RENDERING)`).
- For platforms where coreboot handles BMP rendering (`CONFIG(BMP_LOGO)`
and `CONFIG(USE_COREBOOT_FOR_BMP_RENDERING)`).
This enhancement provides better visibility into the boot process and
allows for more accurate performance analysis related to splash screen
display time.
BUG=b:418935715
TEST=Able to build and boot google/fatcat. Verified below details in
`cbmem -t`.
```
557:Firmware splash screen rendering finished 47,193,590 (2,235)
```
Change-Id: Ibef967dbc6e224741438e9708b42486ba03d0104
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87812
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set open-drain GPIOs for ChromeOS as input and bias-disable mode. Also
set AP_HDMI_RST_ODL to low, which is the only open-drain output pin.
BUG=b:397102113
BRANCH=none
TEST=build pass
Change-Id: I4375c25768de8f1462c491b2c84b9cf31f118126
Signed-off-by: Haikun Zhou <zhouhaikun5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87796
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Increase the CPU little core frequency from 1.6 GHz to 2.0 GHz to
speed up the boot process.
BUG=b:379008996
BRANCH=none
TEST=check little core cpu frequency is 2GHz in kernel by commands
clkdbg() { echo $@ > /proc/clkdbg ; cat /proc/clkdbg ; }
clkdbg fmeter
See the little core CPU frequency:
fm_armpll_ll_ck : 1999968
Signed-off-by: Zhigang Qin <zhigang.qin@mediatek.corp-partner.google.com>
Change-Id: I979f44e9340ea5bd733dc7f0fe47af47a4f403b7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87795
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 support for VMODEM and VSRAM_MD buck converters in MT6359. These
buck converters are required for MT8189 to adjust voltage and CPU
frequency.
BUG=b:379008996
BRANCH=none
TEST=build passed.
Signed-off-by: Zhigang Qin <zhigang.qin@mediatek.corp-partner.google.com>
Change-Id: Ifdf43748a139050ec9fba50f918e071dc622a670
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87799
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Currently on power key long press, PMIC will be reset. It would cause
an unwanted reset pulse in the power-off sequence. To match expected
sequence, change PMIC behavior to "force shutdown".
BUG=b:395848137
BRANCH=none
TEST=long-pressing power key doesn't trigger PMIC_AP_RST_L pulse
Change-Id: Ia8fb9f4a1ffe05955fca51a58468ba338ef8e12d
Signed-off-by: Haikun Zhou <zhouhaikun5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87798
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
GPIO_AP_SUSPEND_L is supposed to be high in S0, and low in S3. EC uses
this pin to determine the AP power state. This pin should be set as
early as possible in bootblock.
BUG=b:396030112
BRANCH=none
TEST=reboot pass. `powerinfo` shows S0 in EC console.
Change-Id: Ib7e9eaa19d232a37b3793bcbe268ba021e456ac7
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87793
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
The commit f66c7c1037 ("util/abuild: Update echo to printf for
consistency") accidentally added whitespaces to the missing_arches
variable, causing the [[ -n "${missing_arches}" ]] check to fail.
The commit c81b08c4ba ("util/abuild: Fix building ChromeOS boards")
intended to fix it, but did it the wrong way.
Now, really fix the problem from the Makefile snippet that is causing
the whitespace issue.
Change-Id: I5e417e851840bad000492bf737fc8e25063fe0c4
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87809
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>
SMI handler previously did not evaluate input slp_typ parameter and
apparently always acted as S3 was requested.
With the change keyboard is no longer a wakeup source from S4/S5, it is assumed MAINBOARD_EC_S5_WAKE attribute defined in ec.h is correct.
Change-Id: I54c7d7455a6737f731c65e57c91b6457643c7cb2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74603
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Boris Mittelberg <bmbm@google.com>
Extracted from coreboot-Google_Teliks.15217.734.0.bin
Change-Id: I2c6b00ab0fc67b651256ec32d4d983b987435010
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87557
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Extracted from coreboot-Google_Yaviks.15217.552.0.bin
TEST=build/boot yaviks/yavilla variant with working display.
Change-Id: I775baf4216eef2a60bc1ac034cef3c5c7c38ea69
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87556
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Extracted from coreboot-Google_Pujjo.15217.460.0.bin.
TEST=build/boot pujjo1e variant with working display.
Change-Id: I82425bdbbba93197fb7b6f7a866412dc49066cdf
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
To have the best usage case on 4GBx32 memory sku, the external display
resolution must not exceed 2560x1700. So use the GPP_E13 signal level
to determine x32 memory configuration and apply the corresponding VBT
accordingly.
BUG=b:415850768
TEST=Check the log for the string "Use vbt-uldrenite_x32mem.bin"
Cq-Depend: chrome-internal:8258325
Change-Id: I82a7415b4c99de9278e04f07a9efb0dfa0bf753d
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87654
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These variants were missing VBTs necessary for display init, so add
them. VBT files taken from the stock firmware images:
coreboot-Google_Dood.11297.368.0.bin
coreboot-Google_Foob.11297-169.0.bin
Since all variants other than the baseboard have VBTs, move the
selection of INTEL_GMA_HAVE_VBT to the baseboard and exclude the
octopus board.
TEST=build/boot various ocotpus variants, including dood/foob.
Change-Id: I67655b149de40e3e7f83971780f62cd7fce820c8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87774
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Needed for coolstar's IOM/TCSS drivers under Windows.
TEST=build/boot Win11 on google/screebo
Change-Id: Ib5a288d9b5d259c27f3b3b2b1b7b86e9c0e1f491
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86822
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
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>
