PCH BIOS spec says that BIOS must clear BIT26 in register 0x338
in PEI, as done on lynxpoint.
Copy and adapt the lynxpoint code to do the same on bd82x6x.
Add special case for UM77 chipset, which only has 4 PCIe ports.
Test: System still boots and all PCIe ports are fully working.
Change-Id: I865818c0c22194fffcb2bbdf8c43737b0dce2307
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Commit 26d54b70e2 ("soc/amd/common/cpu: use TSC_MONOTONIC_TIMER for
SOC_AMD_COMMON_BLOCK_TSC") updated all the AMD SoCs with Zen-based CPU
cores to use TSC_MONOTONIC_TIMER. The same change adjusted the PSP
Verstage timestamps (in microseconds) to the x86 TSC rate. But it
included only the base_time during the adjustment leaving the individual
entry timestamp. This leads to incorrectly adjusted PSP Verstage
timestamps. Fix the adjustment logic.
BUG=None
TEST=Build and boot to OS in Skyrim. Ensure that the PSP Verstage
timestamps in cbmem -t output are adjusted correctly.
Before this change:
5:start of verified boot 67,890 (69,936)
503:starting to initialize TPM 67,890 (0)
504:finished TPM initialization 67,902 (12)
505:starting to verify keyblock/preamble (RSA) 67,906 (3)
506:finished verifying keyblock/preamble (RSA) 67,984 (77)
511:starting TPM PCR extend 67,984 (0)
512:finished TPM PCR extend 67,992 (7)
513:starting locking TPM 67,992 (0)
514:finished locking TPM 67,995 (3)
6:end of verified boot 67,995 (0)
11:start of bootblock 572,152 (504,156)
After this change:
5:start of verified boot 71,000 (73,040)
503:starting to initialize TPM 71,065 (65)
504:finished TPM initialization 101,506 (30,441)
505:starting to verify keyblock/preamble (RSA) 110,624 (9,118)
506:finished verifying keyblock/preamble (RSA) 297,101 (186,477)
511:starting TPM PCR extend 297,297 (196)
512:finished TPM PCR extend 315,338 (18,041)
513:starting locking TPM 315,341 (3)
514:finished locking TPM 322,922 (7,581)
6:end of verified boot 322,943 (21)
11:start of bootblock 570,296 (247,353)
Change-Id: I3e52bef22f65596152f29c511bed680427660ff5
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78231
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Create the dexi variant of the taranza project by
copying the files to a new directory named for the variant.
BUG=b:303533815
BRANCH=dedede
TEST=util/abuild/abuild -p none -t google/dedede -x -a
make sure the build includes GOOGLE_DEXI
Signed-off-by: Kenneth Chan <kenneth.chan@quanta.corp-partner.google.com>
Change-Id: I708a16cb864dca7309cb0201e7887af7456a4885
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78249
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The original code only reserves IOM mmio, but there is other asl
code that requires to program ioe p2sb mmio such as IOE PCIE clk request
control. See \_SB.ECLK.CLKD in src/soc/intel/common/acpi/pcie_clk.asl
TEST=as before: suspend_stress_test 50 cycle pass, type-c display OK
on screebo
Change-Id: Ie55f7975277b390f776e44596c42e426ba9cd235
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78252
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Package C-state auto demotion feature allows hardware to determine lower
C-state as per platform policy. Since platform sets performance policy
to balanced from hardware, auto demotion can be disabled without
performance impact.
Also, disabling this feature results soc to enter below PC8 state and
additional power savings ~30mW in Local-Video-Playback scenario.
BUG=b:303546334
TEST=Local build successfully & Boot to OS successfully
- Also check platform enter PC8 state in local video playback
- before this change: # iotools rdmsr 0 0xE2 -> 0x0000000060008008
- After # iotools rdmsr 0 0xE2 -> 0x0000000000008008
Change-Id: Ia4cf4a7cb6bd5eaae26197b55f9385c078960d7b
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78250
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Add more fields for PCIe slots status and link control and
slot capabilities.
Change-Id: I64e40ea6bd731cd52ce006224b7c3091d5ef3aac
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
When advertising C-state using the ACPI _CST object, make sure
to only advertise those that are supported by the CPU.
Downgrade if it's not and make sure to not advertise duplicate
states.
Add debug prints for the finally selected mapping of ACPI
C-state vs Intel CPU C-state.
Test: Tested on Lenovo X220.
All C-states are still advertised as all are supported.
Change-Id: Iaaee050e0ce3c29c12e97f5819a29f485a7946c2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78194
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Make the code look like on newer platforms. This doesn't change
functionality.
Test: Lenovo X220 still boots and advertises all C-states as
before.
Change-Id: Ie7076d11720d55a4ac11318cbbdab9f75d08e15e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78193
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
According to the BWG C-states are processor specific
and BIOS must check if a C-state is supported at all.
Print the supported C-states in before ACPI _CNT generation.
Test: Tested on Lenovo X220 using Intel i5-2540M.
All C-states are reported as supported.
Change-Id: I713712a1a104714cbf3091782e564e7e784cf21d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78133
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a function to get the number of substates supported by
an Intel CPU C-state.
Test: Can read out the supported C-state substates.
Change-Id: Ie57e87609ea5d6ec6f37154e8b84f1e9574aa4a9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
It was changed from a fixed size-1 array to a flexible array
in commit 242bac0e16 ("…: Use C99 flexible arrays") which resulted
in a change to the serialized format as the header size was no longer
the same.
That broke other tools that read CBFS files, like diffoscope
https://github.com/NixOS/nixpkgs/issues/256896
Change-Id: I4199dcc4823469c5986ac967a55b1c85cc62f780
Signed-off-by: Ivan Jager <aij+git@mrph.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78239
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on the power sequence of the panel [1], the power on T3 sequence
VSN to RESET should be larger than 1ms. Because the Power IC descending
slope takes 2ms, actual measurement needs 3ms to meet the timing of
panel sequence.
[1] HX83102-J02_Datasheet_v03.pdf
BUG=b:302212730
BRANCH=corsola
TEST=emerge-staryu coreboot chromeos-bootimage and boot the panel
Change-Id: I488c746d1fcfc165125b0ecccb0bccbb99231b00
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78185
Reviewed-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Updating from commit id ae822f2d0db7 (2023-09-21):
MDN: Restore SMU fw version 90.41.0
to commit id b1741d184add (2023-10-04):
PCO: Update SMU firmware to 4.30.77.200
This brings in 1 new commit:
b1741d184a PCO: Update SMU firmware to 4.30.77.200
BRANCH=zork
BUG=b:299603947
Change-Id: I0ce75b762bda90a5fa3bc546de42bc5d55637e17
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Intel platforms use Low Power Idle Table (LPIT) to enumerate platform
Low Power Idle states. There are two types of low power residencies
a) CPU PKG C10 - read via MSR (Function fixed hardware interface)
b) Platform Controller Hub (PCH) SLP_S0 - read via memory mapped IO
Ref. https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf,
section 2.2.1: value of 0 indicates that counter runs at TSC frequency.
Ref. Intel 64 and IA-32 Architectures Software Developer’s Manual (Vol 4)
MSR 0x632: PC10 residency counter is at same frequency as the TSC.
Whereas slp_s0 residency counter running in different frequency.
BUG=b:300440936
TEST=check kernel cpuidle sysfs are created after kernel boot
cat /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
Change-Id: Ibde764551a21b9aecb1c269948f4823548294711
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This consolidates the bp, tb, cmp, srp0 and srp1 variables under the new
spi_flash_bpbits struct to allow treating them as one unit in the
refactoring to follow.
Change-Id: I2a1a77fb73047df733498c0fa8b8de1153c3b09e
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42113
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the block protection bits are being passed around as
individual arguments. We will use this new struct to replace the
corresponding arguments in the winbond_bpbits_to_region and
winbond_set_write_protection functions.
Change-Id: I02828b1f764aea29374e794001e74cdc86a94c92
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
This fixes building lenovo/x200 with VBOOT.
All supported CPUs have enough L2 cache to support this.
Change-Id: Ifd6a16ce36c86349955cd7b7ddb3f74a19c17c4d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Quandiso reserve bit 11 for mipi camera usage.
BUG=b:300574047
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot
Change-Id: Id4343083f0d69a49c642657d165ceac349cd7422
Signed-off-by: Robert Chen <robert.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78213
Reviewed-by: Shawn Ku <shawnku@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When service center repair touchscreen or touchpad will change
compatible device not specific one, the fw_config probe mechanism is not
convenient for service center. Removing touchscreen and touchpad
fw_config probe for the purpose.
BUG=b:297840605
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: I66f12ae478f74c019c53ee5e77f7e0f9c324e758
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77538
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the Cezanne FSP binaries (which were just placeholders), as well
as all other defaults removed when running 'make savedefconfig'
Change-Id: I6d355b838d30dca64a9e6206eb6000763cc105a1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78195
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Turn off GPP_H13 (EN_PP3300_SD_X) in s0ix for power saving. It reduces
about 3mW of power consumption in s0ix on pirrha proto board.
BUG=b:300845527
TEST=Built and verified GPP_H13 voltage was 0V in s0ix.
Also verified SD card worked after s0ix for 20 times.
Change-Id: I5ec53820276e50f5b8b01584595118cf2dc4c95c
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch reverses ISH UART pin configuration to allow ISH to enter
into suspend mode. This UART port is for debugging purposes.
BUG=b:302612549
TEST=On Google/rex platform with ISH enabled, do suspend_stress_test
This test must pass
Signed-off-by: Bernardo Perez Priego <bernardo.perez.priego@intel.com>
Change-Id: I8aba45420744a3990e1f9637c3b31ea2e0f78f87
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78049
Reviewed-by: Tanu Malhotra <tanu.malhotra@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch implements an API to report the presence of an external
display on Intel silicon. The API uses information from the transcoder
and framebuffer to determine if an external display is connected.
For example, if the transcoder is attached to any DDI ports other than
DDI-A (eDP), and the framebuffer is initialized, then it is likely
that an external display is present.
This information can be used by payloads to determine whether or not
to power on the display, even if eDP is not initialized.
BUG=b:299137940
TEST=Build and boot google/rex
Scenarios:
Booting with eDP alone: has_external_display value is 0
Booting with eDP + HDMI: has_external_display value is 0
Booting with HDMI alone: has_external_display value is 1
Booting with USB-C display alone: has_external_display value is 1
Change-Id: I77436940978c7fa9368d79394b46a5e794c32e42
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78080
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch introduces a new coreboot table entry named
"has_external_display" to understand if external display is attached.
This information is useful to prevent graceful shutdown by payload
when the LID is closed but an external display is present.
This piece of the information will be gathered by coreboot and passed
into the payload using this new entry aka external_display because
payload (i.e., deptcharge) doesn't have any other way to determine
if external display is available.
BUG=b:299137940
TEST=Able to build and boot google/rex.
w/o this patch:
LID closed and external display attached (HDMI) in developer mode
(GBB 0x39):
> System is powered off by depthcharge
w/ this patch:
LID closed and external display attached (HDMI) in developer mode
(GBB 0x39):
> Booted to OS and device is alive/usable
Change-Id: I0fa7eee4c5a50371a7a66c6ca1ac2c7d046d010b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77796
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel GFX IP TRANS_DDI_FUNC_CTL register bit definitions have changed
since Tiger Lake.
This register is used to map ports and pipes to display controllers,
so reflecting the correct status is important for detecting physical
display end point devices.
This patch ensures that ADL, MTL, and TGL SoCs choose GMA version 2 to
properly reflect the updated port and pipe register definitions.
BUG=b:299137940
TEST=Build and boot google/rex successfully.
Change-Id: Ie2082747d18a5f136f410b1019be4d6c801617b1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This commit updates the port select bit definitions for the
TRANS_DDI_FUNC_CTL registers in the Intel GMA driver to accommodate
the changes introduced since TGL SoC.
Specifically, the following changes were made:
- Updated the DDI select bit definitions from 3-bits (bit 28-30) to
4-bits (bit 27-30).
- Introduces `INTEL_GMA_VERSION_2` config to accommodate the port and
pipe related differences between previous generation GMA register
(TRANS_DDI_FUNC_CTL) to the current generation GMA register.
This commit backports the change from the following upstream patch:
https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-3-lucas.demarchi@intel.com
BUG=b:299137940
TEST=Able to build and boot google/rex.
Change-Id: I815ffa90c2e235afd70baa7e3837e1f9af89b1b0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Set USB port which corresponds PORTSCN/PORTSCXUSB3 register bits for
enable USB wake.
BUG=b:302230434
TEST=Verify USB-A device could wake up Boxy
Signed-off-by: Joey Peng <joey.peng@lcfc.corp-partner.google.com>
Change-Id: I0f6300dc6bbb6fb8226151e49e38f0450b1e71b7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78144
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set USB port which corresponds PORTSCN/PORTSCXUSB3 register bits for enable USB wake.
The physical USB slot is 6, USB2 port5 for Bluetooth, total USB2 port num is 7, USB3 keep 6.
BUG=b:300844110
TEST=Verify USB-A device could wake up Taranza
Signed-off-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
Change-Id: Ied92c4a70bc594bd189dcb942f1a445412509464
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78068
Reviewed-by: Ricky Chang <rickytlchang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Use the common UWES ACPI method to enable wake from USB. The only
difference to other SoCs is that JSL only has 8 USB2 ports, so the USB3
PORTSC register offset is different.
BUG=b:300844110
TEST=When enabled on taranza, all USB2 and USB3 ports can wake from
suspend
Change-Id: Ibc90246965d5d809123e954847543d28d78498a5
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78086
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
The ACPI methods for enabling USB wake are identical on ADL, CNL and
SKL. Move them to a common ASL file so they can be reused more easily
on other SoCs.
Also move the USB_PORT_WAKE_ENABLE macro used to create enable bitmasks
in devicetree to a common header.
BUG=b:300844110
TEST=Use abuild to build kinox, puff, and fizz with and without this
change. Check the generated dsdt.aml is unchanged.
Change-Id: Iabdfe2bece7fafc284ddf04382f1bbcacc370cce
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This panel is never actually enabled on Geralt. The derived project
won't use this panel either. Therefore, remove this panel support.
BUG=none
BRANCH=none
TEST=emerge-geralt coreboot
Change-Id: I97ed5b341724ed42098b2c17d0eb75eab881dbb1
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The tolerance of ADC voltage table is too small. Update the table values
accordring to the suggestion from the hardware team. The patch is
prepared for the derived projects. There is no actual issue now.
BRANCH=none
BUG=b:301908091
TEST=check firmware screen
Change-Id: I3bde30b6bbe79c81e276f23f4110715c3278d42c
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add VCM power control to configure 2.8V and reset pin, and VCM can
be powered on/off properly.
BUG=b:292907385
TEST=Run ITS test
Change-Id: I242025836fd50076a40ffcc4e5d4a5d5bc6fb4d0
Signed-off-by: Serin Yeh <serin.yeh@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78170
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Certain devices are enabled in Alder Lakes chipset.cb, so remove
them from the devicetree.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I929af0bed6c2e1024b4787424a8fe466edce5a36
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78198
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating FSP to v4301.01 caused a strange flicker when connecting
an external display. Update the VBT to 251 from 242 with the exact
same settings to resolve this.
Change-Id: I36bb2cc92e744e761ec6af9c026c429373c1750a
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Simplify the Q events for the battery and charger to just notify
when a status has changed. The EC will trigger these events when
either has changed.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I3300be5254549fe5cd3b3490d9191240c6d36b6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77405
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SPL_TABLE_FILE and SPL_RW_AB_TABLE_FILE Kconfig options provide a
way to override the default SPL file configured in the SoC's fw.cfg file
by passing the '--spl-table' parameter to amdfwtool which will then use
the override instead of the SPL file from the fw.cfg file. When
SPL*_TABLE_FILE is an empty string, the corresponding add_opt_prefix
call in the makefile will result in no '--spl-table' parameter being
passed to amdfwtool, so it'll use the default SPL file from fw.cfg. In
order to not pass an SPL override by default, remove the default from
the SPL_TABLE_FILE in the SoC's Kconfig. The SoC default pointed to the
same SPL file as in fw.cfg file anyway. Now only when a mainboard sets
this option to point to a file, that file will be used as an override.
This override is used to include a special SPL file needed for the
verstage on PSP case on the Chromebooks. Since SPL_TABLE_FILE is an
empty string by default, neither the SPL_TABLE_FILE Kconfig option nor
it being evaluated in the Makefile need to be guarded by HAVE_SPL_FILE,
so remove the dependency in the Kconfig and the ifeq in the Makefile.
Before this patch, the HAVE_SPL_FILE option controlled two things that
shouldn't be controlled by the same Kconfig option: Only when
HAVE_SPL_FILE was set to y, the SPL_TABLE_FILE override was taken into
account, and it also controls if spl_fuse.c got added to the build which
when added will send the SPL fusing command to the PSP. So the case of
needing an SPL file override, but not updating the SPL fuses wasn't
supported before.
The SPL file in the amdfw part will be used by the PSP bootloader for
the anti-rollback feature which makes sure that the SPL file version
isn't lower than what is in the SPL fuses. For this the SPL file needs
to be present in the PSP directory table. The SPL version check happens
way before we're running code on the x86 cores. The SPL fusing PSP
command that can be sent by coreboot will tell the PSP to update the SPL
fuses so that the fused minimal SPL version will be updated to the
current SPL version.
Since the former HAVE_SPL_FILE option now only controls if the SPL
fusing command will be sent to the PSP mailbox, rename it to
PERFORM_SPL_FUSING to clarify what this will do and update the help text
correctly describe what this does.
TEST=With INCLUDE_CONFIG_FILE set to n, timeless builds for both Birman
with Phoenix APU and Skyrim result in identical binaries.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6cec1f1b285fe48e81a961414fbc9978fa1003cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78178
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
During CSE firmware downgrade, data is cleared. To preserve PSR data
during downgrade, it needs to be backed up. Select
SOC_INTEL_CSE_LITE_PSR config to ensure PSR backup related flow is
executed on CSE Lite SKU.
BRANCH=None
BUG=b:273207144
TEST=Verify CSE firmware upgrade/downgrade on rex.
Change-Id: I39af029a5f0c018a5db3ac68191764abfa9518ac
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76115
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds eventlog entries for the below scenarios:
1. To indicate success or failure of PSR data back-up command
2. To indicate the loss of PSR data when CSE update is corrupted, and
data clear command is issued to clear the data.
3. To indicate the loss of PSR data when CSE boot partition info
response is corrupted and data back-up is not initiated.
BRANCH=None
BUG=b:273207144
TEST=Verify elog event added after PSR data backup command is sent
cse_lite: PSR_HECI_FW_DOWNGRADE_BACKUP command sent
...
ELOG: Event(B9) added with size 10 at 2023-06-27 06:44:49 UTC
Change-Id: I2459a2b941d28a87b6c78f75dbe8779d73328d7a
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Get PSR bit state using MKHI_FWCAPS_GET_FW_FEATURE_STATE HECI command
Use this bit info to check if SKU supports PSR and consequently issue
PSR_HECI_FW_DOWNGRADE_BACKUP command for PSR data backup during
downgrade.
BUG=b:273207144
TEST=build CB image and boot on google/rex board. Check for
"PSR is supported in this SKU" message in coreboot logs to confirm
that PSR bit is set in SKU
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I6e92341a9dc799146eb8f1a70b3a4a16fd1aa0ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
During CSE FW downgrade we erase CSE data. This would result in
Platform Service Record(PSR) data also to be erased.
To avoid losing PSR data we need to make a backup before data clear.
This patch sends PSR_HECI_FW_DOWNGRADE_BACKUP HECI command to CSE,
informing the CSE to backup PSR data before a data clear operation
during downgrade.
CMOS memory is used to track the backup status. PENDING is the default
state, it is updated to DONE once PSR_HECI_FW_DOWNGRADE_BACKUP HECI
command is sent.
PSR data can be backed up only post DRAM is initialized. The idea is to
perform cse_fw_sync actions in ramstage when PSR is enabled on a
platform. As part of the cse_fw_sync actions, when a firmware downgrade
is requested the command to back-up data is sent. Once the backup has
been done, trigger the firmware downgrade.
BRANCH=None
BUG=b:273207144
TEST=build CB image for google/rex board and check PSR backup command
is being sent during a CSE FW downgrade. Also check PSR data is not
lost/erased after a downgrade using intel PSR tool.
Change-Id: I135d197b5df0a20def823fe615860b5ead4391f8
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74577
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data. Since firmware downgrade
and PSR data backup flows involve global resets, there is a need to
track the PSR data backup status across resets. So adding a CMOS
variable for the same.
This patch implements API to access PSR backup status stored in CMOS.
The get API allows to retrieve the PSR backup status from CMOS memory.
The update API allows to update the PSR backup status in CMOS.
BRANCH=None
BUG=b:273207144
TEST=Able to retrieve PSR backup status across resets.
Change-Id: I270894e3e08dd50ca88e5402b59c211d7e693d14
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
CSE firmware downgrade and PSR data backup flows involve global resets,
there is a need to track the PSR data backup status across resets. In
the subsequent patches, a CMOS structure to store PSR back-up status
will be added.
The current SOC_INTEL_CSE_FW_PARTITION_CMOS_OFFSET of 68 can only store
cse_specific_info, as ramtop is at offset 100 and PSR back-up status
structure will not be able to fit within the range.
This patch overrides the SOC_INTEL_CSE_FW_PARTITION_CMOS_OFFSET to 161
to accommodate all CSE related info in adjacent CMOS memory.
BUG=b:273207144
TEST=Verify CSE RW FW versions are stored in CMOS memory in rex.
Change-Id: I8bae5245f93b99be15b4e59cfeffbc23eec95001
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78054
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Platform Service Record(PSR) will be enabled on Meteor Lake
platforms. cse_fw_sync actions happen in ramstage when PSR is enabled.
To avoid the boot time penalty of sending the cse_get_bp_info in
ramstage, call cse_fill_bp_info to get cse_bp_info response early in
romstage and store in cbmem. This data can be later used in ramstage.
BUG=b:273207144
TEST=Verify cse_bp_info is filled in romstage in rex.
Change-Id: Ic0e8fb34f21ff07e182a7b848d38e9d329010028
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data, and this command can be
sent only in post-RAM stages. So the cse_fw_sync actions needs to be
moved to ramstage.
Sending cse_get_bp_info command in ramstage takes additional boot time
of ~45-55ms on rex. To avoid the boot time penalty, this patch provides
an API to get the cse_bp_info in early romstage. The response data is
then migrated to cbmem once memory is initialized. The same data in
cbmem can be utilized in ramstage to perform other cse_fw_sync actions.
This patch also adds check to validate cse_bp_info in cbmem and avoids
sending the command again if the data is valid.
BUG=b:273207144
TEST=Verify the command works in early romstage, data is migrated to
cbmem and valid data is available in ramstage on rex.
Change-Id: Ib1e72c950ba0f4911924805f501ec1bd54b6ba3c
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78053
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Patrick Rudolph