While having select statements in Kconfig.name files is valid in the
syntax of the Kconfig language, having the selections split between the
normal Kconfig file and Kconfig.name files makes it harder to see what's
going on.
Kconfig.name files will now be limited to their original purpose of
selecting a particular board or board variant, not actually configuring
that board.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2aab78e296f2958e77a938b1afa40a25a6aa82b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78972
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Assigning the macros in gpio.h to the correct GPIOs. Also, fixing GPE
configurations so that they are mapped to the proper wake sources
(GPP_B, D, E groups).
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I6320cd98e560e514e63c52e173cb7923cfd1cdee
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
We need to increase romstage size a little to make a compiler upgrade
fit (CB:70771). Unfortunately the end of the romstage directly touches
the QCSDI region in the current memlayout, and there is no other way
to reshuffle things to make more space... so we need to move QCSDI out
of the way. This means that anyone who is actually building this
platform with CONFIG_QC_SDI_ENABLE (which requires a proprietary blob
that's not publicly available) will need to recompile their QCSDI binary
to match the new start address.
Change-Id: Iaf13e4001b3c763e3ec59009779931ec75603d5d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79074
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Building coreboot for the Qualcomm SoCs SC7180 and SC7280 requires to
include the Qualcomm blobs, which requires to accept their license.
However, for various reasons it makes sense to build without blobs, e.g.
static analysis or just build-testing.
So in order to do that, run the steps integrating the Qualcomm blobs
into the coreboot binary only if USE_QC_BLOBS is enabled and also remove
guards which prevent building related mainboards when USE_QC_BLOBS is
not enabled.
Change-Id: I249ac477b8f10e7fa0848e967c23a3b3b9bbd27d
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79026
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since this chip is a SoC and also to bring the chipset devicetree more
in line with the chipset devicetree of Sandy Bridge, merge the chip
operations of the northbridge's root complex and the northbridge itself
into one chip operations structure and use it at the top level of the
devicetree.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8b42bac07b1409bbc797bc4428cf9f84a40e94c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
BKDG #52740 Rev 3.05 was used as a reference for the SoC's various PCI
devices. The HDA controller in the FCH at function 2 of device 0x14 on
bus 0 was missing in the mainboard's devicetrees.
TEST=PC Engines APU2 still boots and doesn't show any new problems
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6970c2f6e6d661d40406586f4e6eeb05bcd07979
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79083
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Morphius boards using pre-v3.6 schematics don't have a dedicated GPIO
for touchscreen power/enable, and so fail with runtime detection
enabled. Since it only has one touchscreen option, and no SKUs lack a
touchscreen, we can safely assume it is present in all cases.
TEST=build/boot morphius w/4k screen, verify touchscreen enabled in
cbmem and functional in Linux and Windows.
Change-Id: I13e07e14b5a18fa1dd3b18950cf46e9d7821eedc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Some boards (e.g. prodrive/hermes) that do not provide their own FMAP
and therefore have been generated by the build system (+ ifdtool)
experience a failure when trying to build with an IFD that contains
regions which do not have equivalent fmap names (set to NULL).
Therefore add a NULL check for the fmapname and ignore the region if we
do not have an fmapname.
Test: compile prodrive/hermes
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ib4589b7fdbd11d644214ca5601536e9aeb26882f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79010
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Generated using update_ec_headers.sh [EC-DIR].
The original include/ec_commands.h version in the EC repo is:
ab9b64ac4c Add a host command to print info about AP-firmware state
The original include/ec_cmd_api.h version in the EC repo is:
ab9b64ac4c Add a host command to print info about AP-firmware state
BUG=b:300525571
BRANCH=none
TEST=none
Change-Id: I3570e073a91621cb1d28a24aa35c1f4beedceaab
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79066
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Returning a NULL device name can cause issues if something else does
handle it.
E.g. UART and GNA devices on Intel Alder Lake-N cause
INTERNAL_POWER_ERROR BSOD's in Windows when enabled due to invalid
packages being created from a NULL name
Test: build/boot google/nissa (craaskvin) to Win11
Change-Id: I0679147ad3e330d706bbf97c30bc11b2432e2e8a
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Appears to not be used under Windows, Linux, or ChromeOS, and causes
high CPU usage at idle under Windows.
BUG=none
TEST=build/boot Win11, Linux on google/frostflow, verify camera shutter
function unchanged, CPU usage under Windows idles where expected.
Change-Id: I8a6ea3b886766bdb055b40949c75bec0264eecc5
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77678
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Updating from commit id edd465837e26 (2023-10-20):
cezanne: Update PSP binaries to release 0.11.11.75
to commit id e4519efca746 (2023-11-15):
Revert "picasso: Update PSP binaries to release 0.8.13.7B"
This brings in 1 new commit:
e4519efca7 Revert "picasso: Update PSP binaries to release 0.8.13.7B"
Change-Id: I860aa04324128199cbc91a5f310fcdf92a2cd65d
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
System76 only sells units with memory speeds up to 5200 MT/s, but the
i9-13900HX supports up to 5600 MT/s memory.
Tested by running memtest and checking dmidecode reports 5600 MT/s when
using 2x16 GB 5600 MT/s Crucial SODIMMs (CT2K16G56C46S5) on addw3,
bonw15, serw13.
Change-Id: I9bb0435769c70c1db06d2c5cca2dd28eb5331f49
Signed-off-by: Matt Parnell <mparnell@gmail.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Tested-by: Levi Portenier <levi@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78912
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This uses the size attribute to traverse the possible string.
This patch traverses the entire property for non printable characters
and not just until the first 0 is hit.
Now numbers that start with a zero (memory wise) are not falsely
recognized as strings:
before the patch:
clock-frequency = "";
after the patch:
clock-frequency = < 0x1c2000 >;
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I229c07b76468fe54f90fa9df12f103d7c7c2859d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78025
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch creates a new variant mtlrvp4es_p_ext_ec. The new
variant will support ESx samples. The existing mtlrvp_p_ext_ec
variant will support the QS samples.
BUG=b:310775573
TEST= Build and boot mtlrvp4es_p_ext_ec.
Signed-off-by: Usha P <usha.p@intel.com>
Change-Id: Iad72c0f6343af149d16d8b1f8639ba496f6aab0c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79052
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch sets the default locales to English for platforms that
do not have support for VBOOT configuration. This ensures that the
system will use English locales if the platform does not provide
its own locale settings.
TEST=Built and booted the google/rex platform successfully.
Change-Id: I7554c8bfd58411f460deeb22cf7218059ca8ba9f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79054
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The ux_locales-test relies on the ability to determine supported
locales for the platform. However, this information is unavailable
without VBOOT config being enabled. Therefore, enforce this test for
platforms with VBOOT config alone to avoid unnecessary failures.
Change-Id: I2828eb062e2b601e073e7dab9aef7316fc6ba2cd
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Previously acpigen_pop_len always wrote a 3 byte PkgLength to the 3
bytes reserved by acpigen_write_len_f. After this patch acpigen_pop_len
encodes PkgLength in 1-3 bytes depending on the PkgLength. When less
than the 3 bytes that were previously reserved in the corresponding
acpigen_write_len_f call are needed for PkgLength, the payload data will
be moved back by the number of reserved bytes that aren't needed for the
PkgLength.
This fixes the problem that the Windows AML parser doesn't like a 3 byte
PkgLength being used for the size of the buffer containing UTF-16
strings when the length could be encoded in a single PkgLength byte. In
that case, Windows previously ignored the whole SSDT containing this
larger than necessary PkgLength encoding. It should however be noted
that the ACPI 6.4 spec doesn't specify if it's required to always use
the most compact possible encoding of the PkgLength or not. Since iasl
generates the shortest possible PkgLength encoding, it's also a good
idea to make coreboot's acpigen do the same although it's not required
by the specification.
With this patch applied, Windows still boots on Mandolin and the time it
takes to write the tables doesn't change. To measure the times, the log
level in bs_sample_time was increased to BIOS_CRIT and the console log
level was increased to BIOS_CRIT too to only get those times as output.
BS: BS_WRITE_TABLES run times (exec / console): 8 / 0 ms
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib897b08a05a7cdc52902d51364246c260ea1f206
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79002
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
The THRM and SATA PCI devices do not currently have any ACPI devices
defined, so drop them from soc_acpi_name() so they do not end up in
the LPI constraint list. This eliminates the following errors
under Linux:
AE_NOT_FOUND: _SB_.PCI0.THRM
AE_NOT_FOUND: _SB_.PCI0.SATA
TEST= build/boot google/hatch (jinlon) and verify no ACPI errors.
Change-Id: I3827b152644e2eaecc1ad288d441d2dad4d76ccb
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79013
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After commit adaeb11021 (nb/intel/sandybridge: Clean up post Haswell SPD mapping API migration), no boards use this header anymore and it
no longer offers original content.
Adjust northbridge code #includes as needed and drop it.
Change-Id: I2785e920bd6188dbfc1a6157351083ec4a2526d0
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78785
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
With commit adaeb11021 (nb/intel/sandybridge: Clean up post Haswell SPD mapping API migration), raminit_native.h now only includes 4
other headers and offers no original content. Based on the idea that
all source files should include what they use directly, drop it in
favor of sandybridge.h (which it already includes anyway) and types.h
(replacing stdint.h because it also uses boolean constructs).
Board appears to not use anything sb/intel/bd82x6x/pch.h provides.
And the board still builds after dropping it.
Change-Id: I1b201fe4dd29bac5feb08f372d1e36353eac161d
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78783
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All of these signals have net names, but are actually unstuffed, so we
have to set them to NC.
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I27d8b7cd02aefb49a2dc031a30eb0d1e8aa9faa9
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The comments related to the PCI devices are superfluous since the
reference names from the chipset devicetree are used. So remove the
comments and also the devices which are turned off, or in general have
an equal state compared to the configuration in chipset devicetree.
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: Ic45446b03a3c571837fc1c41f55d60bdf2a25a7e
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79037
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
- Disable unconnected PCH PCIe ports 1 + 3.
- Add smbios_slot_desc to WLAN PCIe port
- Add comment for PCIe port 7 that might have a
XHCI controller connected (some variants only).
Test: Lenovo X220 still boots and all devices are still working
fine. The WLAN slot is shown in dmidecode -t 9.
Change-Id: I3fdfbb7ad30e2ff8a289d9055eaef0557475fdff
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
With migration to Haswell SPD mapping interface complete:
1. Remove weak stubs meant to ensure smooth transition and
internalizes mainboard_get_spd() within raminit.c.
2. Remove post-mainboard SPD data sanitization code in raminit_mrc.c,
now that it fills its own SPD data.
3. Remove old prototypes from raminit_native.h
4a. Drops raminit_native.h from raminit.c, as individual headers
therein are already included.
4b. Drop another header from raminit.c IWYU identified as unneeded.
asus/p8z77-m still builds afterwards.
(sandybridge to receive a full IWYU cleanup later.)
Change-Id: Ie073c1386cd0a645069f0e1416263b4fa359b74b
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76991
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While converting this board to provide SPD info using the Haswell API,
it was discovered that its SPD setup was not correct to begin with.
For a board that only has soldered down memory with SPD data in CBFS,
it didn't enable HAVE_SPD_IN_CBFS in Kconfig. It also duplicated one
set of SPD data with deliberate gaps in between. It worked its dark
magic within mainboard_get_spd(), which is going away as a callback.
Add HAVE_SPD_IN_CBFS to mainboard Kconfig, recreate the one set of SPD
data as a hex dump same as other boards, and hook everything back up
with Haswell-style mb_get_spd_map().
Recreated SPD data was extracted from abuild-built binary and manually
verified for correctness against existing spd.bin (which will be
removed in a follow-up).
Change-Id: I906c49f6d1949f830828530edc0298b1b22ec04d
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76995
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Changes both MRC and native raminit code path to get SPD mapping
from one place.
Boards with all memory socketed specify their mappings in a
devicetree setting introduced in commit 5709e03613
("nb/intel/sandybridge: Migrate MRC settings to devicetree") back in
May 2019 but remains unused as of this patch. This setting
will now hold raw SMBus addresses, and MRC raminit gets code to
translate them into a representation MRC expects.
Boards with soldered down memory (specifically with HAVE_SPD_IN_CBFS
in their board Kconfig), with or without socketed memory, specify
their layouts in mb_get_spd_map() as used by Haswell boards, where
they access hardware GPIO straps to select which SPD data to use.
This harmonizes the way boards specify their SPD layouts across
Haswell/SNB/IVB boards whether using MRC or native raminit. Going
forward they only need to specify the layout in one place. (Going
forward the devicetree setting should be backported to Haswell,
once we get native raminit working there.)
With this, northbridge code is now fully responsible for loading
all SPD data, be it from CBFS or SMBus.
To avoid breakage, transition will happen in stages:
1. This patch gets all the code in, and implements weak stubs that
maintain existing code and data flow (i.e. mainboards still populate
final SPD layout data). At this point devicetree already uses new
representation, but is still unused meaning no breakage.
2. Follow-up patch(es) remove mainboard_get_spd() from mainboards, and
replace it with mb_get_spd_map() or devicetree values (as appropriate)
with converted SPD info. The "weak" mainboard_get_spd() with new logic
takes over. Boards go Haswell Style at this point. Boards with MRC
raminit also lose code to fill in SPD data, allowing new data to take
hold.
3. Clean-up patch removes the weak functions and public prototypes re
mainboard_get_spd(), making it internal to northbridge. Changeover is
complete.
Change-Id: I1a75279d981e46505930a9ce1aae894ccc4e1f24
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76965
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In vboot_get_context(), vb2api_reinit() is called to restore the vboot
context from the previous stage. We use assert() for the return value of
vb2api_reinit() because there shouldn't be runtime errors, except for
one edge case: vb2_shared_data struct version mismatch. More precisely,
when RW firmware's VB2_SHARED_DATA_VERSION_MINOR is greater than RO's,
vb2api_reinit() will return VB2_ERROR_SHARED_DATA_VERSION.
To avoid using an invalid vb2_context pointer (when FATAL_ASSERTS is
disabled), change assert() to die() on vb2api_reinit() failure. For the
vb2api_init() case the assertion is unchanged because there shouldn't be
any runtime error for that.
Also move the vb2api_init() call outside the assert() argument, as
assert() may be a no-op macro depending on the implementation.
Change-Id: I4ff5ef1202bba2384c71634ec5ba12db1b784607
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78808
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is a fixup to CB:78914 which inadvertently broke the RK3288 SoC.
Unfortunately we can only accommodate very little PRERAM_CBFS_CACHE in
the tiny SRAM for that chip, so we would not be able to map an entire
FMAP. Solve this problem for now by mapping less space when CBFS
verification is disabled, and disallowing CBFS verification on that SoC.
Change-Id: I2e419d157dc26bb70a6dd62e44dc6607e51cf791
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Proposed in the comment of commit 29030d0f3d
("drivers/pc80/rtc/option.c: Stop resetting CMOS during s3 resume"),
during sanitize_cmos(), only reset CMOS range covered by checksum and
the checksum itself from the file cmos.default in CBFS, in order to
prevent other runtime data in CMOS (e.g. the DRAM training data on
GM45 platforms for s3 resume) being erased.
Tested: cherry-pick this commit before commit 44a48ce7a4 ("Kconfig:
Bring HEAP_SIZE to a common, large value"), which is already
before my commit 29030d0f3d , Thinkpad X200 with
CONFIG(STATIC_OPTION_TABLE) can resume from s3 again,
indicating that DRAM training data are no longer erased.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Co-authored-by: Jonathon Hall <jonathon.hall@puri.sm>
Change-Id: I872bf5f41422bc3424cd8631e932aaae2ae82f7a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78906
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
init() was always followed by open() and after successful initialization
we only need send-receive function which is now returned by tis_probe()
on success, thus further reducing number of functions to export from
drivers.
This also removes check for opening TIS twice that seems to have no
value.
Change-Id: I52ad8d69d50d449f031c36b15bf70ef07986946c
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76954
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id d81517e:
2023-09-28 14:13:56 -0600 - (Improper bit field offset calculation)
to commit id 0411c75:
2023-11-10 23:59:34 +0000 - (Minor changes to fix issues compiling with clang)
This brings in 1 new commits:
0411c75 Minor changes to fix issues compiling with clang
Change-Id: Ib3adfd7bccd45dfd76ede462677dcfb294baa15d
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79009
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
To see which Kconfig symbols are actually used, and to verify that
they're used correctly, kconfig_lint scans the C code. It gives an error
if it sees a CONFIG(symbol) where the symbol doesn't exist.
This creates a problem when a C preprocessor macro is created to match
multiple Kconfig symbols. The simple solution here is to just ignore
those C preprocessor macro definitions as beyond the scope of this
linter.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5a20e8bb5a3e19e380802cba712d6dd3ff2f4dc0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78681
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When a package length needs to be written, we used to always
write three bytes for it, even when the length would fit into
one or two bytes. To allow such compact package lengths, we
have to move the written buffer data in case the length is
smaller. This makes tracking the start of nested buffers
harder, as they may be moved entirely later when a package
length is written. So instead of tracking start addresses in
test_acpigen_nested_ifs(), let's work with the generated AML
alone. In this lucky case, we can simply search for the `if`
operations.
Change-Id: Id8557dd5d1be3878713ee0b6106c3e0975665e97
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79008
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add variant of LTE and WFC support on gothrax board.
We base decisions on the values within the firmware configuration
CBI field.
In fw_config settings, if the board move LTE and WFC modules,
the hardware GPP_A8/GPP_E13/GPP_F12/GPP_H19/GPP_H23/GPP_R6/GPP_R7
pins need to be deasserted.
BUG=b:303526071
TEST=emerge-nissa coreboot & \
Check against schematic.
Whether it works as expected under different SKUs.
Signed-off-by: Yunlong Jia <yunlong.jia@ecs.corp-partner.google.com>
Change-Id: Ia8041bdc599509911bde95d6294314036e75b227
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78916
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Instead of installing the pip modules system-wide, and possibly causing
conflicts, install them into a virtual environment for the coreboot
user.
If we wanted to, in the future, we could install different versions of
the modules into different virtual environment directories to allow
for testing or anything else we needed.
Change-Id: I49c749a13a698bfb7af29bf07e42ac14b67b2ae7
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79006
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
There is no enumerate_buses() today and also no trace of it in our
repository. Also, in current terms, mainboard_enable() is called
as the very first thing in our enumeration so the comment seems
misleading.
Change-Id: Iae620f83c8166c1cfc8b9fb9ef4a7025987bf1be
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79003
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The buffer length is in bytes, and since we are converting from ASCII
to UTF-16, the value written needs to be 2x the string length + null
terminator.
TEST=build/boot google skyrim (frostflow), dump acpi and check bytecode
for correct buffer length preceding unicode strings.
Change-Id: Id322e3ff457ca1c92c55125224ca6cfab8762a84
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78977
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Guard multiple options depending on another with an if-block. It's not
needed to repeat the condition for every option.
This also cleans up the ordering of the options and groups all options
related to iPXE.
Change-Id: I9e74ab567f619a2d5c20c6c0282b37193d9ac01b
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78925
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When a variant setup is used, checking for each variant in order to do
the mainboard configuration is quite painful. Thus, move the selects
from BOARD_SPECIFIC_OPTIONS, which is enabled by default when a variant
is chosen, out to a common option, which is disabled by default but
selected by the variants.
So in order to enter that config block, it's only needed to check if
that common option is enabled and not for each variant. It's also a very
common scheme now.
Change-Id: I4ed889ce78a0d7cd088e05d0f4b7fbbc89153860
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78975
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
The combination of SOC_INTEL_RAPTORLAKE_PCH_S and FSP_TYPE_IOT is
currently broken. By default, e.g. for MSI PRO Z790-P, the
FSP_HEADER_PATH does not match the default FSP_FD_PATH. For headers
the client FSP is selected, while for the FD file, IoT FSP binary
is chosen. The order of default for both headers and FD file must be
the same to match the headers and binaries.
TEST=Build default MSI PRO Z790-P config and see that FSP_HEADER_PATH
matches FSP_FD_PATH FSP variant-wise.
Change-Id: I8db5ea10c2986ff8d3fa7d616b3f1617d05f0260
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78410
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Dynamic Tuning Technology (DTT) device IRQ is not programmable and
is INT_A/PIRQ_A (IRQ 16).
Reference: Meteor Lake U/H and U Type4 External Design Specification
External Design Document (657165)
TEST=Linux driver successfully uses IRQ 16 on rex. Without this patch
it was binding IRQ 18 but interrupts were going to IRQ 16.
Change-Id: I2cbb9dd41f27c40a29346be325bb9c46d1061afb
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
When the SMI transfer monitor (STM) is configured, get_save_state
returns an incorrect pointer to the cpu save state because the size
(rounded up to 0x100) of the processor System Management Mode (SMM)
descriptor needs to be subtracted out in this case.
This patch addresses the issue identified in CB:76601, which means
that SMMSTOREv2 now works with the STM.
Thanks to Jeremy Compostella for suggesting this version of the patch.
Resolves: https://ticket.coreboot.org/issues/511
Change-Id: I0233c6d13bdffb3853845ac6ef25c066deaab747
Signed-off-by: Eugene D. Myers <edmyers@cyberpackventures.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78889
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Later GSCs don't need a EC_IN_RW GPIO anymore, so removing the use of
this for get_ec_is_trusted().
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I29f94969e9f2c1f239d9f9655f39b8410296f695
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Having a separate romstage is only desirable:
- with advanced setups like vboot or normal/fallback
- boot medium is slow at startup (some ARM SOCs)
- bootblock is limited in size (Intel APL 32K)
When this is not the case there is no need for the extra complexity
that romstage brings. Including the romstage sources inside the
bootblock substantially reduces the total code footprint. Often the
resulting code is 10-20k smaller.
This is controlled via a Kconfig option.
TESTED: works on qemu x86, arm and aarch64 with and without VBOOT.
Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Updating from commit id 37366af8d:
2023-07-28 17:04:54 +0200 - (Merge "fix(cpus): fix minor issue seen with a9 cpu" into integration)
to commit id 88b2d8134:
2023-09-06 11:26:32 +0200 - (Merge "fix(scmi): add parameter for plat_scmi_clock_rates_array" into integration)
This brings in 225 new commits.
Change-Id: I97147fbec5c0a91daab67524027f57962f61d0a1
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78886
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
As TOUCHSCREEN_I2C_SPI will be used for two different configurations,
splitting it to TOUCHSCREEN_GSPI and TOUCHSCREEN_THC, and re-order
the FW_CONFIG bits by moving VPU to different bit position.
BUG=b:307774932
TEST=build and boot rex
Signed-off-by: YH Lin <yueherngl@google.com>
Change-Id: Ied4d732ef7993e95edbb7eb281842b9392e72820
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Some GPIOs (like WP and GSC) need to be configured in bootblock.
Making sure that they get configured earlier for this.
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I8dd4853bc05b954f47d858d87ea2aed48e4b8074
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78943
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are some inaccuracies in arbitrage. This is the first pass at
correcting the incorrectly generated configs. I also tried to update
the "No heuristic was found useful" comment generated by arbitrage
into something more useful (ie: the appropriate NFs).
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I836565e09a3e0b25746b3e2f9ed6610eaacf7e97
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78942
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Initialise overridetree based on the schematics revision 20231020A.
Added data.vbt just only for running abuild completed.
Real vbt define by CONFIG_INTEL_GMA_VBT_FILE in chromium:4936896.
BUG=b:304920262
TEST=abuild -v -a -x -c max -p none -t google/brya -b anraggar
Change-Id: I232bde990747be80e1ab62c3f0d010d5fc854cb5
Signed-off-by: wuweimin <wuweimin@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78456
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the FMAP cache is enabled, it cannot fail in pre-RAM stages unless
flash I/O in general doesn't work. Therefore, it is unnecessary and a
waste of binary size to also link a fallback path for this case.
Similarly, once the cache is written to CAR/SRAM/CBMEM there should be
no way for it to become magically corrupted between boot stages. Many
other parts of coreboot blindly assume that persistent memory stays
valid between stages so there is no reason why this code should link in
extra fallback paths in case it doesn't.
This saves a little over 200 bytes per affected (uncompressed) stage on
aarch64.
Change-Id: I7b8251dd6b34fe4f63865ebc44b9a8a103f32a57
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78904
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A recent security audit has exposed a TOCTOU risk in the FMAP
verification code: if the flash returns a tampered FMAP during the first
setup_preram_cache(), we will abort generating the cache but only after
already filling the persistent CAR/SRAM region with the tampered
version. Then we will fall back into the direct access path, which could
succeed if the flash now returns the original valid FMAP. In later
stages, we will just use the data from the persistent CAR/SRAM region as
long as it looks like an FMAP without verifying the hash again (because
the hash is only linked into the initial stage).
This patch fixes the issue by just calling die() immediately if FMAP
hash verification fails. When the verification fails, there's no
recourse anyway -- if we're not dying here we would be dying in
cbfs_get_boot_device() instead. There is no legitimate scenario where
it would still be possible to continue booting after this hash
verification fails.
Change-Id: I59ec91c3e5a59fdd960b0ba54ae5f15ddb850480
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78903
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The rarely-used fallback path for accessing the FMAP without a cache
currently only maps the FMAP header for the initial verify_fmap() call.
This used to be fine when we were just checking the magic number, but
with CBFS verification we may need to hash the entire FMAP.
Since this path is so rarely used anyway and the size difference only
has a practical impact on a few platforms, lets keep things simple and
just always map the whole FMAP.
Change-Id: Ie780a3662bf89637de93a36ce6e23f77fed86265
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78914
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Change the WiFi device type to generic, so that the LPI constraint
generator does not create a reference for a device which does not
exist in ACPI (SB.PCI0.RP14.MCHC). The invalid reference causes
a Windows BSOD.
TEST=build/boot Win11 on google/hatch (akemi)
Change-Id: Ieab0722a81f0952bb5b6df8e60c4d684ff455418
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78543
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No driver available or needed under Windows, so hide from OS.
TEST=build/boot Win11 on google/kahlee (liara), verify ADAU7002
device no longer listed as unknown under Device Manager.
Boot Linux and verify audio still functional.
Change-Id: If6d250a123825a69441b5c4d3cde35d5a68f568d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78510
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds the required FMD changes to support the change
in cse_lite 'commit Ie0266e50463926b8d377825 ("remove
cbfs_unverified_area_map() API in cse_lite")' for CBFS verification.
With the change in cse_lite the ME_RW_A/B blobs are now part of
FW_MAIN_A/B and corresponding entries in FMD can be removed for boards
that currently use them.
BUG=b:284382452
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I3ca88fee181f059852923d50292b24c0e5b9fd6d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
During warm reboot, NVMe is not detected with non-serial image
sometimes while there is no issue with serial image. This change
toggles NVMe PWR pin as soon as in early stage to make NVMe ready
sooner.
BUG=b:260547988
BRANCH=None
TEST= Build rex0 and try warm reboot from OS console. Check if
the platform with Micron SSD boots to OS again without an issue.
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I2f34e3f49e7fc388198ff85c8e119cb3f242a60e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Intel has identified an idle hang issue on pre-prod silicon that will
not be fixed or root-caused. To avoid the issue, this commit sets
SaGvWpMask to SAGV_POINTS_0_1_2 in the devicetree.
Note: This change will affect system power.
BUG=b:287170545
TEST=Able to idle for more than 5+ hours without any hang on
google/screebo.
Change-Id: Id0b8db0076d983d336c3bec6d6c33614c69964d1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78794
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds power limit settings for 4+8 28W SOC sku and renames
MTL_P_682_CORE to MTL_P_682_482_CORE since they are sharing same 28W
settings.
BUG=b:306677879
TEST=boot on rex with 4+8 SOC and power limit settings are correct
Change-Id: Icb5fc2b13e8510f89c03927439431190439a3a94
Signed-off-by: Curtis Chen <curtis.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78796
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The code for "phase 4" of firmware verification currently only sets a
recovery reason when there's an actual hash mismatch detected in
vb2api_check_hash_get_digest(). This is the most likely way how this
section of code can fail but not the only one. If any other unexpected
issue occurs, we should still set a recovery reason rather than just
reboot and risk an infinite boot loop.
This patch adds a catchall recovery reason for any error code that falls
out of this block of code. If a more specific recovery reason had
already been set beforehand, we'll continue to use that -- if not, we'll
set VB2_RECOVERY_FW_GET_FW_BODY.
Change-Id: If00f8f8a5d17aa113e0325aad58d367f244aca49
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78821
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id 24cb127a:
2023-08-21 Nicholas Bishop sign_uefi_unittest.py: Fix long-line lint
to commit id f2b01bf0:
2023-10-27 Julius Werner firmware: Undeprecate VB2_RECOVERY_FW_GET_FW_BODY
This brings in 47 new commits:
f2b01bf0 firmware: Undeprecate VB2_RECOVERY_FW_GET_FW_BODY
ef6d02df futility/vb2_helper: Add missing newline for error messages
886d13d7 PRESUBMIT: switch to cros format
ac2e1a75 host/lib: Decouple openssl headers from HOSTLIB
86ec05f7 futility: updater: Add help info for --quirks
2850244e futility: updater: Abort if the unlock_csme_* is used on a locked device
f1b5c88d devkeys: delete old unused firmware_bmpfv.bin
4444c5fe crossystem: Fix tpm_fwver for fwid < 12935
98ef339f 2lib: Prevent overwriting the value of fw_vboot2
c7517eb4 make_dev_ssd: support ChromeOS Kdump
8e3462cc tlcl: Increase the TPM_BUFFER_SIZE
740a2966 vboot_reference: Drop 'host' usage for 'internal' in flashrom.h
57877a44 vboot: Remove comments about physical dev switch
3401d16c 2lib: Fix typos, comments and formats
fdf52d45 scripts/: Drop deprecated {g,s}et_gbb_flags.sh scripts
bf76e9ee 2lib: Output the correct kernel_version
1ac4663e make_dev_firmware.sh: update pattern for matching wp status
c57ab9f7 2lib: Add recovery reason VB2_RECOVERY_WIDEVINE_PREPARE
e094ba31 tlcl: Reduce the variants of TPM2B
b047600d sign_official_build: support key config for pkcs11
f8712b73 vboot: support signing with pkcs11 private key
17fe786f strip_boot_from_image.sh: sfill fast
6c856cd3 futility/updater: Fix EC software write protection logic
1dc5a421 futility: update: Deprecate --unlock_me by --quirk unlock_csme_nissa
f0d88587 futility: update: Refactor the 'unlock ME' quirk(s)
81429ee9 futility: update: Do not update RO when the AP RO is locked
a3beb737 futility: update: Revise the ordering or quirks
2c1844fa futility: update: Remove unused quirk 'unlock_wilco_me_for_update'
75530d32 tests/futility: Test with new signer_config.csv based firmware updater
cba649fa 2lib: Expose 2hmac
ab015448 2lib: Refactor hmac to vb2_hmac_calculate
3545f8b4 Revert "sign_uefi: Remove exception catching"
55f625a9 dump_fmap: Add offset and size to flash_ec format output
a27ee336 keygeneration: add shellcheck source statements to help linting
055f9aa2 keygeneration: replace_recovery_key.sh: make minios key optional
6cb8ab60 scripts: delete unused values kernel command line
1f76c38b vboot: Drop phone recovery support
ccf6b037 scripts: Legacy fix for set_gbb_flags.sh
8f03069e futility: Add basic README.md
88963df8 utility: Query platform wp status with futility
6c3817d2 utility: Drop cros_alias technical debt in dev_debug_vboot
df85f512 scripts: Drop cros_alias technical debt in make_dev_firmware.sh
7395cd68 futility/updater_utils.c: Match on EC path to prepare for split
52518415 crossystem: Recover corrupted RW_NVRAM on flash writes
81f9ddaf futility/cmd_gbb_utility.md: Add basic GBB subcmd doc
c4995268 futility/: Fix define confusion
69dab5a6 crossystem: Avoid writing duplicate entries to RW_NVRAM
6c37b520 Revert "crossystem: stop supporting legacy chromeos_acpi driver"
Change-Id: Ic7ecd1755d26df349b8abf1c5a77c806facfe1d8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78820
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>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This prevents a headscratcher when .config in root doesn't have a write
permission bit set which causes a build failure of savedefconfig
not able to write to copied file, for example
*** Error while saving defconfig to:
build/mainboard/emulation/qemu-i440fx/cbfs-file.eU5E0t.out.tmp2
Change-Id: I2e7d35c9f6e8add3e7438d163850bc5fda5a99b2
Signed-off-by: Richard Marko <srk@48.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Windows doesn't have / will likely never have a signed driver for the
FPR, so set the device status as hidden so it will not appear as an
unknown device in Windows Device Manager. Linux does not check/care
about the ACPI device status.
TEST=build/boot Win11 on google/brya (kano), verify FPR does not show
up as unknown device under Device Manager.
Change-Id: Ie73fd9d448ecca9e9112abc0d92b4ab46ce3618d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Windows doesn't have / will likely never have a signed driver for the
FPR, so set the device status as hidden so it will not appear as an
unknown device in Windows Device Manager. Linux does not check/care
about the ACPI device status.
TEST=build/boot Win11 on google/hatch (jinlon), verify FPR does not
show up as unknown device under Device Manager.
Change-Id: Ia4a908afdabad0ae8db45c4731a00c9cb17b42bb
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch allows google/rex mainboard to choose between "Performance"
(PL_PERFORMANCE) and "Baseline" (PL_BASELINE) power limits (PLs).
This is important for platform to meet balance between power and
performance.
The OEM design google/screebo selects baseline power limit to maintain
the balance performance in lower power.
BUG=b:307237761
TEST=Able to build and boot google/screebo.
w/o this patch:
screebo4es-rev1 ~ # cbmem -c -1 | grep "CPU PL"
[INFO ] CPU PL1 = 15 Watts
[INFO ] CPU PL2 = 57 Watts
[INFO ] CPU PL4 = 114 Watts
w/ this patch:
screebo4es-rev1 ~ # cbmem -c -1 | grep "CPU PL"
[INFO ] CPU PL1 = 15 Watts
[INFO ] CPU PL2 = 40 Watts
[INFO ] CPU PL4 = 84 Watts
Change-Id: I43debc5442ae9c01851652beba676ffc102ca27d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the device scope of them.
While on it, remove superfluous comments related to modified lines.
Change-Id: I2f641ce1fc44a9d7c9f9c403d255997214021f47
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78668
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the device scope of them.
While on it, remove superfluous comments related to modified lines.
Change-Id: I15f326774850b3c9562f7eebb78f29430dec1031
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78667
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the device scope of them.
While on it, remove superfluous comments related to modified lines.
Change-Id: I75aeb46ea3b4a7c0a41dce375735e7b42ed59587
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78664
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the device scope of them.
While on it, remove superfluous comments related to modified lines.
Change-Id: I92414efc9ddb849ceb8b9c4f0bc564bdbd92773b
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78638
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DDR interfaces emit electromagnetic radiation which can couple
to the antennas of various radios that are integrated in the system,
and cause radio frequency interference (RFI). The DDR Radio Frequency
Interference Mitigation (DDR RFIM) feature is primarily aimed at
resolving narrowband RFI from DDR4/5 and LPDDR4/5 technologies
for the Wi-Fi high and ultra-high bands (~5-7 GHz).
This patch sets CnviDdrRfim UPD and enables CNVI DDR RFIM feature
for Craask variant.
Refer to Intel doc:640438 and doc:690608 for more details.
BUG=None
BRANCH=None
TEST=Build and boot Craask.
- Verified that Wifi DDR RFIM Feature is enabled and DDR RFI table can be modified.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Change-Id: I5560bbedb26e88edd9d35f16b639fe63ef42c30e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Just as in commit 38569d0610: ("mb/lenovo/{x230, x230s}: Disable
SuperSpeed capabilities for WWAN USB")
Although on ThinkPads with Panther Point PCH the usb port inside wwan
socket is usually wired to XHCI, it has actually no SuperSpeed lines,
so maybe it is okay to disable SuperSpeed capabilities, and wire them
to EHCI #2 by making use of XUSB2PRM and USB3PRM.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I61e61283a821686558f7f3fdfac7073bb3557e93
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78680
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Meteor Lake has a UPD config called In-Band ECC(IBECC) which uses a part of the system DRAM to store the ECC information. There are a few UPD parameters in FSP-M to configure this feature as needed.
This patch adds code to expose these parameters to the devicetree so
that they can be configured on the mainboard level as needed.
Change-Id: Ice1ede430d36dff4175a92941ee85cc933fa56d5
Signed-off-by: Marx Wang <marx.wang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78485
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they will be moved
into the devicetree to their related root ports at some later point.
While on it, remove superfluous comments related to modified lines.
Change-Id: I27bac17098beb8b6cb3942e68a37da0095f0d0bd
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78602
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch introduces a dedicated devicetree.cb file for platforms
built with pre-production SoC. This will help to keep the SoC
configuration separate for platforms with ESx and QSx silicons.
For example, the SaGv WP configuration is different between
pre-production (aka ESx) and production (aka QSx) silicon.
BUG=b:306267652
TEST=Able to build and boot google/rex4es.
Change-Id: I01b0abeeb25ce5a83882c56b30929228fcc6c95c
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78659
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Mike Lee <mike5@huaqin.corp-partner.google.com>
For variants without a digitizer, disable I2C2.
For variants without a proximity sensor, disable I2C3.
For variants without a fingerprint reader, disable SPI1.
For all variants, disable I2C5 as it is unused.
Adjust comment blocks as needed.
Change-Id: I27e9eb2b0dcc869d1964c0b17c656d6691c0f05e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78553
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they will be moved
into the devicetree to their related root ports at some later point.
While on it, remove superfluous comments related to modified lines.
Change-Id: I769233a5baabbea920c9085f8008071ba34bb9dd
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78598
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds the required FMD changes to support the change
in cse_lite 'commit Ie0266e50463926b8d377825 ("remove
cbfs_unverified_area_map() API in cse_lite")' for CBFS verification.
These blobs were kept separate originally to avoid hash loading and
verification every time and hence save boot time.
With the change in cse_lite the ME_RW_A/B blobs are now part of
FW_MAIN_A/B and corresponding entries in FMD can be removed.
BUG=b:284382452
TEST=Build CB image for google/rex board and test CSE FW
update/downgrade with CONFIG_VBOOT_CBFS_INTEGRATION config enabled.
Also confirm there is no increase in boot time with this change.
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I56865a9e5c8b5f9e908e00e1a7e7e187d5d6a2f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
With CBFS verification feature (CONFIG_VBOOT_CBFS_INTEGRATION)
being enabled, we can now remove cbfs_unverified_area_map() APIs
which are potential cause of security issues as they skip verification.
These APIs were used earlier to skip verification and hence save
boot time. With CBFS verification enabled, the files are verified
only when being loaded so we can now use cbfs_cbmem_alloc()/cbfs_map
function to load them.
BUG=b:284382452
Change-Id: Ie0266e50463926b8d377825142afda7f44754eb7
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78214
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Skolas is actually using the SOC_INTEL_ALDERLAKE_PCH_P config, so
fixing Brox to reflect this as it's using the same SoC.
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I632ec055d523956983d2053cd8e7000b1eaabf92
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78656
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce Kconfig choice to pick between lzma, lz4 and no compression
at all of the VBT binary.
If VBT is needed in romstage, it can be used to set VBT lz4
compression as an alternative to enabling lzma compression support.
Indeed, the extra lzma code needed to de-compress VBT undermines the
compression size reduction between lzma and lz4.
BUG=b:279173035
TEST=Verified that vbt.bin is lz4 compressed with
VBT_CBFS_COMPRESSION_LZ4 and not compressed at all with
VBT_CBFS_COMPRESSION_NONE
Change-Id: I1df6a96c2ec122f0ef8ee6a1e96ffbd621b14941
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76816
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
POWER_STATE_OFF_AFTER_FAILURE can't be directly selected since it's a
choice, so instead set POWER_STATE_DEFAULT_ON_AFTER_FAILURE to n, as
it's functionally equivalent. This fixes the warnings generated by
the pre-commit hook Kconfig check.
It is necessary to override and set default n in the mainboard Kconfig
as it is set to default y in src/soc/intel/common/block/pmc/Kconfig.
TEST=select starlabs/starbook_adl in menuconfig and verify the default
power-on setting is S5/soft off.
Change-Id: I3ce33517dcc0af693b8db8d1de2926117ad3c16b
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78627
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Eric Lai <ericllai@google.com>
Add FP enable/disable based on SKU ID for Morphius. This is meant
to resolve a UMA issue with Morphius devices that had the FPMCU
populated on non-fp devices. Since the FPMCU is present, and the
firmware enables the power GPIO's based on variant, not SKU, the
devices were reporting data on fingerprint errantly.
BUG=b:258040377
TEST=Flash to Morphius, test FP.
Disable test SKU, flash on Morphius, test FP.
Change-Id: If5794a9a1b7eb3daaa4cdfd1354dfb0c688624fd
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78622
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
CB:77409 corrected what the UPD `Timer8254ClkSetting` was set to; this
stopped a few boards from booting.
Selecting USE_LEGACY_8254_TIMER ensures that the previous behaviour is
maintained.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ibf898cae6c9fbaf3dc7184eee745278d9b5eade4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78504
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Simplify audio overrides for dalboz baseboard-based variants by using
device aliases. This prevents duplicate ACPI devices from being
generated for the ChromeEC i2s tunnel (which causes Windows to BSOD
with an ACPI_BIOS_ERROR).
TEST=build/boot Win11 on google/zork (vilboz), dump ACPI tables
and verify only one EC tunnel device in SSDT.
Change-Id: I56aa2f761843aa269620f7e8c89ae9c0f205f349
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78509
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is only a single i2c tunnel bus for audio from the EC, so all
attached devices need to exist under a single device attached to that
bus. This change will facilitate cleanup/simplification using device
aliases in a subsequent commit.
TEST=tested with rest of patch train
Change-Id: Ie09c682a7419868d39421574568dff1a651fa0dc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78626
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Select SOC_AMD_COMMON_LATE_SMM_LOCKING to ensure that SMM remains
unlocked on S3 resume until after the AGESA call to s3finalrestore
has completed. If SMM is locked prior, S3 resume will fail:
[DEBUG] agesawrapper_amds3laterestore() entry
[DEBUG] Error: Can't find 57a9e200 raw data to imd
[ERROR] S3 volatile data not found
TEST=build/boot google/liara, verify S3 resume succeeds.
Change-Id: I49659b4e5aba42367d6347e705cd92492fc34a0f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78625
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Pre-Zen SoCs like Stoneyridge call into an AGESA binary as part of S3
resume, which will fail if SMM is locked, causing the device to
(eventually) cold boot. To mitigate this, add a new Kconfig to enable
"late" SMM locking, which restores the previous behavior prior to
commit 43ed5d2534 ("cpu/amd: Move locking SMM as part of SMM init").
TEST=tested with rest of patch train
Change-Id: I9971814415271a6a107c327523a0a7c188a91df6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78352
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move all security patch level (SPL) related Kconfig options to the
common AMD PSP Kconfig file. Commit 4ab1db82bb ("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>
Supports a brand new ACP driver for STONEY / Grunt chromebooks.
AMD's Audio CoProcessor handles i2s/tdm audio, and is located on the
GPU.
On Windows the PCIe device for the GPU is owned by the AMD proprietary
driver, hence a separate device has to be added for the ACP driver.
Fortunately since IOMMU is disabled on STONEY, the driver itself can
pull BAR5 from the GPU and use that to initialize, so no special
configuration is required in ACPI other than the ID.
Change-Id: I0e31c3b31fa9fb99578c04b79fce2d8c1d695561
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the devicetree at their related root ports.
Change-Id: I85f7c0ddebf88dd21e6c2603ce45f0a4fc868d51
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78600
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the devicetree at their related root ports.
While on it, remove superfluous comments related to modified settings.
Change-Id: I67f4fdcfb59da6c594c89d7ad3ee7f2ddbbea69b
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78592
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they should stay in
the devicetree at their related root ports.
Change-Id: I25b87a157e934640355442edceb0760827dc7a43
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78591
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to improve the readability of the settings, use a comma
separated list to assign values to their indexes instead of repeating
the option name for each index.
Don't convert the settings for PCIe root ports as they will be moved
into the devicetree to their related root ports at some later point.
While on it, remove superfluous comments related to modified settings.
Change-Id: I19af8c6b1167af793eb18b000fd93ec409385587
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78597
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
DDR2 already had a define to specify the SPD length, but other memory
types did not. This led to the value being coded into other locations.
Unify the definition for DDR2 to DDR5 and put the value at the top of
the respective header file.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id13b9c5d311984d4a98b831a8746d1659724aa96
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78601
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Keith Hui <buurin@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
For Sandy Bridge boards with MRC raminit support, migrate as much
MRC settings to devicetree as possible, to stop mainboard code from
needlessly overwriting entire PEI data structure, so they will not
interfere with upcoming transition to one standard Haswell way of
providing SPD info to northbridge.
Some exceptions allowed are described below and in code comments.
SPD-related items are kept out of devicetree for now. They will be
migrated (with a different representation) with the Haswell SPD
transition.
google/{butterfly,link,parrot,stout} have max DDR3 frequency set in
pei_data to 1600 (2*800), but in devicetree to 666. The reason for the
difference seems to be problems with native raminit code. These are
converted into ternaries tied to CONFIG_USE_NATIVE_RAMINIT, with an
added "fix me" tag. asus/p8x7x-series also needs the same treatment,
based on testing various memory on p8z77-m hardware.
TEST=Builds on all affected boards. asus/p8z77-m still works with multiple RAM modules tested.
Change-Id: Ie349a8f400eecca3cdbc196ea0790aebe0549e39
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
psys_pmax_watts is configured in SoC node of devicetree.
Value represents Watts the PSU provides.
Zero means automatic/default configuration (not optimal).
BUG=b:289853442
TEST=Build google/rex/ovis4es target board
Change-Id: I69afa06110254f6384352c062891c0c9c0b23070
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76796
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id b1741d184add (2023-10-04):
PCO: Update SMU firmware to 4.30.77.200
to commit id edd465837e26 (2023-10-20):
cezanne: Update PSP binaries to release 0.11.11.75
This brings in 4 new commits:
edd465837e cezanne: Update PSP binaries to release 0.11.11.75
480c9d2efd picasso: Update PSP binaries to release 0.8.13.7B
1b1fd40889 Stoneyridge: Update SMU firmware for fanless/kicker to 33.10.0
c99172d385 Stoneyridge: Update SMU firmware to 26.17.0
Change-Id: I1fc1756a204e5f637ca67ef51daf4592572a6a17
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Update the filename for the PSP_SMUFW2_SUB1_FILE to use the compressed
and signed version (.csbin) rather than the uncompression + signed
version (.sbin), in order to be consistent with the other SMU firmware
files. This will also facilitate dropping the duplicate files in an
upcoming update to the amd_blobs repo and updating the SMU files (all
of which are .csbin).
This change is actually a no-op since the .csbin and .sbin are the same
file; it appears that the .sbin file was incorrectly named when added,
and then the same file was added later with the correct extension.
TEST=build/boot google/kahlee (liara)
Change-Id: I10fa8e949ab589d315862c06b4125c902520cbbc
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78512
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In EC versions older than 1.18, if the mirror flag was enabled, the
EC would mirror once the system reached S5.
When a mirror is successful, the system will automatically power
on, as it acts like it's been in G3. This led to machines turning on
when the intention was them to be off.
In 1.18 and later, they're installed when turning on. The result was
slower boot times when mirroring, but no unwanted powering on.
Because of this, coreboot no longer needs to power off when setting
the mirror flag.
Change-Id: I973c1ecd59f32d3353ca392769b44aadf5fcc9c3
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78200
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Disable the GpioOverride UPD in FSP M, and comment out the Clock Request
GPIOs to ensure that coreboot doesn't touch them.
This solves behaviour that can only be described as weird:
* Devices connected to Root Ports don't initialise
* Hang seen when entering S5
* Hang when edk2 is reached
Change-Id: Idf8d2112a1c44064af73bb54fd3e1a1a429e0649
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Create an event handler for the PEWAKE# GPIO and notify the device
driver to wake up the device.
BUG=b:301150499
TEST=Compiled and tested on google/redrix:
1. Enable runtime suspend for linux mtk_t7xx driver
2. Wait for device to enter suspended state
3. Modem should be able to wake up driver, e.g. on SIM card insert/eject
The interrupts should show up under /proc/interrupts as ACPI:Event
Signed-off-by: Paweł Anikiel <panikiel@google.com>
Change-Id: I32257689da85ea71f9de781093b3ede0cfe70a0e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78297
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This signal gets deasserted by the WWAN modem to reactivate the PCIe
link when in low power mode. In order to handle this efficiently, the
kernel needs to set up an interrupt.
BUG=b:301150499
TEST=Compiled and tested on google/redrix
Signed-off-by: Paweł Anikiel <panikiel@google.com>
Change-Id: I37f6836aefe4a374eaff3e4bc11358be274cf563
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78416
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
When walking the devicetree to generate the list of devices and minimum
sleep states, skip any devices which have the disable or hidden flags
set. This prevents adding entries for devices which are not present,
which are hidden (and likely to not have a min sleep state entry), or
generating duplicate entries in the case of PCIe remapping.
Any of these conditions are considered invalid by Windows and will
result in a BSOD with an INTERNAL_POWER_ERROR.
TEST=tested with rest of patch train
Change-Id: I06f64a72c82b9e03dc8af18700d24b3d10b7d3a7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Users have reported audio cutting in and out when playing through the
speakers on bonw15 and oryp11. This issue originally only affected
serw13 and was fixed before upstreaming. Apply the updated HDA verb
provided by Clevo to fix speaker output on these units as well.
Change-Id: I105bf165227456593863faa9bb8c4f152e49796b
Signed-off-by: Levi Portenier <levi@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Tested-by: Daniel Sutton <daniel@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78511
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Some Type-C monitors do not immediately assert HPD. If we enter FSP-S
before HDP is asserted, display initialisation may fail. So wait for
HPD.
This is similar to commit b40c600914 ("mainboard/hatch: Fix puff DP
output on cold boots") on puff, except we don't use
google_chromeec_wait_for_displayport() since that EC command was removed
for TCPMv2 (https://crrev.com/c/4221975). Instead we use the HPD signals
only. By waiting for any HPD signal (Type-C or HDMI), we skip waiting if
HDMI is connected, which is the same behaviour as puff and fizz.
BUG=b:303533815
BRANCH=dedede
TEST=On dexi, connect a display via a Type-C to HDMI dongle and check
the dev and recovery screens are now displayed correctly. Also check the
logs in the following cases:
Cold reboot in dev mode, Type-C to HDMI dongle:
HPD ready after 800 ms
Warm reboot in dev mode, Type-C to HDMI dongle:
HPD ready after 0 ms
Cold/warm reboot in dev mode, direct Type-C:
HPD ready after 0 ms
Cold/warm reboot in dev mode, direct HDMI:
HPD ready after 0 ms
Cold/warm reboot in dev mode, no display:
HPD not ready after 3000 ms. Abort.
Change-Id: Ib4fc071cac98a542072ffbeb6943bff4c988554c
Signed-off-by: Kenneth Chan <kenneth.chan@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78450
Reviewed-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
Reviewed-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After commit e12b313844 ("drivers/pc80/rtc/option.c: Allow CMOS
defaults to extend to bank 1"), Thinkpad X200 with
CONFIG(STATIC_OPTION_TABLE) can no longer resume from s3 (detected via
bisect).
Further inspection shows that DRAM training result of GM45 is stored
in CMOS above 128 bytes in raminit_read_write_training.c, for s3 resume
to restore, but it will be erased by sanitize_cmos(), which now clears
both bank 0 and bank 1, leaving only "untrained" result restored, so s3
resume will fail.
However, resetting CMOS seems unnecessary during s3 resume. Now,
cmos_need_reset will be negated when acpi_is_wakeup_s3() returns true.
Tested: Thinkpad X200 with CONFIG(STATIC_OPTION_TABLE) can resume from
s3 again with these changes.
Change-Id: I533e83f3b95f327b0e24f4d750f8812325b7770b
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78288
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clevo had apparently swapped the Realtek card reader for the O2 Micro
card reader for newer batches of all TGL models. Enable the BayHub
driver on everything (except bonw15, which doesn't have a card reader)
to fix LTR programming, as was done for other in commit 3d7a5bdf58
("mb/system76: Enable DRIVERS_GENERIC_BAYHUB_LV2 to fix LTR issue").
Tested on system76/galp5: CPU reaches C-states deeper than C2 when idle.
Change-Id: I3667e08acd23c12638159a2f7d2592737a34e63d
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78298
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Update Goodix touchpad HID to GDIX0000 for GXTP7288 and GXTP7863.
BUG=b:305118852
BRANCH=firmware-dedede-13606.B
TEST=Build and touchpads are workable
# evtest for GXTP7863
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: Lid Switch
/dev/input/event1: Power Button
/dev/input/event2: AT Translated Set 2 keyboard
/dev/input/event3: cros_ec_buttons
/dev/input/event4: Elan Touchscreen
/dev/input/event5: GDIX0000:00 27C6:0D51 Mouse
/dev/input/event6: GDIX0000:00 27C6:0D51 Touchpad
# evtest for GXTP7288
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: Lid Switch
/dev/input/event1: Power Button
/dev/input/event10: GDIX0000:00 27C6:01F5 Touchpad
/dev/input/event11: sof-da7219max98360a Headset Jack
/dev/input/event12: sof-da7219max98360a HDMI/DP,pcm=2
/dev/input/event13: sof-da7219max98360a HDMI/DP,pcm=3
/dev/input/event14: sof-da7219max98360a HDMI/DP,pcm=4
/dev/input/event2: AT Translated Set 2 keyboard
/dev/input/event3: cros_ec_buttons
/dev/input/event4: ELAN900C:00 04F3:2E5D
/dev/input/event5: ELAN900C:00 04F3:2E5D UNKNOWN
/dev/input/event6: ELAN900C:00 04F3:2E5D UNKNOWN
/dev/input/event7: ELAN900C:00 04F3:2E5D Stylus
/dev/input/event8: ELAN900C:00 04F3:2E5D Stylus
/dev/input/event9: GDIX0000:00 27C6:01F5 Mouse
Change-Id: Id2a6223bdbb2f0693149136baa853ca2efb57815
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.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>
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>
Meteor Lake TME bits [42-45] are reserved regardless of if the part
supports TME or not.
On a device with TME fused off, we noticed some reboot hangs which
have been narrowed down to internal IP routing issues when the IA
accesses the Input Output Manager (IOM) which is mapped at
0x3fff0aa0000 (0x3ff upper 32 bits).
It turns out since TME is fused off, coreboot uses the full physical
address size reported by CPUID MAXPHYADDR (46 bits). Therefore, it
allocates thunderbolt memory range on 46 bits (0x3fff upper 32 bits).
Since 4 of these bits are actually reserved, it seems that this
address range is "stripped down" to 42 bits (=> 0x3ff upper 32 bits)
resulting in potential conflict with other devices such as IOM.
BUG=b:288978352
TEST=No reboot issue on rex with TME fused off
Change-Id: I96ba23ab304257003c0413243d3ac8129ce31743
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78452
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According the Intel Software Developer Manual,
CPUID.80000008H:EAX[15:8] reports the physical-address width supported
by the processor. Unfortunately, it does not necessarily reflect the
physical-address space the system can actulally use as some of those
bits can be reserved for internal hardware use.
It is critical for coreboot to know the actual physical address size.
Overestimating this size can lead to device resource overlaps due to
the hardware ignoring upper reserved bits. On rex for instance, it
creates some reboot hangs due to an overlap between thunderbolt and
Input Output Manager (IOM) address space.
As some SoCs, such as Meteor Lake, have physical address reserved bits
which cannot be probed at runtime, this commit introduces
`CPU_INTEL_COMMON_RESERVED_PHYS_ADDR_BITS' Kconfig to set the number
of physical address reserved bits at compilation time for those SoCs.
A runtime detection by hardware probing will be attempted if the value
is 0 (default).
BUG=b:288978352
Change-Id: I8748fa3e5bdfd339e973d562c5a201d5616f813e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78451
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `RAMSTAGE_CBFS_CACHE_SIZE' Kconfig to
set a ramstage CBFS cache size. A cache size of zero disables the
CBFS cache feature. The default size is 16 KB which seems a
reasonable minimal value large enough to satisfy basic needs such as
the decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
To support S3 suspend/resume use-case, the CBFS cache memory cannot be
released to the operating system. There are two options to meet this
requirement:
1. Define a static CBFS cache buffer (located in the .bss section)
2. Create a new CBMEM entry
Option #2 seems more powerful but considering that:
1. The CBFS cache is actually not a cache but just a scratch pad
designed to be isolated between stages
2. postcar is a very short stage not really needing CBFS cache
3. The static initialization of the `cbfs_cache' global
variable (cf. src/lib/cbfs.c) offers a simple and robust design
=> It is simpler to use a static buffer and limit the support to
ramstage.
Since some AMD SoCs (cf. `SOC_AMD_COMMON_BLOCK_NONCAR' Kconfig) define
a `_cbfs_cache' region, an extra `POSTRAM_CBFS_CACHE_IN_BSS' Kconfig
must be set to enable the use of a static buffer as the CBFS cache
scratchpad.
TEST=Decompression of vbt.bin in ramstage on rex using cbfs_map()
Change-Id: I7fbb1b51cda9f84842992e365b16c5ced1010b89
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77885
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `PRERAM_CBFS_CACHE_SIZE' Kconfig to set
the pre-memory stages CBFS cache size. A cache size of zero disables
the CBFS cache feature. The default value is 16 KB which seems a
reasonable minimal value enough to satisfy basic needs such as the
decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
We have set this size to zero for all the platforms without enough
space in Cache-As-RAM to accommodate the default size.
TEST=Decompression of vbt.bin in romstage on rex using cbfs_map()
Change-Id: Iee493f9947fddcc57576f04c3d6a2d58c7368e09
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The linker can make relocation entries of a symbol which has a value
of zero point to the undefined symbol entry. It is permitted since
when the symbol value is zero as the documentation of the relocation
entry `r_info' field states:
"If the index is STN_UNDEF, the undefined symbol index, the relocation
uses 0 as the symbol value."
The ELF binary does not really have any missing symbols. It is an
optimization as the symbol points to the undefined symbol because its
value is zero.
A typical way to hit this cbfstool limitation is to define an empty
region using the REGION macro in the linker script. Here is an
example if we assume `CONFIG_MY_REGION' is set to 0:
.car.data {
[...]
REGION(my_region, CONFIG_MY_REGION_SIZE)
[...]
}
A region is defined as follow:
#define REGION_SIZE(name) ((size_t)_##name##_size)
#define DECLARE_REGION(name) \
extern u8 _##name[]; \
extern u8 _e##name[]; \
extern u8 _##name##_size[];
So the size of the region is actually the address of the
`_##name##_size' symbol. Therefore, the `_my_region_size' symbol
address is zero and the linker can make the relocation entry of this
symbol point to the undefined symbol index.
In such a situation, cbfstool hits a segmentation fault when it
attempts to relocate the symbol in `parse_elf_to_xip_stage()'
function. We resolves this issue by making cbfstool skips relocation
entries pointing to the undefined symbol similarly to the way it skips
relocation relative to absolute symbols. A symbol which value is zero
can be considered an absolute symbol and therefore should not be
relocated.
Of course, we could argue that we could just prevent the declaration
of an empty region as illustrated in the following example:
.car.data {
[...]
#if CONFIG_MY_REGION_SIZE > 0
REGION(my_region, CONFIG_MY_REGION_SIZE)
#endif
[...]
}
However, this is not a satisfying solution because:
1. It requires to add unnecessary code in the linker script as an empty
region is a valid declaration. Such a workaround requires the code
using it to mark the region symbols as weak symbols to handle the
situation where the region is not defined.
2. There could be other situations which have yet to be uncovered which
would lead the same cbfstool crash.
3. A binary with an empty region is a valid ELF file and cbfstool
should not crash when it is asked to create an eXecute-In-Place stage
out of it.
Change-Id: I2803fd3e96e7ff7a0b22d72d50bfbce7acaeb941
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Update SaGv gears and frequency values as per recommendation
from power and performance team. This change doesn't cause
negative impact on firmware boot time performance.
BUG=b:274137879
TEST=Verified the settings on google/rex using debug FSP logs.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: Ie8a81c05f25b1cdab1008d09c606d1debea6e6e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78268
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Crypto Engine in PSP prefers the buffer from Static RAM (SRAM). Hence if
a buffer comes from within SRAM address range, then it is passed
directly to Crypto Engine. Otherwise a bounce bufer from the stack is
used. But on SoCs like Picasso where PSP Verstage stack is mapped to a
virtual address space this check fails causing a bounce buffer to be
used and hence a stack overflow. Fix this issue by assuming that the
buffer comes from the SRAM always in such SoCs and pass the buffer
directly to crypto engine.
BUG=b:259649666
TEST=Build and boot to OS in Dalboz with unsigned PSP verstage.
Change-Id: I2161c8f0720c770efa5c05aece9584c3cbe7712a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78426
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The Bayhub BH720 eMMC bridge is a fixed internal device, and needs to
me marked as non-removable in order for Windows to properly recognize/
utilize the device. Add the necessary ACPI to be generated at runtime.
TEST=build/boot/install Win11 on google/kahlee (liara)
Change-Id: I0815abf1d2dc5cfe785dc04670ab91f2a6a1af23
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
AMD Audio CoProcessor handles I2S audio on AMD SoC's. Prior to AMD
Ryzen platforms (e.g. STONEY) it is located on the Integrated GFX
device. As the proprietary AMD driver does not support accessing this
easily, reserve a custom ACPI ID from the coreboot namespace so that
another driver can be attached in Windows device manager.
Change-Id: I855b81908ed9ad0587b6367b052c726c36350208
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This Kconfig option is used as a failback when `get_uint_option`
fails. It will fail after coreboot is flashed, as the cfr code has
not yet setup the options.
Change the default to OFF, so when it does fallback, it's the correct
behaviour.
Change-Id: I5d06047fe23322520e9c84ded8f1941f6d716a51
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78223
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This adds support for the Librem 11 tablet, using the ME 13.50.15.1436
binary from the original BIOS (version 28.D8.E1.021) and FSP binaries
from a Jasper Lake Chromebook.
The following features were tested with PureOS:
* Audio (speakers, microphone, headset jack)
* Cameras
* Display
* Touchscreen and pen
* Keyboard cover, with tablet/laptop mode switch indicated via ACPI
* Power and volume buttons
* USB-C ports (USB 2/3, DP alt mode, PD charging)
* SD card reader
* WLAN
* Bluetooth
* NVMe SSD (socketed)
* Battery state information from EC
* Accelerometer
A UART is accessible with soldering via test points on the mainboard,
documented in the mainboard Kconfig with a toggle to enable it for
coreboot logging.
Change-Id: I545994889ddfb41f56de09b3a42840bccbd7c4aa
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The next board revision of Librem 14 (v1-02) has replaced the ALC256
codec with ALC269. Add verbs for it.
Two GPIOs were changed from SMBus native functions to NC for this
revision. They are not used on either revision, change to NC.
Change-Id: I43b6265d2f502c05d5539ff3abf53ade0da6d706
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78347
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
New Librem 14s have a newer CPU stepping, which changes them from CML
v1 to v2. The product is not significantly different and remains v1,
specifically "v1-02".
Select SOC_INTEL_COMETLAKE_1_2 to support all CPU steppings.
Change-Id: Iab37208b81e973714a2c088d2346eda518bf1214
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Define SOC_INTEL_COMETLAKE_1_2, which creates a build supporting both
Comet Lake v1 and v2 by including both sets of FSP binaries and
selecting one based on the CPUID.
A mainboard can select this instead of SOC_INTEL_COMETLAKE_1 or ..._2
to support all CML-U steppings in one build.
Change-Id: Ic8bf444560fd6b57064c47faf038643fabde010e
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78345
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Support embedding a second FSP-M/FSP-S binary for an SoC that can
select one at runtime.
Comet Lake v1 and v2 are different steppings of the same SKUs, but they
require different FSP binaries. Supporting both in a single build
requires embedding both FSPs and selecting one at runtime based on the
CPUID. This is desirable for a product that may have different CPU
steppings but is not otherwise differentiated enough for a separate
firmware build.
An SoC can select PLATFORM_USES_SECOND_FSP to indicate that two FSP-M/
FSP-S binaries are required. Implement soc_select_fsp_m_cbfs() and
soc_select_fsp_s_cbfs() to choose one based on platform-specific
criteria. For Comet Lake, the first FSP is CML v1 and the second is
CML v2, but in principle a platform could define any meaning for the
first and second FSP.
FSP-T is not affected, only one FSP-T can be embedded if FSP_CAR is
used.
Only one set of FSP headers is used, which is sufficient for Comet Lake
v1/v2; their headers are equivalent.
ADD_FSP_BINARIES, FSP_USE_REPO, and FSP_FULL_FD are supported for both
sets of FSP-S/FSP-M but cannot be configured separately, both use the
same configuration.
Change-Id: Ied4c6c49a6bdf278238272edd47a2006258be8e5
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78344
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Within TBT PCIe, following register offsets have been updated for
production silicon. Update ASL with new offsets.
1. MPC - Miscellaneous Port Configuration Register
2. RPPGEN - Root Port Power Gating Enable
3. SMSCS - SMI/SCI Status Register
BUG=306026121
TEST= Check TBT PCIe Tunnel creation and device enumration.
Change-Id: I0497f7108ef5046c2694aece232263582514a0c5
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78163
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Commit bd9c562a9e ("acpi: Configure
slp-s0 residency counter frequency in LPIT table") led to jenkins
reporting the following error:
!!!!! Error: defined(CONFIG_ACPI_SOC_INTEL_SLP_S0_FREQ_HZ)
used at src/include/acpi/acpi.h:457. Symbols of type 'hex'
are always defined.
Since hex Kconfig are always defined there is no need to test it being
defined but also no need to handle zero or non-zero values.
In addition:
1. This config was defined in Meteor Lake specific Kconfig file while
it should actually be define closer to where it is being used (here
soc/intel/common/block/acpi/Kconfig) and only set by the SoC Kconfig.
2. Once moved and under control of `SOC_INTEL_COMMON_BLOCK_ACPI_LPIT'
gating (lpit.c), the Kconfig name needed to be adjusted to better fit
its use.
3. Make Meteor Lake Kconfig sets the config but does not define it
anymore.
TEST=LPIT ACPI table Counter Frequency field is set to 0x2005 on rex
Change-Id: I2083c9209e61be6180cca2c9f74097e2f4b4ce9a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78458
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The microcode for RPL-S C0 and H0 is actually available, however, the
name of the file contained a typo: 06-b7-05 vs 06-bf-05. Fix the typos
in the comments.
Moreover, the ADL-S C0/H0 microcode file 06-97-05 has the same sha256
sum as the equivalent RPL-S C0/H0 microcode file 06-bf-05. The sha256
sum of ADL-S/RPL-S C0/H0 microcode on intel-microcode tag
microcode-20230808:
5d8d4a4d5456c43b7cc04937c80aec094ccbf3bd89f34ffa5182913ef944a9f9
Update the comments to correctly indicate supported CPU steppings.
Change-Id: I4c848e0dfc40f6c8e26a9b31e7c4cf4c5a09128f
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78413
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SCI handler for the GPE associated with the Super I/O did not clear
the respective PME status bits resulting in the SCI reoccurring
endlessly. The /proc/interrupts reported millions of ACPI interrupts
generated in just a few minutes of uptime. The flood of interrupts
caused some units to be unusable in extreme cases once attempted to
boot Qubes OS for example. On systems like Qubes OS it had a huge
impact on performance due to many IPCs the SCIs caused under Xen.
Clear the PME bits of devices that report a PME event. Then clear
the global PME status bit at the end of SCI handler to prevent the SCI
from asserting again until a new event occurrs. With this change
the number of ACPI interrupts generated in the first minutes of uptime
settles at a few thousands.
TEST=Boot Qubes OS R4.1.2 on Dell OptiPlex 9010 SFF and check
/proc/interrupts in dom0 if the number of ACPI interrupts is only
a few thousands.
Change-Id: I64e03d268138a62b46084be41343ef7fb089dfc3
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Package C-state auto demotion feature allows hardware to determine lower
C-state as per platform policy. Since platform sets performance policy
to balanced from hardware, auto demotion can be disabled without
performance impact.
Also, disabling this feature results soc to enter below PC8 state and
additional power savings ~30mW in Local-Video-Playback scenario.
Change-Id: I6ff408280178a24686180f72f79522d2741607a1
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78278
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel platforms use Low Power Idle Table (LPIT) to enumerate platform
Low Power Idle states. There are two types of low power residencies
a) CPU PKG C10 - read via MSR (Function fixed hardware interface)
b) Platform Controller Hub (PCH) SLP_S0 - read via memory mapped
Ref. https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
System sleep time (SLP_S0 signal asserted) is measured in ticks,
varies in every platform and based on PMC clock.
BUG=b:300440936
TEST=check kernel cpuidle sysfs for non-zero residency after s0ix cycle
and both must match
cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
Change-Id: I401dd4a09a67d81a9ea3a56cd22f1a681e2a9349
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78164
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the IGD joins the MBUS when the firmware splash
screen feature is enabled (aka BMP_LOGO config is enabled).
For ChromeOS platform, it prevents the i915 driver from reinitializing
the display, which can save up to 75ms-80ms of boot time and eliminate
a brief period of blank screen between the firmware splash screen and
the OS login prompt.
BUG=b:284799726
TEST=Able to build and boot google/rex.
Change-Id: I36af167afa902053a987602d494a8830ad9b1b1a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This patch implements `.final` hooks for the IGD device to perform the
required operations before handing the control to the payload or OS.
The MBUS (Memory Bus) is a high-speed interface that connects the
graphics controller to the system memory. It provides a dedicated data
path for graphics data, which helps to improve graphics performance.
The MBUS is a key technology that helps to make the Intel i915 driver
powerful and versatile graphics drivers available. It provides the
high-speed data transfer capabilities that are essential for smooth
and responsive graphics performance.
Enable this config to ensure that the Intel GFX controller joins the
MBUS before the i915 driver is loaded. This is necessary to prevent
the i915 driver from re-initializing the display if the firmware has
already initialized it. Without this config, the i915 driver will
initialize the display to bring up the login screen although the
firmware has initialized the display using the GFX MMIO registers and
framebuffer.
Kernel graphics driver can avoid redundant display init by firmware,
which can optimize boot time by ~15ms-30ms.
Ensures hashing mode is 1x4 to enable a single pipe between Pipe A or B.
Typically, internal display is on Pipe-A, so 1x4 restricts MBUS joining
to internal display alone.
BUG=b:284799726
TEST=Able to build and boot google/rex
Change-Id: I60ae76dc783383e027e66edbcdeeb535472caeb1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78385
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 9b230ae295 introduced a redefinition of the config option
`BOARD_GOOGLE_BROX`, which is already defined in Kconfig.name
accordingly and thus causing a Kconfig warning. Fix that by removing the
type redefinition.
Change-Id: Iea6219a686a23d8d48a0bfb6ac642efd482fded9
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78394
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create the anraggar variant of the nissa reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:304920262
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_ANRAGGAR
Change-Id: I95e72188679fc825c94c4043ed02b0aad310c6a3
Signed-off-by: wuweimin <wuweimin@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This script lists all new commits from users with few merged commits.
By default, it looks at the last week, and considers anyone with fewer
than 5 commits merged to be a new user.
Currently the only command line argument that's accepted is the gerrit
username of the person running the query. To modify any of the other
options, the values hard-coded into the script need to be updated.
To keep down the number of repeated queries, the script saves lists of
users considered to be experienced, as well as the commits from new
users that it lists.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic698798f3fddc77900c8c4e6f8427991bda3f2d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
This patch adds support for detecting dual displays (eDP and HDMI) on
Intel platforms. This information is useful for setting the
`lb_framebuffer.has_external_display` variable, which is used to
determine whether depthchage should avoid shutting down when an
extended display is present.
TEST= Able to build and boot google/rex, where depthchage now
successfully avoids shutting down when both eDP and HDMI displays
are attached.
w/o this patch:
with eDP and HDMI attached: .has_external_display=0
with eDP attached: .has_external_display=0
with HDMI attached: .has_external_display=1
w/ this patch:
with eDP and HDMI attached: .has_external_display = 1
with eDP attached: .has_external_display=0
with HDMI attached: .has_external_display=1
Change-Id: Ie39d48da75a21e3508a1fbcf09da31caedaa1c0a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78383
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reserve SBREG BAR if it is outside of the PCH reserved memory range.
Desktop series processors have larger SBREG BARs, which, unlike mobile
processors, do not fall into the standard PCH reserved range
(0xfc800000 - 0xfe7fffff). Create a separate reservation for such a case. There is no telling what could happen if the reservation is not
made in ACPI.
TEST=Boot Windows 11 and Ubuntu 22.04 on MSI PRO Z690-A DDR4
Change-Id: Ibaf45daba37e3acfcea0e653df69fa5c2f480c4a
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77445
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
When battery level is below critical level or battery is not present,
cpus need to run with a power optimized configuration to avoid platform
instabilities. This will check the current battery status and configure
cpu power limits properly.
BUG=b:296952944
TEST=Build rex0 and check cpu power limits are configured with
a performance efficient configuration and the platform boots to OS if
battery level is above the critical level. And check cpu power limits
are configured with a power optimized configuration and boots to OS
without an issue if battery is not present or battery level is at or
below critical level.
Change-Id: I12fd40abda76c8e7522b06a5aee72665f32ddec8
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78322
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds is_battery_present_and_above_critical_threshold to check the
battery is present and the battery level is above critical level.
BUG=b:296952944
TEST=Build rex and check is_battery_present_and_above_critical_threshold
returns the correct battery status.
Change-Id: Ib38be55bc42559bab4f12d5e8580ddc3e1a6acc1
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78321
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This CL is just getting the initial brox framework to get the
baseboard building. Copied files from brask baseboard and tried to
remove contents of some files like the device tree and memory IDs.
Added support for memory part "MT62F512M32D2DR-031 WT:B", mapped to
DRAM ID 0.
BUG=b:300690448
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_BROX -x -a
Change-Id: I929b465646ac4c69d4bab33ce23848c7b1fa0f98
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78009
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Because integrated PCI devices are hidden in chip_ops
the PCI enumeration code never sees them.
When hiding static devices mark them as hidden so the
PCI enumeration no longer complains about them being
missing, even though they are present and were working
just fine.
Test: Disabled southbridge devices no longer appear in
"Leftover static devices:" log.
Change-Id: Iae70072a85b62a456102190a5f72f4d652ad6d5a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Warn when a device took longer than usual to appear.
Use the PDS bit to detect if a root port has a downstream
device connected and warn if enumeration failed.
Test: On Lenovo X220 all PCIe device are visible, thus the
added code path is never taken.
Change-Id: I86b498b89d672b239d9951e116dc3680030666a6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78229
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Use pci_find_capability() and defines from pci_def.h
- Set the 'Hotplug Capable' bit and 'Hot Plug Surprise' bit in SLCAP
for hotplugable PCIe slots.
- Assign unique slot number and set power limit for PCIe root ports
that have a slot connected. For integrated devices clear slot number
and power limit.
Test: System still boots and all PCIe devices are working.
Change-Id: I03aeb0a1ff0041901acc20fe700d3f7995d22366
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This commit adds all the individual authors and their companies, as
determined by their email addresses. Because it is very difficult to
figure out if an individual is doing work on their own, or on the
company's behalf, both are being added.
This will be maintained as a part of the release process from here on.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id199f1c5d49d74290002d46dbdfc1d33b0fb55e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78286
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
On ICH9 the SPI control register is not naturally aligned
and a word write might be split into smaller naturally aligned
I/O transactions.
As the first byte starts a new SPI transfer, replace the existing
word write with two byte writes and write the second byte first.
This is required for platforms that do not support unaligned
word I/O instructions and would start a SPI transfer while the
second byte hasn't reached the control register yet.
TEST: Virtual SPI controller on qemu 8.0 doesn't start a transfer
early.
Change-Id: Id05b1a080911b71b94ef781c6e26d98165f02f67
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78090
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
We have a tiny HEAP_SIZE by default, except when we don't, and
mainboards that override it, or not.
Since memory isn't exactly at a premium these days, and unused heap
doesn't cost anything extra, just crank it up to the highest value
we have in the tree by default and remove all overrides.
Change-Id: I918a6c58c02496e8074e5fba06e38d9cfd691020
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78270
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Check for pkg-config presence and fail out with actionable message.
BUG=b:302521446
TEST=Build successfully with working pkg-config and failed build with no
pkg-config
Change-Id: I5d604145c919e7f71680d1e095dc68cb21868319
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Some Type-C monitors do not immediately assert HPD. If we enter FSP-S
before HDP is asserted, display initialisation may fail. So wait for
HPD.
This is similar to commit b40c600914 ("mainboard/hatch: Fix puff DP
output on cold boots") on puff, except we don't use
google_chromeec_wait_for_displayport() since that EC command was removed
for TCPMv2 (https://crrev.com/c/4221975). Instead we use the HPD signals
only. By waiting for any HPD signal (Type-C or HDMI), we skip waiting if
HDMI is connected, which is the same behaviour as puff and fizz.
TEST=On dibbi, connect a display via a Type-C to HDMI dongle and check
the dev and recovery screens are now displayed correctly. Also check the
logs in the following cases:
Cold reboot in dev mode, Type-C to HDMI dongle:
HPD ready after 800 ms
Warm reboot in dev mode, Type-C to HDMI dongle:
HPD ready after 0 ms
Cold/warm reboot in dev mode, direct Type-C:
HPD ready after 0 ms
Cold/warm reboot in dev mode, direct HDMI:
HPD ready after 0 ms
Cold/warm reboot in dev mode, no display:
HPD not ready after 3000 ms. Abort.
Change-Id: Id4657b5d5a95a68ecbd9efcf3585cf96ad1e13e1
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Internal testing showed that CPU heatsink gets hot and temperature
goes over 75C. In this situation, the fan does not even start
to lower down CPU temperature. This is because of existing temperature
thresholds of TSR0 and TSR1 sensors are set at 45C to start fan.
With updated new settings based on tuning from thermal team,
the fan starts early at 43C for TSR0 and TSR1 so the CPU temperature
stays below 75C.
BUG=b:302673874
TEST=Built and tested on google/rex board
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Change-Id: I6580652d6165946e98ecf1b46ace3352cd34dcdf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Follow the PCH BIOS spec more closely by porting the broadwell
and braswell PCIe downstream device detection. To safe power
disable PCIe root ports that have no downstream device connected.
By setting the FLAGS_SLOT bit in register PCI_EXP_FLAGS the
PCI_EXP_SLTSTA_PDS bit will be updated with in band device
detection from the PCIe PHY. While this is primarly used for PCIe
hot-plug detection, it is more reliable than probing for downstream
devices by reading DID/VID PCI registers.
The FLAGS_SLOT bit should stay cleared for integrated devices,
as those are known to be present, but to simplify the code all
PCIe ports will have the FLAGS_SLOT bit set. There currently
used devicetrees might also be lacking integrated devices on
the PCH root ports...
The SLOTCAP field must be updated by BIOS when the FLAGS_SLOT
is set, but it shouldn't be filled for integrated devices. Until
now the SLOTCAP field has always been populated and it never
was a problem.
- Set FLAGS_SLOT "Slot Implemented" bit early.
- Read bit PCI_EXP_SLTSTA_PDS to detect connected downstream
devices as done on braswell.
- Disable unused PCIe slots that are not hotplugable.
- Set BIT26 in register 0x338 and wait for bits in register 0x328
to clear as done on broadwell.
Test: Tested on Lenovo X220. Unused root ports are disabled and port
that are in used or marked hot-plug are kept enabled.
Change-Id: I8ccfcab2e0e4faba8322755a4f8c2108d9b007ac
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78226
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Dojo fails to boot from NVMe with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN
enabled. The root cause is using __fls() will get a smaller value when
the size is not a power of 2, for example, __fls(0x3000000) = 25. Hence
the PCIe translation window size is set to 0x2000000. Accessing
addresses higher than 0x2300000 will fail.
Fix translation window by splitting the MMIO space to multiple tables if
its size is not a power of 2.
Resolves: https://ticket.coreboot.org/issues/508.
TEST=Build pass and boot up to kernel successfully via SSD on Dojo
board, it can boot with and without the
CONFIG_RESOURCE_ALLOCATION_TOP_DOWN option.
BUS=b:298255933
BRANCH=cherry
Change-Id: I42b0f0bf9222d284dee0c29f1a6ed6366d6e6689
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78044
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PCH BIOS spec says that BIOS must clear BIT26 in register 0x338
in PEI, as done on lynxpoint.
Copy and adapt the lynxpoint code to do the same on bd82x6x.
Add special case for UM77 chipset, which only has 4 PCIe ports.
Test: System still boots and all PCIe ports are fully working.
Change-Id: I865818c0c22194fffcb2bbdf8c43737b0dce2307
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Commit 26d54b70e2 ("soc/amd/common/cpu: use TSC_MONOTONIC_TIMER for
SOC_AMD_COMMON_BLOCK_TSC") updated all the AMD SoCs with Zen-based CPU
cores to use TSC_MONOTONIC_TIMER. The same change adjusted the PSP
Verstage timestamps (in microseconds) to the x86 TSC rate. But it
included only the base_time during the adjustment leaving the individual
entry timestamp. This leads to incorrectly adjusted PSP Verstage
timestamps. Fix the adjustment logic.
BUG=None
TEST=Build and boot to OS in Skyrim. Ensure that the PSP Verstage
timestamps in cbmem -t output are adjusted correctly.
Before this change:
5:start of verified boot 67,890 (69,936)
503:starting to initialize TPM 67,890 (0)
504:finished TPM initialization 67,902 (12)
505:starting to verify keyblock/preamble (RSA) 67,906 (3)
506:finished verifying keyblock/preamble (RSA) 67,984 (77)
511:starting TPM PCR extend 67,984 (0)
512:finished TPM PCR extend 67,992 (7)
513:starting locking TPM 67,992 (0)
514:finished locking TPM 67,995 (3)
6:end of verified boot 67,995 (0)
11:start of bootblock 572,152 (504,156)
After this change:
5:start of verified boot 71,000 (73,040)
503:starting to initialize TPM 71,065 (65)
504:finished TPM initialization 101,506 (30,441)
505:starting to verify keyblock/preamble (RSA) 110,624 (9,118)
506:finished verifying keyblock/preamble (RSA) 297,101 (186,477)
511:starting TPM PCR extend 297,297 (196)
512:finished TPM PCR extend 315,338 (18,041)
513:starting locking TPM 315,341 (3)
514:finished locking TPM 322,922 (7,581)
6:end of verified boot 322,943 (21)
11:start of bootblock 570,296 (247,353)
Change-Id: I3e52bef22f65596152f29c511bed680427660ff5
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78231
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The original code only reserves IOM mmio, but there is other asl
code that requires to program ioe p2sb mmio such as IOE PCIE clk request
control. See \_SB.ECLK.CLKD in src/soc/intel/common/acpi/pcie_clk.asl
TEST=as before: suspend_stress_test 50 cycle pass, type-c display OK
on screebo
Change-Id: Ie55f7975277b390f776e44596c42e426ba9cd235
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78252
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Package C-state auto demotion feature allows hardware to determine lower
C-state as per platform policy. Since platform sets performance policy
to balanced from hardware, auto demotion can be disabled without
performance impact.
Also, disabling this feature results soc to enter below PC8 state and
additional power savings ~30mW in Local-Video-Playback scenario.
BUG=b:303546334
TEST=Local build successfully & Boot to OS successfully
- Also check platform enter PC8 state in local video playback
- before this change: # iotools rdmsr 0 0xE2 -> 0x0000000060008008
- After # iotools rdmsr 0 0xE2 -> 0x0000000000008008
Change-Id: Ia4cf4a7cb6bd5eaae26197b55f9385c078960d7b
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78250
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
When advertising C-state using the ACPI _CST object, make sure
to only advertise those that are supported by the CPU.
Downgrade if it's not and make sure to not advertise duplicate
states.
Add debug prints for the finally selected mapping of ACPI
C-state vs Intel CPU C-state.
Test: Tested on Lenovo X220.
All C-states are still advertised as all are supported.
Change-Id: Iaaee050e0ce3c29c12e97f5819a29f485a7946c2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78194
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
According to the BWG C-states are processor specific
and BIOS must check if a C-state is supported at all.
Print the supported C-states in before ACPI _CNT generation.
Test: Tested on Lenovo X220 using Intel i5-2540M.
All C-states are reported as supported.
Change-Id: I713712a1a104714cbf3091782e564e7e784cf21d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78133
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id ae822f2d0db7 (2023-09-21):
MDN: Restore SMU fw version 90.41.0
to commit id b1741d184add (2023-10-04):
PCO: Update SMU firmware to 4.30.77.200
This brings in 1 new commit:
b1741d184a PCO: Update SMU firmware to 4.30.77.200
BRANCH=zork
BUG=b:299603947
Change-Id: I0ce75b762bda90a5fa3bc546de42bc5d55637e17
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Intel platforms use Low Power Idle Table (LPIT) to enumerate platform
Low Power Idle states. There are two types of low power residencies
a) CPU PKG C10 - read via MSR (Function fixed hardware interface)
b) Platform Controller Hub (PCH) SLP_S0 - read via memory mapped IO
Ref. https://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf,
section 2.2.1: value of 0 indicates that counter runs at TSC frequency.
Ref. Intel 64 and IA-32 Architectures Software Developer’s Manual (Vol 4)
MSR 0x632: PC10 residency counter is at same frequency as the TSC.
Whereas slp_s0 residency counter running in different frequency.
BUG=b:300440936
TEST=check kernel cpuidle sysfs are created after kernel boot
cat /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
Change-Id: Ibde764551a21b9aecb1c269948f4823548294711
Signed-off-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This consolidates the bp, tb, cmp, srp0 and srp1 variables under the new
spi_flash_bpbits struct to allow treating them as one unit in the
refactoring to follow.
Change-Id: I2a1a77fb73047df733498c0fa8b8de1153c3b09e
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42113
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the block protection bits are being passed around as
individual arguments. We will use this new struct to replace the
corresponding arguments in the winbond_bpbits_to_region and
winbond_set_write_protection functions.
Change-Id: I02828b1f764aea29374e794001e74cdc86a94c92
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
When service center repair touchscreen or touchpad will change
compatible device not specific one, the fw_config probe mechanism is not
convenient for service center. Removing touchscreen and touchpad
fw_config probe for the purpose.
BUG=b:297840605
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: I66f12ae478f74c019c53ee5e77f7e0f9c324e758
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77538
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements an API to report the presence of an external
display on Intel silicon. The API uses information from the transcoder
and framebuffer to determine if an external display is connected.
For example, if the transcoder is attached to any DDI ports other than
DDI-A (eDP), and the framebuffer is initialized, then it is likely
that an external display is present.
This information can be used by payloads to determine whether or not
to power on the display, even if eDP is not initialized.
BUG=b:299137940
TEST=Build and boot google/rex
Scenarios:
Booting with eDP alone: has_external_display value is 0
Booting with eDP + HDMI: has_external_display value is 0
Booting with HDMI alone: has_external_display value is 1
Booting with USB-C display alone: has_external_display value is 1
Change-Id: I77436940978c7fa9368d79394b46a5e794c32e42
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78080
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This patch introduces a new coreboot table entry named
"has_external_display" to understand if external display is attached.
This information is useful to prevent graceful shutdown by payload
when the LID is closed but an external display is present.
This piece of the information will be gathered by coreboot and passed
into the payload using this new entry aka external_display because
payload (i.e., deptcharge) doesn't have any other way to determine
if external display is available.
BUG=b:299137940
TEST=Able to build and boot google/rex.
w/o this patch:
LID closed and external display attached (HDMI) in developer mode
(GBB 0x39):
> System is powered off by depthcharge
w/ this patch:
LID closed and external display attached (HDMI) in developer mode
(GBB 0x39):
> Booted to OS and device is alive/usable
Change-Id: I0fa7eee4c5a50371a7a66c6ca1ac2c7d046d010b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77796
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel GFX IP TRANS_DDI_FUNC_CTL register bit definitions have changed
since Tiger Lake.
This register is used to map ports and pipes to display controllers,
so reflecting the correct status is important for detecting physical
display end point devices.
This patch ensures that ADL, MTL, and TGL SoCs choose GMA version 2 to
properly reflect the updated port and pipe register definitions.
BUG=b:299137940
TEST=Build and boot google/rex successfully.
Change-Id: Ie2082747d18a5f136f410b1019be4d6c801617b1
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
This commit updates the port select bit definitions for the
TRANS_DDI_FUNC_CTL registers in the Intel GMA driver to accommodate
the changes introduced since TGL SoC.
Specifically, the following changes were made:
- Updated the DDI select bit definitions from 3-bits (bit 28-30) to
4-bits (bit 27-30).
- Introduces `INTEL_GMA_VERSION_2` config to accommodate the port and
pipe related differences between previous generation GMA register
(TRANS_DDI_FUNC_CTL) to the current generation GMA register.
This commit backports the change from the following upstream patch:
https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-3-lucas.demarchi@intel.com
BUG=b:299137940
TEST=Able to build and boot google/rex.
Change-Id: I815ffa90c2e235afd70baa7e3837e1f9af89b1b0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
The ACPI methods for enabling USB wake are identical on ADL, CNL and
SKL. Move them to a common ASL file so they can be reused more easily
on other SoCs.
Also move the USB_PORT_WAKE_ENABLE macro used to create enable bitmasks
in devicetree to a common header.
BUG=b:300844110
TEST=Use abuild to build kinox, puff, and fizz with and without this
change. Check the generated dsdt.aml is unchanged.
Change-Id: Iabdfe2bece7fafc284ddf04382f1bbcacc370cce
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This panel is never actually enabled on Geralt. The derived project
won't use this panel either. Therefore, remove this panel support.
BUG=none
BRANCH=none
TEST=emerge-geralt coreboot
Change-Id: I97ed5b341724ed42098b2c17d0eb75eab881dbb1
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The tolerance of ADC voltage table is too small. Update the table values
accordring to the suggestion from the hardware team. The patch is
prepared for the derived projects. There is no actual issue now.
BRANCH=none
BUG=b:301908091
TEST=check firmware screen
Change-Id: I3bde30b6bbe79c81e276f23f4110715c3278d42c
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
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>
During CSE firmware downgrade, data is cleared. To preserve PSR data
during downgrade, it needs to be backed up. Select
SOC_INTEL_CSE_LITE_PSR config to ensure PSR backup related flow is
executed on CSE Lite SKU.
BRANCH=None
BUG=b:273207144
TEST=Verify CSE firmware upgrade/downgrade on rex.
Change-Id: I39af029a5f0c018a5db3ac68191764abfa9518ac
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76115
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds eventlog entries for the below scenarios:
1. To indicate success or failure of PSR data back-up command
2. To indicate the loss of PSR data when CSE update is corrupted, and
data clear command is issued to clear the data.
3. To indicate the loss of PSR data when CSE boot partition info
response is corrupted and data back-up is not initiated.
BRANCH=None
BUG=b:273207144
TEST=Verify elog event added after PSR data backup command is sent
cse_lite: PSR_HECI_FW_DOWNGRADE_BACKUP command sent
...
ELOG: Event(B9) added with size 10 at 2023-06-27 06:44:49 UTC
Change-Id: I2459a2b941d28a87b6c78f75dbe8779d73328d7a
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Get PSR bit state using MKHI_FWCAPS_GET_FW_FEATURE_STATE HECI command
Use this bit info to check if SKU supports PSR and consequently issue
PSR_HECI_FW_DOWNGRADE_BACKUP command for PSR data backup during
downgrade.
BUG=b:273207144
TEST=build CB image and boot on google/rex board. Check for
"PSR is supported in this SKU" message in coreboot logs to confirm
that PSR bit is set in SKU
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I6e92341a9dc799146eb8f1a70b3a4a16fd1aa0ae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
During CSE FW downgrade we erase CSE data. This would result in
Platform Service Record(PSR) data also to be erased.
To avoid losing PSR data we need to make a backup before data clear.
This patch sends PSR_HECI_FW_DOWNGRADE_BACKUP HECI command to CSE,
informing the CSE to backup PSR data before a data clear operation
during downgrade.
CMOS memory is used to track the backup status. PENDING is the default
state, it is updated to DONE once PSR_HECI_FW_DOWNGRADE_BACKUP HECI
command is sent.
PSR data can be backed up only post DRAM is initialized. The idea is to
perform cse_fw_sync actions in ramstage when PSR is enabled on a
platform. As part of the cse_fw_sync actions, when a firmware downgrade
is requested the command to back-up data is sent. Once the backup has
been done, trigger the firmware downgrade.
BRANCH=None
BUG=b:273207144
TEST=build CB image for google/rex board and check PSR backup command
is being sent during a CSE FW downgrade. Also check PSR data is not
lost/erased after a downgrade using intel PSR tool.
Change-Id: I135d197b5df0a20def823fe615860b5ead4391f8
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74577
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data. Since firmware downgrade
and PSR data backup flows involve global resets, there is a need to
track the PSR data backup status across resets. So adding a CMOS
variable for the same.
This patch implements API to access PSR backup status stored in CMOS.
The get API allows to retrieve the PSR backup status from CMOS memory.
The update API allows to update the PSR backup status in CMOS.
BRANCH=None
BUG=b:273207144
TEST=Able to retrieve PSR backup status across resets.
Change-Id: I270894e3e08dd50ca88e5402b59c211d7e693d14
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
CSE firmware downgrade and PSR data backup flows involve global resets,
there is a need to track the PSR data backup status across resets. In
the subsequent patches, a CMOS structure to store PSR back-up status
will be added.
The current SOC_INTEL_CSE_FW_PARTITION_CMOS_OFFSET of 68 can only store
cse_specific_info, as ramtop is at offset 100 and PSR back-up status
structure will not be able to fit within the range.
This patch overrides the SOC_INTEL_CSE_FW_PARTITION_CMOS_OFFSET to 161
to accommodate all CSE related info in adjacent CMOS memory.
BUG=b:273207144
TEST=Verify CSE RW FW versions are stored in CMOS memory in rex.
Change-Id: I8bae5245f93b99be15b4e59cfeffbc23eec95001
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78054
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Platform Service Record(PSR) will be enabled on Meteor Lake
platforms. cse_fw_sync actions happen in ramstage when PSR is enabled.
To avoid the boot time penalty of sending the cse_get_bp_info in
ramstage, call cse_fill_bp_info to get cse_bp_info response early in
romstage and store in cbmem. This data can be later used in ramstage.
BUG=b:273207144
TEST=Verify cse_bp_info is filled in romstage in rex.
Change-Id: Ic0e8fb34f21ff07e182a7b848d38e9d329010028
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78056
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data, and this command can be
sent only in post-RAM stages. So the cse_fw_sync actions needs to be
moved to ramstage.
Sending cse_get_bp_info command in ramstage takes additional boot time
of ~45-55ms on rex. To avoid the boot time penalty, this patch provides
an API to get the cse_bp_info in early romstage. The response data is
then migrated to cbmem once memory is initialized. The same data in
cbmem can be utilized in ramstage to perform other cse_fw_sync actions.
This patch also adds check to validate cse_bp_info in cbmem and avoids
sending the command again if the data is valid.
BUG=b:273207144
TEST=Verify the command works in early romstage, data is migrated to
cbmem and valid data is available in ramstage on rex.
Change-Id: Ib1e72c950ba0f4911924805f501ec1bd54b6ba3c
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78053
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since commit 9b186e0ffe ("util/xcompile: Add NASM to xcompile") NASM
from the coreboot toolchain is properly hooked up to the build system.
So it's not needed to install the distro package. Remove it.
Change-Id: I2ab0317531e25ae6d5baa8be8ac4d41dc145658f
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77728
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Now that Intel has publicly released FSP headers/binaries for
RaptorLake-P/S client platforms, set the defaults accordingly if
FSP_USE_REPO is not selected. This does not change any existing
defaults as the RaptorLake headers in vendorcode are only used when
FSP_USE_REPO is not set.
TEST=build/boot google/brya (osiris)
Change-Id: Ida92d269fcaf6f323599ec174f4dcedbbe65f03c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78190
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
During suspend, the ISH I2C transactions cannot go through
because the GPIO pads remain the pervious value.
The IO Standby State (IOSSTATE) needs to be changed to keep I2C bus
active and functional during suspend.
BUG=b:302612549
TEST=on Google/rex platform with ISH enabled, do suspend_stress_test
and check that no i2c failure.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I9a2c902ed56461f3a535428db399c2050756f2da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78179
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Li1 Feng <li1.feng@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set default to enabled for hibernate on setup failure for all devices
using a Google EC. This will have no impact on devices that don't
bring the GSC down on hibernate, but will provide a recovery path
for all devices that do.
BUG=b:296439237
TEST=Force error on Skyrim with custom build, boot normally with
normal build
Change-Id: I2d9e8f75b25fb6c530a333024c342bea871eb85d
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78098
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Separate these so a mainboard can describe a PS/2 keyboard without a
PS/2 mouse or vice-versa.
Librem 11 has a PS/2 keyboard for the volume keys, but does not have a
PS/2 mouse, and the presence of a mouse device can cause the cursor to
appear on the desktop incorrectly.
ps2_controller.asl remains since many boards include it, it now just
includes the two new files.
Change-Id: I13a4c2caf8dc9e5004b775dc0a9ac2488e39f184
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78096
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of having the get_usable_physical_address_bits function that
only got used in the data fabric domain resource reporting code, drop
this function, select RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT in the
common AMD non-CAR CPU and rename get_sme_reserved_address_bits to
get_reserved_phys_addr_bits so that the common cpu_phys_address_size
function will return the correct number of usable physical address bits
which now can be used everywhere. The common AMD CAR CPU support is only
selected by Stoneyridge which doesn't support secure memory encryption,
so RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT isn't selected by the
SOC_AMD_COMMON_BLOCK_CAR Kconfig option.
Before only the MMIO region reporting took the reserved physical address
bits into account, but now also the MTRR calculation will take those
reserved bits into account. See the AMD64 Programmers Manual volume 2
(document number 24593) for details. Chapter 7.10.5 from revision 3.41
of this document was used as a reference. The MTRR handling code in
older Linux kernels complains when the upper reserved bits in the MTRR
mask weren't set, but sets them after complaining and then continues to
boot. This issue is no longer present in version 6.5 of the Linux
kernel.
The calculation of the TSEG mask however still needs to take all
physical bits into account, including the ones reserved for the memory
encryption. When not setting the reserved bits in the TSEG mask, the
Mandolin board with a Picasso APU won't boot to the OS any more due to
not returning from SeaBIOS calling into the VBIOS. Haven't root-caused
what exactly causes this breakage, but I think previously when something
else was wrong with the SMM initialization, also something went wrong
when calling into the VBIOS.
TEST=Ubuntu 2023.10 nightly build boots on Mandolin via SeaBIOS and EDK2
and Windows 10 boots on it via EDK2.
TEST=On Ubuntu 2022.04 LTS, the kernel complained with the following
warning, but it still continues the boot process as described above:
mtrr: your BIOS has configured an incorrect mask, fixing it.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iad65144006f1116cd82efc3c94e1d6d1ccb31b6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
In the cpuid helper functions eax is always written to
by the cpuid instruction, so add it to the output clobbered list.
This prevents GCC from generating code with undefined behaviour
when the function is inlined.
Test: Verified that the generated assembly is sane and runtime
tests showed no "strange" behaviour when calling cpuid
functions.
Change-Id: I5dc0bb620184a355716b9c8d4206d55554b41ab9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78192
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Updating from commit id a72794810884 (2023-09-07):
IoT ADL-N MR1 (4172_00)
to commit id 481ea7cf0bae (2023-09-19):
Move to RaptorLakeFspBinPkg.dec
This brings in 9 new commits:
481ea7cf0b Move to RaptorLakeFspBinPkg.dec
55e25b819e Raptor Lake FSP C.1.BD.40
2b0aac4f64 Raptor Lake FSP C.0.BD.40
3fa75657aa Add Client Raptor Lake FSP
8d24189361 Add Alder Lake and Raptor Lake to README.md
98f4a1fe2f Rename to AlderlakeSiliconPkg
c78a6784cb Add FvLateSilicon for Alder Lake
849ce8261b Tiger Lake FSP A.0.7E.70
4b0b1eb4e3 Update SplitFspBin.py to latest from edk2
Change-Id: I8a724bf0a03cba5a9689894e1aec0a81a5bf2c94
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78189
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Configure the SCP to operate within domain 8, allowing it to access
only the necessary registers. Any unauthorized access will be prevented
by the DAPC.
- Set SCP domain from domain 0 to domain 8.
- Lock register settings down to prevent unexpected modification.
BUG=b:270657858
TEST=scp bootup successful with dapc settings
Change-Id: I049486c997542d91bd468e0f4662eafbca4c17e0
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77883
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Currently, all the masters controlled by DAPC are in domain 0. With
this setting, there is a potential security problem. For example, if a
certain master is somehow hacked, it may attempt to access registers
that it is not supposed to, with successful results. This is due to the
fact that, in the current setting, all masters are in domain 0 and can
access almost all registers. To prevent this problem, we assign masters
to different domains and restrict access to registers based on each
domain.
This patch sets domains for masters:
SSPM - domain 3
CPUEB - domain 14
PCIE0 - domain 2
SPM - domain 9
Change-Id: Ie3e1d5055e72824257b66d6257982652eeb05953
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77862
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, all the masters controlled by DAPC are in domain 0. With
this setting, there is a potential security problem. For example, if a
certain master is somehow hacked, it may attempt to access registers
that it is not supposed to, with successful results. This is due to the
fact that, in the current setting, all masters are in domain 0 and can
access almost all registers. To prevent this problem, we assign masters
to different domains and restrict access to registers based on each
domain.
This patch updates the permission settings for domains 2, 3, 4, 5, 7,
8, 9, and 14, as these domains will be assigned masters in the upcoming
patch.
BUG=b:270657858
TEST=build pass
Change-Id: I6e95ddb5d84a09ff865d7615596430e25b69d3fc
Signed-off-by: Nina Wu <nina-cm.wu@mediatek.com>
Signed-off-by: Jason Chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77861
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Since also some AMD CPUs have reserved physical address bits that can't
be used as normal address bits, introduce the
RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT Kconfig option which gets
selected by CPU_INTEL_COMMON, and use the new common option to configure
if the specific SoC/CPU code implements get_reserved_phys_addr_bits or
if the default of this returning 0 is used instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0059e63a160e60ddee280635bba72d363deca7f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Update the default branch used for MrChromebox's edk2 fork from 2023-06
to 2023-09. This updated branch has been rebased on the latest upstream
stable tag (edk2-stable202308), and fixes some USB detection issues, as
well the coreboot Kconfig for prefering internal or external boot
devices.
TEST=build/boot google boards link, panther, lulu,reef, ampton, akemi,
banshee, zork, frostflow with edk2 payload selected.
Change-Id: I7c5f9ae1ca4edd8211f55f4ecf2b3b495f473a43
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78136
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Disabling TPM support in edk2 can actually cause problems booting from
USB on some Intel-based boards with a CR50 TPM when using the edk2
GOP driver option, so rather than disable the TPM for all CR50 boards,
restrict the default to only AMD boards, where the boot hang with
TPM enabled was originally observed.
TEST=build/boot Win11, Linux from usb on google/fizz when built
with edk2 payload and edk2 GOP driver option selected.
Change-Id: I01509fea2dd42b741c00abcf9fb8b936e895b932
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78031
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
ASPM on the WLAN PCIe bus introduces large latency spikes, which can be
measured with cyclictest:
$ cyclictest --policy=rr --priority=12 --interval=10000 --threads=1 --loops=6000
Disabling ASPM for WLAN reduces the latency spikes from 2,500-3,000 usec
down to 35-65 usec. These latency spikes can impact the user when
real-time processes like Audio (cras) are starved of CPU time, leading
to buffer underruns resulting in crackling/distorted audio.
ASPM is already disabled for Nipperkin devices (CB:63537), so this CL
disables it for both in the shared declaration of
guybrush_czn_dxio_descriptors.
Power impact for Dewatt:
* ASPM enabled
power_VideoCall.FDO_25min_webrtc
w_energy_rate 7.425043688811071
power_Idle.default20min
wh_energy_used 1.4164200000000022
* ASPM disabled
power_VideoCall.FDO_25min_webrtc
w_energy_rate 8.779998551703423
power_Idle.default20min
wh_energy_used 1.4860800000000012
When using Google Meet over WiFi, power increases by ~1.5W.
BUG=b:297970318
TEST=cyclictest --policy=rr --priority=12 --interval=10000 --threads=1 --loops=6000
Change-Id: I16940987d598943bd5d6ace8b4008eba4d4a177c
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77963
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Implement support for elan i2c touchscreen and use fw_config
to pick between i2c or HID-over-i2c touchscreen.
Support G2 TS have different slave address by fw_config
BUG=b:295272539
BRANCH=firmware-nissa-15217.B
TEST=build and verified touchscreen work
Change-Id: I5e3f85106606d84e1cfa204e62b7b2662db6546b
Signed-off-by: Shon Wang <shon.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Revise the Makefile.inc rules for generating FMD parser files.
- lex: If --header-file is supported then the lex (usually flex) should
also support '-o' so we don't need to do redirection (-t).
- yacc: Bison is already required by bincfg and sconfig so we
can change the default parser compiler to Bison. That also
allows us to use -o and --defines to override the output files.
- both: Line directives are only helpful when debugging the scanner and
the parser, so we should remove them to get better git diff
results (-L for lex, -l for bison).
Also regenerated the shipped files with latest version of flex (2.6.4)
and bison (3.8.2).
Change-Id: I15b58ff65dcd9f3f3a6095aa004091ff733ffec3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75851
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. The PSR data
needs to be preserved across the firmware downgrade flow. CSE Lite SKU
firmware supports command to backup PSR data, and this command can be
sent only in post-RAM stages. So the cse_fw_sync actions needs to be
moved to ramstage.
This patch ensures SOC_INTEL_CSE_LITE_SYNC_IN_RAMSTAGE is selected when
PSR is enabled.
BUG=b:273207144
Change-Id: I7c9bf8b8606cf68ec798ff35129e92cd60bbb137
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78055
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable hibernate on TPM setup error for Skyrim devices.
BUG=b:296439237
TEST=Force the error by hard coding the return code and observe the
device entering hibernate.
BRANCH=None
Change-Id: Ibf96b830f07dac98035d3152c8ec220685a912bc
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77668
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configure PL1 and PL2 are configured for powerformance.
Based on values from Intel Meteor Lake UH Power Map document ID:640982
BUG=b:286834207
TEST=Build and boot google/ovis and check ACPI SSDT for DPTF entries
Change-Id: Ia40884b3abd1417dea6ad291de4845762ee01966
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77623
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch selects LZ4 decompression for logo CBFS file. Able to save
2ms of the boot time when HAVE_FSP_LOGO_SUPPORT config is enabled.
However, the compressed BMP logo size is increased by ~2KB.
Raw BMP Image size is ~97KB.
BUG=b:284799726
TEST=Able to see pre-boot splash screen while booting google/redrix
with 32MB (W25Q256JWEIM) SPI-Flash.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I98e2c9a4f77d0b91f84eda9aec5060b236bd5e94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78121
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Updating from commit id c6e5fba929ef (2023-09-02):
MDN: Update ABL to version WABLMDN3516B01A
to commit id ae822f2d0db7 (2023-09-21):
MDN: Restore SMU fw version 90.41.0
This brings in 3 new commits:
ae822f2d0d MDN: Restore SMU fw version 90.41.0
d4f752a6fa MDN: Restore MP2 fw version 0A.0D.00.06
7b7b04723b CZN: Update VBIOS to version 021
BUG=b:301109173
BRANCH=none
Change-Id: I02b39ea94a23f7c25533347f06cd8488711c37cd
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78140
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Jasper Lake was missing these bases, so attempting to enable an SCI
would poke unrelated registers starting from offset 0. Set them so
GPEs can be enabled.
GPE is used on the Librem 11 for the keyboard dock connector, its sense
signal on GPP_D4 raises a GPE which is used to indicate tablet/laptop
mode to the OS.
The register offsets are documented in the datasheet volume 2 (Intel
document 634545), all groups' GPE_STS/GPE_EN start at the same offsets.
Change-Id: Ib6b9b9a79e9cc4467e609eaf591ec4e87b78d617
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78097
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Don't skip checking out the specified edk2 branch if the repo contains
untracked files, which may be the case if the EDK2_GOP_DRIVER option
is selected. Also ensure the submodule pointers are correct when
checking out.
TEST=build google/panther with GOP driver option and edk2 payload 2x,
switching branches between builds and ensure the correct branch is
used each time and submodules are synced with branch.
Change-Id: If7040bd5c49209b37a4b308485bf59352197d3b6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78030
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Several of the build commands passed by the Makefile only exist
in MrChromebox's fork of edk2. Guard these, and the corresponding
Kconfig options, against the selection of the MrChromebox repository.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I41d8d54e5b91990dd9fb88967fcd549a86cf6fe9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78036
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The mapped windows is up to 16M. Even if the flash size is 32MB, it is
not mapped at 0xFE000000.
So using "0xFFFFFFFF - rom_size + 1" to get the "rom_base_address" can
only explain well when rom_size is less or equal to 16MB. For larger
size, it is not physically correct (Even though it can get expected
result).
If the flash size is larger than 16M, we assume the given addresses
are already relative ones. So we don't need the physical base address
any more.
This commit is part of a series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: I9eea45f0be45a959c4150030e7e213923510ad68
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72959
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Rather than disabling C State demotions for every single Raptor
Lake board due to an issue with S0ix, regardless of if they even
use S0ix, configure it in the mainboard.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I4f941a549bc717ae2f8ec961ead7ac7668347c99
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77087
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Besides fw.cfg, each combo entry needs dedicated APCB files. If no new
APCB is provided, the main APCB is used for all entries.
The combo is fully supported after this.
Change-Id: I21c2bf7d98ded43848ae8a8bb61d1ded1a277f88
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58620
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Before the cpuid(0x80000001) read in smbios_write_type4, it was
previously checked in a slightly convoluted way if the result from
cpu_cpuid_extended_level was larger than 0x80000001, but the check
should be if it is larger or equal to 0x80000001.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iabcfdb2b8b90d80baf8f4c4d2fd79f1f44866dc7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78107
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the HDA device can neither be disabled using softstraps
nor can it be disabled by using FSP UPDs. Add code to disable it in
coreboot when it's marked as 'off' in coreboot's devicetree.
TEST: Device 00:1f.3 is hidden and platform boots into OS without issue.
Change-Id: Ifa1422d653cf81ee6faf2bdda27a471c2084642b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77873
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On the first boot after flashing, the data read from the FMAP and
stored in vbios_data is not valid, so hashing it produces a value which
will not match on the subsequent boot, requiring an additional boot
before the vbios_data and hash match / before the GOP driver can be
skipped. To fix this, update vbios_data before hashing.
BUG=b:271850970
BRANCH=skyrim
TEST=build/boot google/skyrim with USE_SELECTIVE_GOP_INIT selected,
verify that GOP driver execution is skipping on 2nd boot after flashing
when booting in normal / verified boot mode.
Change-Id: Idc10d752bfa004a34b91307a743c620fb97eeb82
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77727
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This adds support for booting the Librem L1UM v2 mainboard with
coreboot, using binaries from the original BIOS.
The following features have been tested on PureOS:
- USB: front USB3, rear USB3, USB2 header on board
- SATA: 8x SATA ports, one M.2 M-key shared with SATA0
- PCIe: two PEG slots, one PCIe slot from PCH, and one M.2 M-key
- Network: 2x GbE
- Video: BMC VGA and IPMI
- Serial: Physical serial port, provided by BMC SuperIO
- Hardware monitor
- POST code display
- TPM2
These binaries are extracted from the original BIOS:
- Intel Management Engine
- Intel Firmware Descriptor
This was developed and tested on a Librem L1UM v2 using a Core i7-9700
CPU. Native graphics init works for the Aspeed AST2500 BMC.
For development, the serial port console works from bootblock. Early
init waits for the BMC to finish booting since this is required for
serial port output.
Change-Id: I990f6024d65098a9553d7d1fe7f36614cc55ea19
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75090
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Makefile.inc to include five generic LPDDR5 SPDs for the following
parts for Dochi:
DRAM Part Name ID to assign
MT62F1G32D2DS-023 WT:B 0 (0000)
K3KL8L80CM-MGCT 1 (0001)
H58G56BK8BX068 0 (0000)
BUG=b:298337185
TEST=USE="project_dochi emerge-brya coreboot"
Change-Id: If0fd4bc950cef484db53b7b21849cfdfdd7816a5
Signed-off-by: Morris Hsu <morris-hsu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78064
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
There is a technical debt in ChromeOS flashrom, `cros_alias.c`, which
is to work around ChromeOS calling flashrom with `-p host` instead of
`-p internal`.
Replace all `-p host` occurrences with `-p internal`.
BUG=b:296978620
TEST=none
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Change-Id: I81674213b9a21598002f349ced1130f0844841ca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77865
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This reverts commit 21e61847c4.
Reverting as it breaks booting on google/dedede based boards. First boot
after flashing is successful, 2nd hangs with the following error:
[EMERG] FspMemoryInit returned with error 0x80000003!
TEST=build/boot google/dedede (magpie, metaknight)
Change-Id: I6a2474617b444414c4248dbeda23ed0915704a17
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
This patch fixes the mistake introduced with 'commit 17cea380d9
("commonlib: Add CBMEM ID to store CSE Boot Partition Info")' where
single CBMEM ID name `CBMEM_ID_CSE_INFO` is associated with two
different name description.
Additionally, use little endian format for `CBMEM_ID_CSE_INFO` cbmem id.
TEST=Build and boot google/rex. Able to fix the issue introduced in
commit 17cea380d9 while running cbmem --list and verify that the
associated name string is proper.
Change-Id: I4235f1f6881ab86ccb252065e922d5d526f7f1f7
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78110
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krishna P Bhat D <krishna.p.bhat.d@intel.com>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost. In order to
backup PSR data before initiating firmware downgrade, CSE Lite firmware
supports a command to do this. This command works only after memory has
been initialized. So the CSE firmware downgrade can be done only in
post-RAM stage. CSE firmware sync actions will be moved to early
ramstage to support this.
Moving CSE firmware sync actions to ramstage results in cse_get_bp_info
command taking additional boot time of ~45-55ms. To avoid this,
cse_get_bp_info will be sent in early romstage and the response will be
stored in cbmem to avoid sending the command again, and re-use in
ramstage.
This patch adds a CBMEM ID to store this CSE Boot Partition Info
response in cbmem.
BUG=b:273207144
Change-Id: I914befadab4ad0ac197435e2a2c4343a796b2b1b
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78052
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
cse_store_rw_fw_version() stores CSE RW firmware version in global
variable or cbmem in romstage and ramstage respectively, based on the
stage it is called in. The call to this function is from the
cse_print_boot_partition_info() in cse_get_bp_info.
In the subsequent patches, the idea is to send the cse_get_bp_info early
in romstage and store in cbmem once memory is initialized. So when the
cse_fw_sync is called in early ramstage, the stored cse_bp_info_rsp is
used instead of sending the CSE get boot partition info command again.
To de-link the call to cse_store_rw_fw_version from cse_get_bp_info and
to ensure the CSE RW FW version is stored in all cases, moving the
function to do_cse_fw_sync.
BUG=b:273207144
Change-Id: I0add2c167c85cbddef2ecb4c019061a08562bbdf
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
PSR data is created and stored in CSE data partition. In platforms that
employ CSE Lite SKU firmware, a firmware downgrade involves clearing of
CSE data partition which results in PSR data being lost.
CSE Lite SKU firmware supports a command to backup PSR data before
initiating a firmware downgrade. PSR data backup command works only
after memory has been initialized. Moving only the downgrade would add
complexity of splitting the cse_fw_sync across pre-RAM and post-RAM
stages. So the idea is to move cse_fw_sync into ramstage when PSR is
enabled.
We are introducing a flow to get CSE boot partition info in early
romstage and then same data will be stored in cbmem once DRAM is
initialized. The CSE BP info data in cbmem will be utilized in early
ramstage to perform cse firmware sync operations. This helps in avoiding
re-sending the CSE get boot partition info command in ramstage. Having
cse_bp_info_rsp as global helps in de-linking cse_get_bp_info from
cse_fw_sync.
Many functions take cse_bp_info as input parameter. Since
cse_bp_info_rsp is global now, we can make use of global cse_bp_info and
remove it as input parameter from those functions.
BUG=b:273207144
TEST=Verify cse_bp_info_rsp holds value across the stage.
Change-Id: I0ee050b49fcae574882378b94329c36a228e6815
Signed-off-by: Krishna Prasad Bhat <krishna.p.bhat.d@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77070
Reviewed-by: sridhar siricilla <siricillasridhar@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anil Kumar K <anil.kumar.k@intel.com>
No Windows driver exists or is needed, so hide to prevent an unknown
device from being listed in Windows Device Manager.
TEST=build/boot Win11 on frostflow, verify unknown device for the
fingerprint reader no longer present.
Change-Id: I666e92706f698608f2df92c8296cfb615d5ece67
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
No Windows driver exists or is needed, so hide to prevent an unknown
device from being listed in Windows Device Manager.
TEST=build/boot Win11 on dewatt, verify unknown device for the ACP
machine driver no longer present.
Change-Id: I44d25fd2ea75593383cbb14f2324d4376b399de7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
No Windows driver exists or is needed, so hide to prevent an unknown
device from being listed in Windows Device Manager.
TEST=build/boot Win11 on morphius, verify unknown device for the ACP
machine driver no longer present.
Change-Id: I14347ab6c840066db4ff700eff1aad4cf6faf66b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Remove the unnecessary tss_common.h header from the repo.
tss_errors.h is a more appropriate place for the TPM_SUCCESS
value, and the other define is only used by tpm_common.c and
can be placed there.
BUG=b:296439237
TEST=Builds
Change-Id: I99cf90f244a75c1eeab5e9e1500e05c24ae0a8e5
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78033
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Dedede boards which select AUDIO_AMP_UNPROVISIONED via fw_config use
rt1015 for the speaker topology, not max98360a.
TEST=build/boot Win11 on google/magpie, verify correct audio profile
selected.
Change-Id: I5b75bd8fd37d2837de3c5bd25a02411a6982103b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
This reverts commit 06cb756f02.
Reason for revert: These Kconfigs are needed by boards which use the
CSE stitching tools (i.e. select STITCH_ME_BIN). They're selected by
some boards in the downstream ChromeOS repo. They're used in
src/soc/intel/Makefile.inc (see the line with
`$(CONFIG_CSE_$(2)_FILE)`).
Change-Id: Ide6fc74b457439f06b7ef9b37f11d6c9ff226b80
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76719
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Without the PCH UART GPIOs set early, there is no serial console
output until ramstage. Add them to the early GPIOs for all puff
variants.
TEST=build/boot google/puff (wyvern) with serial console enabled,
verify console output starts in bootblock.
Change-Id: Ica0506b2b80e4fac0d3ca11b4cfdd128ce424b36
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78029
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Brya queries the TPM in early ramstage (pre-device init) to determine
if the CR50 has support for long-pulse interrupts. If the TPM (and
underlying I2C controller) hasn't already been setup in verstage, it
will fail to do so in ramstage since the I2C controller has not yet
been initialized. To work around this, initialize the TPM in bootblock
for the non-vboot case, to ensure the I2C controller is set up when
needed in early ramstage.
TEST=build/boot google/brya (banshee), verify no I2C errors in cbmem
console when initializing TPM in early ramstage.
Change-Id: I26f0711a9cc4c2eb9837f258cadf391d337994c9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78028
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel Meteor Lake QS silicon provides better size optimized pre-x86
reset blobs.
This patch creates a new flash layout (FMD) for QS to accommodate those
optimizations, and renames the existing FMD for ES (pre-prod) silicon.
Comparative analysis between QS and ES flash layout is here:
For QS silicon:
- SI_ALL reduced from 9MB to 8MB.
- SI_BIOS increased by 1MB (from 23MB to 24MB) to fill in the 32MB SPI
layout.
- ME_RW_A/B reduce from ~4.5MB to 4MB.
- Ensure RW-B slot is starting at 16MB boundary.
- Unused space increased by 1MB.
For ES silicon:
- SI_ALL: 9MB
- SI_BIOS: 23MB
- ME_RWA/B: 4.5MB (for ISH) and 4.4MB (non-ISH).
- Unused space 3MB (for release) and 2MB (for debug) layout.
Change-Id: I881832a6b11a35710d4e847feadcc544b1f5d048
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77994
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
The options in conf.py for the following build targets are either
commented out or contain example values, which suggests that there was
no interest in them recently. Their comments also seem more like
generated examples.
* LaTeX
* man pages
* Texinfo
In order to clean up our configs and scripts for the documentation,
remove the configuration options from conf.py for these build targets.
Also, remove the build targets responsible for generating a PDF file
from Makefile. Don't touch Makefile.sphinx for now though as we usually
wrap around it.
We may bring these build targets back if there is real interest in
them, but it seems only the HTML target was really used.
Change-Id: I7df8ea886f94d9b25e8eeb0ccbc2a7392b96a575
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77439
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No drivers exists or are needed, so use devicetree hidden keyword to
set the ACPI status to hidden to prevent unknown devices from showing
in Windows Device Manager.
TEST=build/boot Win11 on morphius, verify unknown devices for the
fingerprint reader and stylus detection are no longer shown.
Change-Id: I992c0ec8d97c6041e3a268445613bfa42dd8b279
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78038
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Currently MP2 Firmware is not built into RO firmware section but the
soft fuse bit to disable MP2 firmware loading is not set. This causes
the device to boot loop during recovery mode. Set the bit to disable MP2
firmware loading in RO.
BUG=b:259554520
TEST=Build and boot to OS in Skyrim under both normal and recovery
modes.
Change-Id: I9e4cf4f72e2d36ad3cc33629ddb501ecdbf5eda9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78023
Reviewed-by: Robert Zieba <robertzieba@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This board is similar to x11ssm-f but has a proprietary form factor with
NVMe and a single x16 slot (potentially bifurcated to 2x x8) and a x4
slot.
Change-Id: I53a0b6012ae64cf1ba4b625f11aaf771637307f3
Signed-off-by: Kieran Kunhya <kieran@kunhya.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Now that no local union definitions are used any more, pass the msr data
to display_mtrr_fixed_types as an msr_t type parameter instead of a
uint64_t parameter. Also rename the parameter from msr to msr_data to be
more specific that this parameter is the MSR contents and not the MSR
number.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iafde64129acc4bf9f01816de21c7793edfc1a799
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Commit 407e00dca0 ("include/cpu/msr.h: transform into an union")
changed the msr_t type to a union that allows accessing the full 64 bit
via the raw element, so there's no need to wrap it again in another
union for the full 64 bit access.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I750307297283802021fac19e2cdf5faa12ede196
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78003
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Hook up the OC watchdog common block and initialize it if requested.
TEST=Enable watchdog on MSI PRO Z690-A and see the platform resets
after some time. Enable the watchdog in driverless mode and see the
platform no longer resets and periodic SMI keeps feeding the watchdog.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I1c2c640d48b7e03ad8cd8d6cdf6aac447e93cd86
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68945
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the
`DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC` config is enabled if
the underlying platform is built with a pre-production SoC (aka
`SOC_INTEL_METEORLAKE_PRE_PRODUCTION_SILICON` config is enabled).
BUG=b:300652989
TEST=Ensures `DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC` is enabled
for google/rex4es aka all variants with ES silicon.
Change-Id: Ieda39427915fa3973b832376ec20fc414ac2bedd
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77993
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
The tree contains engineering sample boards, that ship with
pre-production Meteor Lake SoC. These boards are not sold.
BUG=b:300652989
TEST=Ensure mainboards like google/rex4es and screebo4es have
`SOC_INTEL_METEORLAKE_PRE_PRODUCTION_SILICON` config enabled.
Change-Id: I1a875a0f1d2c38582f35250ebe645e53599f62de
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77992
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Certain Intel Meteor Lake specific features are only enabled in
production silicon (not available in early SoC aka pre-production
silicon).
- SPI usage for production SoC is much optimized compared to pre-
production silicon.
- MIPI driver requires a way to identify between pre-prod vs prod
silicon.
This patch adds config options to select the Pre-Production
aka Engineering Silicon (ES). The mainboard users can specify which
underlying SoC is being used for the target platform.
BUG=b:300652989
TEST=No change in the functionality, just added new configs.
Change-Id: I60fe11c1151a3a6c290cd0105eb570cb78e81797
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Add the eMMC MMIO device to the devicetree and make it use the common
AMD eMMC driver. Since there is now a device for this in the devicetree,
also use this device to determine if the FSP should be told if the eMMC
controller is supposed to be disabled.
TEST=On Mandolin the eMMC controller both disappears in the Windows 10
device manager and in dmesg on Ubuntu 2022.04 LTS
TEST=Morphius with NVMe SSD still works
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5453b69df776d2ce1f3be11e37cd26c8c64f0cd5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
When the eMMC MMIO device is enabled in the devicetree, it needs to be
exposed in ACPI in order for the OS driver to be able to attach to it.
The Cezanne eMMC controller isn't used in google/guybrush, so this the
code path where the eMMC MMIO device is enabled in the devicetree can't
be easily tested.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I69ff79b2d1c6a08cf333a2bb3996931962c2c102
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
tis_init calls into tis_probe and returns an error or success, simplify
the call stack by removing the current tis_init implementation and
renaming tis_probe to tis_init.
BUG=None
TEST=builds
Change-Id: I8e58eda66a44abf5858123cf9bcf620626f1b880
Signed-off-by: Jon Murphy <jpmurphy@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77943
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Patch adds:
- vboot_fail_and_reboot() for vboot failures handling.
- reboot() weak implementation for payloads to implement, used
by vboot_fail_and_reboot().
- vboot_recovery_mode_enabled() to check if recovery mode flag is set in
vboot context. Implemented for future libcbfs implementation
of VBOOT_CBFS_INTEGRATION in libpayload.
BUG=b:197114807
TEST=none
Change-Id: I53d1955573d54bc56d05f7780c18dcc8ac1fd399
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
To fully and easily implement fallback/recovery in libcbfs with vboot
support the codebase requires access to vboot context. Moving context
management to libpayload allows to avoid unnecessary overhead and code
complication and still allows payloads to access it in a way it was
designed. Access to this codebase will also allow implementation of e.g.
vboot_fail_and_reboot() and other helpful utilities used by coreboot and
depthcharge.
BUG=b:197114807
TEST=make unit-tests
TEST=Build and boot on google/ovis4es with CL:4839296 and
VBOOT_CBFS_INTEGRATION enabled
Change-Id: Id719be7c4f07251201424b7dc6c1125c6b5756d8
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Use data_fabric_get_mmio_base_size in data_fabric_print_mmio_conf
instead of open coding the functionality. This will fix the printing of
the MMIO config in the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO
case which wasn't handled properly before.
TEST=Console output from this function doesn't change on Mandolin:
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 0 ffff 90 9
4 fed00000 fed0ffff 93 x x 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
=== Data Fabric MMIO configuration registers ===
idx base limit control R W NP F-ID
0 fc000000 febfffff 93 x x 9
1 10000000000 ffffffffffff 93 x x 9
2 d0000000 f7ffffff 93 x x 9
3 fed00000 fedfffff 1093 x x x 9
4 0 ffff 90 9
5 0 ffff 90 9
6 0 ffff 90 9
7 0 ffff 90 9
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If602922648deca0caef23a9999c82acdd128b182
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77984
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>
Since vboot_extend_pcr() returns vb2_error_t, the return type of
extend_pcrs() should be vb2_error_t too.
Also fix an assignment for vboot_locate_firmware(), which returns int
instead of vb2_error_t.
Change-Id: I1a2a2a66f3e594aba64d33cfc532d1bd88fa305e
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
For GICD and GICR a SOC needs to implement 2 callbacks to get the base
of those interrupt controllers.
For all the cpu GIC the code loops over all the DEVICE_PATH_GICC_V3
devices in a similar fashion to how x86 lapics are added. It's up to the
SOC to add those devices to the tree.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I5074d0a76316e854b7801e14b3241f88e805b02f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76132
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot offers two vboot schemes VBOOT_SLOTS_RW_A and
VBOOT_SLOTS_RW_AB. When VBOOT_SLOTS_RW_AB is not selected then the
resulting image is rather not expected to have the FW_MAIN_B FMAP
region. When only RW_A region is used, vboot does additional full_reset
cycles to try RW_B, even though it does not exist / the build was not
configured for two RW partitions. To avoid it, a new vboot context
flag has been introduced, VB2_CONTEXT_SLOT_A_ONLY, which can be set
right after context initialization to inform vboot about absence of
slot B. This will result in less full_reset cycles when vboot runs
out of available slots and cause vboot to switch to recovery mode
faster.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Ie123881a2f9f766ae65e4ac7c36bc2a8fce8d100
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75462
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit dc7cc5bc6e ("mb/google/skyrim: Disable
USE_SELECTIVE_GOP_INIT") but limits the default enablement to Skyrim
variant only, to allow for continued testing.
BUG=b:271850970
BRANCH=skyrim
TEST=build/boot ChromeOS R117+ on google/skyrim, verify no display init
failures with feature enabled on cold/warm boots or S0i3 resume.
Change-Id: I21c70111a5f407a7e8dd1ad1f2c2759ddb91893e
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77964
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
cpu_cl_cleanup() function checks if the SOC supports storage-off
feature. This feature allows to turn off PUNIT SSRAM to save power.
Enable the storage-off if it's supported. Enabling it also clears the
crashlog records from PUNIT SSRAM.
cpu_cl_rearm() function rearms the CPU crashlog.
BUG=b:262501347
TEST=Able to build google/rex. Verified both features get asserted.
Change-Id: Id9ba0f5db0b5d2bd57a7a21f178ef1e86ca63fae
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77239
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add more details in CPU crashlog header structure, such as
storage off status and support, re-arm status etc. These fields
are used to check of particular feature is supported or not and
if supported what is the status of the feature.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: I4242b6043b8f8ad9212780f44ca0448cd2b6b9f8
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77562
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
relanding original commit 5013c60a87
("soc/intel/meteorlake: Generate new TME key on each warm boot") which was previously reverted by commit 19e66b7c95
(Revert "soc/intel/meteorlake: Generate new TME key on each warm boot")
due to consecutive reboot post warm reset issue.
The consecutive reboot post warm reboot issue has been fixed with
commit ba7a9eefcf ("soc/intel/common: Fix
invalid MADT entries creation"), hence, reattempting to land the original TME key related patch.
BUG=299294328
TEST=Boot up the system, generate kernel crash using following
commands:
$ echo 1 > /proc/sys/kernel/sysrq
$ echo "c" > /proc/sysrq-trigger
System performs warm boot automatically. Once it is booted,
execute following commands in linux console of the DUT and confirm
ramoops can be read.
$ cat /sys/fs/pstore/console-ramoops-0
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Change-Id: I5d45d265ccef1a7d37669ea22a74b52e2f3ae20d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This reverts commit 449c6d981c.
Reason for revert: (EVT board build does not exhibit shutdown followed
by warm reboot)
This commit reverts the workaround that limits the TCC activation
temperature. The original issue that was reported (shutdown followed
by warm reboot) was not seen in the EVT board build, so this change is
likely unnecessary.
Change-Id: I22adcdee6512e57ad0b6d531f2611e22a95c863e
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77806
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Configure _DSC to ACPI_DEVICE_SLEEP_D3_COLD so that the driver skips
initial probe during kernel boot and prevent privacy LED blink.
TEST=Boot to OS, check camera LEDs.
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: Ib9375d602171aa5018b1add1deac3021724dc207
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC is added to mipi camera
driver to extend the same support for all SoCs, so removing this config
from Alderlake SoC code.
BUG=None
TEST=Build rex and brya to check if the build passes without an
error.
Change-Id: I5bc23fce89f0ae22b64b90cb12621320cac30d85
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Move the existing FSP 4221.00 headers for Raptor Lake to a
subdirectory called 4221.00_google, and select this if the
vendor is Google.
Add the standard FSP 4301.01 headers to a separate directory,
from Intel download #686654, and select this for all other
vendors.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Icd99bdee1eeac70dfcaca3d07150d3de6bb83d81
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77101
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch addresses the increased boot time issue that occurs when ISH
store is enabled, such as in the "rex4es_ec_ish" variant.
During a cold reboot, the CBMEM memory resets and loses the stored
firmware versions. This causes the firmware versions to be fetched again
from the CSE, which increases the boot time by about 200 ms. This patch
stores a backup of the firmware version in CMOS and updates the CBMEM
memory during a cold reboot.
BUG=b:280722061
Test=Verified the changes on rex board.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Ibc5a027aa2bb7217e5032f56fece0846783557a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75755
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements APIs to access the CSE FW partition versions in
CMOS. The get API allows users to retrieve the current version from
CMOS memory. The set API allows users to set the version in CMOS
memory.
BUG=b:280722061
TEST=APIs verified on rex board.
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Change-Id: Idd0ee19575683691c0a82a291e1fd3b2ffb11786
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74995
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Remove the check to follow the new flow that commit 9c348a7b7e
("soc/intel/alderlake: Fix processor hang while plug unplug of
TBT device") introduced.
Processor hang is observed while hot plug unplug of TBT device. BIOS
should execute TBT PCIe RP RTD3 flow based on the value of
TBT_DMA_CFG_VS_CAP_9[30]. It should skip TBT PCIe RP RTD3 flow, if
BIT30 in TBT FW version is not set.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Ie822b8e1fd7592a31275db8455519c4cc6ac02ad
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The memory log we get returned by QcLib contains Windows line endings
("\r\n"), while we prefer to have POSIX line endings in the CBMEM
console (just "\n"). Filter the '\r' character out when copying that log
into the CBMEM console to convert.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0652300c2393fbc0b3c9875bb0ca1aa921e59098
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77722
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
For x86 eXecute-In-Place (XIP) pre-memory `.data` section support, we
have to use an extra segment as the VMA/LMA of the data is different
than the VMA/LMA of the code.
To support this requirement, this patch makes cbfstool:
1. Allow the load of an ELF with an extra segment
2. Makes add-stage for XIP (cf. parse_elf_to_xip_stage()) write its
content to the output binary.
To prevent the creation of unsuitable binaries, cbfstool verifies that
the LMA addresses of the segments are consecutives.
TEST=XIP pre-memory stages with a `.data` section have the `.data`
section covered by a second segment properly included right after
the code.
Change-Id: I480b4b047546c8aa4e12dfb688e0299f80283234
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77584
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For x86 eXecute-In-Place (XIP) .data section support, cbfstool need to
to skip relocation of the .data section symbols in addition to
.car.data section symbols.
To support this requirement, this patch makes the `-S` option take a
multiple section names separated by commas.
TEST=With `-S ".car.data .data"`, XIP pre-memory stages with
a `.data` section do not have any of the `.car.data` or `.data`
section symbols relocated.
Change-Id: Icf09ee5a318e37c5da94bba6c0a0f39485963d3a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
When using Intel(R) Xeon(R) Platinum 8490H on IBM/SBP1 the platform runs
with 480 cores. With 480 cores coreboot needs at least 440KiB for ACPI
tables. Bump the config to 512 KiB to have some free space for future
changes.
Change-Id: I2c0bbc36f45aab921f3189459de4438a0cd5dd1f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
This enables DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC for rex
variants boards with ES SoC to load pre-production signed IPU FW from
IPU kernel driver to make Camera function properly.
BUG=None
TEST=Build rex and check if SSDT-IPU0 includes the correct value for
"is_es" with Meteorlake ES and QS SoC.
Change-Id: I407d1932762622652939e8568fe34c704bc3b433
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77855
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This adds DRIVERS_INTEL_MIPI_SUPPORTS_PRE_PRODUCTION_SOC to provide
the option to load pre-production or production signed IPU FW from IPU
kernel driver.
BUG=None
TEST=Build rex and brya to check if the build passes without an
error.
Change-Id: Ib507bceb6fd85d8ed764df82db400526a10e4d6e
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77854
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Dibbi variants are chromeboxes, so they need different settings in ec.h.
Add a new dibbi baseboard ec.h and use it for dibbi variants. For now
it's identical to the dedede baseboard ec.h. It will be updated in the
following CL.
BUG=b:294963793
TEST=With the following CL, boot dibbi and check the APCI tables no
longer contain lid and PS/2 keyboard devices.
Change-Id: I4075041ab8f02026623d1a26a555bee5eb09e77b
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77782
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
Since d8f2dce "acpi.c: Swap XSDT and RSDT for adding/finding tables"
XSDT is primarily used to add new tables or to find the S3 resume vector.
However with QEMU coreboot does not generate most ACPI tables but takes
them from whatever QEMU provides. Qemu only creates an RSDT and lacks an
XSDT.
To keep the codebase simple with the assumption that XSDT is always
present, create an XSDT based on the existing RSDT and update the
address in RSDP.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ia9b7f090f55e436de98afad6f23597c3d426bb88
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77385
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When CSE jumps between RO and RW, it triggers global reset so the
AP goes down to S5 and back to S0. For Chromebox, when AP goes
down to S5 EC set AP_IDLE flag. This cause an issue to warm reset
the Chromebox device when it is in recovery mode and powered by
USB-C adapter. This patch allows AP to direct EC to clear AP_IDLE
flag before trigger reset.
BUG=b:296173534
BRANCH=firmware-dedede-136-6.B
TEST=Chromebox DUT which is powered by USB-C adapter boots up
after warm reset in recovery mode
Change-Id: Ib0002c1b8313c6f25d2b8767c60639aed8a4f904
Signed-off-by: Derek Huang <derekhuang@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77632
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
Create the dochi variant of the brya0 reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:299570339
BRANCH=firmware-brya-14505.B
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_DOCHI
Change-Id: Iadeb97bd217278cdf777ae350100313b4345ecf3
Signed-off-by: Morris Hsu <morris-hsu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77756
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch shortens the name of the CBMEM field CBMEM_ID_CSE_INFO from
"CSE SPECIFIC INFORMATION" to "CSE SPECIFIC INFO" to improve the
alignment of the text on the screen. The functionality of the field has
not been changed.
BUG=NA
Test=Boot verified on rex board.
Change-Id: I39c716dab7d02d49e7d552cff77d544a1c168433
Signed-off-by: Dinesh Gehlot <digehlot@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77743
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In soundwire.h, SOUNDWIRE_DPN MIN & MAX are set to 1 and 14. When
creating the dpn array, the length was set to MAX - MIN or 13, numbered
0 to 12.
When accessing the array, the code was bailing out if a value greater
than MAX was trying to be accessed, so the array was able to be overrun
by two structure lengths.
Fix this problem by:
1) Not subtracting the MIN value when creating the array, which does
waste a little space. If anyone wants to refactor the code to fix that,
please feel free.
2) Breaking out of the loop when the port is equal to the MAX port
number instead of just when it's greater than the max port number.
Reported-by: Coverity (CID:1429766 & CID:1429771)
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0841bb8c9869fe9f53958f05614848785a98b766
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
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>
When more ACPI tables are written than space is available in CBMEM, the
buffer overflow corrupts other CBMEM tables and a successful boot is unlikely.
Upgrade the error message to critical and be more precise what to do.
Change-Id: I152842945f552905729265f7d623cd581dd0a8d0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77714
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Naresh <naresh.solanki.2011@gmail.com>
commit f8ac3dda02 ("soc/intel/common:
Order the CPUs based on their APIC IDs") sort algorithnm walks all the
`cpu_info' entries without discarding empty ones. Since `cpu_info' is
not initialized, the data that is used is undefined and it generally
results in the creation of invalid `Local x2APIC' entries in the
MADT ("APIC") ACPI table.
Depending on the X2APIC ID value the Linux kernel behavior
changes (cf. arch/x86/kernel/acpi/boot.c::acpi_register_lapic()):
1. If (int)ID >= MAX_LOCAL_APIC (32768), the Linux kernel discards the
entry with the "skipped apicid that is too big" INFO level
message.
2. If (int)ID < MAX_LOCAL_APIC (32768) (including negative) this data
is taken into account and it can lead to undesirable behavior such
as core being disabled as (cf. "native_cpu_up: bad cpu" ERROR
kernel message).
TEST=Verified the MADT does not contain any invalid entries on rex.
Change-Id: I19c7aa51f232bf48201bd6d28f108e9120a21f7e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77615
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
The sta_himax83102 panel sometimes shows abnormally flickering
horizontal lines. The front gate output will precharge the X point of
the next pole circuit before TP term starts, and wait until the end of
the TP term to resume the CLK. For this reason, the X point must be
maintained during the TP term. In abnormal case, we measured a slight
leakage at point X. This is because during the TP term, the GPW does not
fully pull the VGL low, causing the TFT to not be closed tightly.
To fix this, we completely pull GPW to VGL before entering the TP term.
This will ensure that the TFT is closed tightly and prevent the abnormal
display.
BUG=b:299249186
BRANCH=corsola
TEST=FW Screen display normally
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: I5dddaaa38917a65990c1474b657db5eb551940b1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77692
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MPTS method should only be generated for the board sku with 5G.
BUG=NA
TEST=Check kernel messages when going to S3. The following errors
should not be seen:
ACPI BIOS Error (bug):
Could not resolve symbol [\_SB.PCI0.RP06.RTD3._STA]
ACPI Error:
Aborting method \_SB.MPTS due to previous error (AE_NOT_FOUND)
ACPI Error:
Aborting method \_PTS due to previous error (AE_NOT_FOUND)
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Change-Id: I78f434c9049773cf5229d3a1f3934ae82d1fe46d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77690
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that platforms with lids, such as Chromebooks, only
select the VBOOT_LID_SWITCH configuration option.
Only samples the LID GPIO if VBOOT_LID_SWITCH config is enabled,
otherwise fake LID is open to avoid shutdown after reaching
depthcharge.
Tested by building and booting Google/Rex with the VBOOT_LID_SWITCH
configuration option enabled, and verifying that google/ovis does not
required VBOOT_LID_SWITCH config.
Change-Id: Ic5123b822a5a7021023319cb08a3f9e5225961ba
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77693
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch ensures that the LidStatus UPD is passed a dynamic value,
rather than always passing 1 (CONFIG_RUN_FSP_GOP enabled) for FSP 2.0
devices.
Problem statement:
* FSP-S GFX PEIM initializes the on-board display (eDP) even when the
LID is physically closed, because LidStatus is always set to 1.
* FSP-S skips external display initialization even when the LID is
closed.
Solution:
* FSP-S GFX PEIM module understands the presence of an external display
if LidStatus is not set, and tries to probe the other display
endpoint.
* Statically passing LidStatus as always enabled (aka 1) does not
illustrate the exact device scenarios, so this patch updates
LidStatus dynamically by reading the EC memory map offset.
BUG=b:299137940
TEST=Able to build and boot google/rex to redirect the display
using external HDMI monitor while LID is closed.
Change-Id: I7d7b678227a6c8e32114de069af8455b8c1aa058
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
initramfs is built always, ignoring CONFIG_LINUXBOOT_BUILD_INITRAMFS
Built initramfs only is CONFIG_LINUXBOOT_BUILD_INITRAMFS is set
BUG = N/A
TEST = Built and boot facebook monolith
Change-Id: I0d575ff7528fceb06b5394642527713bb071c8b3
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77607
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
AMD's Windows display drivers validate the checksum of the VBIOS data
in the VFCT table (which gets modified by the FSP GOP driver), so
ensure it is set correctly after copying the VBIOS into the table if the
FSP GOP driver was run. Without the correct checksum, the Windows GPU
drivers will fail to load with a code 43 error in Device Manager.
Thanks to coolstar for root causing the issue.
TEST=build/boot Win11 on google/skyrim (frostflow), ensure GPU driver
loaded and functional.
Change-Id: I809f87865fd2a25fb106444574b619746aec068d
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Signed-off-by: CoolStar <coolstarorganization@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@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 7cf9c74518 ("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>
With kernel 5.15, puff hangs during power idle tests because
the NIC does not enter ASPM L1.2. We add "enable_aspm_l1_2" in
devicetree for RTL8111H to enable ASPM L1.2.
BUG=b:268859220, b:279618219
TEST=emerge and run power.Idle
Change-Id: I129dfd79e8112191453be513b2e3a260429b3030
Signed-off-by: Alexis Savery <asavery@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77570
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A workaround was added for puff to assert/deassert the #ISOLATE pin
during suspend/resume to resolve the situation where the realtek
ethernet device cannot enter L1.2 mode when its ASPM is disabled.
The realtek driver has since been fixed and ASPM of realtek devices have
been enabled on kernel 5.10 and 5.15 and this original workaround
is now causing suspend/resume errors on kernel 5.15:
r8169 0000:01:00.0: Unable to change power state from D3cold to D0,
device inaccessible
Puff devices were originally shipped with kernel 4.19, and applying
this change to the firmware on a device running 4.19 causes
suspend/resume failures, basically reversing the problem. We are
upreving the puff kernel to 5.15 so we need this patch, but since
it is incompatible with 4.19 we will have to take that into
consideration when pushing new firmware and potentially will need
to backport the necessary fixes to 4.19.
BUG=b:268859220
TEST=suspend_stress_test -c 500 on wyvern
Change-Id: I5eead2d70cd9528b3ca3fadd11f98c0330601324
Signed-off-by: Alexis Savery <asavery@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77378
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Currently pirrha's digitizer pen uses GPP_F12 for I2C HID interrupt
signal. But its IRQ number is the same as GPD2, which is used as
EC_SYNC_IRQ.
It caused EC driver loading error from dmesg:
cros_ec_lpcs GOOG0004:00: Failed to request IRQ 98: -16
cros_ec_lpcs GOOG0004:00: couldn't register ec_dev (-16)
cros_ec_lpcs: probe of GOOG0004:00 failed with error -16
So change the digitizer pen interrupt type to GpioInt to prevent
the conflict.
BUG=b:292134655
TEST=Verified EC driver reported no error and pen device worked
Change-Id: Ieb88e87fcfb06544a4b5b5133b752aa821fab76a
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77346
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch refactors the existing MRC cache storing logic, which was
spread between the ROM and RAM stages, into a single early MRC cache
store stage. The only exception is when SoC user selects
FSP_NVS_DATA_POST_SILICON_INIT to store MRC cache from ramstage (after
FSP-S).
It reverts all the boot-state logic previously used to locate and store
MRC cache from NVS HOB into NVS because majority of the platform can
potentially use the early MRC cache store with improved memory caching
at the pre-RAM phase (with the ramtop implementation).
The only exception is the Xeon SP platform, which currently locates
the MRC cache post in FSP-S (at ramstage). Therefore, this patch
provides an API to the FSP 2.x silicon init code to perform late
storing of the MRC cache.
In majority cases the updated logic, the romstage (post FSP-M) will
attempt to save the MRC cache. Platform that selects
FSP_NVS_DATA_POST_SILICON_INIT config performs the same operation post
FSP-S. Depending on whether the MRC_STASH_TO_CBMEM config is
enabled, the MRC cache will either be written directly to NVRAM at the
romstage or stashed into CBMEM for a late NVRAM write at ramstage.
Below table captures the change in the boot state w/ and w/o this
patch for storing the MRC cache. Overall the goal is to ensure the
platform behavior is remain unchanged before and after this patch.
w/o this patch:
| | Save MRC | Finalize | Lock the |
| | Cache | MRC Cache | Boot Medium |
+-----------+----------------+----------------+----------------+
| MRC_WRITE | BS_OS_RESUME | BS_OS_RESUME | BS_ON_RESUME |
| NV_LATE | CHECK_ENTRY | CHECK_ENTRY | CHECK_EXIT |
+-----------+----------------+----------------+----------------+
| MRC_STASH | BS_DEV | BS_DEV | BS_DEV |
| TO_CBMEM | ENUMERATE_EXIT | ENUMERATE_EXIT | RESOURCES_ENTRY|
+-----------+----------------+----------------+----------------+
| FSP_NVS | BS_DEV_INIT | BS_DEV | BS_DEV |
| DATA_POST | CHIPS_EXIT | ENUMERATE_EXIT | RESOURCES_ENTRY|
| SILICON | | | |
| INIT | | | |
+-----------+----------------+----------------+----------------+
| Platform | BS_PRE | BS_DEV | BS_DEV |
| w/o above | DEVICE_ENTRY | ENUMERATE_EXIT | ENUMERATE_ENTRY|
| config | | | |
| (FSP 2.0 | | | |
| platforms | | | |
w/ this patch:
| | Save MRC | Finalize | Lock the |
| | Cache | MRC Cache | Boot Medium |
+-----------+----------------+----------------+----------------+
| MRC_WRITE | BS_OS_RESUME | BS_OS_RESUME | BS_ON_RESUME |
| NV_LATE | CHECK_ENTRY | CHECK_ENTRY | CHECK_EXIT |
+-----------+----------------+----------------+----------------+
| MRC_STASH | BS_DEV | BS_DEV | BS_DEV |
| TO_CBMEM | ENUMERATE_EXIT | ENUMERATE_EXIT | RESOURCES_ENTRY|
+-----------+----------------+----------------+----------------+
| FSP_NVS | Post FSP-S | BS_DEV | BS_DEV |
| DATA_POST | (ramstage) | ENUMERATE_EXIT | RESOURCES_ENTRY|
| SILICON | | | |
| INIT | | | |
+-----------+----------------+----------------+----------------+
| Platform | Post FSP-M | BS_DEV | BS_DEV |
| w/o above | (romstage) | ENUMERATE_EXIT | ENUMERATE_ENTRY|
| config | | | |
| (FSP 2.0 | | | |
| platforms | | | |
BUG=b:296704537
TEST=Able to build and boot google/rex without any boot time impact.
Change-Id: Id1e91d25916594f59d1e467a142f5042c6138b51
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77556
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Specify the default path to, and automatically include the FSP binaries
needed to boot a board if USE_AMD_BLOBS is selected. Simplifies board
configs, and matches use in previous patforms.
TEST=build/boot google/skyrim
Change-Id: Ic837d264327723c8dc18a60fb16e8d41fe38b44e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77625
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Automatically include the FSP binaries needed to boot a board if
USE_AMD_BLOBS is selected. Simplifies board configs, and matches
use in soc/amd/picasso.
TEST=build/boot google/guybrush
Change-Id: I5b6e34085410a2aafe5d7876be5097f28f521ce8
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77624
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch renames `SAVE_MRC_AFTER_FSPS` config to
`FSP_NVS_DATA_POST_SILICON_INIT` to highlight the violation in the Xeon
SP FSP implementation, where the FSP Silicon Init API produces
Non-Volatile Storage (NVS) instead of the FSP-Memory Init API.
According to the FSP 2.x specification (section 11.3), the FSP
populates the NVS data using the FSP_NON_VOLATILE_STORAGE_HOB and
expects the boot firmware to parse the FSP_NON_VOLATILE_STORAGE_HOB
after the FspMemoryInit() API in API mode.
However, not all Intel SoC platforms that support the FSP 2.x
specification adhere to this requirement. For example, the FSP binary
for XEON SP platform produces NVS data (aka
FSP_NON_VOLATILE_STORAGE_HOB) after the FspSiliconInit() API.
Therefore, attempting to locate NVS data after the FspMemoryInit() API
on these platforms would result in an error. The `save_mrc_data.c`
implementation provides the required hooks to locate the NVS post
FSP-Silicon Init and store into Non-Volatile Storage.
BUG=b:296704537
TEST=Able to build and boot Intel Xeon SP w/o any functional impact.
Change-Id: I815a64263fa1415bfe30bb3c1c35e4adee307e86
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
With the introduction of a new Linux version a problem has appeared
after a software initiated reset via CF9h register. The problem
manifests itself in the fact that the Linux kernel does not start after
the reboot. The problem is solved by setting bit 3 to 1 in Reset Control
Register (I/O port CF9h). This leads to the fact that the PCH will drive
SLP_S3 active low in the reset sequence. It leads to the same behavior
as in commit 04ea73ee78 ("siemens/mc_apl3: Set Full Reset Bit into
Reset Control Register") explained.
Change-Id: Ibc6d538c939e38732f42995d5ec6c8b61f979a6a
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77603
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that the VR configuration for IA, SA, and GFX is
properly initialized, assigning zero values to VR causes a black screen
(no display) issue.
Problem Statement:
Override CEP (Current Excursion Protection) value with zero aka set to
disable results into black screen issue (no display).
Solution:
Keep CEP default enabled and don't override w/ zero value.
w/o this patch:
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[0] : 0x0
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[1] : 0x0
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[2] : 0x0
w/ this patch:
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[0] : 0x1
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[1] : 0x1
[SPEW ] CPU_POWER_MGMT_VR_CONFIG : CepEnable[2] : 0x1
Change-Id: I8908e8b6c995390b559212d456db6ddf984448a3
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eran Mitrani <mitrani@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
All of the SoCs in the cannonlake directory select the following
options. So move them to the common option SOC_INTEL_CANNONLAKE_BASE
in order to deduplicate selections.
* FSP_USES_CB_STACK
* HAVE_INTEL_FSP_REPO
* SOC_INTEL_CONFIGURE_DDI_A_4_LANES
Change-Id: I6ce5edb2ba2c138b44601b32c3ecba2e761136f7
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77447
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Remove MAILBOX word from CPU_CRASHLOG_MAILBOX_WAIT_STALL
and CPU_CRASHLOG_MAILBOX_WAIT_TIMEOUT macros, because they
can be used for other interface as well.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: I62b04fa4b05c427db494a536ca6504db02dfeb68
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77236
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Region with metadata tag contains information about BDF entry for
SOC PMC SRAM and IOE SRAM. We don't need to parse this as we already
define BDFs in soc/pci_devs.h for these SRAMs. Also we need to skip
to region as it does not contain any crashlog data.
BUG=b:262501347
TEST=Able to build google/rex. Able to trigger crashlog and decode
correctly.
Change-Id: Id8ed40b865cde8e89045f5c9e713398fcbff5890
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76834
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When parsing descriptor table the record can have tag type = 7.
This tag contains metadata depending on SOC. The platform may
choose to parse it based on implementation of crashlog.
BUG=b:262501347
TEST=Able to build google/rex.
Change-Id: I60dda06950974f7949fa5635141e4b7798c4d1f2
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
CPU crashlog discovery table and crashlog record is considered
invalid if first 32bits of the table is either 0x0 (no crashlog)
or 0xdeadbeef (invalid crashlog).
Crashlog record is considered consumed if bit 31 is set. So in this
case stop processing the subsequent records.
BUG=b:289600699
TEST=Able to build and verified invalid records are skipped on
google/rex.
Change-Id: Ia81bd293a533217425e44473ae85b2115c85faf6
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76333
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allow the use of 64bit MMCONF base in MCFG table.
Previously only 32 bits were utilized for MMCONF base, while the
remaining 32bits were reserved & held value of zero as evident from MCFG
table disassembly. This commit entails updating the 'base_address' field
in the 'mmconfig' structure to 64 bits and removing the 'base_reserved'
field.
TEST=Confirmed the functionality of the 64bit MMCONF base in the MCFG
table disassembly below
Signature : "MCFG"
Table Length : 0000003C
Revision : 01
Checksum : BD
Oem ID : "COREv4"
Oem Table ID : "COREBOOT"
Oem Revision : 00000000
Asl Compiler ID : "CORE"
Asl Compiler Revision : 20230628
Reserved : 0000000000000000
Base Address : 0000001010000000
Segment Group Number : 0000
Start Bus Number : 00
End Bus Number : FF
Reserved : 00000000
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: I2f4bc727c3239bf941e1a09bc277ed66ae6b0185
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77539
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a dummy soc (genoa) based on EXAMPLE_MIN86 with
amd linker script hooked up.
Default to 64bit code as that will be a sensible default for this
platform (high memory access required for RAS setup).
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I69253466084d17c4359d7e824d69f12490b076e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76495
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This board will use custom MP2 FW to dump the contents of the STB when
the SOC fails to enter/exit S0i3. Enable `PSP_LOAD_MP2_FW` by default.
BUG=b:259554520
TEST=Built and ran on skyrim device, verified that MP2 FW loads.
Change-Id: I4222521d01e2c98708f0e5b6693a8aee9e59edf2
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72118
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The rule being added to the refactoring section is already present
in the "coding style" section of the guide, but is currently easy
to miss. Adding it to its own section makes it a little more plain
and makes it more strongly worded.
Update a couple of other areas:
- Make kernel specific phrasing better aligned with coreboot.
- Remove duplicate "try to match" phrase in coding style section.
- Remove section on Data structures - it doesn't apply to coreboot.
- Update text to make it clearer and more coreboot-centric.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic3508529f639ea0609d2ea2032cc52407e9543e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71067
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
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>
Add support for FSP ASPM and Clock PM configuration based on Kconfig
options: PCIEXP_ASPM, PCIEXP_CLK_PM and PCIEXP_L1_SUB_STATE. For some
use cases it may be desirable to disable ASPM and Clock PM to achieve
more deterministic and higher performance of PCIe devices.
TEST=Boot MSI PRO Z690-A DDR4 without ASPM and Clock PM. Confirm all
PCIe devices are still working and ASPM and Clock PM capabilities
are not present on the PCIe Root Ports.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I6d9d11016bed89dcfee6909d0d3e3e2e56237a2f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69825
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The amdfw.rom is mostly in region COREBOOT. Calculate the relative
address as the CBFS module address. That is for future 32M flash size
support.
TEST=binary identical test 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
This commit is part of a series of patches to support 32/64M flash.
BUG=b:255374782
Change-Id: I2add8e4e6755e582b3be6a150cf83d1468f2f1be
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72961
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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 Genoa SoC supports MMIO addresses larger than 48 bits. Since the
MMIO base and limit registers in the data fabric only contain bits 16 to
47 of the MMIO address, the MMIO address extension register is
introduced on some SoCs like Genoa. This additional register contains
the upper bits of the MMIO base and limit. Since it's not available on
all SoCs, introduce the SOC_AMD_COMMON_BLOCK_DATA_FABRIC_EXTENDED_MMIO
Kconfig option to select the correct data_fabric_get_mmio_base_size
implementation to be added to the build.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic304f5797bc5661c1d511c95e457c6dde169d329
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77514
Reviewed-by: Martin Roth <martin.roth@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>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
Add HDMI GPIO configuration to early GPIO list to support
VGA text o/p in Pre-RAM stage on HDMI.
BUG=b:279173035
TEST=If CONFIG_UGOP_EARLY_GRAPHICS is set to y, check SOL
text on HDMI during Pre-RAM boot stage.
Change-Id: I13691850d09a442d5d5493a2b1dcf1145cf9797a
Signed-off-by: Anil Kumar <anil.kumar.k@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77521
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This patch sets the Fast V-Mode (FVM) configuration parameter as
suggested in Intel doc 640982. As per the doc, Intel MTL-U 15W CPU
supports FVM on IA and SA.
Fast V-Mode (FVM): Intel Meteor Lake introduces the ability to manage
the peak power events it calls "reactive peak power management".
The Fast V-Mode is one such technique to perform the reactive peak power
management. It relies on the detector integrated inside the processor
which senses when the processor load current exceeds a present threshold
by monitoring the processor power domain IMVP (Intel Mobile Voltage
Positioning) VR sense point.
The baseline ITRIP for IA is 66A and 21A for SA.
BUG=b:286809233
TEST=Able to build and boot google/rex without seeing any performance
regression.
Change-Id: Ia7157bddf2e9586e4a91cc55e48693561072cd05
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75763
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
KBL_STATE was originally intended to provide more granular control
of the keyboard backlight. However, KBL_BRIGHTNESS has a valid value
of "off" which achieves the same thing.
Therefore, unconditionally set the KBL_STATE to enabled, and rely on
KBL_BRIGHTNESS.
Change-Id: Ic7ee6b96b1dcaa6633b111e92097bce87908885e
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77201
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds option to override Fast Vmode on Meteor Lake SoC.
This requires CepEnable, EnableFastVmode, IccLimit FSPM UPDs in FSP
header. If the hardware supports Fast Vmode, the FSPM will set the
ICC limit value to the value passed from coreboot.
With CepEnable and EnableFastVmode enabled, if IccLimit is not
specified by coreboot, FSPM sets IccLimit as default value. If no
values assigned to all the three CepEnable, EnableFastVmode and
IccLimit, coreboot sets their values to 0 and Fast Vmode is disabled.
BUG=b:286809233
TEST=In debug MTL FSP logs, the value of FSP parameters is as passed
from coreboot including enable_fast_vmode, cep_enable, and
fast_vmode_i_trip. Also, fast_vmode_i_trip value is passed to pcode
using mailbox command without any error. This test done on google/rex
board.
Signed-off-by: Jay Patel <jay2.patel@intel.com>
Change-Id: Id05dccac56c504523f9327babe0c6fbeff488ec2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75566
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
This patch adds logic for logging the FW splash screen event to
the event log.
There could be three possible scenarios as below:
1. Platform w/o FW splash screen (i.e., either HAVE_FSP_LOGO_SUPPORT
or BMP_LOGO configs not enabled)
Expectation: Firmware Splash Screen (ELOG_TYPE_FW_SPLASH_SCREEN) not
present in the event log.
39 | 2023-08-27 12:42:54-0700 | System boot | 12
40 | 2023-08-27 12:42:54-0700 | ACPI Wake | S5
41 | 2023-08-27 12:42:54-0700 | Wake Source | Power Button | 0
2. Platform w/ FW splash screen (i.e., both HAVE_FSP_LOGO_SUPPORT
and BMP_LOGO configs are enabled)
Expectation: Firmware Splash Screen (ELOG_TYPE_FW_SPLASH_SCREEN) is
enabled in the event log.
34 | 2023-08-27 12:07:29-0700 | System boot | 11
35 | 2023-08-27 12:07:29-0700 | Firmware Splash Screen | Enabled
36 | 2023-08-27 12:07:31-0700 | ACPI Wake | S5
37 | 2023-08-27 12:07:31-0700 | Wake Source | Power Button | 0
3. Failed to render FW splash screen (due to any reason if FSP failed
to render the splash screen)
Expectation: Firmware Splash Screen (ELOG_TYPE_FW_SPLASH_SCREEN) is
disabled in the event log.
43 | 2023-08-27 13:06:10-0700 | System boot | 13
44 | 2023-08-27 13:06:10-0700 | Firmware Splash Screen | Disabled
45 | 2023-08-27 13:06:11-0700 | ACPI Wake | S5
46 | 2023-08-27 13:06:11-0700 | Wake Source | Power Button | 0
BUG=b:284799726
TEST=Verify that the event shows up in the event log when the user
selects the HAVE_FSP_LOGO_SUPPORT and BMP_LOGO configs to display
the firmware splash screen.
Change-Id: Ie9e09acff5443c31b881c300134bc0bb06c490c6
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77509
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This patch adds support for logging the firmware splash screen event
to the event log. There could be two possible scenarios for this
event: enabled and disabled.
BUG=b:284799726
TEST=Verify that the event shows up in the event log when the user
selects the HAVE_FSP_LOGO_SUPPORT and BMP_LOGO configs to display
the firmware splash screen.
Change-Id: I1e224903df21159d6eef2849a7d6fb05de09f543
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
This change causes a freeze during boot on an RPL-UR that does not have
the memory part string in the CBI.
BUG=b:296353047
BRANCH=firmware-brya-14505.B
TEST='emerge-brya coreboot chromeos-bootimage', flash and boot
problematic DUT to kernel.
This reverts commit c51a7cdde4.
Change-Id: I99fe5111b5294673d9e0a5d13f9c240e0f4a92c3
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77516
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: <srinivas.kulkarni@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
