| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Instead of using a magic constant in the bit_offset field of the C state
resource for the C1 state that's entered via the MWAIT instruction, use
the existing ACPI_FFIXEDHW_CLASS_MWAIT define. This value is checked by
acpi_processor_ffh_cstate_probe in the Linux kernel.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9edc681efab15b5ceba91c8105f7dc6d687d8be8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73498
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 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 pstate_cnt FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If3ddb466de1d437361d811e45e328a1dbff02fcc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73419
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
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 mon_alrm FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iabb5fc7367f1e4e7acea1a58abdb643fc46ca776
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73418
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
|
|
Add stt settings for dptc tablet mode.
BUG=b:257149501
BRANCH=None
TEST=Check if the STT value matches the clamshell/tablet mode.
Run the WebGL aquarium with 5000 fish and verify that there is
no power drop peak.
Change-Id: Ib4aad3af8761b20084717b15a462edf4704b83cc
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73205
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.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>
|
|
Phoenix' implementation of map_oprom_vendev uses this simplified
implementation, so port this back to Cezanne too.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0aa3a0fed37c6cba15a668ada639f5fd0c212d2f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73387
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
Add a new parameter STT_ALPHA_APU' for each DPTC mode.
BUG=b:257149501
BRANCH=None
TEST=Check if the STT value matches the expected setting.
Change-Id: Ib27572712d57585f66030d9e927896a8249e97a7
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-by: John Su <john_su@compal.corp-partner.google.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>
|
|
IRQ9 is used as ACPI SCI IRQ, so add a define for that and use it in the
code like it is also done in the other SoCs in soc/amd.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iddb51d70c15ab1d7088f62b61e22510bd1b30b1e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73320
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since there's a define for the ACPI_SCI_IRQ 9, use the define instead of
a magic number in the code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I23c8f62929f3f66192698e10826d10329ef3d8cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73319
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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 res2 FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifa69ae61bea82acf66e7210c4103ef48e36dbdd2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73318
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use enum cb_err to return an error/success state instead of an int in
get_nv_rdev and get_nv_rdev_rw.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I73706a93bc1dbc8556e11885faf7f486c468bea9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73317
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
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>
|
|
The bool type is used although stdbool.h isn't included. Include types.h
which will include both stdint.h and stdbool.h
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5213ddae3ceb36e0b2e09f8ef3f7f414ebdf187f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73316
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
Add option for mainboards to target builds for SimNow.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Id765437b69f1bc3a9f9d7858edcd27e687d5a7f3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73164
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Rather than explicitly checking for Recovery or Developer mode via
vboot, use display_init_required() so that vboot is not required, and
other instances where the display is needed pre-OS (such as when
applying a critical system update) are covered as well.
With this change, SoCs implementing selective GOP init will need to
select VBOOT_MUST_REQUEST_DISPLAY in order for display_init_required()
to not assert on compilation.
BUG=b:255812886
TEST=build/boot skyrim
Change-Id: Iac7e06863764a9f21c8a50fc19050cb5a6627df2
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73046
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Rather than explicitly checking for Recovery or Developer mode via
vboot, use display_init_required() so that vboot is not required, and
other instances where the display is needed pre-OS (such as when
applying a critical system update) are covered as well.
Select VBOOT_MUST_REQUEST_DISPLAY in order for display_init_required()
to function properly (and not assert on compilation).
BUG=b:255812886
TEST=build/boot skyrim
Change-Id: If2fee71bcc11468fd2db0abaafe4ea35e2953993
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
The coreboot-common acpi_create_fadt writes a pointer to the FACS table
into both firmware_ctrl and x_firmware_ctl_l FADT fields and sets
x_firmware_ctl_h to zero. When x_firmware_ctl_[l,h] is non-zero, the
pointer in firmware_ctrl will be ignored, but that's what is already
done on Cezanne and newer.
TEST=Linux doesn't complain about any new ACPI problem on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib9eab4dcf828f28a60c6312ec96872aac4cfb266
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
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 ARM_boot_arch FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ica968db1228a2d63e83f2b6c4ea57c5f02bf1504
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73187
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Phoenix2 VBIOS PCI DID is 15c8 though the VBIOS image uses a different
PCI ID i.e. 0x1205, so we need to implement map_oprom_vendev for the SoC.
Change-Id: I7eef5eb41b781f02abb9dd4098e92a8652a431f5
Signed-off-by: Ritul Guru <ritul.bits@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73122
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The EFS entry at offset 0x14 can point to either the first level PSP
directory table or to the PSP combo directory structure that was used
before the introduction of the AMD A/B recovery scheme. This scheme is
not to be confused with the VBOOT scheme. The PSP verstage code checks
if the header this entry points to begins with the PSP_COOKIE, which
indicates the entry is a first level PSP directory table. Due to that,
the EFS entry at offset 0x14 is always expected to point to a PSP
directory table, so rename combo_psp_directory to new_psp_directory to
match the actual usage. This EFS entry that points to the PSP directory
table is called new_psp_directory, since the entry at EFS offset 0x10
was used on some early AMD chips to point to the older PSP directory
table and that one is already called psp_directory. amdfwtool uses the
same naming scheme for those two PSP directory table pointers.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I10f19ee63f8d422433dba64402d84fd6bb9e0f9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73083
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add the correct defaults for VGA_BIOS_ID and VGA_BIOS_FILE in
Mendocino's Kconfig instead of relying on the board's .config files
providing the correct settings. Those settings are per-SoC and not
per-board, so this is valid for all boards using the Mendocino APU.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I09c537d3801123e7ffc01608171918b0396b7a5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Add the correct defaults for VGA_BIOS_ID and VGA_BIOS_FILE in Cezanne's
Kconfig instead of relying on the board's .config files providing the
correct settings. Those settings are per-SoC and not per-board, so this
is valid for all boards using the Cezanne APU.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I67101d518c6b873ad89932ae39c2deb2ed6a4c29
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
map_oprom_vendev_rev is implemented in graphics.c in the SoC directory.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0123cb8ff662445fd0a613711d9e1981272b1235
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73052
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The way the PSP_APCB_FILES list is created will always insert at least a
space into it. When tested by the if, this space will prevent the else
clause from ever running and never generate a build error.
Remove the non-functional check. Instead, mainboards should select
warn_no_apcb or die_no_apcb to generate a warning message or build error
if the APCB is missing.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ic96846d74df2dc279e13b22f2a83b6f893954fe8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73009
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The way the PSP_APCB_FILES list is created will always insert at least a
space into it. When tested by the if, this space will prevent the else
clause from ever running and never generate a build error.
Remove the non-functional check. Instead, mainboards should select
warn_no_apcb or die_no_apcb to generate a warning message or build error
if the APCB is missing.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I26b96966495dc35a8b4a0cb7d5a841f3812f2a70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73007
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The way the PSP_APCB_FILES list is created will always insert at least a
space into it. When tested by the if, this space will prevent the else
clause from ever running and never generate a build error.
Remove the non-functional check. Instead, mainboards should select
warn_no_apcb or die_no_apcb to generate a warning message or build error
if the APCB is missing.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ib9fe0f05739fb19da2494629dc1d5aaa0ca6431f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73006
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add target to die when no APCB is found. This is not always a fatal
case, so mainboards can select between this and warn_no_apcb.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I5bbc8dd3200c4781677411e67a4b5f1fe8b20286
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Move missing APCB warning from birman to amd/common so that other
mainboards can utilize the same warnings if the APCB is missing.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I7ae689726ae4f7ccdf6959e47cbb5aee15cdb690
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73002
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Extend the coverage of the 'ifeq ($(CONFIG_SOC_AMD_COMMON),y)' case to
the entire file. This matches the coverage of the related Kconfig.
Add comments to endif to show which if they are ending.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I369e23e7ee9463ca1ae487d1e2181c760ae1bab2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70208
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Since it actually depends on the SoC type whether the old PSP
directory table pointer or the new comboable PSP directory table
pointer is used in EFS, get this information from the SoC ID instead
of passing the comboable flag for the SoCs that need to use the new
comboable PSP directory table pointer.
TEST=Binary identical on amd/majolica, pcengines/apu2, amd/gardenia
Change-Id: I0c3f21065939d1b13c2607aba16cbef74dd8d389
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Add support for the selective GOP init feature by only running the FSP
GOP driver when necessary: if the FMAP cache is invalid, or if the
board is booted in either recovery or developer mode.
BUG=b:255812886
TEST=tested with rest of patch train
Change-Id: I7ddadc254e05aca0fdd7a9567160a9329cb0e15c
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Write the SHA256 hash of the cached VBIOS data when saving to FMAP,
and use it to validate the data read from FMAP on subsequent boots.
Add TPM2 as a dependency to the selection of VBIOS_CACHE_IN_FMAP.
BUG=b:255812886
TEST=tested with rest of patch train
Change-Id: I9c8f23b000b90a1072aeb7a57d3b7b2b2bc626dc
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72402
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
By saving the results of amdfwread into a file, it only needs to be run
once instead of every time amdfwread-offset-size-cmd is called.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I1afaf65b9b2f9fb856aefc3ff37fb3a3442f6369
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72924
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
To assist in debugging, add a way for PSP_verstage to send postcodes to
the system.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I22e45e26f599a0b4f0b781e9b97fccb68e2e5cc1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71852
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Instead of using PCI_DEVFN(SMBUS_DEV, SMBUS_FUNC), use the equivalent
SMBUS_DEVFN define.
Even though the FCH IOAPIC is in the LPC part of the FCH, it needs the
IVRS IOAPIC table's source_dev_id field set to SMBUS_DEVFN which is the
function 0 of the FCH PCI device. LPC is function 3 of the FCH device.
When assigning LPC_DEVFN to source_dev_id, the kernel from Ubuntu
2022.04 LTS complains about the IOAPIC part of the IVRS table being
wrong:
AMD-Vi: [Firmware Bug]: : No southbridge IOAPIC found
AMD-Vi: Disabling interrupt remapping
With SMBUS_DEVFN being used as source_dev_id, no such error is reported.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: I8470d67b2513031e75fb422d4c1c181e017ace0a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
APOB on Phoenix is larger, so expand the reserved DRAM and MRC_CACHE
regions to fit. This requires moving memory addresses around to prevent
overlapping memory linker errors.
TEST='./util/scripts/testsoc -K PHOENIX -K GLINDA' successfully builds
all boards
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I42af7230ca5f09ba66b2b3c4f99ac3feac7feeea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The function has already moved to fw.cfg.
4/5
of split changes of https://review.coreboot.org/c/coreboot/+/58552/28
Change-Id: Idf9e491ed46ae574ccd17f24925e3e5c595039fa
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72467
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
2/5
of split changes of https://review.coreboot.org/c/coreboot/+/58552/28
Change-Id: I18f73462a3995038fe93750320dfc053fec969ba
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
For MDN, PHX, & Glinda platforms, the Keyboard Reset functionality has
been moved from GPIO 129 to GPIO 21.
Additionally, the issue where the system would reset when the KBDRST_L
pin went low even when not configured for Keyboard reset seems to have
been fixed, so remove that text.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Iefe7e00d63777577b59ee98cb974b07afea1fd12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72912
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
One of the main functions performed by the FSP GOP driver is to modify
the ATOMBIOS tables (part of the VBIOS) in memory based on the display
output configuration. This device-specific modified VBIOS can be cached
in a FMAP region specific for that purpose, then loaded into memory
instead of the "generic" VBIOS, saving the ~130ms execution time of the
GOP driver.
As this approach only works when no pre-OS display output is needed,
limit its use to ChromeOS builds, with the GOP driver enabled, and
not booting in either recovery or developer modes.
SoCs supporting this feature will need to selectively run the FSP GOP
driver as needed, using the same criteria used here to determine
whether to load the VBIOS from CBFS or from the FMAP cache.
Boards utilizing this feature will need to add a dedicated FMAP region
with the appropriate name/size, and select the required Kconfig options.
BUG=b:255812886
TEST=tested with rest of patch train
Change-Id: Ib9cfd192500d411655a3c8fa436098897428109e
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
|
|
Instead of having a magic entry in the CPU device ID table list to tell
find_cpu_driver that it has reached the end of the list, introduce and
use CPU_TABLE_END. Since the vendor entry in the CPU device ID struct is
compared against X86_VENDOR_INVALID which is 0, use X86_VENDOR_INVALID
instead of the 0 in the CPU_TABLE_END definition.
TEST=Timeless build for Mandolin results in identical image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: I0cae6d65b2265cf5ebf90fe1a9d885d0c489eb92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72888
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
For Carrizo, the soc name was set as UNKNOWN.
The change is supposed to be binary unmodified, except the SPI
settings. According to the spec, the Stoneyridge and Carrizo have the
same definition of SPI setting in EFS.
Change-Id: I9704a44773b2f541f650451ed883a51e2939e12a
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66823
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
"break" is useless after "return".
Change-Id: I84bc506a3d50e937797f42659299bf90ce392e09
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72895
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>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
The AMD SimNow tool supports fast logging through an IO port. Add a new
console to support SimNow logging through port 80.
TEST=observe significant speed improvements on SimNow console log
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I42a431f48ea14ba4adacbd4a32e15abe7c5e4951
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72751
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Port over the remaining AMD SoCs to use CPUID_FROM_FMS. The Glinda CPUID
still needs to be updated to the actual CPUID, but for now just change
it to use CPUID_FROM_FMS.
TEST=Resulting image of timeless build for Gardenia (Stoneyridge),
Majolica (Cezanne), Chausie (Mendocino), Mayan (Phoenix) and Birman
(Glinda) don't change.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia508f857d06f3c15e3ac9f813302471348ce3d89
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72862
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Implement a get_soc_type function to determine if the silicon the code
is running on is Phoenix or Phoenix 2. This will for example be needed
to provide the correct DXIO descriptor table for the SoC.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5f2b668b83432426b04e7f1354b694ddd6c300d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72861
Reviewed-by: ritul guru <ritul.bits@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Now that there is a cpuid_match function, we can use it instead of doing
basically the same thing manually. In the functions is_fam17_1x and
is_fam17_2x both the stepping number and the lower nibble of the model
number are masked out. To avoid having magic constants in the code,
introduce the CPUID_ALL_STEPPINGS_AND_BASE_MODELS_MASK definition.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I758f9564c08c62c747cc4f93a8d6b540a1834a62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72860
Reviewed-by: Fred Reitberger <reitbergerfred@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>
|
|
TEST=Resulting image of timeless build for Mandolin doesn't change.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I44cb7759206e9e1ce79fd57f62b9a844e52f7394
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72857
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all family
15h model 60h and 70h steppings.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id05f849d59c04efa9f38dd66892f3cb99d94e3ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72855
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There are multiple Phoenix steppings, but that is now covered by using
CPUID_ALL_STEPPINGS_MASK.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id4eb3502dec5ebdfdbba263b15b34621952d0554
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72853
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all Glinda
steppings once GLINDA_A0_CPUID is updated.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic9b8cbb2dc925a8258db6a4eb0d1b00b2745637f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72852
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all
Phoenix 2 steppings that might be available in the future. Right now it
shouldn't change any behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If9878b4687360250cac4cfe1409d5dbad7147cf3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72851
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all
Mendocino steppings that might be available in the future. Right now it
shouldn't change any behavior.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I77ea8c6162667e0a318176e62078b1f57726c10c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72850
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use CPUID_ALL_STEPPINGS_MASK as CPUID match mask to support all Cezanne
steppings. This adds support for Cezanne stepping A1 and possible future
steppings.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Idb020052685d9369109f391797fdd8f8790a91d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72849
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use CPUID_ALL_STEPPINGS_MASK to only need one CPU device ID table entry
per family & model combination and not one per stepping.
TEST=Mandolin with a Picasso APU with PICASSO_B1_CPUID (0x00810f81)
still finished mpinit and boots successfully even though now only
PICASSO_B0_CPUID (0x00810f80) with CPUID_ALL_STEPPINGS_MASK specified as
device match mask. When commenting out the line with PICASSO_B0_CPUID
as a negative test, mpinit fails as expected.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I00ba43834ad86ecffa09d60599b17d122acd0b99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72848
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Instead of always doing exact matches between the CPUID read in
identify_cpu and the device entries of the CPU device ID table,
offer the possibility to use a bit mask in the CPUID matching. This
allows covering all steppings of a CPU family/model with one entry and
avoids that case of a missing new stepping causing the CPUs not being
properly initialized.
Some of the CPU device ID tables can now be deduplicated using the
CPUID_ALL_STEPPINGS_MASK define, but that's outside of the scope of this
patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0540b514ca42591c0d3468307a82b5612585f614
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72847
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Since all SoCs define the df_mmio_control union for the bits used in the
code, data_fabric_print_mmio_conf can take advantage of that and also
print a decoded version of those bits.
Output on Mandolin before the patch:
=== Data Fabric MMIO configuration registers ===
idx control base limit
0 93 fc000000 febfffff
1 93 10000000000 ffffffffffff
2 93 d0000000 f7ffffff
3 1093 fed00000 fedfffff
4 90 0 ffff
5 90 0 ffff
6 90 0 ffff
7 90 0 ffff
Output on Mandolin with the patch:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I06e1d3a3e9abd664f59f2bb852394e7f723f2b30
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
In contrast to Mendocino and all other AMD SoCs in the coreboot tree,
Rembrandt, on which Mendocino is based on, has a DF_MMIO_REG_SET_SIZE of
3 instead of 4, so the next data fabric MMIO register is 3 DWORDs after
the last one instead of the 4 DWORDs on the other SoCs. This was checked
against PPR #56558 Rev 3.04.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I454ad5d182f0040db93c9b3a83941333392c6061
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
To be able to handle a special case, add a per-SoC define for
DF_MMIO_REG_SET_SIZE instead of having this hard-coded as 4 in the
DF_MMIO_* macros. To avoid some duplication, also introduce the
DF_MMIO_REG_OFFSET macro.
TEST=Output from data_fabric_print_mmio_conf doesn't change on Mandolin.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I67420a2973c8ef9a7f0ce19ddc0013de69731689
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Since the MMIO decode range registers in the data fabric are part of the
data fabric and not of the northbridge, replace the NB prefix with a DF
prefix to make this a bit clearer.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ife5e4581752825e9224b50252955d485a067af74
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72877
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
This should make it a bit clearer that those registers are in the data
fabric configuration registers. Also move those defines right after the
register definition those are related to.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic107bd217f4af0a9ddfbe41aafd3c882aa968e22
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72876
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
CPUID 0x00a70f80 is Phoenix 2 and not Phoenix, so update the define name
to match.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie7500130d5470fdd824980b81746f3a0f6d277d4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72843
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: ritul guru <ritul.bits@gmail.com>
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>
|
|
Since things are done a bit differently on Stoneyridge, it's probably
safer to run a test instead of assuming that the test on Picasso was
sufficient to be reasonably sure that this will also work as expected on
Stoneyridge.
TEST=No change of ACPI-related messages in dmesg with this patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I432752fae8be08d3cbd7d30215b350c4528c7206
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
Instead of just printing the register contents, normalize the contents
of the base and limit registers to actual MMIO addresses and then print
those. This will hopefully avoid some confusion caused by the shifted
addresses.
Output on Mandolin before the patch:
=== Data Fabric MMIO configuration registers ===
Addresses are shifted to the right by 16 bits.
idx control base limit
0 93 fc00 febf
1 93 1000000 ffffffff
2 93 d000 f7ff
3 1093 fed0 fedf
4 90 0 0
5 90 0 0
6 90 0 0
7 90 0 0
Output on Mandolin after the patch:
=== Data Fabric MMIO configuration registers ===
idx control base limit
0 93 fc000000 febfffff
1 93 10000000000 ffffffffffff
2 93 d0000000 f7ffffff
3 1093 fed00000 fedfffff
4 90 0 ffff
5 90 0 ffff
6 90 0 ffff
7 90 0 ffff
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I62eeb88ddac6a7a421fccc8e433523459117976a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72739
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Glinda SoC, remove it form the global NVS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I627d05c09d9637caf15e17285dd2c8e0389747c5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Phoenix SoC, remove it form the global NVS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I24ad0a2fbc5a973c0cb40ed10942b5efc31191aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Mendocino SoC, remove it form the global NVS
and add an ACPI object for this in the DSDT of the mainboards that use
it in their ACPI code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1ed0407826f579eb14169246b7b14ba677c20e8d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Cezanne SoC, remove it form the global NVS
and add an ACPI object for this in the DSDT of the mainboards that use
it in their ACPI code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6953da5e0f1966aa3022364d9a9c72ebafc698cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Picasso SoC, remove it form the global NVS
and add an ACPI object for this in the DSDT of the mainboards that use
it in their ACPI code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia265f3eebf5e48c185d2e4bf4ef74f8eab7c9606
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Since the LIDS field is only used in the ACPI code and not in the C code
of any mainboard using the Stoneyridge SoC, remove it form the global
NVS and add an ACPI object for this in the DSDT of the mainboards that
use it in their ACPI code. Eventually the LIDS object should probably be
moved to the EC's ACPI code, but that's out of scope for this patch.
TEST=google/liara doesn't show ACPI errors in Linux' dmesg
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I778c4189607035b4765c6cb8b2e74030dcf9069f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72182
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
|
|
Not exactly sure about the usb4_xhci controllers, but for now I assume
those will behave like any other XHCI controller.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I22384f58e245a1486793831d29d22e9c618f646c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72773
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
The PCI Device ID Assignments table from PPRs #57019 Rev 1.65 and
PPR #57396 Rev 1.54 were used as a reference. Some devices will need to
have ops added in future patches. Since the xhci_2 device isn't there
any more, also drop it from the mainboard devicetrees. The actual USB
port configuration on xhci_0 and xhci_1 is updated in the next patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I49721bc44fa1e2a0118a8c3ac79a36aee64be687
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Now that the PCIe ports on device 1 are added, rename the aliases for
the PCIe ports on device 2 to have a common naming scheme. For phoenix
the device alias names are based on the device and function number the
bridge is connected to.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5f5698408019bb9222b599dd78540ca1b187b56d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72737
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Only the PCIe ports on the functions of device 2 were present in the
devicetree and had the amd_external_pcie_gpp_ops ops assigned. Add the
missing PCIe ports on the functions of device 1 and assign the
amd_external_pcie_gpp_ops ops to them.
This SoC uses a slightly different naming scheme for its PCIe GPP ports.
Previously the PCIe GPP bridge number from the PCI Device ID Assignments
table from the PPR was used. Those bridge numbers are one less than the
function numbers of the device. This is due to function 0 being a dummy
bridge to avoid having to shuffle around the function numbers when the
first bridge is unused, since the PCIe specification mandates the
function 0 to be implemented if any other function on the same device is
implemented. In order for the device aliases to be consistent with the
PCIe device and function numbers which is way more commonly used and
also what lspci shows and what goes into the DXIO descriptors, change
the naming scheme of the aliases.
This was checked with PPR #57019 Rev 1.65 and PPR #57396 Rev 1.54.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib5c62c1df585877d9b6986a462a3636d4f2eb4c7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72736
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Commit b171f768127d ("soc/amd/*: Hook up GPP bridges ops to devicetree")
missed adding the amd_external_pcie_gpp_ops ops to the gpp_gfx_bridge
PCIe ports, so add them. Those devices were previously covered by the
PCI_DID_AMD_FAM17H_MODEL60H_PCIE_GPP_D1 PCI device ID in the list that
got removed in the referenced commit.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I55434bf486569b32901b3840193a09cc5955abb2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72735
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
This switches the Picasso SoC to use the common reset code.
Picasso supports warm resets, so set the SOC_AMD_SUPPORTS_WARM_RESET
flag.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I52515b20ef6c70b137f176d95480757b16bd8735
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72755
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This switches the Phoenix & Glinda SoCs to use the common reset code.
Cezanne and newer do not support warm reset, so use cold resets in all
cases (including the OS).
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4593fa9766ac9e988722a02e355c971e147b8fae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72754
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This switches the Cezanne & Mendocino SoCs to use the common reset code.
This patch does not change any behavior on those chips.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ie05c790573e4e68f3ec91bacffcc7d7efb986d79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72659
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
