This change only enables the IOMMU device. We still require the IVRS
table to take advantage of the IOMMU. This will happen when the picasso
IVRS code is moved into common.
BUG=b:190515051
TEST=lspci shows IOMMU device
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 1631
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I5c7cae3d25af5a45d48658ffa948a2856adc4346
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The Majolica UEFI ACPI tables have this listed as shared. It's already a
level interrupt, so no reason it shouldn't be shared.
This change makes it so Windows can correctly initialize the GPIO
controller.
BUG=b:186212501
TEST=Boot guybrush to windows and see GPIO controller functional. Also
boot guybrush to windows and verify GPIO controller still works.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I48c6d548a2a8d67599f25e37eeafc90764d9e2d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Allow hot plug devices to subscribe to IOMMU services. Currently the
IOMMU end range is limited to device B:0 D:1f F:6. This prevents the
devices on bus 1 and higher to subscribe to IOMMU services. As per AMD
IOMMU spec v3 section 5.2.2.1 all possible device IDs must be defined,
whether the device ID is actually populated or not. Device entries are
used to report ranges when hot-plug and SR-IOV devices are possible.
With this change the hot plug devices can now bind to IOMMU services
(as tested on kernel v5.4), and below errors are not seen in dmesg.
AMD-Vi: Event logged [IO_PAGE_FAULT device=04:00.3 domain=0x0000]
AMD-Vi: Event logged [IO_PAGE_FAULT device=05:00.0 domain=0x0000]
AMD-Vi: Event logged [IO_PAGE_FAULT device=04:00.4 domain=0x0000]
TEST= Verify dGPU can enumerate on hotplug. No IO page fault errors seen.
The hot plug devices can successfully bind to IOMMU services in
kernel.
Signed-off-by: Aamir Bohra <aamirbohra@gmail.com>
Change-Id: I256c0f8032662674a4d75746de49c250e341c579
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55816
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-by: ritul guru <ritul.bits@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
BUG=none
TEST=Boot with CONSOLE_LOGLEVEL_3 and no longer see the message printed.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I0bdb92f547ceb8be624521211f4a3b94a91dae22
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55972
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
We are currently reading the uCode for each CPU. This is unnecessary
since the uCode never changes.
BUG=b:177909625
TEST=Boot guybrush and see "microcode: being updated to patch id" for
each CPU. I no longer see CBFS access for each CPU. This drops device
initialization time by 32 ms.
Also boot Ezkinil and verify microcode was also updated.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I98b9d4ce8290a1f08063176809e903e671663208
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Start using the custom boot device.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4ae7272677f563e8827ba154fe5177c8c01155c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This is a copy of mmap_boot.c and mem_rdev_ro_ops. I split it up so it
was easier to review.
The next patches will add support for the SPI DMA controller. This will
provide a minor speed up vs using mmap reads. It will also provide the
facilities to perform asynchronous SPI loading.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Id26e2a69601d0f31e256d0010008904a447c8e21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Introduce the `ARCH_ALL_STAGES_X86` Kconfig symbol to automatically
select the per-stage arch options. Subsequent commits will leverage
this to allow choosing between 32-bit and 64-bit coreboot where all
stages are x86. AMD Picasso and AMD Cezanne are the only exceptions
to this rule: they disable `ARCH_ALL_STAGES_X86` and explicitly set
the per-stage arch options accordingly.
Change-Id: Ia2ddbae8c0dfb5301352d725032f6ebd370428c9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
To generalise the choice of 32-bit or 64-bit coreboot on x86 hardware,
have platforms select `ARCH_X86` directly instead of through per-stage
Kconfig options, effectively reversing the dependency order.
Change-Id: If15436817ba664398055e9efc6c7c656de3bf3e4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
With two versions of *speed_mhz_to_reported_mts() we need to call the
correct one based on the reported memory type.
BUG=b:184124605
TEST="dmidecode --type 17" in OS on Guybrush
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Change-Id: I92e834097546e3ef7130830444a80f818bdea3d5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55852
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When initializing espi early, there may be mainboard requirements to
configure the bus properly. This allows the mainboard to do that.
BUG=192100564
TEST=Build along with next patch, eSPI works on guybrush
Change-Id: Icc02877a09b8f8ed20fd1b04f3cee0509f1a85c5
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55863
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
In order to support Audio Co-processor (ACP) DMIC hardware runtime
detection on the platform, ACPI _WOV method is populated on the
concerned ACP device. This method returns the ACPI Integer value as 1
if ACP DMIC exists on the platform.
BUG=b:182960979
TEST=Build and boot to OS in guybrush. Ensure that the _WOV ACPI method
is populated under the scope of ACP device.
Scope (\_SB.PCI0.GP41.ACPD)
{
Method (_WOV, 0, NotSerialized)
{
Return (One)
}
}
Change-Id: Ide84f45f5ea2ae42d5efe71ac6d1595886157045
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55029
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the NO_EARLY_BOOTBLOCK_POSTCODES config option is enabled, configure
eSPI as early as possible in the x86 boot sequence.
We found that there are situations that can cause the system to hang if
there are any port80h postcodes sent out before eSPI is initialized.
BUG=b:191370340
TEST=Build & Boot with and without NO_EARLY_BOOTBLOCK_POSTCODES enabled.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I0badb1c529e96ee4f81134287db53ce32473de6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55732
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The original reason the BERT table was moved out of CBMEM was because
the OS was not able to access the region. This happened because the
CBMEM region was marked as type 16 in the e820 table. The OS isn't aware
of this type, so it prevents any drivers from accessing it. Depthcharge
now correctly labels the CBMEM region as reserved in the e820 table so
we can move the BERT table into CBMEM.
TEST=BERT ACPI table generation still works on AMD/Mandolin with SeaBIOS
as payload and BERT region inside CBMEM is inside a BIOS-e820 reserved
range. BERT generation also works on Zork with depthcharge.
Link: https://crrev.com/c/2939677
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie640e91c19ae5f9b275cc333284b4be34211fbf6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Our existing native function gpio configuration macro (PAD_NF) only sets
the pull. For PCIe reset, we now need to be able to set it to its
native function (PCIE_RST_L), and drive it low, then high.
BUG=b:182805349
TEST=Configure GPIO, see correct behavior.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I636371517c99f94f76834abc4575795d51aa0368
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55652
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Pass the info if the non-graphics HD audio controller device is enabled
or disabled in the board's devicetree via a UPD to the FSP so that it
knows if it should enable or disable the corresponding device.
TEST=When adding "device ref hda on end" to the devicetree of
amd/majolica the non-graphics HD Audio controller shows up in lspci and
when that line isn't added the PCIe device doesn't show up.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9f5e164d308906bfc788e5c2674c13c7b2ebf471
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Currently the FSP only has one switch to disable both AHCI controllers.
If at least one of the two AHCI controller devices is enabled in the
board's devicetree, set the SATA enable UPD to 1 and otherwise set it to
0. Setting the UPD value to 0 when both AHCI controllers are disabled
saves around 60ms in boot time.
BUG=b:191385289
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I84e7c8bf2ab08c8254271ddfefd2e4e7d8c2e87b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55669
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Matt Papageorge <matthewpapa07@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using existing defines instead of magic values improves readability of
the code. Also add comments to the MADT IRQ overrides to make it clearer
what those actually do.
TEST=Timeless build results in identical binary for amd/gardenia
(Stoneyridge), amd/mandolin (Picasso) and amd/majolica (Cezanne)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I224ffbe8eb65bcdd5fc70c0ff8b15d55b3f6be01
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55613
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Factoring out those defines brings the Stoneyridge SoC code a bit more
in line with the Cezanne and Picasso SoC code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifba7f13cc926ac28376233aa0bf317164ca9bbd6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55588
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the default state of the MMIO UART devices in the chipset
devicetree is off, the mainboard devicetree entries that disable MMIO
UART devices are removed.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I913a587802020ce4e182b48632cdde1104c2a6e6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55545
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating the APOB takes a considerable amount of time. I decided to be
granular and split out the operations so we know when we read vs read +
erase + write.
BUG=b:179092979
TEST=Boot guybrush and dump timestamps
3:after RAM initialization 3,025,425 (44)
920:starting APOB read 3,025,430 (5)
921:starting APOB erase 3,025,478 (48)
922:starting APOB write 3,027,727 (2,249)
923:finished APOB 3,210,965 (183,238)
4:end of romstage 3,210,971 (6)
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I08e371873112e38f623f452af0eb946f5471c399
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
In acpi_soc_get_bert_region after the bert_errors_region call is was
checked if the region parameter is NULL after the call; since region is
a parameter of acpi_soc_get_bert_region, it's non-NULL. What we should
be checking here is if region points to a non-NULL pointer.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reported-by: Coverity (CID:1457506)
Change-Id: I0523504d65725ab2d2df4db28a5dedd90697b917
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Even though the code is currently commented out, replace the magic
numbers with the existing defines.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id0dbbadf71f2e5a4d23ee998e2aa0a8b67205845
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55534
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Factoring out those defines allows using them easily in the ACPI code
without having to use preprocessor macros.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib9dfddb0d4f32a542fa652ff8c14e932c224f247
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Factoring out those defines allows using them easily in the ACPI code
without having to use preprocessor macros.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I99cb03de8782a0eeeb505f567b982099b0e8a18d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Part of the soc/amd/stoneyridge code already uses the FCH_IOAPIC_ID and
GNB_IOAPIC_ID defines. Use those defines in the remaining location to
make sure that the IOAPIC IDs are always consistent between the hardware
register, the MADT and the IVRS ACPI tables.
TEST=Timeless build of amd/gardenia results in identical binary.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I410a6560de66889b153c8a66b8dc5474ac114ba7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Enable generation of DMI Type 17 data on Cezanne.
BUG=b:184124605
TEST="dmidecode --type 17" in OS on Majolica
Change-Id: Iaa89ee1ce6efa0280f17a443e07571a1190873a6
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Move dmi.c code to common/fsp to be shared among different SOCs.
BUG=b:184124605
Change-Id: I46071556bbbbf6435d9e3724bba19e102bd02535
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52746
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
if VBOOT_STARTS_BEFORE_BOOTBLOCK is set, call boot_with_psp_timestamp to
migrate PSP timestamps into x86 timestamp table.
Signed-off-by: Kangheui Won <khwon@chromium.org>
Change-Id: I4d51802145263145d40908889de29147af54f50f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The warm reset bit in the NCP_ERR register doesn't behave as the PPR [1]
suggested; no matter if something was written to the register, the
NCP_WARM_BOOT bit never got set and the NCP_ERR register in I/O-space
always reads back as 0x7f.
[1] checked with PPR for AMD Family 19h Model 51h A1 (CZN) #56569 Rev
3.01
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I569372db9f36ec7bbc741f4d7312ade312daa70b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55101
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On Linux, in order to set wake alarms >24 hours, the RTC Date Alarm
field must be set to a valid non-zero value. If not, there are two
consequences:
1. Alarms >24 hours don't work
2. The kernel will refuse to enter suspend because it can't resume as
expected to service the alarm.
Since the RTC Date Alarm and RTC AltCentury fields are supported on
Stoneyridge, set them.
This is a mirror of commit 041fcf5902
("soc/amd/picasso/acpi: Set missing RTC offsets") for picasso.
BUG=b:187516317
TEST=On a Chrome OS 'grunt' device, run
`time powerd_dbus_suspend --suspend_for_sec=172800`
and verify the system suspended and woke up after 48 hours
BRANCH=grunt
Signed-off-by: Anand K Mistry <amistry@google.com>
Change-Id: I10831b982662e680fa71aa81d02935e1b7e7a7a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55001
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Note that there are assumptions about LAPIC MMIO location
in both AMD and Intel sources in coreboot proper.
Change-Id: I2c668f5f9b93d170351c00d77d003c230900e0b4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55194
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This also adds BERT table gerenation support for Cezanne, but since the
functionality to populate the BERT memory region isn't implemented yet,
this won't result in a BERT table being generated on Cezanne, since
bert_generate_ssdt will always return false there.
TEST=BERT ACPI table generation still works on AMD/Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I69b4a9a7432041e1f4902436fa4e6dee5332dbd2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Implement acpi_soc_get_bert_region so that the common ACPI code will
generate a BERT ACPI table that points to the BERT memory region instead
of generating the BERT table in the SoC=specific code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I86d4f5ef74d4d40cb93ac4a3feaf28b99022ebd5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55055
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Since bert_errors_present() is only available when ACPI_BERT is selected
the ACPI table generation code needs to check that before calling the
function, so add bert_should_generate_acpi_table that returns false when
ACPI_BERT isn't selected or the return value of bert_errors_present()
when ACPI_BERT is selected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia955f627c190ea38e05b5aaedc7cb2d030274e83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55024
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
EDK2 mandates HOB to be in increments of qword (8). This HOB has 13
elements which causes it be padded with 4 bytes of garbage. This
results in coreboot failing intermittently with invalid data. Add
"number of entries" field to specify the number of valid entries in
the table.
BUG=b:190153208
Cq-depend: chrome-internal:3889619
TEST=verify HOB is present and correct size (13) is reported
Change-Id: Iaafae304f04a5f26d75a41a6d6fcb4ee69954d20
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55237
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some of the I2C buses are required to operate at different voltage level
compared to other I2C buses eg. I2C bus to Google Security Chip (GSC)
should be at 1.8V level. By default, all the I2C buses are initialized
to operate at 3.3 V. Add support to configure I2C pad RX select through
devicetree and update the concerned devicetree.
BUG=b:188538373
TEST=Build and boot to OS in Guybrush. Ensure that the communication
with GSC is fine. Build Majolica mainboard.
Change-Id: I595a64736fdac0274abffb68c5e521302275b845
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55149
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The new cezanne PSP release added support for these svcs. So add those
functionality back to cezanne psp_verstage.
BUG=b:187906425
Signed-off-by: Kangheui Won <khwon@chromium.org>
Change-Id: Id542f5ed0762f582ea966466d67ed938ecb9c1f0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
GSC is connected with AP via i2c bus so we need to enable i2c in
psp_verstage.
Signed-off-by: Kangheui Won <khwon@chromium.org>
Change-Id: I5f7b73be67a692ea7de31ae53bd111d0e4b6998c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55136
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the MCA(X) registers have defined values on the cold boot path,
the is_warm_reset check can be dropped. Also the warm reset bit in the
NCP_ERR register doesn't behave as the PPR [1] suggested; no matter if
something was written to the register or the machine went through a warm
reset cycle, the NCP_WARM_BOOT bit never got set.
[1] checked with PPR for AMD Family 17h Models 11h,18h B1 (RV,PCO)
#55570 Rev 3.15
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4e6df98ffd5d15ca204c9847a76c19c753726737
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55059
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
