amdfwtool always assumes that the PSP BIOS binary (type 0x62 BIOS
directory entry) is always compressed. On boards using vboot, sometimes
PSP BIOS binary is uncompressed - specifically when CBFS verification is
enabled and verified boot starts in bootblock. Add an option to indicate
PSP BIOS binary is uncompressed.
BUG=b:261792282
TEST=Build Skyrim BIOS with x86 verstage and CBFS Verification enabled.
Boot to OS.
Change-Id: I4d56c0ba451b194043ebb5cdb0f2b27482beef1f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
For Intel SPR-SP, the SAD device is hidden, so pcidev_path_on_bus()
returns NULL. Therefore use pci_s_write_config32() instead.
Move lock_pam0123() from finalize.c to util.c, to be together with
unlock_pam_regions().
Change-Id: Ib08d423d8c4d482612077b66dab3878018da8f2b
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Intel SPR-SP has its specific way to get the bus number of ubox.
Move the current implementations to CPX-SP and SKX-SP folders.
Change-Id: I2b69be74d140115f9f78bc991fb690e3c90c88db
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This reverts commit b42ca4d0b2.
Reason for revert: The mirror flag "0x01" is mirror once, which
relies on the EC remembering that it's been mirrored. However, the
EC forgets this if it's been without power for 20 minutes or so.
Even if power is connected then, it'll instantly try to mirror and
it can't charge whilst doing it. It can either result in
incomplete EC firmware, or a loop where it's constantly trying to
mirror.
Change-Id: I79da9143cc63459e7e29431eff2cb14200424b37
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72678
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reverts commit 35354583cd.
Reason for revert: The mirror flag "0x01" is mirror once, which
relies on the EC remembering that it's been mirrored. However, the
EC forgets this if it's been without power for 20 minutes or so.
Even if power is connected then, it'll instantly try to mirror and
it can't charge whilst doing it. It can either result in
incomplete EC firmware, or a loop where it's constantly trying to
mirror.
Change-Id: Ie82cbafd4bea2416526e2847738802a05ed45582
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Only call cbfs_boot_map_optionrom/cbfs_boot_map_optionrom_revision once
and pass the already remapped PCI ID to it. This avoids the spurious
warning that the CBFS file wasn't found from the first
cbfs_boot_map_optionrom call in cases where the PCI ID needs to be
remapped to get the right ID for which a file in CBFS exists.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If7da78c69dd702280a78996a5823972516e0319b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73612
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPE number used for XHCI has now been defined in AMD's common code
in CB:67936. Change over existing code to use this new definition.
BRANCH=guybrush
BUG=b:186792595
TEST=Ran on nipperkin device and verified that XHCI events string use
GPE 31.
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I9c2a44f7d2eb47422ae8c585e5e01ea0b420d461
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69917
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPE number used for XHCI has now been defined in AMD's common code
in CB:67936. Change over existing code to use this new definition.
BUG=b:186792595
TEST=Ran on skyrim device and verified XHCI GPE setting.
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I3bfc2256ea2ca851afe88f2cdb419f39eee76fdd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69916
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
AMD SoCs currently only log the GPE# when an XHCI controller wakes the
system. Add code to log XHCI wake events to the elog.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Change-Id: Ic0489e1df55c4e63cb8a306099e3f31c82eebd58
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67936
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
- Remove functions that are only called in one place.
- Add warning if user doesn't supply a platform, since that can lead to
dumps/layouts that do not include all IFD regions without the user
even reliazing it.
- Inform the User if IFD or Flashmap is not found.
- Inform the User if there is not a single match between FMAP and IFD
region
- Avoid printing usage if not specifically asked by the user.
It tends to obfuscate the original error message.
- Keep indentation consistent throughout the file.
- Remove typedefs (coreboot coding style)
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I7bbce63ecb2e920530394766f58b5ea6f72852e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73448
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Winterhold boards populate either NVMe or eMMC, but not both.
This means that there is always one link that is unpopulated. The PCIe
configuration code takes longer to verify that a link is unpopulated
than to just train the link, so this slows down the boot by roughly
80ms vs the case when the device is present. Not training the device
at all lowers boot time by another 20ms, for a total of 100ms saved.
Looking at the NVMe CLKREQ signal before initializing the ports allows
us to identify which device is populated and only initialize that
device.
BUG=b:271569628
TEST=Boot Whiterun and eMMC or NVMe correctly work, boot time is lower.
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0b87f5e968cd1c87e62a1c0fbdee1fc0723f655d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73441
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
These ports are not hot pluggable, so drop the parameter, which
will result it in being set to zero / not enabled.
BUG=none
TEST=build boot skyrim, verify all PCIe devices functional.
BRANCH=skyrim
Change-Id: Iaa55cc765e8f073b31f25771633789ac13e2fffa
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73512
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Enable both L1.1 and L1.2 substates for the WiFi, SD card reader,
and SSD (both NVMe and eMMC). If a given device does not support
a particular substate, then it will not be enabled during PCIe
enumeration by coreboot.
BUG=b:270690572
TEST=build/boot multiple skyrim/whiterun/frostflow SKUs with different
storage configs, verify WiFi/SD card/SSD all functional and have L1
substates enabled insofar as they are supported by the device.
BRANCH=skyrim
Change-Id: Ib84df8b9d97282ae696414e52c4a65cfb0a81194
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73438
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
This allows variants to override the skyrim port descriptors.
BUG=None
TEST=Tested with following patches
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8cff44f5b39d130a7191a69970cae8a88bb5d475
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
This fixes the case where a Broadwell CPU is combined with an AMD or
NVIDIA GPU would result in using the Broadwell GPU VBIOS file from CBFS
for the discrete GPU too. A further improvement would be to use a list
of the Intel iGPU PCI IDs like it is done in the Skylake code.
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3eb50cb9a0539255d50e5cd8163f10c3a062cc4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73611
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Type 0x5d (MPIO Firmware) was mistakenly placed to PSP Level 1 directory.
It should be in Level 2 PSP directory instead.
Change-Id: Ic5ea00859f1055e0c91600c5f941c5d3acca36e2
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73556
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bao Zheng <fishbaozi@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
This patch updates PMC API name from `pmc_send_pci_enum_done` to
`pmc_send_bios_reset_pci_enum_done` to inform PMC IPC about BIOS done
is also set along with PMC enumeration being done.
BUG=b:270942083
TEST=Able to build and boot google/rex.
Change-Id: I1cf8cb1ecadeb68c109be6b0e751a3f2c448ae4f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Add new memory parts in memory_parts_used.txt and generate SPD id for
these parts:
Hynix H54G46CYRBX267
Samsung K4U6E3S4AB-MGCL
BUG=b:272173189
TEST=run part_id_gen to generate SPD id
Change-Id: I141bda6eda3f658ca608c86ad0b320d018598514
Signed-off-by: Robert Chen <robert.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73554
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the inst field when adding entries to the psp tables. Otherwise,
entries that differ by the inst field will appear as duplicates with an
inst of 0.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I4a84a0730976f4c65902b5c24ed13e21e95b03bb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73522
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Decrease Touch i2c delay during power-on sequence from 300 ms to
150 ms to make S0ix resume time meet requirement.
BUG=b:264199989
TEST=Run the following test from chroot.
test_that -b {BOARD_NAME} {device IP} f:.*power_UiResume/control
Check seconds_system_resume value less than 500 msec
Signed-off-by: Frank Chu <Frank_Chu@pegatron.corp-partner.google.com>
Change-Id: Ib81a9c1a90589b8b08e6ce6471db2abef96047ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73532
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Frank Chu <frank_chu@pegatron.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move the onboard Realtek NIC definition to a child device of
PCIe port 6. This makes sure it is advertised as "onboard", such that
it appears as eno0 on systemd/udev-based systems.
This commit is very similar to
https://review.coreboot.org/c/coreboot/+/73516
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Change-Id: I0550ee9faddd65011ad914aef413a6d1b316c5ad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73519
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The LOGICAL_CPUS Kconfig option is always true and also not user-
configurable, so it can be dropped.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ie4866de003058ec0f99495b405e26dfd7ba1fa28
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Enable whiterun/winterhold platforms to send the fuse SPL (security
patch level) command to the PSP.
BUG=b:254568112
TEST=On a platform that supports SPL fusing, a message indicating
that fusing was requested will appear in the coreboot console log,
followed by a puff of smoke when the fuse is set and the message
"OK" again on the debug console. (Kidding about the smoke.)
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I45578597234ba672c89ac421b4626088faca27d5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72914
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
This adds checks for three more error bits before requesting that the
SPL fuses are updated.
- While I'm here, I'm adding the include of types.h which was previously
done through other include files, but should be done independently.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I87a7d40850c4e9ddbb2d1913c1588a919fdb29d2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Use the presence of an SPL (Software Patch Level) file to trigger the
function that reads and writes the SPL fuses. The current Kconfig
option will be used to decide to write the fuses. This allows us to
see the state of the SPL update bit which determines whether or not
SPL fusing is allowed and needed before enabling the fusing.
- Refactor a bit to prepare for following changes.
- Update phrasing
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I7bd2798b984673a4bd3c72f3cab52f1c9a786c67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Now that the code using the ACPI_SSDT_PSD_INDEPENDENT Kconfig symbol is
moved to soc/amd/common/block/acpi/cpu_power_state.c, also move the
Kconfig symbol to the Kconfig file in this directory.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ide18111df38d4e9c81f7d183f49107f382385d85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73550
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce the get_cstate_io_base helper function that write_cstate_entry
can call directly to get the C state control IO base address instead of
having get_cstate_info pass this Io address to each write_cstate_entry
call.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Suggested-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I4cc80ded0a2fbc2dee9ca819e86284d9ffd58685
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
The bit position of the P state enable bit in the 8 P state MSRs is
identical for all AMD chips including the family 16h model 30h APU that
lives outside of soc/amd. The other bits in those 8 MSRs are more or
less family- and model-specific.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia69c33e28e2a91ff9a9bfe95859c1fd454921b77
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Touchscreen signals were renamed for Rex schematics dated 21st Dec'22.
This CL fixes the comments for those signals.
BUG=b:263411413
TEST=None required (changed comments only)
Signed-off-by: Eran Mitrani <mitrani@google.com>
Change-Id: Ic40ef943d199d9f4a2bec9c0e6d4820224ef6adc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Split the big PSP FW data into two parts, head and body. The head
needs to be located at original specific location. The body address is
more flexible. So the big body will not cover other needed FWs like
EC.
Give the body a specific named AMDFWBODY, which should be defined in
flashmap.
This is one of series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: Ia8b318f71632a2c9b97ce67486374dc24d23e63e
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72703
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Instead of hoping that the default the C state control IO address in
binaryPI won't interfere with any other IO space usage in coreboot,
assign the ACPI_CSTATE_CONTROL value to the CStateIoBaseAddress platform
config structure element to make sure that binaryPI will use a known
address for the IO port based C state control. binaryPI will write this
address to the MSR_CSTATE_ADDRESS and will then also use these IO ports
in the _CST packages in the PSTATE SSDT, so changing this won't cause
a mismatch between those two.
The default CStateIoBaseAddress in the FT4 Stoneyridge binaryPI used on
Careena is 0x1770, so this didn't collide with any other IO space
registers, but it's still much better to tell binaryPI which exact IO
addresses to use.
TEST=On Careena MSR_CSTATE_ADDRESS now contains the ACPI_CSTATE_CONTROL
IO base address 0x420 and the PSTATE SSDT has the IO address 0x421 in
the _CST package entry for the second C state which are both the
expected values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I207202802427d4bf00f283bcbd83a174ab0a2846
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
It is similar to PSP combo.
Change-Id: If0523a4a0e1f31969e4bbaa6062dcc0f2d6da420
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66856
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
If combo is used, fill the EFS header with address of COMBO header.
If not, fill with address of PSP header.
The old code fills with PSP headers all the time.
Change-Id: I0057165aea553d9dc8e4e719e2804557229a0002
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66855
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There will be a loop to set up the combo layout. The combo header only
needs to be created once. This change is actually to move the creation
of combo header outside of the loop.
Change-Id: If6ba3d10dfc598133b9adbbb2b6658f356455608
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66854
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It is easier to understand what these statements are about.
Change-Id: Ib02c68c9f2ea84020b12682c41fb1a6f8f93d725
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66852
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Realtek RTL8111E NIC is currently not defined as a child device,
resulting in the on_board flag not being set to 1. This means that
Linux / udev will call the device enp3s0 rather than eno0, as is
appropriate for on-board ethernet devices.
Additionally, the comment in devicetree.cb stating that PCIe port 6
is the ethernet controller is incorrect. It's actually port 4.
This patch moves the comment to the right port, and defines the NIC
as a child device of said port, so that it's properly defined as an
on-board device.
Link: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/TFWNW3Y7IWTFD4KIBVNQYW3DODJ6SSC2/
Change-Id: Ie1e3a757a6bd6c7dd1702ced177d13711978dcc4
Signed-off-by: Kevin Keijzer <kevin@quietlife.nl>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73516
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Fabian Groffen <grobian@gentoo.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5157fc031c5b19d8633132222520f582620208c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4f5743dd2e4dfdfeb3ffb2e9b964bdc75c84e6c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3669c66094f0137081888ebdd1af838e2ea269b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73501
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id97fcb74ff3d48994a3181d9c31cbbeb5a76c60a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6bd8879ce5968b24893b43041be98db55a4c3c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Instead of using a magic constant in the bit_offset field of the C state
resource for the C1 state that's entered via the MWAIT instruction, use
the existing ACPI_FFIXEDHW_CLASS_MWAIT define. This value is checked by
acpi_processor_ffh_cstate_probe in the Linux kernel.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9edc681efab15b5ceba91c8105f7dc6d687d8be8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce the get_cstate_info helper function that populates the caller-
provided cstate_values array with the data returned by the SoC-specific
get_cstate_config_data function. From the array get_cstate_config_data
returns, only the ctype, latency and power fields are used, so the rest
can be left uninitialized. Those 3 fields are compile-time constants.
For each entry, write_cstate_entry will generate the corresponding
resource information from the given data. In the C1 case where ctype is
1, the state is entered via a MWAIT instruction, while the higher C
states are entered by doing an IO read from a specific IO address. This
IO address is x - 1 bytes into the IO region starting at
MSR_CSTATE_ADDRESS for the Cx state. So for example C2 is entered by
reading from the C state IO base address + 1. This resource information
is generated during runtime, since the contents of MSR_CSTATE_ADDRESS
aren't necessarily known at compile-time.
MAX_CSTATE_COUNT is introduced so that the caller can allocate and pass
a buffer with space for the maximum number of C state entries. This
maximum number corresponds to the number of IO addresses the CPU traps
beginning from MSR_CSTATE_ADDRESS. In practice, it's unlikely that more
than 3 or maybe 4 C states will be available though.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c36c1d604ced349c609882b9d9fe84d5f726a8d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>