Age | Commit message (Collapse) | Author |
|
Function 0 of the devices that have the bridges to other buses are dummy
functions that can be left enabled to not have to shuffle around the
device function numbers when the first PCI bridge on those devices isn't
enabled. Those dummy device functions are however not PCI host bridges,
so change the comments from 'Dummy Host Bridge' to 'Dummy device
function'.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Nico Huber <nico.h@gmx.de>
Change-Id: Ibddfdf558d84bc44434d718b86f41bd06044b22a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0eae9e4d246bd07f43b1d77e5ad7649c010d0efe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Commit e728766f4596 ("soc/amd/mendocino: Do not load MP2 Firmware when
in RO") added logic to ensure that the MP2 disable soft fuse bit was set
for the RO section, but failed to check if the bit was already set
otherwise (as it is for non-ChromeOS builds). This caused the bit to
appear twice in the PSP_RO_SOFTFUSE_BITS string, and when the string
was converted to a series of numeric values and added together, bit
(n+1) ended up being set instead of bit n.
To mitigate this, use the makefile sort() function to ensure the
PSP_[RO_]SOFTFUSE_BITS string does not contain any duplicates before
the bitmask is calculated. Apply this to all AMD SoC makefiles where
the softfuse bits are added.
TEST=build/boot google/skyrim (frostflow). Use a verbose build (V=1)
to verify that the correct soft fuse value is passed to amdfwtool for
RO and RW_A/B for both ChromeOS and non-ChromeOS builds.
Change-Id: I2e207e20132d44016fbcb986bdfd8e935d8fead5
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78823
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Move all security patch level (SPL) related Kconfig options to the
common AMD PSP Kconfig file. Commit 4ab1db82bb30 ("soc/amd: rework SPL
file override and SPL fusing handling") already reworked the SPL
handling, but missed that another Kconfig option
SOC_AMD_COMMON_BLOCK_PSP_FUSE_SPL controlled if the PSP mailbox command
to update the SPL fuses was sent by the code that got added to the build
when PERFORM_SPL_FUSING was selected.
To make things less unexpected, rename PERFORM_SPL_FUSING to
SOC_AMD_COMMON_BLOCK_PSP_SPL since it actually controls if the SPL
support code is added to the build and also rename
SOC_AMD_COMMON_BLOCK_PSP_FUSE_SPL to PERFORM_SPL_FUSING. This changes
what PERFORM_SPL_FUSING will do from including the code that could do
the fusing if another option is set to being the option that controls if
the fusing mailbox command will be set. All SoCs that support SPL now
select SOC_AMD_COMMON_BLOCK_PSP_SPL in their Kconfig, which won't burn
any SPL fuses.
The logic in the Skyrim mainboard Kconfig file is reworked to select
PERFORM_SPL_FUSING for all boards on which the SPL fuses should be
updated; on Guybrush PERFORM_SPL_FUSING default is changed to y for all
variants. The option to include the code that checks the SPL fusing
conditions and allows sending the command to update the SPL fuses if the
corresponding Kconfig is set doesn't need to be added on the mainboard
level, since it's already selected at the SoC level.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I12fd8775db66f16fe632674cd67c6af483e8d4e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
|
|
When CBFS verification is enabled, add amdfw_a/b.rom at offset 128 bytes
to account for CBFS file header with hash attribute. When CBFS
verification is disabled, add amdfw_a/b.rom at offset 64 bytes to
account for CBFS file header without hash attribute.
BUG=None
TEST=Build Skyrim, Myst BIOS images with and without CBFS verification
enabled.
Change-Id: Ic374ac41df0c8fb8ce59488881ce5846e9058915
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78425
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Fix the hash file names to be used to verify signed PSP binaries when
booting with VBOOT FW Slot B.
BUG=None
TEST=Build and boot to OS in Myst with PSP Verstage enabled using both
VBOOT slots A and B.
Change-Id: I89f02922bc901d8ac71d48bf5128fe6ecead43a0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Some stalls are observed while using CCP DMA in PSP verstage -
especially with CBFS verification enabled. Also with RW CBFS
verification enabled, the entire firmware body is not loaded during
verstage for verification. Instead the files are verified as and when
they are loaded from CBFS. Hence the impact to boot time is reduced
since only few files are loaded during PSP verstage. Hence disable CCP
DMA in PSP verstage until the root cause is identified.
BUG=None
TEST=Build and boot to OS in Myst with CBFS verification enabled.
Change-Id: I22ac108b08abcfe432dfd175644393e384888e11
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78234
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add SPI flash RO ranges to be verified by GSC in order to enable CBFS
verification. Also with CBFS verification enabled, CBFS metadata is
more than 64 bytes. So configure the offset of amdfw_a/b to 128 bytes -
next address aligned to 64 bytes.
BUG=b:277087492
TEST=Build and boot to OS in Myst with and without CBFS verification
enabled.
Change-Id: Ibfffd3d6fce8b80ec156a7b13b387e1df8c43347
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78233
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The SPL_TABLE_FILE and SPL_RW_AB_TABLE_FILE Kconfig options provide a
way to override the default SPL file configured in the SoC's fw.cfg file
by passing the '--spl-table' parameter to amdfwtool which will then use
the override instead of the SPL file from the fw.cfg file. When
SPL*_TABLE_FILE is an empty string, the corresponding add_opt_prefix
call in the makefile will result in no '--spl-table' parameter being
passed to amdfwtool, so it'll use the default SPL file from fw.cfg. In
order to not pass an SPL override by default, remove the default from
the SPL_TABLE_FILE in the SoC's Kconfig. The SoC default pointed to the
same SPL file as in fw.cfg file anyway. Now only when a mainboard sets
this option to point to a file, that file will be used as an override.
This override is used to include a special SPL file needed for the
verstage on PSP case on the Chromebooks. Since SPL_TABLE_FILE is an
empty string by default, neither the SPL_TABLE_FILE Kconfig option nor
it being evaluated in the Makefile need to be guarded by HAVE_SPL_FILE,
so remove the dependency in the Kconfig and the ifeq in the Makefile.
Before this patch, the HAVE_SPL_FILE option controlled two things that
shouldn't be controlled by the same Kconfig option: Only when
HAVE_SPL_FILE was set to y, the SPL_TABLE_FILE override was taken into
account, and it also controls if spl_fuse.c got added to the build which
when added will send the SPL fusing command to the PSP. So the case of
needing an SPL file override, but not updating the SPL fuses wasn't
supported before.
The SPL file in the amdfw part will be used by the PSP bootloader for
the anti-rollback feature which makes sure that the SPL file version
isn't lower than what is in the SPL fuses. For this the SPL file needs
to be present in the PSP directory table. The SPL version check happens
way before we're running code on the x86 cores. The SPL fusing PSP
command that can be sent by coreboot will tell the PSP to update the SPL
fuses so that the fused minimal SPL version will be updated to the
current SPL version.
Since the former HAVE_SPL_FILE option now only controls if the SPL
fusing command will be sent to the PSP mailbox, rename it to
PERFORM_SPL_FUSING to clarify what this will do and update the help text
correctly describe what this does.
TEST=With INCLUDE_CONFIG_FILE set to n, timeless builds for both Birman
with Phoenix APU and Skyrim result in identical binaries.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6cec1f1b285fe48e81a961414fbc9978fa1003cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78178
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since all non-CAR AMD SoCs have the same mp_init_cpus implementation,
factor it out and move it to a common location.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibf4fa667106769989c916d941addb1cba38b7f13
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Add a separate Kconfig option for adding np_region.c to the build. Only
the code for Picasso, Cezanne, Mendocino, Phoenix and Glinda call
data_fabric_set_mmio_np which is implemented in that file, so only
select the new SOC_AMD_COMMON_BLOCK_DATA_FABRIC_NP_REGION Kconfig option
for those.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic49ce039462b52e2c593c7d2fef43efc50901905
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77987
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The EFS data structure diagrams in the Makefiles of Picasso and newer
SoCs were wrong, since the BIOS directory table pointer is in a
different location than shown in the diagram. Since the diagram also
wasn't that easy to understand and amdfwtool does all of that handling,
drop the wrong diagram from the Makefiles.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5f86fea29f956ff10746d35dbe967a4a89e11cca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
|
|
Instead of reporting all I2C controllers in the system as enabled in the
corresponding ACPI device's _STA method, report the I2C devices that are
disabled in the devicetree as disabled in the corresponding _STA method
too. This is done by returning the contents of the STAT variable inside
each device's scope in the DSDT that have a default value of 0 (device
not present/disabled). For all enabled and hidden I2C devices
i2c_acpi_fill_ssdt gets called which then writes 0xf (device enabled and
visible) or 0xb (device enabled, but hidden) to the STAT name inside the
same scope, but in the SSDT. This object in the SSDT will then override
the default in the DSDT resulting in the _STA method returning the
correct status of each device. The code was inspired by
commit 7cf9c7451808 ("soc/amd/*: Fix UART ACPI device status").
TEST=On Mandolin all I2C controllers are disabled and with this patch
none shows up in the Windows 10 device manager. When enabling an I2C
controller in the devicetree for testing, it shows up again in the
Windows device manager.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4cd9f447ded3a7f0b092218410c89767ec517417
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
|
|
It is based on work by Arthur Heymans, 69852.
Get rid of the confusing "position index" and use the relative flash
offset as the Kconfig setting instead.
TEST=binary identical on amd/birman amd/majolica amd/gardenia
amd/mayan amd/bilby amd/mandolin amd/chausie amd/pademelon
pcengines/apu2
google/skyrim google/guybrush google/zork google/kahlee google/myst
(The test should be done with INCLUDE_CONFIG_FILE=n)
Change-Id: I26bde0b7c70efe9f5762109f431329ea7f95b7f2
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The psp_transfer.h file was the same under all SoCs, and is really
tied to the file common/vboot/transfer.c, not the SOC.
This patch makes an include directory under vboot to put the header into
and sets it to be included for all SoCs using SOC_AMD_COMMON. This makes
the header file available to all platforms, so that new chips that don't
use the psp_verstage don't have to make a psp_transfer.h file just to
satisfy the compiler.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5b9f2adee3a1d4d8d32813ec0a850344b7d717b2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77303
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Implement get_iohc_fabric_id for each SoC that translates the coreboot
domain number to the fabric ID of the corresponding PCI root. This
allows the primary domain to have the number 0 even though the
destination data fabric ID will be non-zero. Keeping the primary domain
number 0 allows to use config_of_soc() which can be resolved at link
time and not need to dynamically find the SoC device to get the config.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6538a777619eed974b449fc70d3fe3084ba447dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77168
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
The data fabric also controls which PCI bus numbers get decoded to the
PCI root. In order for the resource allocator to know how the hardware
is configured, read the corresponding data fabric registers to get the
information that then gets passed to the allocator.
Picasso, Cezanne, Mendocino and Rembrandt only support one PCI segment
with 256 buses while the Phoenix and Glinda data fabric hardware has
support for more PCI segments. Due to this change, the register layout
is different and incompatible between those two, so introduce the
SOC_AMD_COMMON_BLOCK_DATA_FABRIC_MULTI_PCI_SEGMENT Kconfig option for a
SoC to specify which implementation is needed. At the moment, coreboot
doesn't have support for multiple PCI segments and the code doesn't
support PCI segments other than segment 0.
On Picasso the PCI bus number limit read back from the data fabric
register is 255 even though CONFIG_ECAM_MMCONF_BUS_NUMBER is set to 64,
so also make sure that the bus and limit returned by
data_fabric_get_pci_bus_numbers is within the expected limits.
TEST=PCI bus allocation still works on Mandolin (Picasso) and Birman
(Phoenix). Picasso has 64 PCI buses. coreboot puts this info into the
resource producer in _SB\PCI0\_CRS which the Linux kernel reads:
* coreboot: PCI0 _CRS: adding busses [0-3f]
* Linux: pci_bus 0000:00: root bus resource [bus 00-3f]
This matches the information in the ACPI MCFG table.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ide5fa9b3e95cfd59232048910cc8feacb6dbdb94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77080
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I8fa26e7a398eee855c31a76f0f89b4111368c2a6
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
PPRs #57019 Rev 3.05 and #57396 Rev 3.06 were used as a reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id0fe478a710ecc1f2c8b36347aaf2d1634ebba9a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77078
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Prior to commit d1c0f958d198 ("acpi: Call acpi_fill_ssdt() only for
enabled devices"), uart_inject_ssdt() was used to set the ACPI status
(_STA) for both enabled and disabled devices. The aforementioned commit
limited it to being called only on enabled devices, which left disabled
devices without any _STA method at all -- which the OS assumes means
that the device is present and enabled.
To fix this, create the _STA method in the UART asl code for each port,
and set the return value to a name variable (STAT) which defaults to
0 (not present/disabled). Then, have uart_inject_ssdt() set STAT to
present and enabled (0xF) for UARTs actually present on the board.
TEST=build/boot google/skyrim (frostflow), dump ACPI tables, and verify
that _STA returns 0xF only for UARTs enabled in devicetree.
Change-Id: Id89e74c3ea7f53280935898ee35311b7cf3b152a
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77092
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
PPRs #57019 Rev 3.05 and #57396 Rev 3.06 were used as a reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I769dc317115981391cf0f4e0b743c600407a6eb6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76958
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Rename the fabric_id struct field in the df_mmio_control union to
dst_fabric_id to both better match the register definitions and also be
a bit clearer about what this is doing. Also use tabs for indentation in
the struct inside the df_mmio_control union.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0a17d82a5d7b66a8f84854f21fbbb319da81ac43
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76932
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>
|
|
Order the data fabric register definitions by function number and
register offset.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia3066ad0f564520cb322a3e41a413eb3bf51260d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76923
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Now that the data fabric PCI device functions are included in the
register definitions, the remaining data fabric device function numbers
can be dropped from the define names.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia0355838ac1d513ba562fd6fb4672342dd383498
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76888
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>
|
|
To have both the PCI function number and the register offset into the
config space of that function of the data fabric device in the data
fabric register definitions, introduce and use the DF_REG_ID, DF_REG_FN
and DF_REG_REG macros. The DF_REG_ID macro is used for register
definitions where both the function number and the register offset are
specified, and the DF_REG_FN and DF_REG_REG macros are used to extract
the function number and the register offset from the register defines.
This will allow having one define for accessing an indexed group of
registers that are on different functions of the data fabric device.
TEST=MMIO resources read from the data fabric's MMIO decode registers
don't change on Mandolin and the ACPI CRAT table is also identical.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I63a284b26081c170a217b082b100c482f6158e7e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76886
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
header="src/soc/amd/common/block/include/amdblocks/post_codes.h \
src/include/cpu/intel/post_codes.h \
src/soc/intel/common/block/include/intelblocks/post_codes.h"
array=`grep -r "#define POST_" $header | \
tr '\t' ' ' | cut -d ":" -f 2 | cut -d " " -f 2`
for str in $array; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r $str src | cut -d ':' -f 1 | \
xargs sed -i'' -e "s/$str/POSTCODE_$splitstr/g"
done
Change-Id: Id2ca654126fc5b96e6b40d222bb636bbf39ab7ad
Signed-off-by: Yuchen He <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76044
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Include multiple hash tables into relevant CBFS.
BUG=b:277292697
TEST=Ensure that all multiple hash tables are part of Myst BIOS image
with PSP verstage enabled.
Change-Id: I1601f4a01db5b2bbf8b5636ef9e69e41c1d9a980
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76589
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
On mainboards using Phoenix SoC with PSP verstage enabled, to
accommodate growing number of PSP binaries, multiple smaller hash tables
are introduced. Also some hash tables are in V2 format identifying the
concerned PSP binaries using UUID. Add SVC calls to support multiple
hash tables with different versions.
BUG=b:277292697
TEST=Build and boot to OS in Myst with PSP verstage enabled. Ensure that
all the hash tables are injected successfully. Ensure that PSP validated
all the signed PSP binaries using the injected hash tables successfully.
Change-Id: I64e1b1af55cb95067403e89da4fb31bec704cd4f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76588
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Factor out the common FSP-specific code to report the usable and
reserved memory resources read from the HOBs that FSP has put into
memory. This both reduces code duplication and also moves FSP-specific
code out of the SoC code into the FSP-specific common AMD SoC code
folder.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib373c52030209235559c9cd383f48ee1b3f8f79b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76759
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
On the mobile SoCs, SMN_IOHC_MISC_BASE_13B1 is the only IOHC misc base
address, but on for example Genoa it's the address of the IOHC misc base
of the second IOHC. Due to it not being the first one on Genoa, use 13B1
as part of the name instead of using an index of 0 which would look odd
in the Genoa case.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1db28ec03a3ba1c2040d8a1500ae17aa9705f6e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76756
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>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Since the per PCI root IOAPIC is now reported as domain MMIO resource
and the IVRS code now again probes for the IOAPIC resource on the domain
device, the IOAPIC resource doesn't need to be reported as resource of
the northbridge PCI device any more.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8604bd321ec4239076b1be99dca095e47f8b75a7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76600
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Add the SoC-specific non-PCI MMIO register list. PPR #57019 Rev 3.05 was
used as a reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6f57df6ca09f1583409f6c4e68177b05b9f31def
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76597
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Do not add type 0x63 entry to amdfw.rom when APOB_NV cache is disabled.
BUG=b:290763369
TEST=boot birman multiple times with/without APOB_NV cache enabled
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Iefe6f56d7dbedd289680f25a5f372eaa12e967b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76568
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Disable the APOB cache for only Myst, and re-enable APOB for other
Phoenix SOC mainboards.
BUG=b:290763369
TEST=verify APOB cache is disabled
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ie611e0b84611b2f50c989c75612fc2186b2dbfdf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76567
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ic030f91bbfd7226d7adbbe83a2f9e7930af46207
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: If2048c9cade731b2e4464d0670e0578f5f4bcea0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The enable_acpimmio_decode_pm04 function uses the IO port based indirect
access of the PM register space. The PM_INDEX and PM_DATA registers
don't exist any more on Phoenix, so the code shouldn't access those.
Since the PM_04_ACPIMMIO_DECODE_EN bit in the
ACPIMMIO_DECODE_REGISTER_04 register is 1 after reset, the ACPIMMIO
space is still accessible.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia41f239b023edc094f5cbae63ed7c079649c74da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76437
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There is a data abort in ABL when the memory training data is used from
APOB Cache. Disable APOB Cache until the cause is identified. The
downside of this change is that the memory training happens in every
boot cycle.
BUG=b:290763369
TEST=Build BIOS image and boot to OS in Myst. Trigger a reboot from AP
console and ensure that the system boots to OS.
Change-Id: I20f4f40cdaac68bca6e121e3a238d13fe80d0d3c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Commit cde4f3b2790d ("acpi/gnvs.c: Drop unused pointer to the cbmem
console") removed writing the coreboot memory console pointer to the
GNVS and kept the CBMC field as reserved. Since those fields aren't
needed any more and there are no dependencies on the absolute position
of the different fields in GNVS as long as both GNVS definitions on the
C and the ASL side match, remove the deprecated and unused CBMC field
from the GNVS structs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iadfaf5a4ec1401b027dbfb6a7c6ce74a1dcecdfa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76351
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
Use the _tohex function to convert values to hex instead of 'shell
printf'
TEST=timeless builds identical for grunt,dalboz,guybrush,chausie,birman
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ic7f7d1b764479088cc0980b208d8d603bc712832
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76314
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Change-Id: I7e2018dbccead15fcd84e34df8207120d3a0c57c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64303
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
|
|
Rather than repeat the same line multiple times, save it in a variable
once and use that variable in the rest of the file.
TEST=timeless birman build identical
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I4eb262adb3bbda04add79b2e2b8bee9a609a1e5b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76197
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Pass the APOB NV address as a flash offset instead of x86 address.
TEST=boot birman and verify APOB_NV is working
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I0f710f12cc5d933a75840dbce1c4bad0c2ea04cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76162
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Phoenix is an x86 soc that supports sha256 instructions.
TEST=boot birman to chromeos
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Id228399ba02708b97110d524ce12c2626588762d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76166
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ifd2b53ff24776238190eb946db7b12827fcfc804
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76165
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Replace:
$(shell awk '$$2 == "xyz" {print $$3}' $(obj)/fmap_config.h)
with:
$(call get_fmap_value,xyz)
to improve code readability/maintainability.
Change-Id: If6859108c7d5611a63fc38909dc75195bfb1d59a
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76168
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
BUG=b:288520486
TEST=In kernel, dump `dmidecode -t 17`.
Change-Id: I1a8aae12ec449fe921814a6e363306fced969367
Signed-off-by: Konrad Adamczyk <konrada@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76109
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
sed -i'' '30,${s/#define POST/#define POSTCODE/g;}' \
src/commonlib/include/commonlib/console/post_codes.h;
myArray=`grep -e "^#define POSTCODE_" \
src/commonlib/include/commonlib/console/post_codes.h | \
grep -v "POST_CODES_H" | tr '\t' ' ' | cut -d ' ' -f 2`;
for str in ${myArray[@]}; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r POST_$splitstr src | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
grep -r "POST_$splitstr" util/cbfstool | \
cut -d ':' -f 1 | xargs sed -i'' -e "s/POST_$splitstr/$str/g";
done
Change-Id: I25db79fa15f032c08678f66d86c10c928b7de9b8
Signed-off-by: lilacious <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I296697d579b9ad8e35b22ada939a74a5ef6d6f61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75828
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This makes sure that the resource allocator won't use this address range
for anything else. In the systems I looked at, this was between the end
of the above 4GB memory and the beginning of the above 4GB PCI BAR MMIO
region, but better reserve it here so nothing else will get allocated
there if this expectation isn't met.
TEST=Reserved region is printed in the console logs:
update_constraints: PCI: 00:00.0 09 base fd00000000 limit fdffffffff mem (fixed)
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5a8150873cb019ca1d903ed269e18d6f9fabb871
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Update all the required sources to lay the ground work to enable PSP
verstage.
BUG=b:284984667
TEST=Build Myst BIOS image with PSP verstage enabled.
Change-Id: I6fbb1f835ac2ad6ff47f843321e1bd380af7ce33
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75584
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
By adding all DXIO IOAPIC with the same resource index, the IVRS code
can always pick that resource which simplifies the code.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I10345e2337dcb709c2c1a8e57a1b7dd9c04adb9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75710
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
|
|
The file VGA_BIOS_FILE points to is right now the Mendocino VBIOS. Since
the default value probably shouldn't point to a location in site-local,
drop this for now, but leave a TODO to put that back once the correct
VBIOS files are available in 3rdparty/amd_blobs.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifbc6cbe1e371d8d247f86555a5361ed237897dea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Hook up xhci ops for Phoenix xHCI device. Benefit is we don't have to
bother by adding xhci DID.
BUG=b:285981912
TEST=check coreboot log shows below.
[INFO ] \_SB.PCI0.GP41.XHC0.RHUB.SS01: USB3 Type-A Port A0 (MLB)
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Ib59874948725966b04b54def3f6de463afeda709
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75659
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Replace the magic constants by using defines.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I16179a37b6ee19bc3b4862b7dcb3bbc4caf63f2e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75668
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Use the ROOT_BRIDGE macro in soc.asl to replace the pci0.asl file. The
soc/amd/common/acpi/lpc.asl file which was included in the now removed
pci0.asl file now gets included in the correct scope in the soc.asl
file.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If293188fc8d0ff41b47ab84c9655333e9ebe58e8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75594
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Use the new common AMD code that gets the usable non-fixed MMIO windows
from the data fabric MMIO decode registers and generate the PCI0 _CRS
ACPI code based on those regions. For a more detailed description see
the corresponding patch that changes the Picasso code to use this new
code. In contrast to the Picasso code, this change will drop the
unneeded _STA method inside the PCI0 scope which wasn't present in
Picasso's ACPI code before it got replaced by the SSDT that gets
generated by amd_pci_domain_fill_ssdt.
BUG=b:283495475
TEST=Myst still boots and both the coreboot console and the kernel show
the expected PCI MMIO ranges being used.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I425876c4ef470574e00e123d36101641240c98cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
This makes sure that the resource allocator won't use those ports for
anything else.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie42260902ee2b383dd5867ac813cae029f706f2d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75556
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Follow 57263_FP8_MBDG_rev_0_92 Table.57 to update the alias. We
can match the schematic for now.
BUG=b:285793461
TEST=USB still works.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Id1058279fe5b0e3131608a0b9bbd708dbbde7e87
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75615
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Move microcode load/unload to pre_mp_init and post_mp_init callbacks.
It allows to make sure that ucode is freed only if all APs updated
microcode.
BUG=b:278264488
TEST=Build and run with additional debug prints added
to confirm that data are correctly unmapped
Change-Id: I200d24df6157cc6d06bade34809faefea9f0090a
Signed-off-by: Grzegorz Bernacki <bernacki@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
The phoenix SoC does not support multiple EFS locations. Set the default
to the only valid value and prevent mainboard overrides by making the
option non-user-configurable.
TEST=build birman-phoenix
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I0f720dbadf2d28a3c39daa4bd653a407be4893d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74249
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
cbfs_boot_map_optionrom will generate lower case hex digits for the
filename to look for in CBFS, so make sure that the file name will use
lower case hex digits and no upper case hex digits.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1d4daa04120de0f2c853a44691b7e2c52eb2af20
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75483
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Set the default soft fuse bits to the recommended values
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I2354aefe90a08eaef95a68926806d11a9118c3de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Don't set bit 2 of the return value of the _STA method in order for
Windows not to show a warning about an unknown device in the device
manager for this device.
TEST=The unknown device with device instance path ACPI\AMD0040\3
disappeared from the device manager in Windows 10 build 19045 on a
Mandolin board with a Picasso APU.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If005f06843956004c281fd70cf364171148cb9ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68962
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Commit 396fb3db74db ("soc/amd/*/acpi/mmio.asl,sb_fch.asl: hide AAHB
device") didn't only change the visibility of the device, but also
changed the _STA method to a name. While this worked, the specification
says that _STA is supposed to be a method, so change it back to being a
method.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id0932b2875aaf563a4dbd860bdd11a04272e3780
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75169
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Beware that there's no XHCI2 controller and the USB4 controller device
pointers were added right after the xhci_0 and xhci_1 controller device
pointers.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I14725d4b546ffcca42e21bbe7756babaaff8fea3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74658
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Return 0xf from PCI0 _STA method so that bit 2 is set which indicates
that the device should be shown in the user interface. This ports commit
c259d7192806 ("soc/amd/stoney/acpi: Unhide PCI0 root device from OS")
forward from Stoneyridge to the newer AMD SoCs.
TEST=On Mandolin the PCI Express Root Complex now shows up in the device
manager on Windows 10 and when switching the view to 'devices by
connection', all PCI(e) devices are shown below it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4155556dc5df8f163fe06aa6719fadbb2684cc19
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74949
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Iadc32f4dbf8bd48d8666a213d7b5f3ba42175a90
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
I forgot to remove these in commit 0fe36db154eb ("ACPI: Make FADT
entries for SMI architectural").
Change-Id: Ib1bc1dad6053ddb0454d4510917fd2bcf0901f35
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74811
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
For AMD, replace name RTC_ALT_CENTURY with RTC_CLK_ALTCENTURY
that points to same offset. Since the century field inside
RTC falls within the NVRAM space, and could interfere with
OPTION_TABLE, it is now guarded with config USE_PC_CMOS_ALTCENTURY.
There were no reference for the use of offset 0x48 for century.
Change-Id: I965a83dc8daaa02ad0935bdde5ca50110adb014a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74601
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
On boards with RECOVERY_MRC_CACHE FMAP section, populate type 0x63 BIOS
directory entry in RO with that section. If the RECOVERY_MRC_CACHE
section is not present, then fall back to RW_MRC_CACHE.
BUG=b:270569389
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Ic5ac87685eaa5fec717e3efa4df7af511b4ce8aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73257
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
|
Change-Id: I80aa71b813ab8e50801a66556d45ff66804ad349
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74600
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
It is unused. The use of field irq is problematic as it should
appear relative to IOAPIC GSI bases in the devicetree.
Change-Id: I460fd5fde3a7fba5518ccfc153a266d097a95a39
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Fix copy-paste comment on closing endif
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I9671a9228c304988eb3903391f74a21d80d0a8bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Change IRQ #0 to GSI #2 override to positive edge trigger from
the bus ISA default (positive edge).
Change-Id: I2de941071fca6f7208646a065a271fbf47ac2696
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74354
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Platform needs to implement this to provide information about SCI IRQ
pin and polarity, to be used for filling in ACPI FADT and MADT entries.
Change-Id: Icea7e9ca4abf3997c01617d2f78f25036d85a52f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Phoenix doesn't have an eMMC controller, so remove the remaining eMMC-
related defines.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I412c968479d23deb7f2e060b26b4a56ec9c764f2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I95916e409b3fbd4941a861054733a34100244da9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
Since it's an internal bus, it's PCIE_ABC_C_DEVFN and not
PCIE_GPP_C_DEVFN. This also makes it consistent with the rest of the
internal PCI buses.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ica8b666161c3cd3b0b4a29f8a4b0aff473b4d833
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74656
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
In the PPRs #57019 Rev 3.03 and #57396 Rev 3.04, SMITYPE_XHC3_PME,
SMITYPE_XHC4_PME and SMITYPE_CUR_TEMP_STATUS_5 are defined, so add those
defines. When doing the initial update for Phoenix, at least XHC3 and
XHC4 PME events were missing from the PPR. Those two are the PME events
of the two USB4 controllers. SMITYPE_XHC2_PME doesn't exist on this SoC.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic6fff9175b73cc9d0fd324d4a568a5761b92d078
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74655
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
|
|
When one of the General-Purpose PCIe bridges is not used, it doesn't
show up on the PCI bus at all, so coreboot notes it as an issue in the
devicetree. This happens even if the device is marked as off.
To solve this, we're marking the GPP bridge devices in devicetree as
hidden, so they'll only show up in devicetree if they're actually used
on a mainboard.
BUG=b:277997811
TEST=Build
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7b7577baa2dbb0ea7ebbcdb1a8ae81770e61d76f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74527
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Set up SoC-specific XHCI defines and enable SOC_AMD_COMMON_BLOCK_XHCI
to allow for XHCI events to be logged.
BUG=b:277273428
TEST=builds
Change-Id: I3ca4f84fb0f1fef8441ab6ef7b6f6348c52b2922
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74280
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
After the obsoletion of Processor() it is necessary to provide
_CST package to define P_LVLx IO addresses for C2/C3 transitions.
The latency values from _CST will always replace those in FADT.
Change-Id: I3230be719659fe9cdf9ed6ae73bc91b05093ab97
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Iabba97e003d1a5140c98e3fc5a3496f66f8795c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74528
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Parts of this file were still a copy of the file from the Mendocino SoC,
so update the file to match the PPR #57019 Rev 3.03 and the chipset
devicetree of the Phoenix SoC. Phoenix has 4 GFX/GPP PCIe bridges/ports,
the numbering scheme of the GPP PCIe bridges/ports was changed so that
the numbers match the device and function numbers, and there are new
device functions for the IPU and the USB4 controller and router devices.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie9429c03839bb0199a04cd6cafe9a955ebdacc91
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74565
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In both PPR #57019 Rev 3.03 and PPR #57396 Rev 3.04, the i2s_ac97
function on bus C isn't mentioned any more and the microarchitecture
specification document for this SoC also doesn't mention it, so remove
it from the devicetree.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibd115953bdd60e1dfcc79797b0c2158e5d861636
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74564
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Boards with SOC_INTEL_COMMON_BLOCK_ACPI_CPU_HYBRID have
special handling for the time being.
Change of aopen/dxplplusu is coupled with sb/intel/i82801dx.
Change of emulation/qemu-i440fx is coupled with intel/i82371eb.
For asus/p2b, this adds MADT LAPIC entries, even though platform
has ACPI_NO_MADT selected. Even previously ACPI_NO_MADT creates
the MADT, including an entry for LAPIC address.
Change-Id: I1f8d7ee9891553742d73a92b55a87c04fa95a132
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74316
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
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>
|
|
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 and use this
bitfield struct in get_pstate_core_freq and get_pstate_core_power. The
signature of those two function will be changed in a follow-up commit.
PPR #57019 Rev 1.65 and PPR #57396 Rev 1.54 were used as a reference as
well as the reference code. This patch also adds and uses the cpu_vid_8
bit which is the 9th bit of the voltage ID specified in the SVI3 spec.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia024d32ae75cf2ffbc2a2e86a8b3af3dc6cbad61
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73923
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>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.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>
|