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 자체가 불가능합니다. 멈춘 상태가 어디인지를 먼저 알아야 합니다.

LTSSM은 Detect → Polling → Configuration → L0 순으로 진행하며, L0 이후에는 일시 오류 시 Recovery로 빠졌다가 재training하거나 L0s/L1/L2 전력 절감 상태로 내려갑니다. 각 상태가 하는 일은 다음과 같습니다.

SoC의 PCIe controller register가 LTSSM 상태 필드를 노출하는 경우가 있습니다. 레지스터 offset과 상태 값 인코딩은 컨트롤러마다 다르므로, 해당 SoC reference manual에서 확인한 값으로 읽습니다.

#Protocol Analyzer 캡처

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

가격은 벤더가 공개하지 않아 —로 둡니다.

캡처할 항목:

• TS1·TS2 ordered set — Polling 단계 분석
• Flit 흐름 — CXL.mem M2S·S2M sequence
• Flex Bus 모드 협상 — link training 중 modified TS1/TS2 ordered set으로 CXL 지원 여부를 주고받는 구간

#호스트 측 진단 명령

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

5
# 안 보이면 — LTSSM이 L0에 도달하지 못한 것
6

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

12
# LnkSta 폭이 LnkCap보다 좁으면 — Configuration에서 일부 lane만으로 협상된 것
13

14
# 3. CXL DVSEC 발견 여부
15
$ lspci -vvv -s 5e:00.0 | grep -A 2 "Designated Vendor-Specific"
16
  Capabilities: [...] Designated Vendor-Specific: Vendor=1e98 ID=0000 Rev=1 Len=56: CXL
17
    PCIe DVSEC for CXL Devices
18
    CXLCap:  Cache- IO+ Mem+ ...
19

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

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

25
# 비어 있으면 — CEDT 누락 또는 cxl_acpi 미로딩
26
$ dmesg | grep -i cxl
27
$ 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 진화