Repository navigation
Conversation
The Infineon SLB 9672 on newer Clevo machines regularly fails TPM Resume on S3 with the error `TPM_RC_VALUE`. Per TPM2 spec, handle the failure by performing a TPM Restart. > The startup behavior defined by this specification is different than > TPM 1.2 with respect to Startup(STATE). A TPM 1.2 device will enter > Failure Mode if no state is available when the TPM receives > Startup(STATE). This is not the case in this specification. It is up > to the CRTM to take corrective action if it the TPM returns > TPM_RC_VALUE in response to Startup(STATE). Fixes the following error from being repeatedly logged in Linux: > kernel: tpm tpm0: A TPM error (256) occurred attempting get random Ref: Trusted Platform Module Library, Part 1: Architecture, rev 1.59 Change-Id: I3388007d4448c93bd0dda591c8ca7d1a8dc5306b Signed-off-by: Tim Crawford <tcrawford@system76.com>
Previously, only _PR0 was specified, which allowed devices to enter D0. Add _PR3 to allow the same devices to enter D3Cold, enabling proper runtime power management for devices that support it. Change-Id: Id7f4373989dffe8c3bc68a034f59a94d2160dd15 Signed-off-by: Jeremy Soller <jeremy@system76.com>
Change-Id: Ic30bec272e82535f6f606033c3ba512662cb2c8b Signed-off-by: Jeremy Soller <jackpot51@gmail.com>
These values were taken from alderlake. Change-Id: Ib790c7d52748156b25bad423ed082c1b51a33550 Signed-off-by: Jeremy Soller <jackpot51@gmail.com>
Intel introduced a new UPD specifically for setting the HDA subsystem ID in FSP-M. Using SiSsidTablePtr in FSP-S no longer works as it will be locked with a default value of 0 by that point. Tested on Clevo V560TU with MTL FSP 4122.12 (0D.00.A8.20). TEST=PCI config space for HDA device has subsystem ID set. Change-Id: I5e668747d99b955b0a3946524c5918d328b8e1d3 Signed-off-by: Tim Crawford <tcrawford@system76.com>
The Bonobo has 2 AMPs: one for the speakers and one for the subwoofer. Smart AMP data was collected using a logic analyzer connected to the IC during system start on proprietary firmware. This data is then used to generate a C file [1]. [1]: https://github.com/system76/smart-amp Change-Id: I5389a9890563ebd3adb20096b6225f474bc006f9 Signed-off-by: Tim Crawford <tcrawford@system76.com>
This config is not available in coreboot FSP headers, but is required for USB3 to work correctly. Change-Id: I9f69935123b8d3e2a7f93318ea39667d8a9efe0d Signed-off-by: Tim Crawford <tcrawford@system76.com>
Add a driver for laptops with NVIDIA Optimus (hybrid) graphics. The driver provides ACPI support for dynamically powering on and off the GPU, NVIDIA Dynamic Boost support, and a function for enabling the GPU power in romstage. References: - DG-09845-001: NVIDIA GN20/QN20 Hardware Design Guide - DG-09954-001: NVIDIA GN20/QN20 Software Design Guide Change-Id: I2dec7aa2c8db7994f78a7cc1220502676e248465 Signed-off-by: Jeremy Soller <jeremy@system76.com> Signed-off-by: Tim Crawford <tcrawford@system76.com>
System76 EC supports a lock bit on Clevo-based boards (`ME_WE`) that prevents writing its flash when enabled. Extend this lock to system flash by protecting regions when the `SECURITY` feature is present and enabled. Change-Id: Ifd5f77e8516bfd538409a079022f444a571d4e72 Signed-off-by: Jeremy Soller <jeremy@system76.com> Signed-off-by: Tim Crawford <tcrawford@system76.com>
Change-Id: I4b07846c404eb93ab4baf0a78a4bbffcc5d8afca Signed-off-by: Tim Crawford <tcrawford@system76.com>
The Bonobo has been updated with a Thunderbolt 5 controller (Barlow Ridge). Identified chip changes from the schematics: - JHL8540_MP -> JHL9580_QS - TPS65994BF -> TPS65994BH - IT5570E-128 -> IT5570E-256 Change-Id: I784e489cdd034febeaaac0182ab5b4fe672381ec Signed-off-by: Tim Crawford <tcrawford@system76.com>
The Meerkat 9 is an Intel Meteor Lake-H based small form factor desktop computer based on the Asus NUC-155H R2. Change-Id: I37a0b808cf383379b8e284831644c824c0d4817e Signed-off-by: Jeremy Soller <jeremy@system76.com> Signed-off-by: Tim Crawford <tcrawford@system76.com>
Change-Id: Ibc3401463084173483ef2c98e4241af6557607ce Signed-off-by: Tim Crawford <tcrawford@system76.com>
Change-Id: I35b792e0298700f41fc8469fcf9c75a1bae3d4d4 Signed-off-by: Jeremy Soller <jeremy@system76.com> Signed-off-by: Tim Crawford <tcrawford@system76.com>
The newer batch of these boards do not de-assert VW PLTRST# on S3 resume, causing the units to not power on in the EC code. Switch them to S0ix as a workaround. Enable CSME in CMOS options by default so that S0ix will work. Change-Id: I95337c1391102db9e020e82bdd938659c1a4f905 Signed-off-by: Tim Crawford <tcrawford@system76.com>
Change-Id: I1b2ec2ec95f5d29e71e4d99a76a0d186679fd101 Signed-off-by: Tim Crawford <tcrawford@system76.com>
Drain pending SPI sync SMIs before dropping write protect for SMMSTORE and once more after the command runs. This keeps a stale sync status from leaking into the next request. Change-Id: I7ba21719a6dafa926b0d5986a253da9cff52575a Signed-off-by: Sean Rhodes <sean@starlabs.systems> Reviewed-on: https://review.coreboot.org/c/coreboot/+/91726 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Commit a1ef551 ("soc/intel: Use chipset.cb for PCIe root port ops linking") added `ops pcie_rp_ops` to PCH root ports in chipset.cb and trimmed the pch_pcie PCI ID list in pcie.c. CPU-side bridges (PEG / pcie4 / pcie5) were never given explicit ops, so they still relied on DID-based binding and lost pcie_rp_ops after that cleanup, resulting in NVMe boot failures. Wire the same pcie_rp_ops used for PCH RPs on CPU PCIe devices for all Intel SoCs, to restore the previous functionality. This fixes NMVe booting on google/crota and other boards which use CPU-attached PCIe root ports for attached storage. TEST=build/boot google/crota with NVMe storage. Change-Id: I15fab69657cc5a26d1e6f454896136e71d5cb149 Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/92629 Reviewed-by: Sean Rhodes <sean@starlabs.systems> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Downstream bridges behind a discrete Thunderbolt controller need the PCIe hotplug scan path when PCIEXP_HOTPLUG is enabled. Use the hotplug scanner only for bridges whose parent is also handled by the dTBT driver, and keep the normal PCIe bridge scan for the upstream bridge. Tested on ThinkPad T480: Hotplugging AMD Radeon R7 250X and ATI Radeon HD 2600 XT works. Change-Id: I48ba91a523bb7ad697ac7ab966056ff4c04d9851 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/92520 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Replace arbitrary delay between PWR_EN and RST# with a check for PWRGD. Increase the time from 25ms (romstage) and 5ms (ACPI) to 50ms for both. All boards using the driver except CFL (addw1, oryp5) have the pin. Change-Id: I613f30fca2e3783eba8f87a4197e34ab682f9820 Signed-off-by: Jacob Kaulike <kaulike@system76.com> Signed-off-by: Tim Crawford <tcrawford@system76.com>
Change-Id: I4440417af3aac21d715b591bcb983d48b453a478 Signed-off-by: Tim Crawford <tcrawford@system76.com>
[ upstream commit 8cdb7bc ] Rework the Kconfigs for boards using SoC directories to have a common config block and board-specific configs. CNL-H boards are not touched as they are a separate mess that needs to be cleaned up. TEST: Build with CONFIG_INCLUDE_CONFIG_FILE=n and BUILD_TIMELESS=1 is identical. Change-Id: I259c00b54e6d204fbbf7b8c6e9a761140112c5ed Signed-off-by: Tim Crawford <tcrawford@system76.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/92902 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Match the new default region size from commit d32a372 ("drivers/smmstore: Increase default size of store to 512KB"), as was done for Google and Star Labs boards. Change-Id: I61298df80e4ce50d79adcf2c74f947c319b0c40b Signed-off-by: Tim Crawford <tcrawford@system76.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/91768 Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The cherry-picked commit missed some models that were added later upstream that already had the increased size. Change-Id: I758cc7e279d95e60f7cab7b1bb3855f2a5337ab8 Fixes: bcbc146 ("mb/system76: Increase size of SMMSTORE to 512KB") Signed-off-by: Tim Crawford <tcrawford@system76.com>
The adl baseboard selects both of these; rpl selects neither. They gate the
build of the devicetree chip drivers used to describe a TCSS Type-C port:
- drivers/intel/pmc_mux/Makefile.mk builds mux.c and conn/conn.c only when
CONFIG_DRIVERS_INTEL_PMC is set
- drivers/intel/usb4/retimer is gated on CONFIG_DRIVERS_INTEL_USB4_RETIMER
Without them, a variant that adds "chip drivers/intel/pmc_mux" or
"chip drivers/intel/usb4/retimer" to its overridetree fails to link.
This commit has no functional effect on its own, and none on any variant that
does not use those drivers. It is a prerequisite for the lemp12 change that
follows.
TEST=Builds for lemp12. No change to the built image: with no variant using
these drivers yet, the .config gains the two symbols but no additional objects
are linked.
Change-Id: Iada38a12a1157c5190084aa7c893c13c2f29d236
Signed-off-by: mw <mw@mattsp.dev>
lemp12's sole USB-C connector (J_TYPEC1) never operates above USB 2.0 and DisplayPort alt-mode never engages. Reported in firmware-open#675. soc/intel/alderlake fill_fsps_tcss_params() derives UsbTcPortEn from whether the devicetree device tcss_usb3_port1 is enabled: s_cfg->UsbTcPortEn = 0; for (int i = 0; i < MAX_TYPE_C_PORTS; i++) if (is_dev_enabled(tcss_port_arr[i])) s_cfg->UsbTcPortEn |= BIT(i); chipset.cb defaults tcss_root_hub and tcss_usb3_port1 to off, the rpl baseboard declares no TCSS section, and no rpl variant enables them, so the bit stays clear and FSP-S never enables the Type-C port. The connector's USB2 pair routes to the PCH and keeps working, which is why the port enumerates devices at 480 Mbps while its SuperSpeed lanes stay dark. Enable the port and describe it the way the adl variants do. The per-port drivers/usb/acpi descriptors under xhci are added at the same time, since the pmc_mux conn node references usb2_port3 and the board has no per-port descriptors at all today. Upstream CB:94134 adds those descriptors to all twelve rpl variants; if that lands here first, that hunk can be dropped. GPP_E4 is this board's retimer force-power pad, declared in its own gpio.c as TBT_FORCE_PWR and confirmed against the Clevo L140AU schematic (board 6-71-L14A0-D02A): PCH ball FC22 -> GPPE4_TBT_FORCE_PWR -> R411 (0R, populated) -> TC_RETIMER_FORCE_PWR -> JHL8040R FORCE_PWR ball A9. All adl variants (7/7) enable tcss_usb3_port1; no rpl variant (0/12) does. The same split holds for tgl-u and mtl, which suggests the rpl directory was created without carrying the Type-C stack over. Reading their overridetrees, darp9, galp7 and oryp11 look affected the same way -- in each case the Type-C connector with no PCH usb3_ports[] entry is the one users report as broken (firmware-open#472 for oryp11, #497 for darp9). I have deliberately left those boards alone: I do not own them and cannot test them, so this change is scoped to the one board I can verify on. The same blocks should apply, with the conn alias and the retimer pad adjusted per board. TEST=Builds for lemp12 on the current release (2025-07-24_c242738). Generated static.c has _dev_tcss_usb3_port1 .enabled = 0 before this change and 1 after, and gains drivers_intel_pmc_mux_ops, drivers_intel_pmc_mux_conn_ops and drivers_intel_usb4_retimer_ops. Comparing a stock and a patched ROM built from the same tree: identical CBFS file set, FSP, microcode, payload and bootblock bit-for-bit unchanged, fallback/ramstage +2189 B and romstage +768 B. The string INTC105C appears only in the patched ramstage, and decoding the device array out of the extracted ramstage shows tcss_usb3_port1 .enabled going 0 -> 1, so the bit reaches the image that would be flashed. NOT tested on hardware. This machine's SPI flash is a leadless WSON-8 part with no external programmer attached and the flash map has a single COREBOOT region, so I have not flashed it. The runtime behaviour is unverified; I will follow up once I have flashed it, and would welcome anyone with a bench unit testing it first. Change-Id: I69f5f7ceef1f39a2be4a28a24270e9650589f915 Signed-off-by: mw <mw@mattsp.dev>
Member
|
Please disclose any LLM usage in the creation of this PR including all associated code changes and PR descriptions. |
Author
|
pretty much everything is LLM generated and edited by me |
Member
|
Fork has been rebased on 26.09. The xHCI ACPI configs have been upstreamed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
lemp12's USB-C connector (
J_TYPEC1) never operates above USB 2.0 and DisplayPortalt-mode never engages. Reported in firmware-open#675, which has the measurements.
fill_fsps_tcss_params()derivesUsbTcPortEnfrom whether the devicetree devicetcss_usb3_port1is enabled.soc/intel/alderlake/chipset.cbdefaults itoff, therplbaseboard declares no TCSS section, and norplvariant enables it, so the bitstays clear and FSP-S never brings the port up. The connector's USB2 pair routes to the
PCH (
usb2_ports[2] = USB2_PORT_TYPE_C) and keeps working, so devices enumerate at480 Mbps with the SuperSpeed lanes dark.
7/7
adlvariants enabletcss_usb3_port1; 0/12rplvariants do.tgl-uandmtlenable it as well.
Commits:
mb/system76/rpl: selectDRIVERS_INTEL_PMCandDRIVERS_INTEL_USB4_RETIMER.adlselects both,
rplneither; the chip entries below do not link without them.mb/system76/lemp12: enabletcss_root_hub/tcss_usb3_port1undertcss_xhci, adddrivers/intel/usb4/retimerundertcss_dma0, adddrivers/intel/pmc_mux+connunder
pmc, add the per-portdrivers/usb/acpidescriptors underxhci. Mirrorslemp11.
GPP_E4is this board's retimer force-power pad, per its own gpio.c (TBT_FORCE_PWR)and the Clevo L140AU schematic (
6-71-L14A0-D02A): PCH ball FC22 →GPPE4_TBT_FORCE_PWR→ R411 (0 Ω, populated) →TC_RETIMER_FORCE_PWR→ JHL8040RFORCE_PWRball A9.CB:94134 adds the per-port
drivers/usb/acpidescriptors to all twelverplvariants;that hunk can be dropped if it lands here first. It is included because
pmc_mux/connreferences
usb2_port3and lemp12 has no per-port descriptors on this branch.Verified:
28fb5085(release2025-07-24_c242738).static.c:_dev_tcss_usb3_port1.enabled0 → 1; gainsdrivers_intel_pmc_mux_ops,drivers_intel_pmc_mux_conn_opsanddrivers_intel_usb4_retimer_ops;conn.usb2_port=&_dev_usb2_port3,conn.usb3_portandretimer.dfp[0].typec_port=&_dev_tcss_usb3_port1.payload and bootblock unchanged,
fallback/ramstage+2189 B,romstage+768 B.INTC105Cpresent only in the patched ramstage. Decoding the device array out of theextracted ramstage shows
tcss_usb3_port1.enabled0 → 1.Not tested on hardware. This board's SPI part is a leadless WSON-8
MX25L25673G(U41),I have no external programmer, and the flash map has a single
COREBOOTregion, so Ihave not flashed a patched ROM. The runtime behaviour is unverified.
darp9, galp7 and oryp11 show the same pattern — a Type-C connector with no PCH
usb3_ports[]entry (firmware-open#472, #497). Not touched here; I cannot test them.