The value from raw_read_cntfrq_el0() could be large enough to cause
overflow when multiplied by USECS_PER_SEC. To prevent this, both
USECS_PER_SEC and hz can be reduced by dividing them by their GCD.
This patch also modifies the return type of `timer_hz()` from
`uint64_t` to `uint32_t`, assuming that in practice the timestamp
counter should never be that fast.
BUG=b:307790895
TEST=boot to kernel and check the timestamps from `cbmem`
Change-Id: Ia55532490651fcf47128b83a8554751f050bcc89
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78888
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Drop the hda_soc_ssdt_quirks function since it doesn't apply for any of
the SoCs supported by the Stoneyridge code which was the only SoC
implementing it. This code was added when commit 91a7abf25c
("soc/amd/hda: Move HDA PCI device from DSDT to SSDT") rewrote the code
originally added in commit 1587dc8a2b ("soc/amd/stoneyridge: Add
northbridge support") as a copy from northbridge/amd/pi/00670F00. This
code was moved around in commit 6580408a7e ("amd/pi/hudson: Move audio
to northbridge"), since the HDA controller was moved from the FCH to the
northbridge complex. When the controller was moved, the PCI config space
interface also changed, so those bits are no longer the DisableNoSnoop,
DisableNoSnoopOverride, and EnableNoSnoopRequest bits of the Misc
Control register of the HDA controller, but some bits within the
ClassCodeW field of the ACGAZ Mirrot Reg Ctrl 0 register.
BKDG #55072 Rev 3.04 (Stoneyridge), BKDG #50742 Rev 3.08 (family 15h
model 60h-6fh / 00670F00), and BKDG #52740 Rev 3.05 (family 16h model
30h-3fh) were used as a reference. Only the SoC with BKDG #52740 still
has the HDA controller in the FCH; the other two have it in the
northbridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I77fc76752b1c7de62ba8a196f15c198f55be3074
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78940
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The builds from the configs directory were not being saved in the
junit.xml files that Jenkins uses to determine pass vs fail of the
individual builds.
This also fixes the path to a log file that I noticed while testing.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I37dbee676cc9e507e612ce66994a04aba062757a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78863
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 44a48ce7a4.
Reason for revert: It breaks wakeup from suspend on a bunch of boards.
While this approach of eyeballing "correct" values by chipset _should_
be fixed, it should also be accompanied by compile time verification
that the memory map works out.
Since nobody seems to care enough, let's just revert this, instead of
keeping the tree broken for a bunch of configurations.
Change-Id: I3cd73b6ce8b15f06d3480a03ab472dcd444d7ccc
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78850
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Now VBOOT is always assumed to run after romstage and be linked inside
romstage. This currently is the case but for flexibility reasons (e.g.
linking romstage into bootblock or having a verstage before romstage)
this could be more precise.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I361731c930a35e12245153920df1b6884d47064c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
A .data section now exists.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ic1510221582aca91c814d43f522a8fb6cba05921
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78937
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This code was written in a romcc bootblock time. There is no reason why
it would not work in bootblock now.
Untested but expected to work.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I34812fbcd1222eceeb9870b9cbb7431ead63ce6a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78936
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This code was written in a romcc bootblock time. There is no reason why
it would not work in bootblock now.
Untested but expected to work.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4113dc3208fe15305d1132136dd33417dd086bfb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78935
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This code was written in a romcc bootblock time. There is no reason why
it would not work in bootblock now.
Untested but expected to work.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I708e8a3b503eb3a7fdf6063803d666529096f651
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This is a RW mirror of AMD's openSIL for Genoa with additions from
Arthur Heymans.
- origin/openSIL/main from
https://github.com/openSIL/openSIL.git
- origin/ArthurHeymans/64b_public from
https://github.com/ArthurHeymans/openSIL.git
The current main branch starts with Arthur's branch and adds 5 commits
from the AMD's openSIL repo.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8917edf3a6a8493ffa9230902cafcc6234d3d571
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The community preview branch for coreboot on latest Xeon Scalable
processor is opensource at:
https://review.coreboot.org/plugins/gitiles/intel-dev-pub/.
Change-Id: Ie2ffc1722a4a26d6039b6642efa95bf072d896ad
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78787
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8dc93b12b81abee41f6f225f41d1f9953d1d93e1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78898
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
All base addresses of MMIO devices in the devicetree should also have
corresponding defines in iomap.h. PPR #55901 Rev 0.26 was used as a
reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0444e6cc0587b484a4a1ff49fa4b1540a24c8e80
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78897
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The base addresses of I2C 5 and I3C 3 were wrong and all I3C controllers
should use the base address of the 4kiB block where all registers of
that I3C controller are located in. PPR #55901 Rev 0.26 was used as a
reference.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1c983d4a709000ef7963b96228322603b98728aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Instead of redirecting the output of sed into a temporary file and
copying it to its target then, just tell sed to do the replacements
in-place and don't let it create a backup of the original file. The
overhead is not needed.
Change-Id: I442616cd78098b653af5bd49bc7a4f021c99e081
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Remove space to improve compatibility with OS drivers and various
tools, and to be consistent with other device names with the 360
suffix.
TEST=build/boot Windows/Linux on Akali360, verify audio functional.
Change-Id: Ib9b909dba939f726e6fbe71f5b4956b432086029
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78876
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The value from raw_read_cntfrq_el0() could be large enough to cause
overflow when multiplied by USECS_PER_SEC. To prevent this, both
USECS_PER_SEC and tfreq can be reduced by dividing them by their GCD.
BUG=b:307790895
TEST=emerge-geralt coreboot
TEST=boot to kernel and check the timestamps from `cbmem`
Change-Id: I366667de05392913150414f0fa9058725be71c52
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78800
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After CB:78800 applied, the bootblock increases 2128 bytes and exceeded
its allotted size (40K). Therefore, we enlarge BOOTBLOCK to 44K to solve
the compilation error. This patch also increases PRERAM_CBFS_CACHE to
103K to fill the empty space (1K) between TIMESTAMP and TTB.
BRANCH=none
BUG=none
TEST=./util/abuild/abuild -p none -t GOOGLE_HEROBRINE -x -a -B
Change-Id: Iae9d44939b29098e823508dd3965a1bae7a69041
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78893
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Change-Id: I30e4b02a9ca6a15c9bc4edcf4143ffa13a21a732
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78799
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
1.In contrast to the MediaTek Wi-Fi module, the Intel Wi-Fi module needs to load a SAR table.
2.Describe the FW_CONFIG probe for the settings on marasov.
- WIFI_SAR_ID_0 for MTK Wi-Fi module MT7921L
- WIFI_SAR_ID_1 for Intel Wi-Fi module AX211NGW
BUG=b:300045956
BRANCH=firmware-brya-14505.B
TEST=emerge-brya coreboot chromeos-bootimage
Change-Id: I5b5c6bea6c2c916fb682044218ec7b3a5d2659f6
Signed-off-by: Daniel Peng <Daniel_Peng@pegatron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77789
Reviewed-by: Daniel Peng <daniel_peng@pegatron.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
To get tracehub working, it requires few settings such as
SOC_INTEL_METEORLAKE_DEBUG_CONSENT=2 and enable tracehub device in
dev tree. This commit binds all tracehub related settings to Kconfig,
so that users only need to enable SOC_INTEL_COMMON_BLOCK_TRACEHUB
TEST=boot on screebo and test tracehub device exists and working
Change-Id: Ie830fe2fd38e3456497bea37fe42ca60d26ca305
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78648
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Enable FW_CONFIG for corsola so that the information can be passed to
payloads via coreboot tables.
BUG=b:157692450
TEST=emerge-corsola coreboot
BRANCH=none
Change-Id: I6c12041d3666907c884f5a50a12c1433c2085961
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Add an entry in the min_pci_sleep_states array for SA_DEVFN_DPTF,
to correct warning in cbmem log:
[WARN] unknown min d_state for PCI device 00:04.0
TEST=build/boot google/brya (banshee), verify warning not present in
cbmem log, verify entry for DPTF device in ACPI LPI constraint list.
Change-Id: I2a9976b065f08e4acd31c3deca13c5278f031a90
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78877
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Indicate FSP has support to display logo when graphics initialization is
done in FSP.
BUG=b:294055390
TEST=Build and boot to OS in Skyrim with and without passing the BMP
logo buffer from coreboot.
Change-Id: I6112c03723dcbc34cb0f57c400f831c765b95115
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78882
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 2bc9cee0f7 ("Braswell: Update the ACPI tables") switched the
SoC from using its own HPET generation code to the common x86 code, but
along the way the min_tick value got lost. Restore the original value
prior to the above commit, which is now set via a Kconfig override.
TEST=build/boot google/cyan (edgar), verify min_tick value in HPET
ACPI table is correct.
Change-Id: I2633e7cd0c3d74c1554ae8c1f2bb6387fd6dde2b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78744
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, there are 3 separate settings for DPTF which are not always
in sync:
- the enabled/disabled state of the devicetree PCI device
- the 'dptf_enable' register, which sets the ACPI device status via GNVS
- the 'DptfDisable' register, which sets the FSP UPD of the same name
To make things sane, drop the two chip registers, and set the GNVS
variable and FSP UPD based on the enabled/disabled status of the DPTF
PCI device in the mainboard's devicetree.
TEST=build/boot google/cyan (edgar). Verify that the PCI and ACPI
devices are present/enabled when DPTF is enabled in devicetree, and not
present/disabled when disabled in devicetree.
Change-Id: I8fc1b63eda0dc2e047d9cb1e11a02d41ab8b2ad7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The device name for the SA thermal/DPTF PCI device was missing from
soc_acpi_name(), leading to an invalid PLI device constraint entry
being generated in the SSDT (the name field was blank/missing).
Add the missing entry, matching the name to the existing ACPI
device.
TEST=build/boot Win11 on google/puff (wyvern) without a BSOD.
Change-Id: I7ac03fd292246981f32d9ad894b8f0f9870240fc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78869
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Add an entry in the min_pci_sleep_states array for SA_DEVFN_THERMAL,
to correct warning in cbmem log:
[WARN] unknown min d_state for PCI device 00:12.0
TEST=build/boot google/puff (wyvern), verify warning not present in
cbmem log, verify entry for THRM device in ACPI LPI constraint list.
Change-Id: Ide98c1b82c56ed1d34c608f9419f61c8e15d2dab
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78868
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change the LAN/WiFi device types from PCI to generic, so that the bogus
PCI device and function values don't end up in coreboot's internal
device tree. The presence of these bogus PCI devices cause the LPI
constraint generator to create a reference for an ACPI device which does
not exist (SB.PCI0.RP{xx}.MCHC). The invalid reference(s) cause a
Windows BSOD (INTERNAL_POWER_ERROR).
TEST=build/boot Win11 on google/puff (wyvern). Verify LAN/WLAN devices
function correctly under Windows and Linux.
Change-Id: Ibc5f96250edb358d0517bd3840bf5604defe0b39
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78870
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
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:305887856
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: I5993049ac63520c4dfd057c38b566fc69502d825
Signed-off-by: Rex Chou <rex_chou@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78843
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Change the dGPU/LAN/WiFi device types from PCI to generic, so that the
bogus PCI device and function values don't end up in coreboot's
internal device tree. The presence of these bogus PCI devices cause the
LPI constraint generator to create does a reference for an ACPI device
which does not exist (SB.PCI0.RP{xx}.MCHC). The invalid reference(s)
cause a Windows BSOD (INTERNAL_POWER_ERROR).
TEST=untested
Change-Id: Ic997b5ad893853b99ae53a2e5c7acf58467ea4f1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78873
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch calls into the function to join the MBUS if the GFX PEIM
module inside the FSP binary is taking care of graphics initialization
based on the RUN_FSP_GOP config option. The FW skips joining the MBUS
in case of a non-FSP solution and/or SOC_INTEL_GFX_MBUS_JOIN config is
not enabled.
BUG=b:284799726
TEST=MBUS joining is only applicable for google/rex while using GFX
PEIM.
Change-Id: I50d719a286722f5aafbad48ab4ca60500c836dd6
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This reverts commit 2e10a6d6f3.
Reason for revert: The FW version check is not supported except
for ADL platform. Reverted change broke S0ix functionality;
the original CL was added as HW W/A for ADL ONLY.
BUG=b:306214725
TEST=S0ix cycles on Rex with TBT Device attached.
Change-Id: Ib8eb11d36eac4e1c94a3349386442fa3eeeaef37
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78457
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The latest updates to Vboot use libnss, so add the library to the
coreboot sdk.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Iee0c44296b189b5327ef8f950b1bba9eb668f298
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78867
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
gnatgcc is deprecated and in recent GCC releases its purpose is
fulfilled by the gcc binary. In case of a deprecated gnatgcc version is
installed, it doesn't provide the expected output and hostcc_has_gnat1()
fails. In this case, just set the value of CC to gcc.
It's still required to install GNAT in addition to GCC.
Change-Id: I730bdfda81268d10bd2a41ef5cb4e3810b76a42c
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78215
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Commit e728766f45 ("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>
On guybrush, keyboard presses are signaled by the EC via eSPI virtual
wire. The interrupt is shared with others and should be active low.
From 74bce48f1d ("mb/google/{zork,guybrush,skyrim},soc/amd/espi: Fix vw_irq_polarity"):
> The default state for the IRQ lines when the eSPI controller comes
> out of reset is high. This is because the IRQ lines are shared with
> the other IRQ sources using AND gates. This means that in order to
> not cause any spurious interrupts or miss any interrupts, the
> IO-APIC must use a low polarity trigger.
Setting `vw_irq_polarity` in the device tree provides an option to
invert interrupts from the eSPI controller, but the register is
initialized from verstage which is baked into RO.
As a workaround, the necessary interrupts on the EC have been
reconfigured to be active low, and we can modify the IO-APIC
accordingly.
EC related CL here: https://crrev.com/c/4891663
BUG=b:218874489
TEST=-`emerge-guybrush chromeos-ec coreboot chromeos-bootimage`
-Flash new RW fw and verify keyboard is functional
-`suspend_stress_test -c 1` and verify i8042 irq is removed as a
wake source
-`echo mem > /sys/power/state`. Press key and verify system wake
from i8042.
Cq-Depend: chromium:4891663
Change-Id: I7d093d94a666263684645ef724e945069c68c806
Signed-off-by: Mark Hasemeyer <markhas@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Thanks to x86 CBFS cache support, we can leverage cbfs_map() function
to load the VBT binary regardless of if it is compressed or not.
Change-Id: I1e37e718a71bd85b0d7dee1efc4c0391798f16f7
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit 1df1cf994a ("commonlib/fsp_relocate: add PE32 section
support") introduced a potential NULL pointer dereference if there is
PE32 binary to relocate outside of the first firmware volume.
The `fih_offset' pointer was used as an output variable but now it is
also used as an input variable to pass the FSP information header to
the `pe_relocate()' function.
This commit resolves this potential NULL-pointer dereference by
passing the pointer systematically and without affecting the logic as
it is only set if it has not been set before.
Change-Id: I9fad90a60854d5f050aa044a5c0b3af91c99df4a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78501
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A new FSP-S UPD is added to allow passing a buffer containing boot logo
in BMP format. Update the FSP-S UPD and add a SoC specific callback to
populate the UPD.
BUG=b:294055390
TEST=Build and boot to OS in Skyrim. Pass the BMP logo buffer through
the UPD to FSP-S. Ensure that the concerned driver in FSP-S handles the
buffer.
Change-Id: Ie522956b6dfe2400ef91d43c80f2adc6d52c8415
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78817
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I think this was probably a cut & paste error. We don't want prompts
for the "default" Kconfig options. Those should be set by the platform,
not the end user. These prompts didn't make sense where they were in the
Kconfig menus either.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Idcd2ba84591d31a9a25bcc6cae3ec163939d7836
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78818
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
The ACPI name of any device needs to match the name used for generating
the S0i3 LPI constraint list, which comes from soc_acpi_name() for each
SoC. The names used for the eMMC controller do not match, which will
lead to broken ACPI tables since the LPI constriant will reference
an ACPI device which does not exist. Some OSes tolerate this better
than others, but it should still be corrected.
TEST=build/boot google/{hatch,volteer, brya}, dump ACPI and verify
no invalid device names referenced.
Change-Id: Icbc22b6b2a84bbe73f1b09083f27081612db5eba
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78825
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch fixes the redundent GFX modeset issue when a dual display
is attached (e.g. an eDP display and an HDMI display).
The issue was caused by the MBUS joining logic not considering the
display type. This patch introduces three types of display: internal,
external, and dual-display. The MBUS joining logic is then updated
to consider the display type and ensure that the correct pipes are
joined to the MBUS:
For internal-only displays, only PIPE-A is joined to the MBUS.
For external displays, no pipes are joined to the MBUS.
For dual-displays, all available pipes are joined to the MBUS.
BUG=b:284799726
TEST=Able to fix the redundent modeset issue when eDP and HDMI attached
to the google/rex.
Change-Id: Ie2a3b9f1212a9dcab2b7305078fe22ee35e7423c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78691
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In 64bit movsq is available which moves memory in chunks of 8 bytes
rather than 4 bytes.
Linux uses the same code.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I65f178d2ed3aae54b0c1ce739c2b4af8738b9fcc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78646
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Yidi Lin