Age | Commit message (Collapse) | Author |
|
Use the newly introduced 'all_x86' make target to add the compilation
unit to all stages that run on the x86 cores, but not to verstage on
PSP.
TEST=Timeless builds for Mandolin without verstage on PSP and Guybrush
with verstage on PSP result in identical images with and without this
patch applied.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I94de6de5a4c7723065a4eb1b7149f9933ef134a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74151
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The i2c.c compilation unit is added to all stages in all cases, so use
the all target instead of adding it to all stages separately. Also order
the all targets alphabetically.
TEST=Timeless build on Mandolin results in identical image.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie90380075a3c87d226cdcb0f41f7e94275eaaa42
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74149
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Picasso and Cezanne use the serial voltage ID 2 standard to communicate
the CPU voltage to the voltage regulator module on the mainboard, while
Mendocino, Phoenix and Glinda use the serial voltage ID 3 standard for
this. Both standards encode the voltage in a different way, so add the
serial VID version number to the defines to clarify for which version
the define is.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8ddab8df27c86dc2c70a6dfb47908d9405d86240
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73994
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
The _LO part in the definition names is a leftover from before moving to
the pstate_msr union access to the bitfield elements where it still
mattered if a bit was in the lower of higher half of the MSR. With the
mask-and-shift access to the two parts of the MSR being gone, the _LO
part in the name isn't useful any more and possibly a bit misleading, so
drop that part.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib43c71e946388c944ecf40659d4c12ca02a27a5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73927
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>
|
|
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>
|
|
Add the pstate_msr union of a bitfield struct and a raw uint64_t to
allow easier access of the bitfields of the P state MSRs which will be
implemented in a following patch. PPR #57254 Rev 1.52 was used as a
reference. This patch adds and uses the cpu_vid_8 bit which is the 9th
bit of the voltage ID specified in the SVI3 spec. The way the CPU
frequency is encoded in the PSTATE MSR has changed compared to Phoenix,
so also update the comment in the SoC's Kconfig file that the selected
SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H is likely incompatible which will be
addressed in the future.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3d1878ce4d9bc62ac597e6f71ef9630491628698
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Assign true/false instead of 1/0 to the valid_freq_divisor bool variable
in get_pstate_core_freq.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I92d0eb029c55f80a2027ff6d404c63ed84282750
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.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>
|
|
And rename PSP_HW_IPCFG_FILE to PSP_HW_IPCFG_FILE_SUB0
Change-Id: Ia1ab8482074105de367905be2b4b0418066823d2
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.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 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iec9cf7c195fa5cb5c8d992aeab400d05cbe801c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
MAINBOARD_BLOBS_DIR is defined the same way by
picasso/cezanne/mendocino/phoenix/glinda and unused by stoneyridge, so
move it to a common area.
This makefile variable is currently only used to locate APCB blobs for
the different mainboards.
Add a Kconfig option to point to the APCB blobs directory. This allows
simple overriding to locations such as site-local.
TEST=Timeless builds
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I0702fdb97fbc2c73d97994ab4d5161ff0f467518
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69410
Reviewed-by: Jason Glenesk <jason.glenesk@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>
|
|
Even though the register name begins with ESPI, it resides in the SPI
registers and not in the eSPI registers, so add a comment to point this
out to hopefully avoid some confusion.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9f8d15ceb98f51aad0816021f98ec5c78953e7f3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72122
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>
|
|
Checked against document #57396 revision 1.52 and removed the
DIS_ESPI_MASCTL_REG_WR define, since that bit is marked as reserved.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3e8b1c65118b4e85e7934e822a7a7e329746a88d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72121
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
From Cezanne on, the TMPS, TCRT and TPSV fields are unused in both the C
and ACPI code, so they can be removed. Also remove the unused fields
that were previously used for PCNT and PWRS. The LIDS field is only used
in the ACPI code, but keep if for now, since it would require a bigger
rework to remove it from the global NVS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie1c3c25591deadb27b7bf38a81dcd6fe746de55b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72096
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The Picasso SoC code generates a CRAT ACPI table which is not done for
Cezanne and newer. A significant part of the Picasso CRAT generation
code can likely be moved to the common AMD SoC code and then used in all
SoCs, but this still needs to be checked.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8f1ebe74f0376c60396dbd80e64676d1374ed811
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72027
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This changes the alignment of the IVRS table from 8 bytes to 16 bytes
and aligns the ALIB table to a 16 byte boundary.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I965791fbbe499702e191dcbf1f5fbfcb5e1bab6b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72026
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
<gpio.h> chain-include <soc/gpio.h>.
Change-Id: I112e41ad4c7ee638954dfe3f1ddfeb10c138459a
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71807
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The device operations for the CPU bus are identical for all AMD SoCs, so
introduce a common device operations struct for this and use it in all
AMD SoC's chipset devicetrees as ops for the CPU cluster.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id32f89b8a33db8dbb747b917eeac3009fbae6631
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The AMD SoCs no longer have a variable position for EFS - it's now fixed
at 0xff020000 - 128KiB into the 16MiB ROM decode region.
It's a little more complex than that because the chip can be larger than
16MiB, and the entire ROM can be decoded if mapped above the 4GiB
boundary, but we don't currently support doing that in coreboot, so this
is enough for now.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I343a875ba9aa8294a090f2eff7b5dfb5e86334f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71769
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Replace old style declaration "const static" with "static const".
This to enable "Wold-style-declaration" command option.
Change-Id: I757632befed1854f422daaf4dfea58281b16e2f5
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71841
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I62b15d59cc4a5f214e45c3995f651228b1ae6ea7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71900
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Use the common preloader for fsp-s
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I32f8ca02c4de9e882f207c2dd2378b6b44dc61ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71848
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Id24a7c7db24f49672df9d5ceefec5b7596f23e09
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I080b7b579338c3cf342beabda54f43f525d8b65c
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71679
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I5a3e3506415f424bf0fdd48fc449520a76622af5
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71525
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since commit 28e61f16341f ("device: Use __pci_0_00_0_config in
config_of_soc()") config_of_soc() was changed form being an actual
function to a macro for the __pci_0_00_0_config struct pointer generated
by util/sconfig. This change didn't only improve linker optimizations,
but also turned runtime errors into link-time errors, so it's guaranteed
that __pci_0_00_0_config won't be NULL and config_of_soc() won't
"return" NULL.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id99ceaa9f7a70788da3f3068fb3da92d34fb6361
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70732
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The size of a pointer changes between a 32 and 64 bit coreboot build. In
order to be able to use a 32 bit FSP in a 64 bit coreboot build, change
the pointer in the UPDs to a uint32_t to always have a 32 bit field in
the UPD for this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5db2587ff74432a0ce1805d8d7ae76d650693eea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
At the moment IO trap is not implemented for AMD platforms.
Change-Id: Ib62ac4e4e418a8bab80c30dfb5183ecd8beb998d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Use the broadcast ID to deliver LINT1 as NMI to all CPUs,
instead of listing individual LAPIC IDs.
Change-Id: Iaf714d8c2aabd16c59c3bcebc4a207406fc85ca9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
For the most part, this doesn't change any post codes, simply making the
existing post-codes into macros.
picasso/romstage.c did get a couple of post codes removed to match the
other files.
The POST_ROMSTAGE and POST_BOOTBLOCK codes are intended to become global
at some point, while the POST_AGESA and POST_PSP codes would stay AMD
specific.
Change-Id: I007a09b6a3ed3280bac674cd74e298ec5c408ab7
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Update the fields that need to be updated directly in the local static
usb_phy_config struct instead of dereferencing the pointer written to
the corresponding UPD field. This will allow updating the type of UPD
field in a follow-up commit to enable 64 bit coreboot builds.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I44a9fe719e6803fc957fee3db13b261489ed313d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69896
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
This ports forward part of commit df0968062622 ("soc/amd/picasso: Add
support for 64bit builds") to the newer AMD SoCs.
Use -Wl instead of -l to get the output format that the commands in the
Makefile expect to extract the value for PSP_BIOSBIN_SIZE. Without this
change, readelf will split the output into two lines in case of a 64 bit
coreboot build. This results in invalid amdcompress and amdfwtool
command lines which will cause the amdfwtool call to fail with
Error: BIOS binary destination and uncompressed size are required
With the old readelf -l command we get this output in a 64 bit build:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000080 0x0000000002030000 0x0000000002030000
0x0000000000010000 0x0000000000010000 RWE 0x10
while we get the correct output in a 32 bit build:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000060 0x02030000 0x02030000 0x10000 0x10000 RWE 0x20
With readelf -Wl we also get the expected output in a 64 bit build:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x0000000002030000 0x0000000002030000 0x010000 0x010000 RWE 0x10
TEST=This fixes the 64 bit build on Cezanne with some follow-up patches
applied.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I35f9feda4d0da3546592dfac233ca66732bd5464
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69895
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Calling setup_ioapic() was only correct for the
IOAPIC routing GSI 0..15 that mimic legacy PIC IRQs.
Change-Id: Ifdacc61b72f461ec6bea334fa06651c09a9695d6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Use the newly added functions to iterate over the FSP HOBs to report the
resources used by FSP to the resource allocator instead of open coding
the iteration over the HOBs in the SoC code.
TEST=Patch doesn't change reported resources on Mandolin
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I67ca346345c1fa08b008caa885d0a00d2d5afb12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69476
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Use VBOOT_STARTS_BEFORE_BOOTBLOCK to determine whether the VERSTAGE
needs to be build as x86 stage.
Change-Id: I126801a1f6f523435935bb300f3e2807db347f63
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
When no HOB list is found, not only adding the resources reported by the
FSP were skipped, but also adding the GNB IOAPIC resource was skipped.
Fix this bug by moving the reporting of the GNB IOAPIC resource before
the resources reported in the FSP HOBs to not skip the IOAPIC resource
when there's no HOB list.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9174c8d7e5e94144187d27210e12f2dca3a6010f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69460
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It is no longer necessary to explicitly add "ERROR: "/"WARNING: " in
front of every BIOS_ERR/BIOS_WARN message.
Change-Id: I22ee6ae15c3d3a848853c5460b3b3c1795adf2f5
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69405
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>
|
|
Use the common device ops instead of an soc-specific device ops.
TEST=builds for each soc
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I1804200c3c3f5ab492d237f4b03484c383862caf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Morgana/Glinda have a different register mapping for data fabric access,
although the registers themselves are mostly compatible. The register
layouts defined by each soc capture the differences and the common code
can use those.
Move the register offsets to soc headers and update the offsets for
morgana/glinda per morgana ppr #57396, rev 1.52 and glinda ppr #57254,
rev 1.51
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I9e5e7c85f99a9afa873764ade9734831fb5cfe69
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This change disables support for memory types not used by each of the
chips. This will in turn remove the files for those memory types from
the platform builds.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8c7f47b43d8d4a89630fbd645a725e61d74bc2a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68994
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Add structs to define the data_fabric register bitfields, updated per
glinda ppr #57254, rev 1.51
Update IOMS0_FABRIC_ID and DF_MMIO_NP per referenced ppr.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I509eaf5910d8d65ce0956200d7c00451ff9ce864
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The data_fabric_set_mmio_np function is effectively identical, so move
it to common code.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I58e524a34a20e1c6f088feaf39d592b8d5efab58
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Also sort includes.
Change-Id: Iea29938623fe1b2bcdd7f869b0accbc1f8758e7a
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69033
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Don't set bit 2 in _STA in order for Windows not to show a warning about
an unknown device in the device manager for this device. Since the _STA
object just returns a constant, a name definition can be used instead of
a method definition.
TEST=The unknown device with device instance path ACPI\AAHB0000\0
disappeared from the device manager in Windows 10 build 19045 on a
Mandolin board with a Picasso APU.
Just shutting down and then booting it again won't clear some internal
state in Windows, so a reboot is needed instead for the change to become
visible.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8cb1712756c3623cc3ea16210af69cde0fa18f62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68961
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
CB:66943 - commit 8d66fb1a705 (soc/amd: Add amdfw.rom in coreboot.pre)
changed the build flow for the amd firmware binary after glinda was
branched from morgana. Update glinda to match the other SoCs.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5b0ccaa8c33e59f7146edd6a86f107480c152008
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68931
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
This adds the initial framework for the Glinda SoC, based on what's been
done for Morgana already.
I believe that there's more that can be made common, but that work will
continue as both platforms are developed.
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: I43d0fdb711c441dc410a14f6bb04b808abefe920
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68684
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|