# [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]
