Hi, Please create a ticket under ticket.coreboot.org. One possible thing I can think of is that you need to pull up a some kind of reset GPIO in the early_gpios. See also `src/mainboard/intel/adlrvp/early_gpio.c` for reference.
greetings Max On October 24, 2026 10:59:43 AM UTC, "Erdinç ÇALIŞICI" < [email protected]> 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]
