| Age | Commit message (Collapse) | Author |
|---|
|
Instead of having PCI0's _BBN method in the DSDT that always returns 0,
use acpigen_write_BBN to generate the _BBN method that returns the first
PCI bus number in the PCI domain/host bridge.
TEST=On mandolin the _BBN method in the _SB/PCI0 scope is now in the
SSDT instead of the DSDT, but still returns 0.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8badeb0064b498d3f18217ea24bff73676913b02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74992
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use amd_pci_domain_read_resources function that gets the configured MMIO
regions for the PCI root domain from the data fabric's MMIO decode
registers instead of using pci_domain_read_resources. This results in
the same IO port range being used by the allocator, but makes sure that
the allocator will only allocate non-fixed MMIO resources in the address
ranges that get decoded to the PCI root complex. In order for the PCI0
_CRS ACPI resource template to match the decoded PCI root domain MMIO
windows, use amd_pci_domain_fill_ssdt to generate the _CRS ACPI code
instead of having a mostly hard-coded _CRS method in the DSDT. This
makes sure that the OS will know about the MMIO regions it is allowed to
used.
Before this patch, only the region from TOM1 to right below
CONFIG_ECAM_MMCONF_BASE_ADDRESS was advertised as usable PCI MMIO in the
PCI0 _CRS method. Also the resource allocator didn't get any constraint
on which address ranges it can use to put the non-fixed MMIO resources.
This approach worked until now, since all address range from 0 up to
right below TOM1 was filled with either usable or reserved memory and
the allocator was allocating beginning right from TOM1, since it was
using the bottom-up allocation approach and everything below TOM1 was
already in use. The MMIO region from TOM1 to right below
CONFIG_ECAM_MMCONF_BASE_ADDRESS also matched the MMIO decode window
configured in the data fabric's MMIO decode registers, so everything
seemed to work fine. However, when either selecting
RESOURCE_ALLOCATION_TOP_DOWN or enabling above 4GB MMIO, things broke
badly. This was partially due to the allocator putting non-fixed MMIO
resources in regions that weren't decoded to the PCI root, since AMD
family 17h and 19h silicon doesn't subtractively decode PCI MMIO and the
wrong ranges the allocator used also weren't advertised in ACPI.
TEST=Even when selecting RESOURCE_ALLOCATION_TOP_DOWN that usually ends
up with a non-working system when the MMIO ranges aren't reported
correctly to the resource allocator due to the reasons descried above,
Ubuntu 22.04 LTS still boots on Mandolin both with SeaBIOS and EDK2
payload and Windows 10 boots with EDK payload. There's however an EDK2
bug that results the MMCONFIG region not being advertised in the e820
table, which causes Linux to not use the MMCONFIG and fall back to the
legacy PCI config access method. This only happens with EDK2 payload and
everything works fine when using SeaBIOS as payload. That e820 issue is
unaffected by this patch.
At the end of the data_fabric_set_mmio_np call, this is the data fabric
MMIO register configuration:
=== 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
The limit of the data fabric MMIO decode register 1 is configured as
0xffffffffffff although this is way beyond the addressable memory space.
add_data_fabric_mmio_regions fixes this up, so the range that gets
passed to the allocator in that case is 0x7fcffffffff which takes both
the reserved most significant address bits used for the memory
encryption and the 12GB reserved data fabric MMIO at the top of the
usable address space into account.
This results in the following domain ranges passed to the resource
allocator:
DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff done
DOMAIN: 0000 mem: base: fc000000 size: 0 align: 0 gran: 0 limit: febfffff
DOMAIN: 0000 mem: base: 10000000000 size: 0 align: 0 gran: 0 limit: 7fcffffffff
DOMAIN: 0000 mem: base: d0000000 size: 0 align: 0 gran: 0 limit: f7ffffff
The IO resource producer region is split into two parts to not cover the
PCI config IO region resource consumer. This results in these resources
being added to the PCI0 _CRS resource template:
amd_pci_domain_fill_ssdt ACPI scope: '\_SB.PCI0'
PCI0 _CRS: adding busses [0-3f]
PCI0 _CRS: adding IO range [0-cf7]
PCI0 _CRS: adding IO range [d00-ffff]
PCI0 _CRS: adding MMIO range [fc000000-febfffff]
PCI0 _CRS: adding MMIO range [10000000000-7fcffffffff]
PCI0 _CRS: adding MMIO range [d0000000-f7ffffff]
PCI0 _CRS: adding VGA resource
Kernel version 5.15.0-43 from Ubuntu 2022.4 LTS prints this in dmesg:
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-3f]
pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
pci_bus 0000:00: root bus resource [mem 0xd0000000-0xf7ffffff window]
pci_bus 0000:00: root bus resource [mem 0xfc000000-0xfebfffff window]
pci_bus 0000:00: root bus resource [mem 0x10000000000-0x7fcffffffff window]
Another noteworthy thing I wasn't aware of at first when testing ACPI
changes on Windows 10 is that a normal Windows shutdown and boot cycle
won't result in it processing the changed ACPI tables; you have to tell
it to reboot to do a proper full boot where it will process the updated
ACPI tables (and fail if it dislikes something about the ACPI tables and
bytecode).
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia24930ec2a9962dd15e874e9defea441cffae9f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74712
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Generate the PCI0 _CRS ACPI resource template to tell the OS which PCI
bus numbers and IO and MMIO regions can be used for PCI devices below
_SB/PCI0. This data corresponds to what amd_pci_domain_scan_bus and
amd_pci_domain_read_resources provided to the resource allocator. This
makes sure that the PCI0 _CRS ACPI resource template matches the
constraints the resource allocator used when allocating resources.
TEST=With also the rest of the current patch train applied, the
generated _CRS resource template contains the expected PCI bus numbers
and IO and MMIO resources and both Linux and Windows boot on Mandolin.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaf6d38a8ef5bb0163c4d1c021bf892c323d9a448
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74843
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Provide amd_pci_domain_scan_bus to enumerate the PCI buses in the one
PCI root domain and amd_pci_domain_read_resources to read the MMIO
regions that the resource allocator can use to allocate the PCI MMIO
BARs in the one PCI root domain from the corresponding data fabric MMIO
decode registers. This makes sure that the allocator will only put PCI
MMIO resources in areas that are decoded to the PCIe root complex. The
current code only covers the case of a system with one PCI root where
all PCI bus numbers belong to the only PCI root, all IO ports get
decoded to the only PCI root and the MMIO regions from the data fabric
MMIO decode registers get decoded to the only PCI root. In future
patches, this will be extended to also support the multi PCI root case.
TEST=With also the rest of the current patch train applied, the resource
allocator uses the constraints on the MMIO regions and both Linux and
Windows boot on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4aada7c8a2a43145ad08d11d0a38d9cdc182b98e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74717
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In case the secure memory encryption is enabled, some of the upper
usable address bits of the host can't be used any more. Bits 11..6 in
CPUID_EBX_MEM_ENCRYPT indicate how many of the address bits are taken
away from the usable address bits in the case the secure memory
encryption is enabled.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia810b0984972216095da2ad8f9c19e37684f2a2e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75623
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
types.h provides uint32_t via a chain include.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I875e3bb096b56bbea862c9ad0e3e14e025e3298b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75622
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This makes sure that the resource allocator won't use those ports for
anything else.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I014ffe3ee94ec153e91113f9a17e89f24ca040b3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75619
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
This makes sure that the resource allocator won't use those ports for
anything else.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie42260902ee2b383dd5867ac813cae029f706f2d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75556
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Follow 57263_FP8_MBDG_rev_0_92 Table.57 to update the alias. We
can match the schematic for now.
BUG=b:285793461
TEST=USB still works.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Id1058279fe5b0e3131608a0b9bbd708dbbde7e87
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
This adds printing content of 'manifest' file at ramstage.
It allows to learn about blobs version used to build the coreboot
binary, which is useful when investigating bugs.
Version data are stored in CBFS file, which was generated during
coreboot build. If AMD FW blobs will be manually replaced in coreboot
image, versions from CBFS file are no longer valid.
Log:
AMDFW blobs version:
type: 0x01 ver:00.3c.01.18
type: 0x08 ver:00.5a.28.00
type: 0x30 ver:2b.25.b0.10
type: 0x73 ver:00.3c.01.18
BUG=b:224780134
TEST=Tested on Skyrim device
Change-Id: I8df54b74cd987b4a3be635932d38ea178d0b0311
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74269
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
pci_rom_probe() can allocate memory when mapping a CBFS
file, so pci_rom_free() should be called before leaving
the function.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: Ie6fbbfd36f0974551befef4d08423a8148e151e7
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74779
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
|
|
Move microcode load/unload to pre_mp_init and post_mp_init callbacks.
It allows to make sure that ucode is freed only if all APs updated
microcode.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: I200d24df6157cc6d06bade34809faefea9f0090a
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
The phoenix SoC does not support multiple EFS locations. Set the default
to the only valid value and prevent mainboard overrides by making the
option non-user-configurable.
TEST=build birman-phoenix
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I0f720dbadf2d28a3c39daa4bd653a407be4893d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74249
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
This adds manifest generated by amdfwtool to CBFS.
BUG=b:224780134
TEST=Tested on Skyrim device
Change-Id: I13c9d322735e0979484b120c665fb100cf187eab
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74267
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
BUG=b:217968734
TEST=Build guybrush firmware
Change-Id: I93dfa50cd1116e0f6652186acb37fd43d638cf84
Signed-off-by: Konrad Adamczyk <konrada@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75491
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>
|
|
This brings the ACPI code more in line with both what the new code for
the AMD SoCs will do and also what the current Intel code does. This was
mainly done to have a reduced delta to the new AMD domain resource
handling functions to debug it, but it might still be useful to upstream
this change.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8cca05976b1c9d4e994e407b8c0197da7dd35eb2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75487
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>
|
|
cbfs_boot_map_optionrom will generate lower case hex digits for the
filename to look for in CBFS, so make sure that the file name will use
lower case hex digits and no upper case hex digits.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1d4daa04120de0f2c853a44691b7e2c52eb2af20
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75483
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
EFS header is mapped during PSP verstage and bootblock to read some SPI
configuration. After use it is left unmapped. Unmap the EFS region after
use.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I865f45a3d25bc639eb8435b54aa80895ec4afd27
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75455
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
cbfs_unmap does not unmap the mapped region from the boot device. This
leads to some resource leaks eg. TLB slots in PSP. Explicitly call
rdev_munmap on the address mapped by cbfs_map.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I51b9d066a40103f2ebdf2ef2fc3da13beb467921
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
cbfs_unmap does not unmap the mapped region from the boot device. This
leads to some resource leaks eg. TLB slots in PSP. Explicitly call
rdev_munmap on the address mapped by cbfs_map.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: If1d355972cc743b8d8c451e1b3f827abd15e98fe
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
On FMAP without RW slots, PSP verstage fails to build because of
reference to FMAP_SECTION_FW_MAIN_A_*. Instead extract the offset and
size of relevant sections using fmap_locate_area().
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I29997534c6843b47a36655431f79e5c70bd17f9b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Earlier the entire SPI ROM is mapped at the start of verstage and then
unmapped at the end of verstage. With CB:74606, this behavior has
changed. So unmap the hash table CBFS file after usage.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim. Perform cold, warm reboots and
suspend/resume cycles for 50 iterations each. Ensured that there is no
impact to boot time.
Change-Id: I5c605f8ba8bbd571b589b3cdf91e9cc71d711c1c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75092
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Currently the SPI ROM is mapped completely when the boot device is
initialized. That mapping remains active throughout the execution time
of PSP verstage. Every 1 MiB of mapped SPI ROM region consumes 1 TLB
Slot in PSP for use during memory mapped or DMA access. With 16 MiB of
mapped SPI ROM + FCH devices + 4 reserved TLB slots, 31 out of 32 total
TLB slots is consumed. This leaves almost no scope for future expansion.
With upcoming programs possibly using 32 MiB SPI ROM, PSP will run out
of TLB slots to support 32 MiB.
Hence instead of mapping the entire SPI ROM upfront, get the SPI ROM SMN
address during the boot device initialization. Update the boot device
region operations to map and unmap the SPI flash with the desired offset
and size using the SVC call. Then anytime a memory mapped SPI ROM access
is performed: map the required area, read the data and immediately unmap
the area. There is no update required when using CCP DMA, since the
concerned SVC call performs mapping and unmapping of the required SPI
flash area implicitly.
With these changes, maximum of 8 slots(size of RO section) might get
used at any point in time during the PSP verstage execution.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim. Perform cold, warm reboots and
suspend/resume cycles for 50 iterations each. Ensured that there is no
impact to boot time.
Change-Id: Icd44ea7b2a366e9269debcab4186d1fc71651db2
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74606
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Currently unsigned PSP verstage binary is copied from ELF file only when
required in amdfw*.rom. If a signed PSP verstage binary is supplied
while building amdfw*.rom, then it is dropped. Copy the unsigned PSP
verstage binary always so that it can be used for signing directly from
the CI build infrastructure instead of a locally built binary.
BUG=None
TEST=Build Skyrim BIOS image and ensure that the unsigned PSP verstage
is part of the build artifacts.
Change-Id: If797dcfd20aa2991f3517904ef862406b9b9875c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75334
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>
|
|
Both the AMD AGESA reference code and the default coreboot
ACPI_CPU_STRING use hexadecimal numbers in the ACPI CPU object names, so
change the ACPI_CPU_STRING format string in the both the Stoneyridge
Kconfig and the common non-CAR AMD SoC config Kconfig which covers all
other AMD SoCs in soc/amd. All platforms where the P state and C state
SSDT from binaryPI (Stoneyridge) or FSP (Picasso) was used in coreboot
before it got replaced by native code, had at most 8 cores/threads, so
the mismatch never became apparent.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9d6822c5df01786ee541ce90734b75ed1a761fca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75250
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Set the default soft fuse bits to the recommended values
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I2354aefe90a08eaef95a68926806d11a9118c3de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
In ACPI 1.0 the processor objects were inside the \_PR scope, but since
ACPI 2.0 the \_SB scope can be used for that. Outside of coreboot some
firmwares still used the \_PR scope for a while for legacy ACPI 1.0 OS
compatibility, but apart from that the \_PR scope is deprecated.
coreboot already uses the \_SB scope for the processor devices
everywhere, so move the \_SB scope out of the ACPI_CPU_STRING to the
format string inside the 3 snprintf statements that use the
ACPI_CPU_STRING.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: I76f18594a3a623b437a163c270547d3e9618c31a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Don't set bit 2 of the return value of the _STA method in order for
Windows not to show a warning about an unknown device in the device
manager for this device.
TEST=The unknown device with device instance path ACPI\AMD0040\3
disappeared from the device manager in Windows 10 build 19045 on a
Mandolin board with a Picasso APU.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If005f06843956004c281fd70cf364171148cb9ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68962
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Commit 396fb3db74db ("soc/amd/*/acpi/mmio.asl,sb_fch.asl: hide AAHB
device") didn't only change the visibility of the device, but also
changed the _STA method to a name. While this worked, the specification
says that _STA is supposed to be a method, so change it back to being a
method.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id0932b2875aaf563a4dbd860bdd11a04272e3780
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75169
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This reverts commit d6e0a90aa0bd574b28b6c9b4b46289bf46a208db.
Reason for revert: Not ready to land, blocked by ancestor CL
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ic14e17db4aed2f998878920c66cdc16362920dcb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75050
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
FSP-M is normally memmapped and then decompressed. The SPI DMA
controller can actually read faster than mmap. So by reading the
contents into a buffer and then decompressing we reduce boot time.
It is interesting that FSP-M takes an additional 8ms to execute. I
suspect since we call it 50ms earlier it's having to wait for one of
its dependencies.
BUG=b:179699789
TEST=Boot guybrush and see 30ms reduction in boot time
| 970 - loading FSP-M | 0.316 | 0.997 Δ( 0.68, 0.05%) |
| 17 - starting LZ4 decompress (ignore for x86) | 0.026 | 13.874 Δ( 13.85, 0.96%) |
| 18 - finished LZ4 decompress (ignore for x86) | 64.361 | 0.337 Δ(-64.02, -4.43%) |
| 2 - before RAM initialization | 0.534 | 0.529 Δ( -0.01, -0.00%) |
| 950 - calling FspMemoryInit | 1.455 | 1.132 Δ( -0.32, -0.02%) |
| 951 - returning from FspMemoryInit | 207.695 | 216.537 Δ( 8.84, 0.61%) |
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I850b1576501753a355e7b23745e04802a0560387
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Beware that there's no XHCI2 controller and the USB4 controller device
pointers were added right after the xhci_0 and xhci_1 controller device
pointers.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I14725d4b546ffcca42e21bbe7756babaaff8fea3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74658
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Return 0xf from PCI0 _STA method so that bit 2 is set which indicates
that the device should be shown in the user interface. This ports commit
c259d7192806 ("soc/amd/stoney/acpi: Unhide PCI0 root device from OS")
forward from Stoneyridge to the newer AMD SoCs.
TEST=On Mandolin the PCI Express Root Complex now shows up in the device
manager on Windows 10 and when switching the view to 'devices by
connection', all PCI(e) devices are shown below it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4155556dc5df8f163fe06aa6719fadbb2684cc19
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74949
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Adjust a few things so that the sleepstates.asl file is the same for
sb/amd and soc/amd. These adjustments don't have a functional impact.
Change-Id: I0cc9462b326cdc371ffdbf5759d8adc42456ce74
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74960
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Commit cbc5d3f34b87db779829eabc90c32780a3865a56 ("soc/intel: Don't
report _S1 state when unsupported") added the `ACPI_S1_NOT_SUPPORTED`
option and commit 0eb5974def63a2fc0dce6dfdad62b0b4c6f4b865 ("acpigen:
Add a runtime method to override exposed _Sx sleep states") added a
mechanism to override the enabled sleep states at runtime. However,
these were only hooked up to Intel sleepstates. so the options would
not have any effect on AMD platforms.
Apply the changes from these two commits to AMD sleepstates so that
both options can be used on AMD platforms as well.
Change-Id: I7d5ef2361e36659ac5c6f54b2c236d48713a07c9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74959
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that we don't need to find a specific resource in the set resources
function any more, there's no need to use hard-coded indices for the
fixed resources. Instead use an index variable that gets incremented
after each fixed resource got added. The index now starts at 0 instead
of at 1, but now the only requirement is that those indices are unique.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ida5f1f001c622da2e31474b62832782f5f303a32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74849
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Drop the custom lpc_set_resources implementation that does some register
access that has no effect and then calls pci_dev_set_resources and use
pci_dev_set_resources for set_resources in amd_lpc_ops instead.
The SPI controller's base address got configured early in boot in the
lpc_set_spibase call and the enable bits got set early in boot in the
lpc_enable_spi_rom call.
TEST=The contents of the SPI_BASE_ADDRESS_REGISTER at the beginning and
at the end of the call stay the same, so it's simply a no-op.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7a5e3e00b2e38eeb3e9dae6d6c83d11ef925ce22
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74848
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I77471d464dddffc63bb2f005fef3a33c84ff5f5e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74847
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I813a27e392a842188dc474018f82e10309783260
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I63fb70da3e9ded6c05354f94ee69bc6dd04e58f0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The memory map granularity for those devices is 4kByte.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8806128bdce8988f5cd7c8fa8a342fdb01eb7f42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Since the 16MByte of memory-mapped SPI flash region right below the 4GB
boundary is both a fixed region and isn't decoded on a device below the
LPC device, but assumed to be decoded by the LPC device itself, it
shouldn't be reported as a subtractive resource, but as an MMIO resource
instead.
TEST=On mandolin the 16MByte MMIO-mapped SPI flash now show up as a
reserved region in the e820 memory map which wasn't the case before:
13. 00000000ff000000-00000000ffffffff: RESERVED
The Linux kernel doesn't show any new or possibly related errors.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: Ib52df2b2d79a1e6213c3499984a5a1e0e25c058a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74839
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Iadc32f4dbf8bd48d8666a213d7b5f3ba42175a90
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
In order for Windows to detect/load drivers for any child devices,
the PCI0 root device status must be enabled and visible.
TEST=build google/liara, boot Windows, verify PCI child devices
visible in Device Manager.
Change-Id: I3fb1ba11247f0811120a4cf8a4fd99342ae201de
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
I forgot to remove these in commit 0fe36db154eb ("ACPI: Make FADT
entries for SMI architectural").
Change-Id: Ib1bc1dad6053ddb0454d4510917fd2bcf0901f35
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74811
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY
that points to same offset. Since the century field inside
RTC falls within the NVRAM space, and could interfere with
OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY.
There were no reference for the use of offset 0x48 for century.
Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
On boards with RECOVERY_MRC_CACHE FMAP section, populate type 0x63 BIOS
directory entry in RO with that section. If the RECOVERY_MRC_CACHE
section is not present, then fall back to RW_MRC_CACHE.
BUG=b:270569389
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ic5ac87685eaa5fec717e3efa4df7af511b4ce8aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73257
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
This ports back commit d75ee46d3ce6 ("soc/amd/picasso/acpi: Change PCI0
BAR window") to Stoneyridge so that the correct end of the non-fixed
MMIO region gets reported in PCI0's _CRS method.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I19153947cbb1b1b684291765eb1902caac65b9ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74809
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
This ports commit 8c28e51a16e1 ("soc/amd/picasso: fix host bridge bus
numbers") back to Stoneyridge so that the correct number of PCI buses
gets reported from PCI0's _CRS method. The MCFG ACPI table already had
the correct last bus number.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I40121ab0e0438281192b6a0bec8dbecdc1749379
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74804
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Add UPD parameter for eDP power sequence adjustment.
The edp_panel_t9_ms parameter is set for bloff to varybloff.
BUG=b:271704149
BRANCH=Skyrim
TEST=Build; Verify the UPD was pass to system integrated table.
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Change-Id: Id651c9cc4d6f4e27f6c78ca10ca12936d66ef43b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74789
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
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>
|
|
Rename the UPD pwr_on_vary_bl_to_blon to edp_panel_t8_ms to
match the eDP sequence timing in milliseconds.
BUG=b:271704149
BRANCH=Skyrim
Test=Build/Boot to ChromeOS
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Change-Id: Iecdfe47cd9142d8a1ddeee0ec988d37b2a11028e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74787
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Change-Id: I80aa71b813ab8e50801a66556d45ff66804ad349
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74600
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
It is unused. The use of field irq is problematic as it should
appear relative to IOAPIC GSI bases in the devicetree.
Change-Id: I460fd5fde3a7fba5518ccfc153a266d097a95a39
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Commit c7b8809f155a ("soc/amd/common/block/gfx: Use TPM-stored hash
for vbios cache validation") replaced checking the vbios signature
(first two bytes) with checking against a TPM-stored hash, but there
exists an edge case where the empty cache can be hashed and therefore
never updated with the correct vbios data. To mitigate this, re-add
the signature check to ensure that an empty cache will never be hashed
to TPM.
BUG=b:255812886
BRANCH=skyrim
TEST=build/boot skyrim w/selective GOP enabled, flash full firmware
image, ensure GOP driver is run until cache updated with valid data
and hashed to TPM.
Change-Id: Id06a8cfaa44d346fb2eece53dcf74ee46f4a5352
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74525
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Fix copy-paste comment on closing endif
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I9671a9228c304988eb3903391f74a21d80d0a8bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Change IRQ #0 to GSI #2 override to positive edge trigger from
the bus ISA default (positive edge).
Change-Id: I2de941071fca6f7208646a065a271fbf47ac2696
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74354
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Platform needs to implement this to provide information about SCI IRQ
pin and polarity, to be used for filling in ACPI FADT and MADT entries.
Change-Id: Icea7e9ca4abf3997c01617d2f78f25036d85a52f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Add the missing 'b' to the 4gb so that get_top_of_mem_above_4gb is in
line with get_top_of_mem_below_4gb.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic9170372d8b0c27d7de3bd04d822c95e2015cb10
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Glinda doesn't have an eMMC controller and also doesn't have GPIO pins
that eMMC signals can be multiplexed on, so drop the eMMC related code
from Glinda.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I49ead01075780ea97dae99a36632f7659fd00587
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74662
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Phoenix doesn't have an eMMC controller, so remove the remaining eMMC-
related defines.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I412c968479d23deb7f2e060b26b4a56ec9c764f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Mendocino and Rembrandt don't have an eMMC controller and also don't
have GPIO pins that eMMC signals can be multiplexed on, so drop the eMMC
related code from Mendocino.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib8ec49a7084bdd62e480baee75a280fde8b13d01
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74660
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I95916e409b3fbd4941a861054733a34100244da9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Since it's an internal bus, it's PCIE_ABC_C_DEVFN and not
PCIE_GPP_C_DEVFN. This also makes it consistent with the rest of the
internal PCI buses.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ica8b666161c3cd3b0b4a29f8a4b0aff473b4d833
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74656
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
In the PPRs #57019 Rev 3.03 and #57396 Rev 3.04, SMITYPE_XHC3_PME,
SMITYPE_XHC4_PME and SMITYPE_CUR_TEMP_STATUS_5 are defined, so add those
defines. When doing the initial update for Phoenix, at least XHC3 and
XHC4 PME events were missing from the PPR. Those two are the PME events
of the two USB4 controllers. SMITYPE_XHC2_PME doesn't exist on this SoC.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic6fff9175b73cc9d0fd324d4a568a5761b92d078
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74655
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
When one of the General-Purpose PCIe bridges is not used, it doesn't
show up on the PCI bus at all, so coreboot notes it as an issue in the
devicetree. This happens even if the device is marked as off.
To solve this, we're marking the GPP bridge devices in devicetree as
hidden, so they'll only show up in devicetree if they're actually used
on a mainboard.
BUG=b:277997811
TEST=Build
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7b7577baa2dbb0ea7ebbcdb1a8ae81770e61d76f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74527
Reviewed-by: Matt DeVillier <matt.devillier@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>
|
|
When one of the General-Purpose PCIe bridges is not used, it doesn't
show up on the PCI bus at all, so coreboot notes it as an issue in the
devicetree. This happens even if the device is marked as off.
To solve this, we're marking the GPP bridge devices in devicetree as
hidden, so they'll only show up in devicetree if they're actually used
on a mainboard.
BUG=None
TEST=Don't see the "PCI: Leftover static devices:" warning for these in
the boot console.
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I517776e4dedc70e957a0c836ab3c2e5d49e156d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74526
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Use get_top_of_mem_below_4gb instead of open-coding the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icc9e5ad8954c6203fc4762aa976bba7e8ea16159
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
|
|
Use get_top_of_mem_below_4gb instead of open-coding the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic673deb725a541c7535ae769f589cd82ea42a561
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Use get_top_of_mem_below_4gb and get_top_of_mem_above_4g instead of
open-coding the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I04f2a3744aee9beedaa97b154a652ce6f0c705c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Use get_top_of_mem_below_4gb and get_top_of_mem_above_4g instead of
open-coding the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I35895340f6e747e2f5e1669d40f40b201d8c1845
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74612
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Change-Id: I7d0718b5d2e0dd16eb90f63dd9d33329a2d808ba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Rename amd_topmem and amd_topmem2 to get_top_of_mem_below_4gb and
get_top_of_mem_above_4g to make it clearer what those functions return.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic6e98d94c731af74aea0ce276a9a7e4867e3986f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74589
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Set up SoC-specific XHCI defines and enable SOC_AMD_COMMON_BLOCK_XHCI
to allow for XHCI events to be logged.
BUG=b:277273428
TEST=builds
Change-Id: I3ca4f84fb0f1fef8441ab6ef7b6f6348c52b2922
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74280
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
After the obsoletion of Processor() it is necessary to provide
_CST package to define P_LVLx IO addresses for C2/C3 transitions.
The latency values from _CST will always replace those in FADT.
Change-Id: I3230be719659fe9cdf9ed6ae73bc91b05093ab97
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Iabba97e003d1a5140c98e3fc5a3496f66f8795c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74528
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Parts of this file were still a copy of the file from the Mendocino SoC,
so update the file to match the PPR #57019 Rev 3.03 and the chipset
devicetree of the Phoenix SoC. Phoenix has 4 GFX/GPP PCIe bridges/ports,
the numbering scheme of the GPP PCIe bridges/ports was changed so that
the numbers match the device and function numbers, and there are new
device functions for the IPU and the USB4 controller and router devices.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie9429c03839bb0199a04cd6cafe9a955ebdacc91
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74565
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In both PPR #57019 Rev 3.03 and PPR #57396 Rev 3.04, the i2s_ac97
function on bus C isn't mentioned any more and the microarchitecture
specification document for this SoC also doesn't mention it, so remove
it from the devicetree.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibd115953bdd60e1dfcc79797b0c2158e5d861636
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74564
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5e067f6fb2bab66d9b2f6965636845dfd8b7cacd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
CBFS library performs memory mapped access of the files during loading,
verification and de-compression. Even with MTRRs configured correctly,
first few file access through memory map are taking longer times to
load. Update the SPI DMA driver to load the files into CBFS cache, so
that they can be verified and de-compressed with less overhead. This
saves ~60 ms in boot time.
BUG=None
TEST=Build Skyrim BIOS image and boot to OS. Observe ~60 ms improvement
with the boot time. Performing additional test to confirm there are no
regressions.
Before:
=======
970:loading FSP-M
15:starting LZMA decompress (ignore for x86) 760,906 (60,035)
16:finished LZMA decompress (ignore for x86) 798,787 (37,881)
8:starting to load ramstage
17:starting LZ4 decompress (ignore for x86) 1,050,093 (13,790)
18:finished LZ4 decompress (ignore for x86) 1,054,086 (3,993)
971:loading FSP-S
17:starting LZ4 decompress (ignore for x86) 1,067,778 (3,313)
18:finished LZ4 decompress (ignore for x86) 1,068,022 (244)
90:starting to load payload
17:starting LZ4 decompress (ignore for x86) 1,302,155 (11,285)
18:finished LZ4 decompress (ignore for x86) 1,303,938 (1,783)
After:
======
970:loading FSP-M
15:starting LZMA decompress (ignore for x86) 709,542 (12,178)
16:finished LZMA decompress (ignore for x86) 739,379 (29,837)
8:starting to load ramstage
17:starting LZ4 decompress (ignore for x86) 1,001,316 (12,368)
18:finished LZ4 decompress (ignore for x86) 1,001,971 (655)
971:loading FSP-S
17:starting LZ4 decompress (ignore for x86) 1,016,514 (3,031)
18:finished LZ4 decompress (ignore for x86) 1,016,722 (207)
90:starting to load payload
17:starting LZ4 decompress (ignore for x86) 1,244,602 (10,313)
18:finished LZ4 decompress (ignore for x86) 1,244,831 (228)
Change-Id: Ie30b6324f9977261c60e55ed509e979ef290f1f1
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Boards with SOC_INTEL_COMMON_BLOCK_ACPI_CPU_HYBRID have
special handling for the time being.
Change of aopen/dxplplusu is coupled with sb/intel/i82801dx.
Change of emulation/qemu-i440fx is coupled with intel/i82371eb.
For asus/p2b, this adds MADT LAPIC entries, even though platform
has ACPI_NO_MADT selected. Even previously ACPI_NO_MADT creates
the MADT, including an entry for LAPIC address.
Change-Id: I1f8d7ee9891553742d73a92b55a87c04fa95a132
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74316
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The reference to a constant FCH IOAPIC interrupt count used
with GNB IOAPIC was a bit obscure.
Change-Id: I2d862e37424f9fea7f269cd09e9e90056531b643
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Use the common acpi_fill_root_complex_tom function instead of the SoC-
level northbridge_fill_ssdt_generator function that does basically the
same.
TEST=Resulting coreboot SSDT remains unchanged on Careena.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie0f100e0766ce0f826daceba7dbec1fb88492938
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Printing the value of a variable is not informative for a normal user,
so decrease the value from BIOS_INFO to BIOS_DEBUG.
Fixes: b9caac74a320 ("soc/amd/mendocino: Reinterpret smu_power_and_thm_limit")
Change-Id: I22f6293fd47633dfdbdae37b7257f47a5a4bb29c
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74271
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
PCIe bridges need to provide the LTR (latency tolerance reporting)
maximum snoop/non-snoop values so that they are inherited by downstream
PCIe devices which support and enable LTR. Without this, downstream
devices cannot have LTR enabled, which is a requirement for supporting
PCIe L1 substates. Enabling L1ss without LTR has unpredictable behavior,
including some devices refusing to enter L1 low power modes at all.
Program the max snoop/non-snoop latency values for all PCIe bridges
using the same value used by AGESA/FSP, 1.049ms.
BUG=b:265890321
TEST=build/boot google/skyrim (multiple variants, NVMe drives), ensure
LTR is enabled, latency values are correctly set, and that device
power draw at idle is in the expected range (<25 mW).
Change-Id: Icf188e69cf5676be870873c56d175423d16704b4
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74288
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Restrict DPTC to 15W boards, since we only have 15W values defined in
the devicetree. This will revert the 6W boards back to their default
values, rather than (incorrectly) configuring them with 15W values.
BUG=b:253301653
TEST=Verify DPTC values are set for 15W boards
TEST=Verify DPTC values are set not set for 6W boards
Change-Id: I94f3974fce6358e3cbb0c30c1af33eb7ecb29ad7
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74127
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The FSP will return the TDP in the format 0xX0000, where 'X' is the
value we're interested in. For example: 0xF0000 (15W), 0x60000 (6W).
Re-interpret the value so the caller just sees the TDP directly, without
needing to re-interpret things themselves.
BUG=b:253301653
TEST=Manually verify value is correct
Change-Id: I632e702d986a4ac85605040e09c1afab2bbdc59d
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74126
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use the newly introduced 'all_x86' make target to add the compilation
unit to all stages that run on the x86 cores, but not to verstage on
PSP.
TEST=Timeless builds for Mandolin without verstage on PSP and Guybrush
with verstage on PSP result in identical images with and without this
patch applied.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I94de6de5a4c7723065a4eb1b7149f9933ef134a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74151
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The i2c.c compilation unit is added to all stages in all cases, so use
the all target instead of adding it to all stages separately. Also order
the all targets alphabetically.
TEST=Timeless build on Mandolin results in identical image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie90380075a3c87d226cdcb0f41f7e94275eaaa42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74149
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
tsc_freq.c gets built into all stages, but the tsc_freq_mhz function it
implements calls the get_pstate_0_reg function which was only built into
ramstage. Since tsc_freq_mhz was only called in ramstage, commit
2323acab6a7a ("soc/amd/stoneyridge: implement and use get_pstate_0_reg")
didn't cause the build to fail, but better factor out the P-state-
related utility functions into a separate compilation unit and include
it in all stages that also include tsc_freq.c.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id3a3ee218f495be5e60a888944487704e7e8a1a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74145
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>
|
|
monotonic_timer.c, tsc_freq.c and uart.c get added to all stage targets,
so just add those to the all stage targets. They still need to be added
to the smm stage target, since the all target doesn't add things to the
smm stage.
TEST=Timeless build results in identical image for Gardenia.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I16c02bc0ff54553f212b94d110abef6a7bdedbb4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74144
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that only one build target per stage is included in the build
depending on CONFIG_SOC_AMD_COMMON_BLOCK_TSC being set, don't use a
separate ifeq block for this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id9e551b37707081eb2ea1d682013f57c7ca8aabd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74017
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
All AMD SoCs with Zen-based CPU cores are already using timestamps based
on the TSC counter, so use the existing common infrastructure instead of
reimplementing it in a similar way.
The behavior of the code changes slightly, but results in identical
timestamps. The timestamp_get implementation in soc/amd/common/block/cpu
divided the result of rdtscll() in timestamp_get by the result of
tsc_freq_mhz() and didn't override the weak timestamp_tick_freq_mhz
implementation that returns 1. The non AMD specific code returns the
result of rdtscll() in timestamp_get, but returns tsc_freq_mhz() instead
of 1 in timestamp_tick_freq_mhz, so we still get the correct timestamps.
TEST=The raw timestamps printed on the serial console are now multiplied
by the expected factor of the TSC frequency in MHz.
TEST=Normalized timestamps printed on the serial console by the x86 code
don't change significantly on Mandolin when comparing before and after
this patch. A slight variation in the timestamps is expected. An example
would be:
Before: CPU_CLUSTER: 0 init finished in 630 msecs
After: CPU_CLUSTER: 0 init finished in 629 msecs
TEST=The calculations of the time spent in verstage on PSP before
entering the bootblock on Guybrush result in similar times when
multiplying the value before the patch with the TSC frequency in the
case with the patch applied. The raw values printed on the serial
console by the verstage on PSP use the 1us time base, but the timestamp
logs that end up in CBMEM will be fixed up to use the same time base as
the x86 part of coreboot.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I57b732e5c78222d278d3328b26bb8decb8f4783e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
|
In order for the code to find the correct VBIOS file in CBFS, remap the
revision ID in the RAVEN2_VBIOS_VID_DID case to the one that matches the
CBFS file name. This will make the code work as expected on devices with
the PCI ID RAVEN2_VBIOS_VID_DID and a revision != RAVEN2_VBIOS_REV.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I94412dc2e778e7c4f74e475cd49114a00a81b2ce
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74045
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Refactor map_oprom_vendev_rev as a preparation to also remap the
revision ID in the RAVEN2_VBIOS_VID_DID case.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3b81a9464ed49672889fcb767920154fe6efdfcc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74044
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Use enum cb_err as return value of fsp_find_range_hob instead of using
the raw -1 and 0 values. Also update the call sites accordingly.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6c9f69a886f53868f1ef543c8fa04be95381f53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Since the return value of the fsp_find_range_hob call is only used in
one location, move the call and return value check into the if condition
block to not need the status variable.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4b9e9251368b86382dc4e050cf176db79dbfb230
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Instead of using the PSTATE SSDT generated by binaryPI, use the common
AMD code by selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE. To
match the SSDT from binaryPI, set ACPI_SSDT_PSD_INDEPENDENT to n. There
are two differences to the binaryPI SSDT: Now coreboot includes the C1
state in the _CST package instead of just having the kernel add this due
to the ACPI_FADT_C1_SUPPORTED bit being set and the address of the
PS_STS_REG P state status MSR is written to the corresponding field of
the _PCT package instead of being 0.
TEST=On Careena the new P and C state ACPI packages are nearly identical
to the ones from the SSDT from binaryPI with the two functional
differences mentioned above.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icdf6bc8f0e0363f185a294ab84edcb51322e7eb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74023
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Both the algorithm and the registers involved are described in the
public version of BKDG #55072 Rev 3.09 in chapter 2.5.2.1.7.3.2 _PSS
(Performance Supported States).
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9b2c177d9d80c5c205340f3f428186d6b8eb7e98
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
The help text for VGA_BIOS_SECOND_ID was outdated and from a time before
we found out that just looking at the CPUID doesn't reliably tell us on
which type of silicon we're running and which VBIOS file to pick, so we
had to use a different method. Update the help text to match what the
code does.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia568771ed7dfa0c7bb850b0efcd2959d7ddfd4a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73335
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
On the Zen-based CPUs, the transition and bus master latency are always
written as 0, but on but on Stoneyridge hardware-dependent values are
used. Introduce get_pstate_latency that returns 0 for all non-CAR AMD
CPUs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I81086fa64909c7350b3b171ea6ea9b46f1708f67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
