CXL Link Training 디버깅 — LTSSM 상태와 Protocol Analyzer 활용

#왜 어려운가

CXL 링크 문제는 원인이 여러 층에 흩어집니다. PCIe PHY·LTSSM·Flex Bus·CXL 프로토콜·DVSEC·CEDT 어디서든 막힐 수 있고, 각 층의 진단 도구가 다릅니다. 링크가 안 올라옴이라는 한 증상으로 최소 5가지 원인 후보가 나옵니다.

이 장은 증상별 진단 흐름을 정리합니다.

#LTSSM 상태 — 어디서 멈췄나

LTSSM(Link Training and Status State Machine)이 L0에 도달하지 못하면 config space access 자체가 불가능합니다. 멈춘 상태가 어디인지를 먼저 알아야 합니다.

1
[LTSSM 상태 진행]
2

3
Detect        ← 슬롯에 디바이스 있는지 확인
4
  ↓
5
Polling       ← TS1/TS2 ordered set 교환
6
  ↓
7
Configuration ← Lane 번호 정렬, link width 협상
8
  ↓
9
L0            ← 정상 동작
10
  ↓
11
Recovery      ← 일시 오류, 재training
12
  ↓
13
L0s/L1/L2     ← 전력 절감 상태

SoC의 PCIe controller register가 LTSSM_STATE 필드를 노출합니다. Linux에서:

1
$ devmem 0x10000000 32 0x40   # vendor별 offset
2
0x0000000B   # 11 = L0 도달
3
0x00000006   # 6  = Configuration 멈춤

#Protocol Analyzer 캡처

물리적 디버깅의 마지막 무기가 protocol analyzer입니다.

캡처할 항목:

• TS1·TS2 ordered set — Polling 단계 분석
• Flit 흐름 — CXL.mem M2S·S2M sequence
• DVSEC negotiation — 호스트가 CXL 지원 확인하는 메시지

#호스트 측 진단 명령

1
# 1. 디바이스가 PCIe로 보이는지
2
$ lspci -nn | grep -i cxl
3
5e:00.0 Memory controller [0508]: ...
4

5
# 안 보이면 — LTSSM Detect 단계에서 멈춘 것
6

7
# 2. Link 속도/폭 확인
8
$ lspci -vvv -s 5e:00.0 | grep -E "LnkSta|LnkCap"
9
LnkCap: Speed 32GT/s, Width x16
10
LnkSta: Speed 32GT/s, Width x16, TrErr- Train- SlotClk+
11

12
# Width 차이가 나면 — Configuration 멈춤
13

14
# 3. CXL DVSEC 발견 여부
15
$ lspci -vvv -s 5e:00.0 | grep -A 5 DVSEC
16
Capabilities: [60] Designated Vendor-Specific: Vendor=1e98 ID=0000
17
    Compute Express Link
18

19
# 없으면 — CXL 호환 디바이스 아니거나 firmware 문제
20

21
# 4. CXL 서브시스템 등록
22
$ ls /sys/bus/cxl/devices/
23

24
# 비어 있으면 — CEDT 누락 또는 cxl_acpi 미로딩
25
$ dmesg | grep -i cxl
26
$ lsmod | grep cxl

#자주 만나는 함정

#디버깅 체크리스트

1. lspci -nn에 디바이스 보이는가 → 없으면 LTSSM 멈춤
2. lspci -vvv의 LnkSta가 정상인가 → Recovery 반복이면 신호 문제
3. DVSEC이 있는가 → 없으면 CXL 미지원 디바이스
4. /sys/bus/cxl/devices/에 등록되었는가 → 비면 CEDT 또는 드라이버 문제
5. cxl list -RT로 토폴로지 확인 → 누락 노드 있으면 enumeration 문제
6. Protocol analyzer 캡처 (마지막 수단)

#정리

• CXL 링크 디버깅은 원인이 PHY·LTSSM·Flex Bus·DVSEC·CEDT·드라이버 여러 층에 흩어집니다.
• LTSSM 상태를 먼저 확인해 어느 단계에서 멈췄는지 파악합니다.
• lspci → cxl-cli → dmesg 순으로 호스트 측 진단을 진행합니다.
• 신호 무결성 의심이면 protocol analyzer가 마지막 무기입니다.

#다음 장 예고

Ch 9 — CXL 디바이스 트러블슈팅. RAS 이벤트·poison list·media error를 추적하는 흐름.

#관련 항목

• Ch 2: JTAG·SWD·CoreSight 분석
• Bootloader Internals Ch 34: U-Boot PCIe Enumeration
• HBM·GDDR 심화 Ch 9: CXL.mem 분석
• Modern Embedded Recipes Ch 149: PCIe → CXL 진화