There is no telling when the next udelay will be, so explicitly call
`thread_yield()` after completing a transaction. This will allow any
pending transactions to immediately start.
BUG=b:179699789
TEST=Verify new transaction is enqueued right after another.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I9c1272bde46c3e0c15305b76c2ea7a6dde5ed0b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56321
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Once we enable COOP_MULTITASKING, we need to guarantee that we don't
have multiple threads trying to access the DMA hardware.
BUG=b:179699789
TEST=Boot guybrush with APOB patches.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ibb8e31c95d6722521425772f4210af45626c8e09
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56231
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change will make it so the standard rdev readat call will use the
SPI DMA controller if the alignment is correct, and the transfer size is
larger than 64 bytes.
There is a magic bit that needs to be set for the SPI DMA controller to
function correctly. This is only available in RN/CZN+.
BUG=b:179699789
TEST=Boot guybrush to OS. This reduces loading verstage by 40ms,
verifying RW by 500us and loading romstage by 500 us.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I0be555956581fd82bbe1482d8afa8828c61aaa01
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Also rename the existing PCI_DEVICE_ID_ATI_FAM19H_MODEL51H_GPU
definition to PCI_DEVICE_ID_ATI_FAM19H_MODEL51H_GPU_CEZANNE to clarify
that that is the one for Cezanne.
BUG=b:193888172
Change-Id: I1c5446c1517f2e0cd708d3275b08d2bce4be0ea8
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56396
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Also move the registers in the order they are in the hardware.
Change-Id: If018e746e58c14475caeda76feb8b5281d7732f1
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56315
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only when ACPI_BERT is selected the BERT functionality needs to be
included in the build.
Change-Id: I8a21562f4535fb0ea3c53f2ea8df50f66cc6a64c
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56314
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since we don't need to skip the MCA check on cold boot on MCAX capable
systems, add a mca_skip_check implementation that always returns false.
Change-Id: Id8fc4b6f02b6c02b03172fe11f0451a9893e514d
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56313
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This will allow moving mca_check_all_banks to mca_common.c.
Change-Id: I58e100c1447907bab984a2fdff6c6e0181910c23
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56312
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This aligns the mca_check_all_banks implementation in the common mca.c
with the one in the common mcax.c file. Do the MCA bank count check
before the !is_warm_reset() check, so that a mismatch also gets printed
on the cold boot path.
Change-Id: Idbd3e9ce9c7483f84f87adab7adac47335cd59aa
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56311
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Since those functions are implemented and used only inside the common
MCA(X) code, there's no need to have them in the header file that gets
included in the SoC-specific code.
Change-Id: Ia84e149d67ac7d80de595379c73a6cf08730719d
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
For Cezanne stubs are added for the functions that the SoC-specific code
needs to provide. Since the mca_is_valid_bank stub on Cezanne always
returns false, the checks get skipped for it at the moment. The actual
functionality will be added in a later patch.
Change-Id: Ic31e9b1ca7f8fac0721c95935c79150d7f774aa4
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
According to the AMD FCH architects, we should be using the default
value for the NO_HOG bit. This fixes a problem where the SPI DMA no
longer functions after the LPC init runs.
BUG=b:179699789, b:192373221
TEST=Boot guybrush and see SPI DMA working
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: If015869657f36d3533f4ab9ebd1f54b0d4eb283a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
There is no technical reason this needs to be done in romstage. Moving
it into ramstage allow us (in future CLs) to use threads to pre-load
the apob from SPI.
BUG=b:179699789
TEST=Boot and Ezkinil and Guybrush and verify APOB update still work
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I960437ff4400645de5a3e7447fcdbc52de85943e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56227
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The %p format specifier already prints out 0x, so remove the 0x from the
string. I also updated the other format specifiers to use the %# syntax
to print out the 0x.
BUG=b:179699789
TEST=see correct format.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I5b00d2c06687e549f69486eb5e18f7bed560b2ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56225
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
PLTRST# is currently asserted and latched when eSPI_RST# gets asserted.
If eSPI_RST# isn't used on a platform or it doesn't properly assert
in all cases, then PLTRST# will never be asserted. This could result in
the AP and EC being out of sync.
BUG=b:188188172, b:188935533
TEST=Warm reset guybrush with partial #22 rework. Verify that peripheral
channel is correctly reset.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I20d12edf3efc6100096e24aa8d1aec76bbde264f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
On RW boot path psp_verstage call cbfs_map which calls chain of
_cbfs_alloc, cbfs_boot_lookup and cbfs_get_boot_device. Then
cbfs_get_boot_device initializes MCACHE which is used later.
However on RO boot path psp_verstage doesn't try to find anything in the
CBFS which results RO MCACHE not to be initialized. Add
cbfs_get_boot_device(true) to explicitly initialize MCACHE on recovery
boot.
BUG=b:177091575
BRANCH=none
TEST=build and boot jelboz
Signed-off-by: Kangheui Won <khwon@chromium.org>
Change-Id: I6c4b522fef5a4affd215faa122bdf6b53190cf3d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54711
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We were missing the stdint.h header, and the header was sorted
incorrectly in chip.h
BUG=non
TEST=build guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I209d3c9c48e5b06b2a56759af51cf2858eb99f51
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54922
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
ESPI_SLAVE_CHANNEL_READY is a read-only bit from the host perspective.
It is set when the eSPI peripheral has configured the channel.
We actually want to set the ESPI_SLAVE_CHANNEL_ENABLE flag. This never
caused an issue before because the peripheral channel is enabled by
default after PLTRST# is deasserted. This does fix the case where
periph_ch_en == 0. It now properly clears the enable flag.
BUG=b:188188172, b:188935533
TEST=Boot guybrush to OS, perform warm reset
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I24e0734d5652601ae9c967da528fec5e3f780991
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The ChromeEC might take longer than 1ms for the peripheral channel to be
enabled. The PLTRST# interrupt handler takes about ~539us.
This doesn't account for the time it takes for the interrupt handler
to be scheduled. Increasing the timeout to 10ms gives ample time.
BUG=b:188188172, b:188935533
TEST=Boot guybrush and no longer see channel enable errors
Suggested-by: Rob Barnes <robbarnes@google.com>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ib6db577bf06175ceb17b446af706ad8c9f891481
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54788
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
commit ce0e2a0140 (drivers/intel/fsp2_0:
use FSP to allocate APEI BERT memory region) adds a mechanism to reserve
the BERT region inside the coreboot code, so we can get rid of the
workaround to reserve it in the FSP and return the location in a HOB.
mcfg->bert_size defaults to 0 which makes the FSP not generate the
corresponding HOB, but that field is planned to be removed at least on
Cezanne, so don't explicitly set it to 0.
BUG=b:169934025
TEST=BERT table that gets generated in a follow-up patch for Picasso
points to expected BERT region and Linux is able to access, decode and
display it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaca89b47793bf9982181560f026459a18e7db134
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52584
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When performing an in-band reset the host controller and the
peripheral can have mismatched IO configs.
i.e., The eSPI peripheral can be in IO-4 mode while, the
eSPI host will be in IO-1. This results in the peripheral
getting invalid packets and thus not responding. This causes the
NO_RESPONSE status bit to be set and cause eSPI init to fail.
If the peripheral is alerting when we perform an in-band
reset, there is a race condition in espi_send_command.
1) espi_send_command clears the interrupt status.
2) eSPI host controller hardware notices the alert and sends
a GET_STATUS.
3) espi_send_command writes the in-band reset command.
4) eSPI hardware enqueues the in-band reset until GET_STATUS
is complete.
5) GET_STATUS fails with NO_RESPONSE and sets the interrupt
status.
6) eSPI hardware performs in-band reset.
7) espi_send_command checks the status and sees a
NO_RESPONSE bit.
As a workaround we allow the NO_RESPONSE status code when
we perform an in-band reset.
BUG=b:186135022
TEST=suspend_stress_test and S5->S0 tests on guybrush and zork.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I71271377f20eaf29032214be98794e1645d9b70a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Rob Barnes <robbarnes@google.com>
This removes the need to include this code separately on each
platform.
Change-Id: I3d848b1adca4921d7ffa2203348073f0a11d090e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Also drop unneeded intermediate cast to void * before casting the
address of the struct dptc_input type variables to uint8_t *.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie1e2aa1ec728a4e16d3a587d7400cdfc8962f443
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54077
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Cezanne PSP is missing implementations for some svc apis. Do not
include files related to missing svc apis.
This CL should be reverted after the cezanne PSP supports these
functions.
BUG=b:187906425
Signed-off-by: Kangheui Won <khwon@chromium.org>
Change-Id: Ibaab4e8435624d403ef18e980146ebfd1598b61b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This will change the names of the GPP bridges, but this ok since there
is no hand written ASL that references these names.
BUG=b:184766519
TEST=Boot picasso and dump ACPI
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ic09200156e8a37bd1a29ca95a17c8f8ae2b92bd3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54028
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Lowercase characters are not valid ACPI identifiers.
BUG=b:184766519
TEST=Boot picasso to OS and verify ACPI errors are no longer printed.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I75aca67f4607e97ced8ac00ac68e51c359aff944
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54027
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
