| Age | Commit message (Collapse) | Author |
|---|
|
Use IOMMU_CAP_BASE_[LO,HI] instead of magic values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7032d9f032a22649951ef1535f39b918eb8bd539
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76223
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>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie155cab1f659e9f7b64cd87ba8a77260056656d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76222
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Select DRIVERS_UART_8250MEM_32 will select DRIVERS_UART_8250MEM too.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I87a47e2d76ab7a0717edf725bf94d87f9f2357f1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76184
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
The dimm_num shall be dimm, not channel.
BUG=b:288520486
TEST=In kernel, see output from `dmidecode -t 17`.
Observe that Locator reflects proper location of the module.
Change-Id: Id876a5c245ed1a145c930b3456830d7b42780b74
Signed-off-by: Konrad Adamczyk <konrada@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
When probing the resource with the IOMMU_IOAPIC_IDX index, we need to
use the PCI device 0 function 0 on the first bus in the domain for
probing and not the domain device, since the resource isn't on the
domain device, but on the northbridge device which is B0F0D0 in the case
of the APUs.
TEST=This fixes the following error on Mandolin with Picasso:
AMD-Vi: [Firmware Bug]: : IOAPIC[1] not in IVRS table
AMD-Vi: Disabling interrupt remapping
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id88f17d68ba5accef6561837478828bd3d24baa5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76117
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Add NULL check for ivrs pointer before use.
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: Ibeb0ea3bcaa3512a93500588ad4f11046edee61f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
|
|
Don't rely on vendorcode to set enable bit on IOMMU.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: I1805a20656b7fb3915f8cc93c618ee074461840f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Zero-initialize the ivhd_range and ivhd_entry structs to make sure that
the whole struct is in a defined state.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iccacc89bfc497449ad0716a3436949505b65f748
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76079
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
To determine the length parameter of memset, use sizeof with the
instance as argument instead of the type. The behavior is the same, but
it clarifies parameters in the memset call a bit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I63674fbed7097a583cd77fa6e700652d6dcc5565
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Assign the current address casted to acpi_ivrs_ivhd[11,40]_t pointer to
*ivhd_[11,40] at the beginning of acpi_fill_ivrs[11,40] and then use
memset on *ivhd_[11,40] to zero-initialize the structs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I70b12fee99d6c71318189ac35e615589a4c8c629
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76077
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Zero-initialize the ivhd_hpet struct right at the beginning of the
ivhd_describe_hpet function to make sure that the whole struct is in a
defined state.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If4d3563c485eed4a7cb0526a62f7b6c80f763bfd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76074
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
|
Allow the caller to specify the HID that gets written to the
ivrs_ivhd_f0_entry_t struct.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I830f1fbbd535b100c88997ece10142a5d553950f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76073
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
|
|
Zero-initialize the ivhd_f0 struct right at the beginning of the
ivhd_describe_f0_device function to make sure that the whole struct is
in a defined state.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia6750b58dacb9b9192ed21128eb6e3a4495b96d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
|
|
The eMMC entry in the IVRS table should only be generated if an eMMC
controller is present in the SoC.
Where the PCI_DEVFN(0x13, 1) is from is currently unclear to me. There
is no PCI device 0x13 on bus 0 and the eMMC controller is also an MMIO
device and not a PCI device, but this is what the reference code does.
My guess would be that it mainly needs to be a unique PCI device that
won't collide with any existing PCI device in the SoC. Add a comment
about this too.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I00865cb7caf82547e89eb5e77817e3d8ca5d35dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75933
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Commit d054bbd4f1ba ("Makefile.inc: fix multiple jobs build issue")
added a dependency on $(obj)/fmap_config.h to all .c source files in all
stages, so it's not needed any more to add it as a dependency to files
that include fmap_config.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7b62917f32ae9f51f079b243a606e5db07ca9099
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76002
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
In order to clean up the post code macros, move them to a separate
header away from unrelated code. The new header file is included in
the file where the post codes are moved out of, so that the current
state remains unchanged.
Change-Id: I28a932ce071488e90000e1bbd30b4d739a4bae43
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75809
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>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I85f58565bf1f955f704e223d538d0b374bc6fbda
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75915
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie17fd14bed9ec91c5f11aee00bf5d2d2e253ec08
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75897
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This makes sure that the resource allocator won't use this address range
for anything else. In the systems I looked at, this was between the end
of the above 4GB memory and the beginning of the above 4GB PCI BAR MMIO
region, but better reserve it here so nothing else will get allocated
there if this expectation isn't met.
TEST=Reserved region is printed in the console logs:
update_constraints: PCI: 00:00.0 09 base fd00000000 limit fdffffffff mem (fixed)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5a8150873cb019ca1d903ed269e18d6f9fabb871
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
In soc/amd this function is unused so drop it and rename
_acpi_fill_ivrs_ioapic().
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ic403fd84cb9cd5805fbc6f0c5a64cefbf4b0cd81
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75711
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
|
|
By adding all DXIO IOAPIC with the same resource index, the IVRS code
can always pick that resource which simplifies the code.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I10345e2337dcb709c2c1a8e57a1b7dd9c04adb9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
|
|
Rename get_smee_reserved_address_bits to get_sme_reserved_address_bits
since the feature is called secure memory encryption and the last 'e' in
SMEE bit in the SYSCFG MSR just stands for enable. The function will
return a valid number of reserved address bits no matter if this is
enabled or not, so drop the second 'e'.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3795f7a861e39cb6c8209fee10191f233cbcd308
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
As per AMD64 Architecture Programmer's Manual, section 10.2.5 SMRAM
Protected Areas:
The TSEG range must be aligned to a 128 Kbyte boundary and the minimum
TSEG size is 128 Kbytes.
The SMM TSEG size should be less than SMM reserved size.
AMD TSEG mask works like an MTRR. It needs to be aligned to it's size
and it's size needs to be a power of 2.
Change-Id: Ic4f557c7b77db6fc5ab2783ca4e2ebe7a4476e85
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75405
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
This commit introduces a refactored version of the IVRS (I/O
Virtualization Reporting Structure) table generation. The main objective
of this refactoring is to generalize the process of generating the IVRS
table based on the IOMMU (Input/Output Memory Management Unit) domains
and their corresponding resources.
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: Ic471f05d6000c21081d70495b7dbd4350e68b774
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75451
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When instantiated in the DSDT, this macro will expand to the static part
of the PCIe root bridge device. This macro allows both to deduplicate
parts of the DSDT code as well as adding more than one PCIe root bridge
device in the DSDT.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I6f20d694bc86da3c3c9c00fb10eecdaed1f666a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75568
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that Stoneyridge is the only AMD SoC that still needs the part of
the SSDT that contains the TOM1 and TOM2, move it from the common code
to the Stoneyridge northbridge code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9091360d6a82183092ef75417ad652523babe075
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75564
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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: 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
On the Zen-based CPUs, P state 0 corresponds to the first P state MSR,
but on Stoneyridge this isn't the case. Introduce get_pstate_0_reg that
returns 0 for all non-CAR AMD CPUs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icc11e5b6099d37edb934e66fe329d8013d25f68d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Factor out the MSR access into a function with a more descriptive name.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I331c3205390edcbd8749b2d52b7cc7ac3a8ced5a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
The SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option is valid for all SoCs
with Zen-based CPU cores including the family 1Ah, so remove the suffix.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I58d29e69a44b7b97fa5cfeb0e461531b926f7480
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74015
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Move the static mhz variable inside the only function that is accessing
it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ief98c0a1c35fe1bbc4ff38dd175f12e0b3ddc515
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74014
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>
|
|
Use get_pstate_core_freq instead of open-coding the calculations in
tsc_freq_mhz. In the case of the CPU frequency divider being 0,
get_pstate_core_freq will return 0; in this case that shouldn't happen,
TSC_DEFAULT_FREQ_MHZ will be used as frequency, since for the TSC
frequency it's better to err on the end of the expected frequency being
too high which will cause longer than expected delays instead of too
short delays.
Now that the code is using get_pstate_core_freq, this code is valid for
Glinda too, so also remove the comment on the
SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option being selected in the Glinda
Kconfig. This Kconfig option will be renamed in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I01168834d4018c92f44782eda0c65b1aa392030d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74013
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>
|
|
This function will be used in follow-up patches for both the TSC rate
calculation and the still to be implemented P state ACPI table
generation in coreboot. The was checked against BKDG 52740 Rev 3.05,
BKDG #55072 Rev 3.04, and BKDG #50742 Rev 3.08.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9afaa044da994d330c3e546b774eb1f82e4f30e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Factor out the get_pstate_core_freq function from the SoC's acpi.c files
to both avoid duplication and to also be able to use the same function
in the TSC frequency calculation in a follow-up patch. The family 17h
and 19h SoCs use the same frequency encoding in the P state MSRs while
the family 1Ah SoCs use a different encoding. The family 15h and 16h
SoCs use another encoding, but since this isn't implemented in
Stoneyridge's acpi.c, this will be added in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8619822c2c61e06ae5db86896d5323c9b105b25b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74010
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>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Idb6087dc44e76ab63bc6b462c3328c23d83ae018
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74009
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
A core voltage ID larger than 0xff shouldn't happen, since SVI2's core
VID is only 8 bit long. In order for making it more difficult to use
this function in a wrong way that results in a very wrong voltage being
returned, also return 0 for those invalid core VID values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I95417c45db86cd2373879cdad8a07fb9eb8dfdda
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74000
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that all get_pstate_core_power implementations in each SoC's acpi.c
file is identical, factor it out into a common implementation. This
implementation will also work for Stoneyridge which isn't using the
common P state code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iba3833024a5e3ca5a47ffb1c1afdbfd884313c96
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73997
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since SVI3 has the CPU voltage ID split into two parts, a serial voltage
ID version specific function is needed to get the raw core VID value.
This will allow making get_pstate_core_power common for all AMD CPUs in
a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I71ca88c38b307558905a26cce8be1e8ffc5fbed4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73996
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.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>
|
|
Instead of implementing the conversion from the raw serial voltage ID
value to the voltage in microvolts in every SoC, introduce the
SOC_AMD_COMMON_BLOCK_SVI[2,3] Kconfig options for the SoC to select the
correct version, implement get_uvolts_from_vid for both cases and only
include the selected implementation in the build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I344641217e6e4654fd281d434b88e346e0482f57
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73995
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>
|
|
The included acpi/acpigen.h provides the cppc_config struct and nothing
in this header file is using the cppc_config struct.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia91fd4105e6872d812f595447783d02a0dd1568b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73993
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
When the code was made common in commit 8f7f4bf87a23 ("soc/amd/cezanne,
common: factor out CPPC code to common AMD SoC code"), the include guard
wasn't renamed accordingly, so do that now.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9eefe2065fae31e97aa4e6710008a6f9712bed40
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73992
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since we already have and use the pstate_msr union in get_pstate_info,
also pass it directly to the get_pstate_core_freq and
get_pstate_core_power function calls avoids having to sort-of convert
the msr_t type parameter in the implementations of those two functions.
In amdblocks/cpu.h a forward declaration of the pstate_msr union is used
since soc/msr.h doesn't exist in the two pre-Zen SoCs that also include
amdblocks/cpu.h.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I112030a15211587ccdc949807d1a1d552fe662b4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73926
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
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>
|
|
Use the pstate_msr union in get_pstate_info to check if the P state
enable bit is set. Also drop the now unused PSTATE_DEF_HI_ENABLE_SHIFT
and PSTATE_DEF_HI_ENABLE_MASK definitions.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I79119e09af79a4bb680a18e93b4a61a049f0080e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73925
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
When doing coreboot builds, we can set V=1 to see all of the make info
printed as the compile is happening. Use this flag to set the debug
flag for amdfwtool so it doesn't have to be enabled separately.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5b05cbc9f9b540a174db479822af657cf35733de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73658
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The regex getting rid of lines containing a '*' didn't match anything
in any configs, so get rid of it. There's nothing in the amdfwtool
dataparse.c file that would match it either.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I05aaf46cfb479cebab9234a47574073335984a5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
After adding the ability to add paths into the amdfw.cfg file for the
amdfwtool, the dependency generation needs to be updated to not add
the firmware location in front of those values.
This also allows us to filter out the MP2 binaries as dependencies
based on whether or not the Kconfig value is set.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3a9b9c8246808dc60020a32a7d9d926bc5e57ccd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, the address of the microcode update can
be directly written to the raw value instead of needing to split it into
the lower and higher 32 bits and assigning those separately.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I51c84164e81477040a4b7810552d3d65c0e3656b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73636
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, the address of the bootblock_resume_entry
can be directly written to the raw value instead of needing to split it
into the lower and higher 32 bits and assigning those separately.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I7ebab1784ec592e18c29001b1cf3ee7790615bf8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
This separates the SPL fusing function into a separate C file which can
be excluded if it is not needed. This allows the psp_set_spl_fuse()
function to be made static again as the state of the function will
always match the boot_state entry.
Move the required #defines to the common header file so they can be
used by both psp_gen2.c & spl_fuse.c.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ifbc774a370dd35a5c1e82f271816e8a036745ad5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73655
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Even though right now TSEG will always be located below 4GB, better not
make assumptions in the SMM relocation code. Instead of clearing the
higher 32 bits and just assigning the TSEG base and per-core SMM base to
the lower 32 bits of the MSR, assign those two base addresses to the raw
64 bit MSR value to not truncate the base addresses. Since TSEG will
realistically never be larger than 4GB and it needs to be aligned to its
power-of-two size, the TSEG mask still only needs to affect the lower
half of the corresponding MSR value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1004b5e05a7dba83b76b93b3e7152aef7db58f4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Since mst_t is a union of the struct containing the lower and higher 32
bits and the raw 64 bit value, there's no need to convert the lower and
higher 32 bits into a 64 bit value and we can just use the 64 bit raw
value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5923df84f0eb3a28ba6eda4a06c7421f4459e560
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The get_threads_per_core function isn't specific to the non-CAR CPUs and
also applies for Stoneyridge and even for family 16h model 30h outside
of soc/amd, so move it from the non-CAR-specific cpu.c file to the
common AMD SoC cpu.c file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I05946f163112ff93f33139f6c43fed5820fd0a3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73615
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>
|
|
Picasso already uses the Cxxx ACPI CPU device naming scheme, due to it
being what the AGESA reference code uses. We initially relied on the
AGESA/FSP generated SSDT for the P- and C-state support before we had a
native implementation for this in coreboot. The Cxxx naming scheme can
also be used for the other AMD SoCs except Stoneyridge which is pre-Zen
and doesn't select SOC_AMD_COMMON_BLOCK_NONCAR. The main advantage of
using Cxxx instead of CPxx is that the Cxxx scheme supports systems with
more than 256 CPU threads.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I884f5c0f234b5a3942dacd60847b2f095f9c0704
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73620
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
AMD SoCs currently only log the GPE# when an XHCI controller wakes the
system. Add code to log XHCI wake events to the elog.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Change-Id: Ic0489e1df55c4e63cb8a306099e3f31c82eebd58
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
This adds checks for three more error bits before requesting that the
SPL fuses are updated.
- While I'm here, I'm adding the include of types.h which was previously
done through other include files, but should be done independently.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I87a7d40850c4e9ddbb2d1913c1588a919fdb29d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Use the presence of an SPL (Software Patch Level) file to trigger the
function that reads and writes the SPL fuses. The current Kconfig
option will be used to decide to write the fuses. This allows us to
see the state of the SPL update bit which determines whether or not
SPL fusing is allowed and needed before enabling the fusing.
- Refactor a bit to prepare for following changes.
- Update phrasing
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7bd2798b984673a4bd3c72f3cab52f1c9a786c67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Now that the code using the ACPI_SSDT_PSD_INDEPENDENT Kconfig symbol is
moved to soc/amd/common/block/acpi/cpu_power_state.c, also move the
Kconfig symbol to the Kconfig file in this directory.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ide18111df38d4e9c81f7d183f49107f382385d85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73550
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Introduce the get_cstate_io_base helper function that write_cstate_entry
can call directly to get the C state control IO base address instead of
having get_cstate_info pass this Io address to each write_cstate_entry
call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I4cc80ded0a2fbc2dee9ca819e86284d9ffd58685
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73533
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>
|
|
The bit position of the P state enable bit in the 8 P state MSRs is
identical for all AMD chips including the family 16h model 30h APU that
lives outside of soc/amd. The other bits in those 8 MSRs are more or
less family- and model-specific.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia69c33e28e2a91ff9a9bfe95859c1fd454921b77
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73506
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>
|
|
The implementations of get_pstate_info of Picasso, Cezanne, Mendocino,
Phoenix and Glinda are identical, so factor it out and move it to the
common AMD SoC code. The SoC-specific get_pstate_core_freq and
get_pstate_core_power functions remain in the SoC-specific code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibe0494f1747f381a75b3dd71a8cc38fdc6dce042
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
