1. Extend 1 bit [34] for the TOUCHSCREEN_SOURCE.
SSFC range for TOUCHSCREEN_SOURCE is bit[32:34].
2. Touchscreen panel: MUTTO A153728S1Y,
and set TOUCHSCREEN_ILIT2901 to value "4"
3. Datasheet: #153728S1V1.0 SPEC_20240923.pdf
BUG=b:375986645
BRANCH=firmware-nissa-15217.B
TEST=1. emerge-nissa coreboot chromeos-bootimage
2. Confirm command evtest and touchscreen function is workable.
Change-Id: I6e13c948edca5a894e1a00a1954f0f88c4a079cf
Signed-off-by: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84894
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add API to get Power Delivery (PD) Chip info which includes vendor ID,
product ID and firmware version(if any).
BUG=None
TEST=Build Brox BIOS image and boot to OS.
Change-Id: I4cc4493ac64d44076877fee633488c95cd09807e
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
commit 6c83a71b0a ("skl mainboards/dt: Move usb{2,3}_ports settings
into XHCI device scope") not only moved the USB port definitions under
the XHCI device reference, but also combined multiple register
definitions. In doing so, it broke the inheritance from the baseboard,
since the variant overridetree registers now replaced the entire
usb2_ports/usb3_ports structs, rather than replacing individual array
elements therein. This resulted in any USB ports inherited from the
baseboard and not overridden by the variant being non-functional as they
were not included in the resulting combined devicetree.
To fix this, return to overriding individual array elements in the
usb2/3_ports structs.
TEST=build/boot google/fizz/var/karma. Verify all USB ports present and
functional. Verify mainboard/static.c in built shows all ports.
Change-Id: I0e80bf4949a857c21d44537eb720a7a8a7db2f80
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84955
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch configures the ESPI_SOC_ALERT_L GPIO pad on fatcat as
NC to enable S0ix low power entry.
TEST=Build fatcat and check the platform boots without an issue.
Change-Id: Icb80a56177105c0281d05fe1f5daa87e6f7e291f
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84957
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.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.
TEST=Build fatcat and check the platform boots without an issue.
Change-Id: I01f2cb8ac1093ae98cc076e35ad1924baa53aa59
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
1. Modify the I2C frequency of the touchpad between 380 Khz and
400 Khz to meet the spec.
2. Increase clk the time of high (TH) to greater than 600ns.
Before:
I2C0 - 420KHz
TH - 557ns
After:
I2C0 - 398Khz
TH - 630ns
BUG=b:351968527
TEST=Check that the wave form meets the spec.
Change-Id: I5ccaa3a669e18319311de14833966410c7adf40d
Signed-off-by: Hualin Wei <weihualin@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84898
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Weimin Wu <wuweimin@huaqin.corp-partner.google.com>
Add Micron part MT62F2G32D4DS-020 WT:F only for Francka.
DRAM Part Name ID to assign
MT62F2G32D4DS-020 WT:F 0 (0000)
BUG=b:373394046
TEST=emerge-fatcat coreboot
Change-Id: I2de56c8c7a028edefbd3dc53f8b1e26dee3286f7
Signed-off-by: Amanda Huang <amanda_hwang@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84781
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The size of the inner array of the 2-dimensional array pad_funcs should
be 4 instead of SPI_BUS_NUMBER (6). This bug leads to two extra
gpio_set_mode() calls with unexpected GPIOs.
Inspecting spi.o, the data immediately after the .rodata.pad_funcs
section is .rodata.spi_ctrlr_bus_map, with the following data:
00000428 00 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00
00000438 00 00 00 00 00 00 00 00 ...
This is equivalent to the following calls:
gpio_set_mode(GPIO(GPIO05), 0);
gpio_set_mode(GPIO(GPIO00), 0);
The second call is already included in the pad_funcs array, so the first
call is the only practical impact of this bug.
Change-Id: I9c44f09b3cdadbbf039b95efca7144f213672092
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
If the mainboard expects upcoming reset, then skip the reset after
disabling UFS. This will reduce the number of resets during firmware
update.
BUG=b:375444631
TEST=Build Brox BIOS image and boot to OS. Perform a firmware update and
confirm that the number of reset is reduced by 2 resets.
Change-Id: I4399555302ec23a76f89f406f437f311eea0ef99
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84935
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Select SOC_INTEL_RAPTORLAKE to force coreboot to use the RPL FSP
headers for FSP as banshee is using a converged firmware image.
This effort also helps to save banshee boot time by 80-100ms as
RPL FSP is better optimized.
Additionally, Raptor Lake platform only needs 1 SIPI-SIPI which
saves 10ms of the boot time.
BUG=b:358254132
TEST=Able to build and boot google/banshee.
cold boot time w/o this CL
```
Total Time: 1,399,888
```
cold boot time w/ this CL
```
Total Time: 1,295,334
```
Change-Id: If22e07a4c1b35fe1d060ca523743c6c503937287
Signed-off-by: Ian Feng <ian_feng@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84949
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
From power team's recommendation, increase the VccIn Aux Imon IccMax
to 30A to meet HW settings.
BUG=b:376306118
TEST=Build firmware and check the value is changing as expected.
Paste the firmware log.
[SPEW ] VccInAuxImonIccImax= 0x78
[SPEW ] (MAILBOX) VccInAuxImonIccImax = 120 (1/4 Amp)
[INFO ] Override VccInAuxImonIccImax = 120
Change-Id: I71020c2f631cb517a52d4bb65e35277eb731ced7
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
According to the PCIe CEM specification, the deassertion of PERST#
should occur at least 100ms after the assertion. Right now we simply
wait for 100ms in ramstage for that.
To speed up the boot time, pre-initialize PCIe by asserting PERST#
earlier in the bootblock stage. The pre-initialization time is stored
in the early init data region, so that the PCIe initialization in
ramstage could make sure the required 100ms delay is still reached.
This pre-initialization will speed up the boot time by 100ms on rauru.
TEST=Build pass, show pcie init pass log:
mtk_pcie_domain_enable: PCIe link up success (1)
BUG=b:317009620
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: I2b84c25ae3ea9069fd38fa6b20b8235a7fc3a484
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
We want to configure different VBT timings for panels of different sizes
and distinguish them through SSFC. We select the reserved bit 6 of SSFC
as the flag bit. When using a 12-inch panel, set this bit to 0; when
using an 11-inch panel, set this bit to 1.
Without splitting, the platform_BootPerf test will fail.
BUG=b:374428465
TEST=
1. can match VBT with SSFC
-When SSFC is set to 0x40:
$ cat /sys/firmware/log | grep vbt
Bit 6 of SSFC is 1, use vbt-teliks_panel_11_inch.bin
CBFS: Found 'vbt-teliks_panel_11_inch.bin' @0x1c6140 size 0x50f in mcache @0x76adda14
-When SSFC is set to 0x0:
$ cat /sys/firmware/log | grep vbt
Bit 6 of SSFC is 0, use vbt-teliks.bin
CBFS: Found 'vbt-teliks.bin' @0x1c5bc0 size 0x50e in mcache @0x76add9b0
2. can pass platform_BootPerf test
The platform_BootPerf time measured for all SKUs is less than 1.55s.
Change-Id: Ia8fb45aede5ead4826d983760506c366a70643ee
Signed-off-by: Qinghong Zeng <zengqinghong@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84871
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jianeng Ceng <cengjianeng@huaqin.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This commit adjusts the EC host command range for the Fatcat board to
0x800-0x807 & 0x200-0x20f.
This change is necessary because the microchip EC used on the Fatcat
board has a smaller host command range than the ITE/Nuvoton ECs used
on other Fatcat variants.
The `gen1_dec` register in the devicetree is updated to reflect this
change.
As per boot log, the `gen1_dec` aka offset 0x84, base address is 800
and size is 8 bytes.
AP FW Boot log:
[SPEW] PCI: 00:00:1f.0 resource base 800 size 8 align 0 gran 0 limit 0 flags c0000100 index 84
BUG=b:376207365
TEST=Able to build and boot google/fatcat w/o any error.
without this patch:
[SPEW ] LPC: Trying to open IO window from 800 size 8
[ERROR] LPC: Cannot open IO window: 800 size 8
[ERROR] No more IO windows
with this patch:
[SPEW ] LPC: Trying to open IO window from 800 size 8
Change-Id: Ifcee533341fa583d841a4b564f25831c6d04e951
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84919
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
This patch implements the `save_dimm_info()` API to populate and pass
DRAM-related information to the next stage. This information
is used to generate the SMBIOS memory table, providing details about
installed DIMMs.
This addresses the issue where SMBIOS lacked detailed DIMM information.
Verified that `dmidecode` correctly dumps the DIMM information from the
SMBIOS table after this change.
BUG=b:376103463
TEST=Built and booted successfully. Verified DIMM info in SMBIOS using
`dmidecode`.
> dmidecode -t 17
```
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
Handle 0x000B, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2 GB
Form Factor: Row Of Chips
Set: None
Locator: Channel-0-DIMM-0
Bank Locator: BANK 0
Type: LPDDR5
Type Detail: Unknown Synchronous
Speed: 6400 MT/s
Manufacturer: Hynix
Serial Number: 00000000
Asset Tag: Channel-0-DIMM-0-AssetTag
Part Number: H58G56BK7BX068
Rank: 1
Configured Memory Speed: 6400 MT/s
Minimum Voltage: 0.5 V
Maximum Voltage: 0.5 V
Configured Voltage: 0.5 V
...
...
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2 GB
Form Factor: Row Of Chips
Set: None
Locator: Channel-3-DIMM-0
Bank Locator: BANK 0
Type: LPDDR5
Type Detail: Unknown Synchronous
Speed: 6400 MT/s
Manufacturer: Hynix
Serial Number: 00000000
Asset Tag: Channel-3-DIMM-0-AssetTag
Part Number: H58G56BK7BX068
Rank: 1
Configured Memory Speed: 6400 MT/s
Minimum Voltage: 0.5 V
Maximum Voltage: 0.5 V
Configured Voltage: 0.5 V
```
Change-Id: I3b942610272de401589ee0463de9cd0985974774
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch adds ACPI names for the following devices:
- THC0 (PCI: 00:10.0)
- THC1 (PCI: 00:10.1)
- SRAM (PCI: 00:14.2)
- FSPI (PCI: 00:1f.5)
TEST=Able to build and boot google/fatcat without any error.
w/o this patch:
[ERROR] Missing ACPI Name for PCI: 00:10.0
[ERROR] Missing ACPI Name for PCI: 00:10.1
[ERROR] Missing ACPI Name for PCI: 00:14.2
[ERROR] Missing ACPI Name for PCI: 00:1f.5
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I474089607522a4bd13375cc34b8f8645ca3663d9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84910
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This change sets the SMBUS device to min sleep state D0 in the ACPI
sleep state table.
TEST=Able to build and boot google/fatcat.
w/o this patch:
[WARN ] Unknown min d_state for PCI: 00:1f.4
w/ this patch:
No Error or Warning.
Change-Id: If84d2ee8abfef34f6411e01e6c37d4e2008a3666
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84909
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit defines the EC_SYNC_IRQ and GPIO_PCH_WP macros for
different Fatcat variants.
The EC_SYNC_IRQ macro is used for tight timestamps and wake support,
while the GPIO_PCH_WP macro is used for the WP signal to the PCH.
These macros were previously undefined or incorrectly defined for some
variants. This commit fixes these issues and ensures that the macros
are defined correctly for all variants.
Specifically, this commit:
- Defines EC_SYNC_IRQ and GPIO_PCH_WP for Fatcat Nuvo and Fatcat ITE.
- Defines EC_SYNC_IRQ as 0 (not connected) for Fatcat.
- Defines GPIO_PCH_WP as GPP_D02 for Fatcat.
- Leaves EC_SYNC_IRQ and GPIO_PCH_WP as 0 (TODO) for Francka.
TEST=Able to build and boot google/fatcat.
w/o this patch:
```
cros_ec_lpcs GOOG0004:00: couldn't retrieve IRQ number (-22)
cros_ec_lpcs GOOG0004:00: probe with driver cros_ec_lpcs failed with error -22
```
w/ this patch:
```
cros_ec_lpcs GOOG0004:00: Chrome EC device registered
```
Change-Id: I9bd248496f08869c08cf6daafeed6584d0b166b7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84900
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
This patch updates the flash map layout to guarantee that the
RW_SECTION_B section starts at the 16MB boundary.
Additionally, fix typo in flash descriptor comment, where comment
incorrectly referred to "MTL" instead of "PTL".
TEST=Successfully builds google/fatcat.
Change-Id: Ia6dba611fba50f9694a75670d954a4630cde4d70
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84899
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This to fix the error when using C23:
cannot cast an object of type 'nullptr_t' to 'uintptr_t' (aka 'unsigned long')
return (uintptr_t)NULL;
^
Change-Id: Ibdc8794513a508fc61a5046692f854183c36b781
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84893
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Use the resource size to determine Vtd BAR size and drop the code to
calculate the Vtd BAR size.
While on it do not truncate the resource address to 32-bit, since the
DMAR entry is 64-bit wide anyway.
TEST: Booted on intel/archercity_crb
Change-Id: Ibaadc25c44345ba2eb9e6f75989d32b43d00d7a5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Align DSDT names with SSDT naming scheme, as provided by
iio_domain_set_acpi_name() and hide unused devices by implementing
the _STA method as done on newer platforms.
Change-Id: I8488907f28a78a6f71046dba54ba9cbd4b0652eb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Get rid of some helper functions by properly using a pci_driver.
Configure SAD if necessary and lock SAD if necessary in the newly added
SAD PCI driver. This allows to drop lock_pam0123(), unlock_pam_regions()
and socket0_get_ubox_busno().
- Fixes SAD instance on secondary sockets not decoding the C-F segments
as DRAM, which would prevent those sockets to access the ACPI/SMBIOS
table anchor
- Adds PCI multi segment support
(SKX and CPX only, other were working properly already)
- Moves locking of PAM0123_CSR and PAM456_CSR from SoC to driver code
Change-Id: I167b6ce48631fe3f97359ee33704f52ca854dbd1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84794
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set characteristics 1 based on slot type and scan PCI capabilities
to update the characteristics 2 field in SMBIOS type 9 accordingly.
Change-Id: If96e0381b10c25cf73b3797a0f02a40dc933993e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78292
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Add a helper method to read the PME capability.
Will be used in the following commit.
Change-Id: Id1fdc98c9ce86d3ddf8056bb609afc58008cf2e9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84793
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Add the code to request the provisioning of the RPMC root key from the
PSP. When RPMC hasn't already been provisioned enabled and the PSP has
detected a SPI flash chip that both supports RPMC and has monotonic
counters that can still be provisioned, we send the PSP mailbox command
to request the RPMC provisioning and then reset the system, so the PSP
can do the actual provisioning.
TEST=On an out of tree AMD reference board using the Cezanne SoC code,
provisioning RPMC works as expected when selecting the corresponding
PERFORM_RPMC_PROVISIONING Kconfig option:
1st boot to initiate the RPMC provisioning:
[DEBUG] PSP: Querying PSP capabilities...OK
[DEBUG] PSP: Querying HSTI state...OK
[SPEW ] RPMC isn't provisioned
[SPEW ] SPI flash supports RPMC
[SPEW ] RPMC revision 0
[SPEW ] PSP NVRAM isn't healthy
[SPEW ] PSP NVRAM is using RPMC protection
[SPEW ] SPI flash RPMC counter 0 can still be provisioned
[SPEW ] SPI flash RPMC counter 1 can still be provisioned
[SPEW ] SPI flash RPMC counter 2 can still be provisioned
[SPEW ] SPI flash RPMC counter 3 can still be provisioned
[SPEW ] SPI flash RPMC counter 0 is in use
[SPEW ] SPI flash RPMC counter 1 is not in use
[SPEW ] SPI flash RPMC counter 2 is not in use
[SPEW ] SPI flash RPMC counter 3 is not in use
[SPEW ] SoC RPMC slot 0 can still be provisioned
[SPEW ] SoC RPMC slot 1 can still be provisioned
[SPEW ] SoC RPMC slot 2 can still be provisioned
[SPEW ] SoC RPMC slot 3 can still be provisioned
[DEBUG] RPMC: perform fusing using RPMC counter address 0
[DEBUG] OK
[NOTE ] RPMC: Rebooting
[INFO ] warm_reset() called!
2nd boot after the provisioning is done:
[DEBUG] PSP: Querying PSP capabilities...OK
[DEBUG] PSP: Querying HSTI state...OK
[SPEW ] RPMC is provisioned
[SPEW ] SPI flash supports RPMC
[SPEW ] RPMC revision 0
[SPEW ] PSP NVRAM isn't healthy
[SPEW ] PSP NVRAM is using RPMC protection
[SPEW ] SPI flash RPMC counter 0 has already been provisioned
[SPEW ] SPI flash RPMC counter 1 can still be provisioned
[SPEW ] SPI flash RPMC counter 2 can still be provisioned
[SPEW ] SPI flash RPMC counter 3 can still be provisioned
[SPEW ] SPI flash RPMC counter 0 is in use
[SPEW ] SPI flash RPMC counter 1 is not in use
[SPEW ] SPI flash RPMC counter 2 is not in use
[SPEW ] SPI flash RPMC counter 3 is not in use
[SPEW ] SoC RPMC slot 0 has already been provisioned
[SPEW ] SoC RPMC slot 1 can still be provisioned
[SPEW ] SoC RPMC slot 2 can still be provisioned
[SPEW ] SoC RPMC slot 3 can still be provisioned
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia7760c0bf7618ca60ef160329d0110ac8109032a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84707
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the code to query the status of the replay-protected monotonic
counter (RPMC) infrastructure from the PSP and display it in a decoded
form.
Certain SPI flash chips have 4 32-bit monotonic counters in addition to
the actual flash storage. During the RPMC root key provisioning process,
which is done at the end of manufacturing, a 256 bit RPMC root key is
generated by the PSP and programmed into both SoC fuses and the RPMC SPI
flash chip. After that, commands to read or increment the monotonic
counters can be sent to the SPI flash which are protected by a
HMAC-SHA-256 signature using a key derived from the provisioned RPMC
root key.
The code to do the RPMC provisioning is added in a follow-up patch.
TEST=On an out of tree AMD reference board using the Cezanne SoC code
and with the SOC_AMD_COMMON_BLOCK_PSP_RPMC Kconfig option selected, the
newly added code prints this on the console after the provisioning was
done:
[DEBUG] PSP: Querying PSP capabilities...OK
[DEBUG] PSP: Querying HSTI state...OK
[SPEW ] RPMC is provisioned
[SPEW ] SPI flash supports RPMC
[SPEW ] RPMC revision 0
[SPEW ] PSP NVRAM isn't healthy
[SPEW ] PSP NVRAM is using RPMC protection
[SPEW ] SPI flash RPMC counter 0 has already been provisioned
[SPEW ] SPI flash RPMC counter 1 can still be provisioned
[SPEW ] SPI flash RPMC counter 2 can still be provisioned
[SPEW ] SPI flash RPMC counter 3 can still be provisioned
[SPEW ] SPI flash RPMC counter 0 is in use
[SPEW ] SPI flash RPMC counter 1 is not in use
[SPEW ] SPI flash RPMC counter 2 is not in use
[SPEW ] SPI flash RPMC counter 3 is not in use
[SPEW ] SoC RPMC slot 0 has already been provisioned
[SPEW ] SoC RPMC slot 1 can still be provisioned
[SPEW ] SoC RPMC slot 2 can still be provisioned
[SPEW ] SoC RPMC slot 3 can still be provisioned
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I498eec58189da710b725ac6575c68ba7ab0bcc43
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84706
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The functions psp_get_ftpm_capabilties, psp_get_hsti_state, and
psp_get_psp_capabilities which were added in commit 5e7ab1a233
("soc/amd/common/psp: add helper functions to retrieve capability bits")
have a bug in the 'cmd_status' error handling logic. In case of an
error, 'cmd_status' is non-zero, while the check somehow expected the
opposite. Fix the bug by returning an error if 'cmd_status' is non-zero.
Change-Id: Iafcd185ec4a8a4c0e463b0ac5bac3ef78a0af305
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84836
Reviewed-by: Ana Carolina Cabral
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
When creating variant, it was copied from teliks, and according to the requirements of telith project, update the override devicetree to use ELAN touchscreen.
BUG=b:373510302
BRANCH=None
TEST=1. emerge-nissa coreboot chromeos-bootimage
2. power on proto board successfully
3. touchscreen is functional
Change-Id: If0da85a38f3a68b6f50cfd096a628174b313fcc9
Signed-off-by: Kun Liu <liukun11@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84865
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Create the rull variant of the nissa reference board by copying
the template files to a new directory named for the variant.
And based on schematics NB7559_MB_SCH_V1_2024_1010.pdf
update devicetree settings.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0)
BUG=b:374673463
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_RULL
Change-Id: If48273f3e9db69507b41ea0313916d94ecabe309
Signed-off-by: Rui Zhou <zhourui@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84828
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This change enables the integrated GPU (iGPU) display on the Fatcat
board based on the FW_CONFIG setting (specifically the DISPLAY bit).
By conditionally probing the display based on FW_CONFIG, the iGPU
is dynamically enabled or disabled according to the SKU configuration.
TEST=Verified display functionality on Fatcat with the iGPU:
> cbi set 6 0x58A814 4 (DISPLAY_ABSENT):
- lspci does not list the iGPU.
- No display output, but the device boots to the OS (verified via
console).
> cbi set 6 0x5CA814 4 (DISPLAY_PRESENT):
- lspci lists the iGPU.
- Display output is functional, showing firmware and OS UI.
Change-Id: I5762adf5ec8a86a00c16544670cb2f998055bd35
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84877
Reviewed-by: Jayvik Desai <jayvik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
The iGPU device is enabled by default in the Pantherlake chipset
configuration. Remove the redundant device entry in the Fatcat
devicetree.
This change ensures that the iGPU remains enabled without explicit
configuration in the board-specific devicetree.
TEST=Able to build google/fatcat and able to see firmware and OS
display/UI.
Change-Id: I9a2ec9b47acb389f5bb6b30e61352aaefa327328
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84876
Reviewed-by: Jayvik Desai <jayvik@google.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Add a trivial mainboard_needs_pcie_init implementation that always
return true. For now, the storage types of rauru SKUs are still unknown.
TEST=Build pass, show pcie init pass log:
mtk_pcie_domain_enable: PCIe link up success (1)
BUG=b:317009620
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: I6b4f08e15f62da18aa37226075894f2827a9e7ba
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84697
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add PCIe driver for MT8196 platform.
According to the PCIe CEM specification, the deassertion of PERST#
should occur at least 100ms after the assertion. To ensure the 100ms
delay requirement is met and to save delay time in the ramstage, add
an early init data region to store the elapsed time since assertion.
This will speed up the boot time by 100ms.
PCIe port 1 and port 2 share the same PCIe resources, but PCIe port 2 is
not used. Therefore, in mtk_pcie_pre_init(), make sure PCIe port 2 is
reset to prevent interference with PCIe port 1.
TEST=Build pass, show pcie init pass log:
mtk_pcie_domain_enable: PCIe link up success (1)
BUG=b:317009620
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: I826a96822e88972bcd4966b6681797a646adf3d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
This code is never reached since the hardware uses different SoCs.
Besides, mainboard specific code should not be added to SoC code.
Change-Id: Id82d5d0b829442c35c093974c06a029259838a9a
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This commit improves the debug messages when initializing SPI flash
windows by adding the window type (Fixed Decode or Extended Decode)
to the log output.
This makes it easier to understand which window is being initialized
and can help with debugging issues related to SPI flash access.
w/o this patch:
[INFO ] MMAP window: SPI flash base=0x1000000, Host base=0xff000000, Size=0x1000000
[INFO ] MMAP window: SPI flash base=0x900000, Host base=0xf9900000, Size=0x700000
w/ this patch:
[INFO ] Fixed Decode Window: SPI flash base=0x1000000, Host base=0xff000000, Size=0x1000000
[INFO ] Extended Decode Window: SPI flash base=0x900000, Host base=0xf9900000, Size=0x700000
Change-Id: I904f70f42fa70ea06e6f49bd44631a8491463207
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84868
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Ideally lock configuration is not applicable for early GPIO
configuration (like bootblock/romstage) and is only required for GPIO
PAD configuration by later statge (like ramstage).
The GPP_D15 pin was previously configured with LOCK_CONFIG in the
early bootblock GPIO configuration. This is not necessary and prevents
later boot stages from configuring this GPIO.
Change-Id: Ie0e648b750d7579def39ed95eab862dc3245499c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Cliff Huang <cliff.huang@intel.com>
BUG=b:348678529
TEST=on Google Fatcat board. Set the proper CBI fw_config bit(s) and
check that the corresponding GPIO PADs are configured as expected
value accordingly.
Change-Id: I914f73ff06bfb801fc319b45b23d7ce4cb7a6d54
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84408
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aamir Bohra <aamirbohra@google.com>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch updates the flash map layout to guarantee that the
RW_SECTION_B section starts at a 16MB boundary.
TEST=Successfully builds google/fatcat.
Change-Id: I74ea21a8a4107d438bc03a0da182ea7e991e74bc
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84821
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
