Add an SVC call to get the state of Hardware Security Processor (HSP) in
AMD SoCs. This SVC call will be used from PSP verstage to get and
report HSP state.
BUG=b:198711349
TEST=Build Skyrim BIOS image and boot to OS. Ensure that the HSP state
is read and reported in the firmware logs.
Change-Id: I7fe3363d308a80cc09e6bdadd8d0bb1d67f7d2bf
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71207
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update settings for touchpad I2C frequency and data hold time.
I2C frequency and data hold time need to meet touchpad spec.
- I2C frequency: 380kHz - 400kHz
- Data hold time: 0.3us - 0.9us
BUG=b:262320419
TEST=On winterhold, touchpad i2c measurement from vendor,
Frequencies: 395 kHz, Data hold time: 0.66 us
Change-Id: I40fa6f9e88656d4ec02a4120f75a2a9413b5abaa
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Exposing the GPIOs via an ACPI PowerResource and the _CRS results in the
OS driver and ACPI thinking they own the GPIO. This can cause timing
problems because it's not clear which system should be controlling the
GPIO.
There's no reason to require explicit disablement however, so drop the
superfluous 'disable' flag, and change the _CRS generation to check if
the GPIOs will be exported via the 'has_power_resource' flag instead.
This mirrors the change made for drivers/i2c/generic.
TEST=untested, as no boards selected this option.
Change-Id: Icb60502a4a7c5e7a1fcf1ee60e23c77e00d6de7b
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71851
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Exposing the GPIOs via an ACPI PowerResource and the _CRS results in the
OS driver and ACPI thinking they own the GPIO. This can cause timing
problems because it's not clear which system should be controlling the
GPIO.
There's no reason to require explicit disablement however, so drop the
superfluous 'disable' flag, and change the _CRS generation to check if
the GPIOs will be exported via the 'has_power_resource' flag instead.
This mirrors the change made for drivers/i2c/generic.
TEST=untested, as no boards selected this option.
Change-Id: I4f95d0e453d89b7e1978d3efac304518304495d1
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71850
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Exposing the GPIOs via an ACPI PowerResource and the _CRS results in the
OS driver and ACPI thinking they own the GPIO. This can cause timing
problems because it's not clear which system should be controlling the
GPIO.
Previously, we flagged as an error any device which set the
'has_power_resource' flag but did not set 'disable_gpio_export_in_crs.'
There's no reason to require explicit disablement however, so drop the
superfluous 'disable' flag, and change the _CRS generation to check if
the GPIOs will be exported via the 'has_power_resource' flag instead.
BUG=b:265055477
TEST=build/boot skyrim, dump SSDT and verify touchscreen GPIOs only
listed under PRx, not under _CRS.
Change-Id: I837ae6c6fe4b8e1c4e10686406cba06bdb7759d2
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
There was a typo in the config disabling bootblock
should have been:
# CONFIG_VBOOT_STARTS_BEFORE_BOOTBLOCK is not set
As the line moved, it is the missing underscore after CONFIG,
preventing it from working as intended.
The other changes are updates to allow it to match what we get by
copying it to .config, then running:
make olddefconfig; make savedefconfig
Change-Id: Ic41a91e0a6ecd254a86d0872da19a0d4d321b8e3
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71840
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When pulling in commonlib/storage/pci_sdhci.c into herobrine, am
seeing an "error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]", so fixing that.
BUG=b:254092907
BRANCH=None
TEST=emerge-herobrine coreboot
Make sure that we can build without errors
Change-Id: Ib1718f156708a619f7eeb181e19b1a8c620de1f8
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71828
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
0xF8000000 was taken from old platform during phoenix porting, updating
it to 0xE0000000 to make room for 256 pci busses which is required for
usb4 and hotplug support. mmconf size gets set to 0x10000000 when 256
busses are used.
Change-Id: Ic143171f5650aff5db48c8f477d7aca3e7f5c1e7
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71870
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The smu_sx_entry function is identical for all AMD SoCs, so introduce it
as common code that can be selected to be included in the build via the
SOC_AMD_COMMON_BLOCK_SMU_SX_ENTRY Kconfig option. The only SoC-specific
difference in this function is the ID of the SMC_MSG_S3ENTRY message
which is defined in each SoC's soc/smu.h include file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I49758e9333a351d8e50e8f1b53a7f00fbe89866c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71875
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
If a discoverable device (e.g. a PCI device) does not appear in the
devicetree (typically because it is removable), coreboot enables it
by default. Disable the SATA2 (device for SATA ports 4 and 5, which
is not used in AHCI mode) and Thermal devices on W520 as well. Both
devices were only disabled on the T520.
Tested, this change fixes a long boot time when using MrChromebox's
edk2 payload on the W520, likely related to the following errors:
AHCI: Error interrupt reported PxIS: 40000001
Non data transfer failed at retry 0
AHCI: Error interrupt reported PxIS: 40000001
Non data transfer failed at retry 1
AHCI: Error interrupt reported PxIS: 40000001
Non data transfer failed at retry 2
AHCI: Error interrupt reported PxIS: 40000001
Non data transfer failed at retry 3
AHCI: Error interrupt reported PxIS: 40000001
Non data transfer failed at retry 4
Change-Id: I0b0483aae05fa84d97987a93db634b740f830e18
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71857
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested with the following drives:
- Crucial P5 Plus (CT500P5PSSD8)
- Kingston KC3000 (SKC3000S/512G)
- Sabrent Rocket NVMe 4.0 (SB-ROCKET-NVMEe4-500)
- Samsung 970 EVO (MZ-V7E250)
- Samsung 970 EVO Plus (MZ-V7S250)
- Samsung 980 PRO (MZ-V8P2T0)
- WD Black SN850X (WDS100T2XD0E)
- WD Blue SN580 (WDS500G2B0C)
- WD Green SN350 (WDS240G2G0C)
Test:
- Drive is functional and has no unrecoverable errors on boot
- Drive is functional and has no unrecoverable errors after S0ix
Change-Id: I51492c97c48f760d4aa9e4a2b2e57b0f1a06d090
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71662
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Tested with the following drives:
- Crucial P5 Plus (CT500P5PSSD8)
- Kingston KC3000 (SKC3000S/512G)
- Sabrent Rocket NVMe 4.0 (SB-ROCKET-NVMEe4-500)
- Samsung 970 EVO (MZ-V7E250)
- Samsung 970 EVO Plus (MZ-V7S250)
- Samsung 980 PRO (MZ-V8P2T0)
- WD Black SN850X (WDS100T2XD0E)
- WD Blue SN580 (WDS500G2B0C)
- WD Green SN350 (WDS240G2G0C)
Test:
- System still asserts `SLP_S0#` during suspend (power LED blinks)
- `slp_s0_residency_usec` still increases after suspend
Change-Id: I919d75cb2a88c0d623c46e44c506ec2d85567995
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
The DDR5 board is almost identical to the DDR4 one. The only major
difference is the board's DDR5 memory design.
TEST=Boot MSI PRO Z690-A board successfully to Ubuntu 22.04. Memory:
Crucial CT8G48C40U5.M4A1 in all 4 slots.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I652a879d1616df4708fe4690797ad98384897f53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Use 'enum cb_err' values for below cse lite functions instead of true or
false.
Functions whose return values updated in this patch:
1. cse_set_next_boot_partition()
2. cse_data_clear_request()
3. cse_set_and_boot_from_next_bp()
4. cse_boot_to_rw()
5. cse_fix_data_failure_err()
TEST= Do boot test on Gimble.
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I7fec530aeb617bab87304aae85ed248e51a6966b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71822
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
