| Age | Commit message (Collapse) | Author |
|---|
|
There's no reason to name this choice block. Remove the name.
Change-Id: Iebf8b1e7af928b988ab514d9dd85d2e70bf00c09
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78917
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Drop the hda_soc_ssdt_quirks function since it doesn't apply for any of
the SoCs supported by the Stoneyridge code which was the only SoC
implementing it. This code was added when commit 91a7abf25c72
("soc/amd/hda: Move HDA PCI device from DSDT to SSDT") rewrote the code
originally added in commit 1587dc8a2b4d ("soc/amd/stoneyridge: Add
northbridge support") as a copy from northbridge/amd/pi/00670F00. This
code was moved around in commit 6580408a7e0a ("amd/pi/hudson: Move audio
to northbridge"), since the HDA controller was moved from the FCH to the
northbridge complex. When the controller was moved, the PCI config space
interface also changed, so those bits are no longer the DisableNoSnoop,
DisableNoSnoopOverride, and EnableNoSnoopRequest bits of the Misc
Control register of the HDA controller, but some bits within the
ClassCodeW field of the ACGAZ Mirrot Reg Ctrl 0 register.
BKDG #55072 Rev 3.04 (Stoneyridge), BKDG #50742 Rev 3.08 (family 15h
model 60h-6fh / 00670F00), and BKDG #52740 Rev 3.05 (family 16h model
30h-3fh) were used as a reference. Only the SoC with BKDG #52740 still
has the HDA controller in the FCH; the other two have it in the
northbridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I77fc76752b1c7de62ba8a196f15c198f55be3074
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78940
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This reverts commit 44a48ce7a46c36df69f7b2cf3552bf10fa5f61b6.
Reason for revert: It breaks wakeup from suspend on a bunch of boards.
While this approach of eyeballing "correct" values by chipset _should_
be fixed, it should also be accompanied by compile time verification
that the memory map works out.
Since nobody seems to care enough, let's just revert this, instead of
keeping the tree broken for a bunch of configurations.
Change-Id: I3cd73b6ce8b15f06d3480a03ab472dcd444d7ccc
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78850
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9fc155fe76c05fefd4ce31ae6b96dcc4527b6abc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78901
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0eae9e4d246bd07f43b1d77e5ad7649c010d0efe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8dc93b12b81abee41f6f225f41d1f9953d1d93e1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78898
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
All base addresses of MMIO devices in the devicetree should also have
corresponding defines in iomap.h. PPR #55901 Rev 0.26 was used as a
reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0444e6cc0587b484a4a1ff49fa4b1540a24c8e80
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78897
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The base addresses of I2C 5 and I3C 3 were wrong and all I3C controllers
should use the base address of the 4kiB block where all registers of
that I3C controller are located in. PPR #55901 Rev 0.26 was used as a
reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1c983d4a709000ef7963b96228322603b98728aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
|
|
Indicate FSP has support to display logo when graphics initialization is
done in FSP.
BUG=b:294055390
TEST=Build and boot to OS in Skyrim with and without passing the BMP
logo buffer from coreboot.
Change-Id: I6112c03723dcbc34cb0f57c400f831c765b95115
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78882
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Commit e728766f4596 ("soc/amd/mendocino: Do not load MP2 Firmware when
in RO") added logic to ensure that the MP2 disable soft fuse bit was set
for the RO section, but failed to check if the bit was already set
otherwise (as it is for non-ChromeOS builds). This caused the bit to
appear twice in the PSP_RO_SOFTFUSE_BITS string, and when the string
was converted to a series of numeric values and added together, bit
(n+1) ended up being set instead of bit n.
To mitigate this, use the makefile sort() function to ensure the
PSP_[RO_]SOFTFUSE_BITS string does not contain any duplicates before
the bitmask is calculated. Apply this to all AMD SoC makefiles where
the softfuse bits are added.
TEST=build/boot google/skyrim (frostflow). Use a verbose build (V=1)
to verify that the correct soft fuse value is passed to amdfwtool for
RO and RW_A/B for both ChromeOS and non-ChromeOS builds.
Change-Id: I2e207e20132d44016fbcb986bdfd8e935d8fead5
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78823
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
A new FSP-S UPD is added to allow passing a buffer containing boot logo
in BMP format. Update the FSP-S UPD and add a SoC specific callback to
populate the UPD.
BUG=b:294055390
TEST=Build and boot to OS in Skyrim. Pass the BMP logo buffer through
the UPD to FSP-S. Ensure that the concerned driver in FSP-S handles the
buffer.
Change-Id: Ie522956b6dfe2400ef91d43c80f2adc6d52c8415
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78817
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
I think this was probably a cut & paste error. We don't want prompts
for the "default" Kconfig options. Those should be set by the platform,
not the end user. These prompts didn't make sense where they were in the
Kconfig menus either.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Idcd2ba84591d31a9a25bcc6cae3ec163939d7836
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78818
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
This patch adds PCI interrupt details as per the Processor Programming
Reference (PPR) version 0.25 (#55901), table 319.
Change-Id: I81251bd60aac1d7bd3181699d3adca315291f336
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78392
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use the common AMD data fabric resource reporting code to report how
openSIL distributed PCI buses, MMIO, and IO resources to coreboot's
resource allocator. This replaces the original CB:76521 which was
written back when the common AMD data fabric resource reporting code
didn't exist yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ifcd655ea6d5565668ffee36d0d022b2b711c0b00
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iffe21fb0c0bff0fc21ce1ac3af71d39bb62fd384
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78660
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Select SOC_AMD_COMMON_LATE_SMM_LOCKING to ensure that SMM remains
unlocked on S3 resume until after the AGESA call to s3finalrestore
has completed. If SMM is locked prior, S3 resume will fail:
[DEBUG] agesawrapper_amds3laterestore() entry
[DEBUG] Error: Can't find 57a9e200 raw data to imd
[ERROR] S3 volatile data not found
TEST=build/boot google/liara, verify S3 resume succeeds.
Change-Id: I49659b4e5aba42367d6347e705cd92492fc34a0f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78625
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Pre-Zen SoCs like Stoneyridge call into an AGESA binary as part of S3
resume, which will fail if SMM is locked, causing the device to
(eventually) cold boot. To mitigate this, add a new Kconfig to enable
"late" SMM locking, which restores the previous behavior prior to
commit 43ed5d253422 ("cpu/amd: Move locking SMM as part of SMM init").
TEST=tested with rest of patch train
Change-Id: I9971814415271a6a107c327523a0a7c188a91df6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78352
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Move all security patch level (SPL) related Kconfig options to the
common AMD PSP Kconfig file. Commit 4ab1db82bb30 ("soc/amd: rework SPL
file override and SPL fusing handling") already reworked the SPL
handling, but missed that another Kconfig option
SOC_AMD_COMMON_BLOCK_PSP_FUSE_SPL controlled if the PSP mailbox command
to update the SPL fuses was sent by the code that got added to the build
when PERFORM_SPL_FUSING was selected.
To make things less unexpected, rename PERFORM_SPL_FUSING to
SOC_AMD_COMMON_BLOCK_PSP_SPL since it actually controls if the SPL
support code is added to the build and also rename
SOC_AMD_COMMON_BLOCK_PSP_FUSE_SPL to PERFORM_SPL_FUSING. This changes
what PERFORM_SPL_FUSING will do from including the code that could do
the fusing if another option is set to being the option that controls if
the fusing mailbox command will be set. All SoCs that support SPL now
select SOC_AMD_COMMON_BLOCK_PSP_SPL in their Kconfig, which won't burn
any SPL fuses.
The logic in the Skyrim mainboard Kconfig file is reworked to select
PERFORM_SPL_FUSING for all boards on which the SPL fuses should be
updated; on Guybrush PERFORM_SPL_FUSING default is changed to y for all
variants. The option to include the code that checks the SPL fusing
conditions and allows sending the command to update the SPL fuses if the
corresponding Kconfig is set doesn't need to be added on the mainboard
level, since it's already selected at the SoC level.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I12fd8775db66f16fe632674cd67c6af483e8d4e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
|
|
Supports a brand new ACP driver for STONEY / Grunt chromebooks.
AMD's Audio CoProcessor handles i2s/tdm audio, and is located on the
GPU.
On Windows the PCIe device for the GPU is owned by the AMD proprietary
driver, hence a separate device has to be added for the ACP driver.
Fortunately since IOMMU is disabled on STONEY, the driver itself can
pull BAR5 from the GPU and use that to initialize, so no special
configuration is required in ACPI other than the ID.
Change-Id: I0e31c3b31fa9fb99578c04b79fce2d8c1d695561
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Update the filename for the PSP_SMUFW2_SUB1_FILE to use the compressed
and signed version (.csbin) rather than the uncompression + signed
version (.sbin), in order to be consistent with the other SMU firmware
files. This will also facilitate dropping the duplicate files in an
upcoming update to the amd_blobs repo and updating the SMU files (all
of which are .csbin).
This change is actually a no-op since the .csbin and .sbin are the same
file; it appears that the .sbin file was incorrectly named when added,
and then the same file was added later with the correct extension.
TEST=build/boot google/kahlee (liara)
Change-Id: I10fa8e949ab589d315862c06b4125c902520cbbc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78512
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Select the common block graphics driver for Stoneyridge.
Drop Stoney's ACPI stub for the iGPU as the device will now be
generated by the common block acpigen and put into the SSDT.
TEST=tested with rest of patch train
Change-Id: I260b964be59c1a208ff907c474243a9ace03f206
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78428
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Factor out the FSP-dependent graphics init call and header into a
separate file, so that the common graphics init can be used by non-FSP
platforms (eg Stoneyridge) without any preprocessor guards.
TEST=build google/skyrim
Change-Id: Ib025ad3adec0945b4454892d78c30b4cc79e57a0
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78599
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When CBFS verification is enabled, add amdfw_a/b.rom at offset 128 bytes
to account for CBFS file header with hash attribute. When CBFS
verification is disabled, add amdfw_a/b.rom at offset 64 bytes to
account for CBFS file header without hash attribute.
BUG=None
TEST=Build Skyrim, Myst BIOS images with and without CBFS verification
enabled.
Change-Id: Ic374ac41df0c8fb8ce59488881ce5846e9058915
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78425
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Fix the hash file names to be used to verify signed PSP binaries when
booting with VBOOT FW Slot B.
BUG=None
TEST=Build and boot to OS in Myst with PSP Verstage enabled using both
VBOOT slots A and B.
Change-Id: I89f02922bc901d8ac71d48bf5128fe6ecead43a0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Some stalls are observed while using CCP DMA in PSP verstage -
especially with CBFS verification enabled. Also with RW CBFS
verification enabled, the entire firmware body is not loaded during
verstage for verification. Instead the files are verified as and when
they are loaded from CBFS. Hence the impact to boot time is reduced
since only few files are loaded during PSP verstage. Hence disable CCP
DMA in PSP verstage until the root cause is identified.
BUG=None
TEST=Build and boot to OS in Myst with CBFS verification enabled.
Change-Id: I22ac108b08abcfe432dfd175644393e384888e11
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78234
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add SPI flash RO ranges to be verified by GSC in order to enable CBFS
verification. Also with CBFS verification enabled, CBFS metadata is
more than 64 bytes. So configure the offset of amdfw_a/b to 128 bytes -
next address aligned to 64 bytes.
BUG=b:277087492
TEST=Build and boot to OS in Myst with and without CBFS verification
enabled.
Change-Id: Ibfffd3d6fce8b80ec156a7b13b387e1df8c43347
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78233
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `PRERAM_CBFS_CACHE_SIZE' Kconfig to set
the pre-memory stages CBFS cache size. A cache size of zero disables
the CBFS cache feature. The default value is 16 KB which seems a
reasonable minimal value enough to satisfy basic needs such as the
decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
We have set this size to zero for all the platforms without enough
space in Cache-As-RAM to accommodate the default size.
TEST=Decompression of vbt.bin in romstage on rex using cbfs_map()
Change-Id: Iee493f9947fddcc57576f04c3d6a2d58c7368e09
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: I8d64236fc81e848503535db6f52e93328a60404c
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I2419feed1a76ec1cb04cb9640689b8758fa1d3f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Change-Id: Ief56bff2a1b8825d6e65aeb5f7ed9e8f432e465b
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I068fcbbcb0641cddce8fa85e2a64ab44d91d6bcf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76526
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
As per PPR, Genoa supports up to 96 core, that is 192 threads.
It also supports dual socket.
Change-Id: I817fea7c41477f476794e9e5c16451037d01f912
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78402
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Crypto Engine in PSP prefers the buffer from Static RAM (SRAM). Hence if
a buffer comes from within SRAM address range, then it is passed
directly to Crypto Engine. Otherwise a bounce bufer from the stack is
used. But on SoCs like Picasso where PSP Verstage stack is mapped to a
virtual address space this check fails causing a bounce buffer to be
used and hence a stack overflow. Fix this issue by assuming that the
buffer comes from the SRAM always in such SoCs and pass the buffer
directly to crypto engine.
BUG=b:259649666
TEST=Build and boot to OS in Dalboz with unsigned PSP verstage.
Change-Id: I2161c8f0720c770efa5c05aece9584c3cbe7712a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78426
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
On all targets the domain works as a host bridge. Xeon-sp code intends
to feature multiple host bridges below a domain, hence rename the
function to pci_host_bridge_scan_bus.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4e65fdbaf0b42c5f4f62297a60d818d299d76f73
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78326
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iec6e05bbe9fad7d78002560b78169dc293294af6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78341
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
This code only gets built when the SOC selects
SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO which no SoC before Genoa
does.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia5495ebf0f157fd0c456ce44acaf1ab222a188dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaf4a1fd61ad1d545b1ea0ab3fcf6c7a3d0260cd0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78319
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
This functionality will eventually be used by the common data fabric
domain resource reporting code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ieedd432c144e53e43d8099ec617a15056bb36fd1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78307
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I18871af0a8dbc1423524b681d516476e63b9596a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78306
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: I1529657f30b6e228c2e3cd7e0438255522381367
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76507
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I2e827e9ffbb2ec1be0f1247b77660a9fdeb04f7b
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78222
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Add SMI definitions as per Genoa PPR Doc #55901
Change-Id: I491f4075cef8976e4b0762752c9e2e3c2ef886d5
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Add GPIO definitions as per Genoa PPR Doc #55901
Change-Id: I0c4e425699c9a158ca95a1baf94f7756f0b12b44
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
We have a tiny HEAP_SIZE by default, except when we don't, and
mainboards that override it, or not.
Since memory isn't exactly at a premium these days, and unused heap
doesn't cost anything extra, just crank it up to the highest value
we have in the tree by default and remove all overrides.
Change-Id: I918a6c58c02496e8074e5fba06e38d9cfd691020
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78270
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4965eac4ec3d600b1e840affce4e5b4fa2ea4360
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic9553e6016c92c9b1678c395cd6a9e6860bf8a76
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76506
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I05990c2aca40d9cf47a9ebdfd269b80b8f60e300
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Commit 26d54b70e282 ("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>
|
|
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>
|
|
Simplify the code a bit by returning 0 early in the function when the
SYSCFG_MSR_SMEE bit isn't set.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I7536b82d98e55c51105448090d1206e1ed7f62d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78176
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of having the get_usable_physical_address_bits function that
only got used in the data fabric domain resource reporting code, drop
this function, select RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT in the
common AMD non-CAR CPU and rename get_sme_reserved_address_bits to
get_reserved_phys_addr_bits so that the common cpu_phys_address_size
function will return the correct number of usable physical address bits
which now can be used everywhere. The common AMD CAR CPU support is only
selected by Stoneyridge which doesn't support secure memory encryption,
so RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT isn't selected by the
SOC_AMD_COMMON_BLOCK_CAR Kconfig option.
Before only the MMIO region reporting took the reserved physical address
bits into account, but now also the MTRR calculation will take those
reserved bits into account. See the AMD64 Programmers Manual volume 2
(document number 24593) for details. Chapter 7.10.5 from revision 3.41
of this document was used as a reference. The MTRR handling code in
older Linux kernels complains when the upper reserved bits in the MTRR
mask weren't set, but sets them after complaining and then continues to
boot. This issue is no longer present in version 6.5 of the Linux
kernel.
The calculation of the TSEG mask however still needs to take all
physical bits into account, including the ones reserved for the memory
encryption. When not setting the reserved bits in the TSEG mask, the
Mandolin board with a Picasso APU won't boot to the OS any more due to
not returning from SeaBIOS calling into the VBIOS. Haven't root-caused
what exactly causes this breakage, but I think previously when something
else was wrong with the SMM initialization, also something went wrong
when calling into the VBIOS.
TEST=Ubuntu 2023.10 nightly build boots on Mandolin via SeaBIOS and EDK2
and Windows 10 boots on it via EDK2.
TEST=On Ubuntu 2022.04 LTS, the kernel complained with the following
warning, but it still continues the boot process as described above:
mtrr: your BIOS has configured an incorrect mask, fixing it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iad65144006f1116cd82efc3c94e1d6d1ccb31b6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Convert TPM functions to return TPM error codes(referred to as
tpm_result_t) values to match the TCG standard.
BUG=b:296439237
TEST=build and boot to Skyrim
BRANCH=None
Change-Id: Ifdf9ff6c2a1f9b938dbb04d245799391115eb6b1
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77666
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: I70db8bf9f553fa9bfd2a5c20a1393119786047f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76504
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ifb4d7dda5fcf1ccacb901b24e4f7cf6945ee16e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76503
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
All verified with PPR.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: If288079310ba74333f04173978f6a123ce95f4d9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: Ie1ae2ba4d4833570ca0621023bdeed67ccabe5cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76501
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: I5d5d3ff27ab0953844f9bbef30b6487fb480e29b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76500
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Only the lower half of the flash gets memory mapped below 4G in the
current setup.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: Iffe5c17a50f3254411a4847c7e635ce0fd282fde
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76499
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
TESTED: AMD onyx reaches x86 code
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Change-Id: I95d84f93663a80f322fd4d7cdeb35ccfe0ec7d21
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76498
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I6c9879a9f06f81d577bc09f6001158d7f9326362
Signed-off-by: vbpandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78082
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
On the first boot after flashing, the data read from the FMAP and
stored in vbios_data is not valid, so hashing it produces a value which
will not match on the subsequent boot, requiring an additional boot
before the vbios_data and hash match / before the GOP driver can be
skipped. To fix this, update vbios_data before hashing.
BUG=b:271850970
BRANCH=skyrim
TEST=build/boot google/skyrim with USE_SELECTIVE_GOP_INIT selected,
verify that GOP driver execution is skipping on 2nd boot after flashing
when booting in normal / verified boot mode.
Change-Id: Idc10d752bfa004a34b91307a743c620fb97eeb82
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77727
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Since all non-CAR AMD SoCs have the same mp_init_cpus implementation,
factor it out and move it to a common location.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibf4fa667106769989c916d941addb1cba38b7f13
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Currently MP2 Firmware is not built into RO firmware section but the
soft fuse bit to disable MP2 firmware loading is not set. This causes
the device to boot loop during recovery mode. Set the bit to disable MP2
firmware loading in RO.
BUG=b:259554520
TEST=Build and boot to OS in Skyrim under both normal and recovery
modes.
Change-Id: I9e4cf4f72e2d36ad3cc33629ddb501ecdbf5eda9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78023
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Add the eMMC MMIO device to the devicetree and make it use the common
AMD eMMC driver. Since there is now a device for this in the devicetree,
also use this device to determine if the FSP should be told if the eMMC
controller is supposed to be disabled.
TEST=On Mandolin the eMMC controller both disappears in the Windows 10
device manager and in dmesg on Ubuntu 2022.04 LTS
TEST=Morphius with NVMe SSD still works
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5453b69df776d2ce1f3be11e37cd26c8c64f0cd5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
When the eMMC MMIO device is enabled in the devicetree, it needs to be
exposed in ACPI in order for the OS driver to be able to attach to it.
The Cezanne eMMC controller isn't used in google/guybrush, so this the
code path where the eMMC MMIO device is enabled in the devicetree can't
be easily tested.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I69ff79b2d1c6a08cf333a2bb3996931962c2c102
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Add a separate Kconfig option for adding np_region.c to the build. Only
the code for Picasso, Cezanne, Mendocino, Phoenix and Glinda call
data_fabric_set_mmio_np which is implemented in that file, so only
select the new SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig option
for those.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic49ce039462b52e2c593c7d2fef43efc50901905
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77987
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Make naming convention consistent across all functions return values.
BUG=b:296439237
TEST=Boot to OS on Skyrim
BRANCH=None
Change-Id: If86805b39048800276ab90b7687644ec2a0d4bee
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77536
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Factor out data_fabric_set_mmio_np and the helper functions it uses into
a separate compilation unit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I58625c5a038f668f8e30ae29f03402e1e2c4bee3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Use data_fabric_get_mmio_base_size in data_fabric_print_mmio_conf
instead of open coding the functionality. This will fix the printing of
the MMIO config in the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO
case which wasn't handled properly before.
TEST=Console output from this function doesn't change on Mandolin:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 0 ffff 90 9
4 fed00000 fed0ffff 93 x x 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If602922648deca0caef23a9999c82acdd128b182
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
data_fabric_disable_mmio_reg and data_fabric_find_unused_mmio_reg are
only used by data_fabric_set_mmio_np in the same file, so make them
static and drop the prototype from the header file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6bf7a868aae2fd01b8adecd3e4cba6ff6d5119af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The EFS data structure diagrams in the Makefiles of Picasso and newer
SoCs were wrong, since the BIOS directory table pointer is in a
different location than shown in the diagram. Since the diagram also
wasn't that easy to understand and amdfwtool does all of that handling,
drop the wrong diagram from the Makefiles.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5f86fea29f956ff10746d35dbe967a4a89e11cca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
Change-Id: I2866dcdd6900c98310b4b3736b40ebe4eaa77ea2
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77719
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of reporting all I2C controllers in the system as enabled in the
corresponding ACPI device's _STA method, report the I2C devices that are
disabled in the devicetree as disabled in the corresponding _STA method
too. This is done by returning the contents of the STAT variable inside
each device's scope in the DSDT that have a default value of 0 (device
not present/disabled). For all enabled and hidden I2C devices
i2c_acpi_fill_ssdt gets called which then writes 0xf (device enabled and
visible) or 0xb (device enabled, but hidden) to the STAT name inside the
same scope, but in the SSDT. This object in the SSDT will then override
the default in the DSDT resulting in the _STA method returning the
correct status of each device. The code was inspired by
commit 7cf9c7451808 ("soc/amd/*: Fix UART ACPI device status").
TEST=On Mandolin all I2C controllers are disabled and with this patch
none shows up in the Windows 10 device manager. When enabling an I2C
controller in the devicetree for testing, it shows up again in the
Windows device manager.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4cd9f447ded3a7f0b092218410c89767ec517417
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
|
|
Per the PSP team, this field in the transfer buffer isn't used anymore
and always set to zero, causing devices to incorrectly report having
pre-production silicon.
Change-Id: Ida4bf4b9328ac83d905e4c3f822e6ceabe9be79d
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77630
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
We don't have file for the fuse chain, but we need to set the level
for some cases.
Change-Id: Idb546f761ae10b0d19a9879a9a644b788828d523
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I639fb1e911a7449d0db0d2bfcfbb6f4f225b0cef
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Specify the default path to, and automatically include the FSP binaries
needed to boot a board if USE_AMD_BLOBS is selected. Simplifies board
configs, and matches use in previous patforms.
TEST=build/boot google/skyrim
Change-Id: Ic837d264327723c8dc18a60fb16e8d41fe38b44e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77625
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Automatically include the FSP binaries needed to boot a board if
USE_AMD_BLOBS is selected. Simplifies board configs, and matches
use in soc/amd/picasso.
TEST=build/boot google/guybrush
Change-Id: I5b6e34085410a2aafe5d7876be5097f28f521ce8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77624
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This adds a dummy soc (genoa) based on EXAMPLE_MIN86 with
amd linker script hooked up.
Default to 64bit code as that will be a sensible default for this
platform (high memory access required for RAS setup).
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I69253466084d17c4359d7e824d69f12490b076e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76495
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
The amdfw.rom is mostly in region COREBOOT. Calculate the relative
address as the CBFS module address. That is for future 32M flash size
support.
TEST=binary identical test on amd/birman amd/majolica amd/gardenia
amd/mayan amd/bilby amd/mandolin amd/chausie amd/pademelon
pcengines/apu2
google/skyrim google/guybrush google/zork google/kahlee google/myst
This commit is part of a series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: I2add8e4e6755e582b3be6a150cf83d1468f2f1be
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72961
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It is based on work by Arthur Heymans, 69852.
Get rid of the confusing "position index" and use the relative flash
offset as the Kconfig setting instead.
TEST=binary identical on amd/birman amd/majolica amd/gardenia
amd/mayan amd/bilby amd/mandolin amd/chausie amd/pademelon
pcengines/apu2
google/skyrim google/guybrush google/zork google/kahlee google/myst
(The test should be done with INCLUDE_CONFIG_FILE=n)
Change-Id: I26bde0b7c70efe9f5762109f431329ea7f95b7f2
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The Genoa SoC supports MMIO addresses larger than 48 bits. Since the
MMIO base and limit registers in the data fabric only contain bits 16 to
47 of the MMIO address, the MMIO address extension register is
introduced on some SoCs like Genoa. This additional register contains
the upper bits of the MMIO base and limit. Since it's not available on
all SoCs, introduce the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO
Kconfig option to select the correct data_fabric_get_mmio_base_size
implementation to be added to the build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic304f5797bc5661c1d511c95e457c6dde169d329
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77514
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
The !CONFIG_SOC_AMD_COMMON_BLOCK_APOB_NV_DISABLE comment was likely a
copy-paste leftover, so remove it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I45b12d1dc5af84be99d54fea0c9ccf610cf5dae3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77513
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The psp_transfer.h file was the same under all SoCs, and is really
tied to the file common/vboot/transfer.c, not the SOC.
This patch makes an include directory under vboot to put the header into
and sets it to be included for all SoCs using SOC_AMD_COMMON. This makes
the header file available to all platforms, so that new chips that don't
use the psp_verstage don't have to make a psp_transfer.h file just to
satisfy the compiler.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5b9f2adee3a1d4d8d32813ec0a850344b7d717b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77303
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The Genoa server SoC has 4 IOHC PCI roots instead of the 1 the mobile
SoCs have, so add the additional 3 SMN base address definitions.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I72dba39bff7c7a739e1dfddd80e7f22e65b5f139
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77395
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of open coding this, use the mmio_range helper function to tell
the resource allocator about the northbridge's IOAPIC's MMIO. This
change sets the IORESOURCE_RESERVE and IORESOURCE_STORED bits in the
resource flags that weren't set before, but mmio_range is already used
elsewhere for similar purposes.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id66a73cdb22fd551e4359914ba5513313dcc3193
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77173
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Instead of open coding the same functionality, use fixed_io_range_flags
to tell the resource allocator about the FCH subtractively decoding the
first 0x1000 bytes of I/O space. Also update the comment to match the
code.
TEST=On Mandolin the flags of this resource stay the same (0xc0040100).
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia30a87a4e37c98248568476b74af2730a3c0e88d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77170
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use get_iohc_fabric_id() to translate the coreboot domain's number into
the destination data fabric ID of the PCI root. This allows using the
coreboot domain 0 as primary domain of the SoC in all cases, so it's
still possible to use config_of_soc(). This allows dropping the
SOC_AMD_COMMON_BLOCK_DATA_FABRIC_DOMAIN_MULTI_PCI_ROOT Kconfig option
and do the check if the destination fabric ID in the PCI bus number,
MMIO, and IO decode registers is the correct one for the domain without
the need to use a non-zero number for the primary PCI root domain.
TEST=Mandolin still boots and the PCI bus, IO and MMIO resources still
get reported correctly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I880ee0bf5c185cfe4af7de0d39581eb951ee603a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77169
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Implement get_iohc_fabric_id for each SoC that translates the coreboot
domain number to the fabric ID of the corresponding PCI root. This
allows the primary domain to have the number 0 even though the
destination data fabric ID will be non-zero. Keeping the primary domain
number 0 allows to use config_of_soc() which can be resolved at link
time and not need to dynamically find the SoC device to get the config.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6538a777619eed974b449fc70d3fe3084ba447dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
In the case of SoCs hat have more than one PCI root, we need to check to
which PCI root the PCI bus number, IO and MMIO regions configured in the
data fabric registers get routed to and only tell the resource allocator
about the resources that get routed to the current PCI root domain. For
this the numbers of the domains need to match the PCI root's destination
data fabric ID.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib6a6412f733d321044678d2b064c33418a53861c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
The data fabric also controls which PCI bus numbers get decoded to the
PCI root. In order for the resource allocator to know how the hardware
is configured, read the corresponding data fabric registers to get the
information that then gets passed to the allocator.
Picasso, Cezanne, Mendocino and Rembrandt only support one PCI segment
with 256 buses while the Phoenix and Glinda data fabric hardware has
support for more PCI segments. Due to this change, the register layout
is different and incompatible between those two, so introduce the
SOC_AMD_COMMON_BLOCK_DATA_FABRIC_MULTI_PCI_SEGMENT Kconfig option for a
SoC to specify which implementation is needed. At the moment, coreboot
doesn't have support for multiple PCI segments and the code doesn't
support PCI segments other than segment 0.
On Picasso the PCI bus number limit read back from the data fabric
register is 255 even though CONFIG_ECAM_MMCONF_BUS_NUMBER is set to 64,
so also make sure that the bus and limit returned by
data_fabric_get_pci_bus_numbers is within the expected limits.
TEST=PCI bus allocation still works on Mandolin (Picasso) and Birman
(Phoenix). Picasso has 64 PCI buses. coreboot puts this info into the
resource producer in _SB\PCI0\_CRS which the Linux kernel reads:
* coreboot: PCI0 _CRS: adding busses [0-3f]
* Linux: pci_bus 0000:00: root bus resource [bus 00-3f]
This matches the information in the ACPI MCFG table.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ide5fa9b3e95cfd59232048910cc8feacb6dbdb94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77080
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The SOC_AMD_REMBRANDT_BASE comment at the end of Glinda's Kconfig is
probably a leftover from the Mendocino/Rembrandt SoC this file was
copied from. Change it to SOC_AMD_GLINDA to match the corresponding
'if SOC_AMD_GLINDA' in the file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I85132e4840c1bc713cfc2f3493f800d66edd10ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77121
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Set the maximum subordinate bus number of the domain to the last PCI bus
number that is decoded to this PCI root. This makes sure that the
resource allocator knows the maximum number of PCI buses on this PCI
root to not assign bus numbers to buses below this PCI root that aren't
routed to that PCI root.
Now that we have this info in the link list structure or the domain
device, we can pass the max_subordinate field to the
acpigen_resource_producer_bus_number call and can leave the subordinate
number after pci_domain_scan_bus is done unchanged instead of setting it
to the limit.
TEST=On Mandolin both the bus resource producer in _SB\PCI0\_CRS and the
PCI bus number allocation remain unchanged.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2ee75b2a7054a306b0c7d98c5357391c029187bb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77112
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Icafa36ae2e07068c276600067bba1d0377f0824b
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74258
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Rembrandt has different data fabric component IDs compared to Mendocino.
PPR #56558 Rev 3.04 was used as a reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3c840a3e071a289d9e02143ee790c26faeda029d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
With reference to the Picasso PPR 55570 Rev 3.18, LegacyIoEn bit is 0 on
reset and setting it will enable the decoding of the following legacy IO
ports:
0x20, 0x21, 0xA0, 0xA1 (PIC);
0x40, 0x41, 0x42, 0x43, 0x61 (8254 timer);
0x70, 0x71, 0x72, 0x73 (RTC);
0x92.
Verstage does not use those legacy IO ports. Also newer SoCs like
Phoenix do not support Legacy I/O registers to access Power Management
registers and accessing them from PSP verstage causes a hang. Hence
enable legacy IO only on platforms that support it.
BUG=b::284984667
TEST=Build Myst BIOS image with PSP Verstage. Boot to OS successfully
with PSP verstage.
Change-Id: I5e74b4cd1fa7e942770976e5e2197ded47503660
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76692
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I8fa26e7a398eee855c31a76f0f89b4111368c2a6
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
PPRs #57254 Rev 1.52 and #57255 Rev 0.33 were used as a reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie54fd6c5a82f368018d0b5fb811a6c9220c2c70b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77079
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
PPRs #57019 Rev 3.05 and #57396 Rev 3.06 were used as a reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id0fe478a710ecc1f2c8b36347aaf2d1634ebba9a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77078
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
