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>
The GPE number used for XHCI has now been defined in AMD's common code
in CB:67936. Change over existing code to use this new definition.
BRANCH=guybrush
BUG=b:186792595
TEST=Ran on nipperkin device and verified that XHCI events string use
GPE 31.
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I9c2a44f7d2eb47422ae8c585e5e01ea0b420d461
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69917
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@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>
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>
With the exception of the generate_cppc_entries call, the
implementations of generate_cpu_entries of Picasso, Cezanne, Mendocino,
Phoenix and Glinda are identical, so factor it out and move it to the
common AMD SoC code. Since all SoCs that support CPPC already select the
SOC_AMD_COMMON_BLOCK_ACPI_CPPC Kconfig option, this can be used to only
call generate_cppc_entries for platforms where it is available.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I71323d9d071b6f9d82852479b60dc56c24f2b9ec
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73504
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Split the big PSP FW data into two parts, head and body. The head
needs to be located at original specific location. The body address is
more flexible. So the big body will not cover other needed FWs like
EC.
Give the body a specific named AMDFWBODY, which should be defined in
flashmap.
This is one of series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: Ia8b318f71632a2c9b97ce67486374dc24d23e63e
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72703
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Instead of hoping that the default the C state control IO address in
binaryPI won't interfere with any other IO space usage in coreboot,
assign the ACPI_CSTATE_CONTROL value to the CStateIoBaseAddress platform
config structure element to make sure that binaryPI will use a known
address for the IO port based C state control. binaryPI will write this
address to the MSR_CSTATE_ADDRESS and will then also use these IO ports
in the _CST packages in the PSTATE SSDT, so changing this won't cause
a mismatch between those two.
The default CStateIoBaseAddress in the FT4 Stoneyridge binaryPI used on
Careena is 0x1770, so this didn't collide with any other IO space
registers, but it's still much better to tell binaryPI which exact IO
addresses to use.
TEST=On Careena MSR_CSTATE_ADDRESS now contains the ACPI_CSTATE_CONTROL
IO base address 0x420 and the PSTATE SSDT has the IO address 0x421 in
the _CST package entry for the second C state which are both the
expected values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I207202802427d4bf00f283bcbd83a174ab0a2846
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5157fc031c5b19d8633132222520f582620208c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4f5743dd2e4dfdfeb3ffb2e9b964bdc75c84e6c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73502
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>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3669c66094f0137081888ebdd1af838e2ea269b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73501
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>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id97fcb74ff3d48994a3181d9c31cbbeb5a76c60a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73500
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>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6bd8879ce5968b24893b43041be98db55a4c3c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73499
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>
Introduce the get_cstate_info helper function that populates the caller-
provided cstate_values array with the data returned by the SoC-specific
get_cstate_config_data function. From the array get_cstate_config_data
returns, only the ctype, latency and power fields are used, so the rest
can be left uninitialized. Those 3 fields are compile-time constants.
For each entry, write_cstate_entry will generate the corresponding
resource information from the given data. In the C1 case where ctype is
1, the state is entered via a MWAIT instruction, while the higher C
states are entered by doing an IO read from a specific IO address. This
IO address is x - 1 bytes into the IO region starting at
MSR_CSTATE_ADDRESS for the Cx state. So for example C2 is entered by
reading from the C state IO base address + 1. This resource information
is generated during runtime, since the contents of MSR_CSTATE_ADDRESS
aren't necessarily known at compile-time.
MAX_CSTATE_COUNT is introduced so that the caller can allocate and pass
a buffer with space for the maximum number of C state entries. This
maximum number corresponds to the number of IO addresses the CPU traps
beginning from MSR_CSTATE_ADDRESS. In practice, it's unlikely that more
than 3 or maybe 4 C states will be available though.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c36c1d604ced349c609882b9d9fe84d5f726a8d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73428
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>
Instead of having binaryPI generate a PSTATE SSDT that uses \_PR_ as the
scope for the CPU objects and patching this SSDT in coreboot to use the
\_SB_ scope in patch_ssdt_processor_scope, request binaryPI to use the
\_SB_ scope instead by setting the late platform configuration option
ProcessorScopeInSb to true.
TEST=Careena still boots and Linux doesn't show any ACPI errors with
this patch applied. With only patch_ssdt_processor_scope removed, but
the ProcessorScopeInSb option not set, Linux will complain that it can't
resolve the \PR.P00x symbols.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If88820a0f5df923f129e2e3b5335f5f0e38ee7f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The legacy ACPI CPU control registers in IO space where the first 4 IO
locations control the CPU throttling value don't exist any more on the
Zen-based CPUs. Instead this IO address is written to MSR_CSTATE_ADDRESS
in set_cstate_io_addr which will cause accesses from the 8 IO addresses
beginning with ACPI_CSTATE_CONTROL to be trapped in the CPU core. Reads
from those IO addresses will cause the CPU to enter low C states.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c34e201cc0add1026edd7a97c70aa57f057782b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Finally figured out why ACPI_GPE0_BLK only being 4 bytes after
ACPI_CPU_CONTROL won't work and its due to the CPU trapping 8 IO
addresses from ACPI_CPU_CONTROL on for C state control. This is set up
in set_cstate_io_addr by writing the ACPI_CPU_CONTROL value into
MSR_CSTATE_ADDRESS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iedf53bbdae6ca65224601aad5cd1163df4b54131
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Picasso and newer don't implement the P_CNT register to control the CPU
duty cycle and also trap the C state control IO addresses directly in
the CPU, so those won't reach the FCH. This register is unused in the
Picasso code and not even defined any more in the Cezanne PPR. The
Picasso PPR does define this register, but since it's useless and might
even just be a leftover form a pre-Zen CPU generation, drop the define.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3820db542c4714a100c7d36de673daa1a06e4a67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the duty_offset and duty_width FADT field in
acpi_fill_fadt for all SoC except Stoneyridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib63b24891d44298841153dfc500b030619e1a5ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Picasso neither has the corresponding P_CNT register implemented nor
writes a _PTC ACPI object that would specify the P_CNT register. The
Picasso UEFI reference code also sets the duty_width FADT entry to 0.
This also aligns the Picasso code with the Cezanne code in this regard.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I74645e5c4e54a2ad6bc7f9e72f5f656027a79860
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The SPL parameter for DPTC settings is not available for STT-enabled
platforms. It needs to be removed to avoid confusing STT calculations.
BUG=b:265267957
BRANCH=none
TEST=Run the WebGL aquarium with 5000 fish and verify that
there are no power drop peaks.
Change-Id: I8e6dad7d24883f8aadce83ebac401ecd4137d61a
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
To support 32M flash, the non-vboot also need to split amdfw.
The amdfw.rom is the default filename added to CBFS.
Keep the default filename and then we don't have to change all the
CBFS definition.
This is one of series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: Id77b11422d4549cf57a1cd8980c7a9cf3597d1bc
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72702
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Instead of adding the P-state number to the PSTATE_0_MSR number to get
the P-state MSR number for the rdmsr call, provide a macro that directly
calculates the MSR number for a given power state. Also drop the unused
PSTATE_[1..4]_MSR definitions which also didn't cover all P-state MSRs
available in the hardware.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If85acf556efe82c209e1608e56c05f7a2a748403
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The latency values in the _CST package override the values in the
p_lvl2_lat and p_lvl3_lat FADT fields. In Picasso, Cezanne, Mendocino,
Phoenix and Glinda generate_cpu_entries generates the _CST packages for
each CPU device. The coreboot code for Stoneyridge doesn't generate _CST
packages for the CPU objects, but those are provided via the PSTATE SSDT
binaryPI generates and agesa_write_acpi_tables gets and adds to the ACPI
tables. The AGESA reference code also sets those two FADT entries to the
equivalents of ACPI_FADT_C2_NOT_SUPPORTED and ACPI_FADT_C3_NOT_SUPPORTED
so this also matches the AGESA behavior.
From the ACPI 6.4 spec: "Values provided by the _CST object override
P_LVLx values in P_BLK and P_LVLx_LAT values in the FADT."
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1116a3013576b18b6f521604d6b0a9d75b971e0b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
It's sufficient to generate CPU devices for all available CPU cores/
threads instead of for the maximum number of possible CPU cores/threads.
TEST=google/careena with 2 cores still boots and Linux doesn't complain
about ACPI errors due to referenced but not present CPU objects.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6850edfa305304060092cb5480f4296f4f5ddacc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
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
TEST=Build and boot to OS in Skyrim. Ensure that the Type 0x63 BIOS
directory entry is populated with the base and size of appropriate MRC
cache.
Change-Id: I49ec4f64e33c4d5780a7fe6a5540eab42b6cec9f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
If a mainboard has RECOVERY_MRC_CACHE and the recovery mode is enabled,
then use APOB data from that section and make any updates to that
section. Otherwise continue to use DEFAULT_MRC_CACHE section.
BUG=b:270569389
TEST=Build and boot to OS in Skyrim.
When in normal mode, DEFAULT_MRC_CACHE is used.
Normal Mode Boot1:
------------------
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[INFO ] APOB RAM hash differs from flash
[SPEW ] Copy APOB from RAM 0x02001000/0x1db18 to flash 0x0/0x1e000
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[DEBUG] SF: Successfully erased 122880 bytes @ 0x0
[INFO ] Updated APOB in flash
Normal Mode Boot2:
-----------------
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[DEBUG] APOB hash matches flash
When the device is in recovery mode, RECOVERY_MRC_CACHE is used.
Recovery Mode Boot1:
--------------------
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[INFO ] APOB RAM hash differs from flash
[SPEW ] Copy APOB from RAM 0x02001000/0x1db18 to flash 0x650000/0x1e000
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[DEBUG] SF: Successfully erased 122880 bytes @ 0x650000
[INFO ] Updated APOB in flash
Recovery Mode Boot2:
--------------------
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[DEBUG] APOB hash matches flash
Switch from Recovery Mode to Normal Mode:
-----------------------------------------
[DEBUG] FMAP: area RW_MRC_CACHE found @ 0 (122880 bytes)
[DEBUG] APOB hash matches flash
Switch from Normal Mode to Recovery Mode:
-----------------------------------------
[DEBUG] FMAP: area RECOVERY_MRC_CACHE found @ 650000 (122880 bytes)
[DEBUG] APOB hash matches flash
Change-Id: I93f357e407c98b6e5fca495f4f779fad54a3430f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Because the ChromeOS boards don't fill a manufacturer in for the memory
SPDs, that information isn't available from the FSP. We can get the
Manufacturer ID based on the memory name from CBI instead. Use this
information to fill in an ID so that the manufacturer name is available
in the SMBIOS information.
BUG=None
TEST=Look at dmidecode output
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I810c3191180dd3b566d7ea64006f29b625b10526
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73255
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The DMI error correction type was not being filled in, so was reporting
as "Error Correction Type: <OUT OF SPEC>". This patch fixes that.
Since it's now filling in information for both Type 16 & 17, rename
the function to reflect that.
BUG=None
TEST=dmidecode now reports the type correctly.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I6b51612d808c63de1acd2be952cb6c152f8a1be5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73253
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
