Hi,
You likely want to disable GpioOverride, as FSP re-assigning clocks is likely
what's causing issues for you.
Leave SRCCLKREQ GPIOs unconfigured and add "PCIE_RP_CLK_REQ_DETECT" flag.
Of course there might be a GPIO-controlled power regulator, but that can be
verified with a multimeter.
Likewise, you can toggle SRCCLKREQ GPIOs with libgpio and check for clock
presence with an oscilloscope.
Never enable ASPM if you don't have schematics for the board you are working on
and are unsure if your mapping is correct.
P.S: Please do not submit LLM-generated support requests in the future.
99.99% of LLM-generated bug reports/support requests are a complete and utter
waste of time (not to mention being disrespectful towards developers). This
entire email could've been 4 sentences to read.
On 24/10/2026 12:59, Erdinç ÇALIŞICI wrote:
>
> # [ADL-N] PCH PCIe Root Port 9 (M.2 NVMe) link does not train in coreboot —
> works under OEM
>
>
>
> ## Board / environment
>
> - **Board:** new port, ASUS PRIME N100I-D D4 (Intel Processor N100, Alder
> Lake-N, CPUID 0x0B06E0).
>
> - **coreboot:** commit d2bd9a4d03a03169b258d08784899adf300d748d
> (SOC_INTEL_ALDERLAKE_PCH_N, FSP_TYPE_IOT).
>
> - **FSP:** 3rdparty AlderLakeFspBinPkg/IoT/AlderLakeN, `Fsp.fd` ImageId
> `$TWLFSPE`, ImageRevision 0x0CE28A40 (Twin-Lake-merged ADL-N binary;
> byte-identical to current intel/FSP upstream).
>
> - **Payload:** SeaBIOS. Flash descriptor + ME preserved byte-for-byte from
> the OEM image (only the BIOS region is coreboot).
>
> - Serial console (SuperIO NCT6798D COM1 @ 0x3F8, 115200) and com_debug
> (port-80) both work; full boot log available.
>
>
>
> ## Problem
>
> The M.2 NVMe (ASUS spec: single M-key socket, PCIe 3.0 **x2**) is on **PCH
> Root Port 9 (00:1d.0)**. Under the OEM AMI BIOS the SSD works perfectly (that
> is where the installed Linux lives). Under coreboot the root port comes up
> but **no device is ever detected** — the link never trains.
>
>
>
> coreboot log:
>
> ```
>
> PCI: 00:00:1d.0: ASPM enabled L0s and L1 (no endpoint)
>
> ```
>
>
>
> Register dump added in ramstage (BS_WRITE_TABLES) reading 00:1d.0 directly:
>
> ```
>
> coreboot: LnkCap=0x09727c23 LnkSta=0x1001 (DLLActive=0, Width=0, Speed=1)
>
> SltCap=0xfd00 SltSta=0x0008 (PresDet=0) bus03:00.0 =
> 0xffffffff
>
> ```
>
> vs the same registers read from the running OEM system (lspci -xxxx):
>
> ```
>
> OEM: LnkCap=0x09724823 LnkSta=0x3023 (DLLActive=1, Width=x2,
> Speed=8GT/s)
>
> SltCap=0xfd00 SltSta=0x0040 (PresDet=1) NVMe present at
> 03:00.0 (x2 8GT/s)
>
> ```
>
> So in coreboot the PHY never sees the device (PresDet=0, DLLActive=0, width
> 0); the port is otherwise enabled and responds in config space.
>
>
>
> ## Ruled out (verified, not guessed)
>
> - **Reference clock.** Tried clk_src = 0 and 2 (clk_req matched) with and
> without PCIE_RP_CLK_REQ_DETECT. Then forced **all** PCIe clock sources
> free-running via `register "pcie_clk_config_flag[0..4]" =
> "PCIE_CLK_FREE_RUNNING"` (+ PCIE_RP_CLK_SRC_UNUSED on RP9). No change. OEM
> GPIO dump shows the M.2 CLKREQ is SRCCLKREQ2 (GPP_D7); our gpio.h has
> GPP_D5–D8 = NF1 (SRCCLKREQ0–3), correct.
>
> - **Reset / power GPIO.** None exists: OEM ACPI (SSDT) RP09 has
> RSTG={SSDR,SDRP}/PWRG={SSDP,SDPP}, but the GNVS fields SSDR/SSDP/SDRP/SDPP
> are all **0** (read via /dev/mem on the live OEM system). SltCap shows
> PwrCtrl-/HotPlug-. So reset is internal (PLTRST), no board GPIO.
>
> - **FSP detect timeout.** Added `.pcie_rp_detect_timeout_ms = 100`. No change.
>
> - **HSPHY** is CPU-PCIe only (RP9 is PCH); "All HSPHY ports disabled" is
> expected and unrelated.
>
> - **Straps/lane mapping** should be identical: the OEM descriptor (with PCH
> soft straps) is preserved.
>
> - Device 0x1d exposes only function 0 (RP9) in OEM; RP10–12 absent. OEM
> pmc_core shows RP9 is in controller **SPC** (runtime-gated when idle, normal).
>
>
>
> ## Devicetree (relevant part)
>
> ```
>
> device ref pcie_rp9 on
>
> register "pch_pcie_rp[PCH_RP(9)]" = "{
>
> .clk_src = 2,
>
> .clk_req = 2,
>
> .flags = PCIE_RP_LTR | PCIE_RP_AER | PCIE_RP_CLK_SRC_UNUSED,
>
> .pcie_rp_detect_timeout_ms = 100,
>
> }"
>
> end
>
> ```
>
>
>
> ## Question
>
> With the same FSP binary and the same (OEM) descriptor/straps, what else
> governs PCH PCIe RP9 PHY/lane bring-up that could leave the link untrained in
> coreboot while the OEM FSP flow trains it fine? Specifically:
>
> 1. Is there a known ADL-N (0xB06E0) PCH PCIe regression in the
> Twin-Lake-merged `$TWLFSPE` FSP, i.e. should we use an older ADL-N-only FSP?
>
> 2. Are there FSP-M/FSP-S UPDs beyond clk_src/clk_req/detect_timeout/enable
> that affect PCH RP link training (e.g. lane reversal, controller/port
> mapping, ModPHY/FIA lane ownership) that coreboot does not set?
>
> 3. Any mainboard that saw "PCH RP no-endpoint, works in vendor FW" and the
> fix?
>
>
>
> Full serial boot log and OEM lspci -vvv/-xxxx dumps available on request.
>
>
>
>
>
> Best Regards
>
>
>
>
>
> Erdincca
>
>
> _______________________________________________
> coreboot mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
