To avoid having to calculate the length of a struct separately, rework
the code to give the struct a tag name, so that `sizeof()` can be used
instead. This involves refactoring the `get_emi_eeprom_vpd()` function
to return a struct instead of a union, so callers can no longer access
the EEPROM data as an array of bytes without additional code, but this
array view is only used inside `get_emi_eeprom_vpd()` when reading the
data from EMI.
Change-Id: Id1bc40939631baa131b5f60eadbfe42838294ebe
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73983
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
This patch avoids the redundant programming of SRAM BAR when
the SRAM PCI device is enabled. Rather read the PCH SRAM Base
Address Register while enabling crashlog feature.
Additionally, this patch relies on PCI enumeration to get the
SRAM BAR rather than hijacking the SPI temporary base address
which might have resulted in problems if SPI is disabled on
some platform with BAR being implemented.
TEST=Able to build and boot google/marasov and crashlog is working.
Change-Id: I8eb256aa63bbf7222f67cd16a160e71cfb89875a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Disable devices in variant.c instead of adding probe statements to
devicetree because storage devices need to be enabled when fw_config is
unprovisioned, and devicetree does not currently support this (it
disables all probed devices when fw_config is unprovisioned).
BUG=b:273791621
TEST=emerge-nissa coreboot
Change-Id: I1a6013e0ad0c430d83bbbad4b92392c8c4815b0d
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74059
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This sets the location of the skyrim MP2 firmware within the mainboard's
blobs directory, and adds the Kconfig option to the mainboard directory
so that it can be enabled in a saved .config file.
The skyrim MP2 firmware is skyrim specific, so it should not be placed
in the main PSP AMD_BLOBS directory.
We will also only want to enable the MP2 firmware for chromeos builds as
it's not useful for non-chromeos builds.
BUG=b:259554520
TEST=Build MP2 firmware into image, see that it gets loaded
BRANCH=skyrim
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I04be6f2d0b605d4eca37fd927a70310259dc106c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73659
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Instead of using the PSTATE SSDT generated by binaryPI, use the common
AMD code by selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE. To
match the SSDT from binaryPI, set ACPI_SSDT_PSD_INDEPENDENT to n. There
are two differences to the binaryPI SSDT: Now coreboot includes the C1
state in the _CST package instead of just having the kernel add this due
to the ACPI_FADT_C1_SUPPORTED bit being set and the address of the
PS_STS_REG P state status MSR is written to the corresponding field of
the _PCT package instead of being 0.
TEST=On Careena the new P and C state ACPI packages are nearly identical
to the ones from the SSDT from binaryPI with the two functional
differences mentioned above.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icdf6bc8f0e0363f185a294ab84edcb51322e7eb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74023
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
The C state ACPI packages binaryPI generates and passes to coreboot in
the PSTATE SSDT only include the C2 state, but the kernel will add the
C1 state to its usable C states in this case. The native C state code
will generate both the C1 and C2 state packages to be more complete and
also to be more in line with the other AMD SoCs.
The code added in this commit isn't used yet, but will be used as soon
as Stoneyridge will be using the common AMD generate_cpu_entries by
selecting SOC_AMD_COMMON_BLOCK_ACPI_CPU_POWER_STATE once all needed
helper functions are implemented for Stoneyridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I06f90306ac196704e0102d0da6eab03f51513c29
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74001
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Use get_pstate_core_freq instead of open-coding the calculations in
tsc_freq_mhz. In the case of the CPU frequency divider being 0,
get_pstate_core_freq will return 0; in this case that shouldn't happen,
TSC_DEFAULT_FREQ_MHZ will be used as frequency, since for the TSC
frequency it's better to err on the end of the expected frequency being
too high which will cause longer than expected delays instead of too
short delays.
Now that the code is using get_pstate_core_freq, this code is valid for
Glinda too, so also remove the comment on the
SOC_AMD_COMMON_BLOCK_TSC_FAM17H_19H option being selected in the Glinda
Kconfig. This Kconfig option will be renamed in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I01168834d4018c92f44782eda0c65b1aa392030d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74013
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Factor out the get_pstate_core_freq function from the SoC's acpi.c files
to both avoid duplication and to also be able to use the same function
in the TSC frequency calculation in a follow-up patch. The family 17h
and 19h SoCs use the same frequency encoding in the P state MSRs while
the family 1Ah SoCs use a different encoding. The family 15h and 16h
SoCs use another encoding, but since this isn't implemented in
Stoneyridge's acpi.c, this will be added in a follow-up patch.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8619822c2c61e06ae5db86896d5323c9b105b25b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Due to a non-constant TSC rate before the microcode update is applied,
the Performance Time Stamp Counter is used instead. To clarify this, add
a comment to the timestamp_get implementation. See commit 24079323d4
("soc/amd/stoneyridge: provide alternate monotonic timer") and the
description of the TscInvariant bit in CPUID Fn8000_0007_EDX Advanced
Power Management Information in the public version of BKDG #55072 Rev
3.09 for more details.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I824b372c36fa6f3eb912469b235a9474f6a58ff5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74018
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
There are two conditions within the config space dump code, one to
print offset, one at the end to put a newline. Tweak the printk
strings so the first conditioned printk does it all and move the
second printk out of the loop to the very end.
Change-Id: Ie9dc744406ba20412892df96720e88e24c3d52bc
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73887
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From Meteor Lake onwards Intel FSP will generate the Trace Hub related
HOB if the Trace Hub is configured to save data in DRAM. This memory
region is used by Trace Hub to store the traces for debugging purpose.
This driver locates the HOB and marks the memory region reserved so
that OS does not use it.
Intel Trace Hub developer manual can be found via document #671536 on
Intel's website.
Change-Id: Ie5a348071b6c6a35e8be3efd1b2b658a991aed0e
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72722
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Fix the VGA_BIOS_ID IDs to match the PCI IDs in the VBIOS binaries and
the PCI ID Stoneyidge's map_oprom_vendev returns. This fixes the problem
that the display wasn't initialized due to not finding the VBIOS file in
CBFS. This bug in the Stoneyridge Kconfig was unmasked by commit
42f0396a10 ("device/pci_rom: rework PCI ID remapping in
pci_rom_probe").
TEST=Display in Careena lights up again.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4d1e6a3a65d7d7b07f49df9ce90620b79d9a2d78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74019
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Currently ifdtool --validate will not correctly validate the FMAP
against the IFD regions, since it will compare the IFD bios region with
an FMAP region called SI_BIOS.
It's probably a good idea to define default name for the BIOS FMAP
region like we have for 'COREBOOT' or 'FMAP' FMAP region.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I55eddfb5641b3011d4525893604ccf87fa05a1e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
On systems that do not provide their own *.fmd (Flashmap) file, we
fall back to a default flashmap file. That file however does not contain
the blobs (ME, GBE ...), that are usually placed below the BIOS Flashmap.
It can therefore easily happen that the placement of the blobs collides
with the placement of the BIOS region (e.g. if CBFS_SIZE is big enough).
The fmaptool can't catch that, since it does not know of the blobs
placement.
This patch basically maps the regions described in the IFD (Intel
Firmware Descriptor) to the default Flashmap.
Test: Build and see that build/fmap.fmd contains all blobs now (on intel
systems that are supported by the ifdtool)
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I82cb252fff456773af69943e188480a4998736fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Set open-drain GPIOs for ChromeOS as input and bias-disable mode.
After applying this patch, the voltage of these pins will become the
expected value 1.8V (previously 1.0V), preventing wrong judgement of
low/high.
Reference document:
MT8188G_GPIO_Formal_Application_Spec_V0.3
BUG=b:274058085
TEST=build pass
Change-Id: I057716df6c59efb84fc395109db022b82ce528c4
Signed-off-by: jason-ch chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73963
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A core voltage ID larger than 0xff shouldn't happen, since SVI2's core
VID is only 8 bit long. In order for making it more difficult to use
this function in a wrong way that results in a very wrong voltage being
returned, also return 0 for those invalid core VID values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I95417c45db86cd2373879cdad8a07fb9eb8dfdda
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74000
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
