커스텀 보드에서 USB 3.0이 2.0으로만 잡힐 때 — dmesg 판독법과 Type-C CC 로직(PTN5150A)/크로스바 추적

---

i.MX8MP 커스텀 보드의 Type-C 포트에 USB 3.0 메모리를 꽂았는데 속도가 안 나온다. 이럴 때 첫 질문은 "3.0을 시도하다가 실패한 건가, 아예 시도조차 안 한 건가"이다. 이 둘은 원인 영역이 완전히 다르기 때문이다. 이 글은 dmesg 로그에서 그 답을 읽는 법과, 커스텀 Type-C 설계에서 SuperSpeed가 증발하는 하드웨어 경로(CC 로직, 크로스바 스위치)를 추적한 과정이다.

환경

• SoC: i.MX8MP (xHCI, USB 3.0 지원)
• Type-C 구성: PTN5150A (CC 로직 IC) + SS 신호 크로스바 스위치
• 증상: USB 3.2 Gen1 메모리가 항상 480Mbps(High-Speed)로만 열거

1. dmesg 판독: "시도 후 실패"와 "시도 없음"은 로그가 다르다

실제 로그를 보자.

ptn5150 1-003d: UFP attached
xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
xhci-hcd: new USB bus registered, assigned bus number 3
xhci-hcd: new USB bus registered, assigned bus number 4
xhci-hcd: Host supports USB 3.0 SuperSpeed
hub 3-0:1.0: USB hub found      ← 버스 3 = USB 2.0 루트 허브
hub 4-0:1.0: USB hub found      ← 버스 4 = USB 3.0 루트 허브
usb 3-1: new high-speed USB device number 2 using xhci-hcd

판독 포인트는 세 가지다.

① xHCI는 루트 허브를 두 개 만든다. 버스 하나는 2.0용, 하나는 3.0(SuperSpeed)용이다. "Host supports USB 3.0 SuperSpeed"는 컨트롤러 능력의 선언일 뿐, 장치가 3.0으로 붙는다는 뜻이 아니다.

 

② 장치가 어느 버스에 붙었는지 보라. usb 3-1: new high-speed는 2.0 버스에 High-Speed(480Mbps)로 붙었다는 뜻이다. 3.0으로 붙었다면 usb 4-1: new SuperSpeed USB device가 떠야 한다.

 

③ 링크 트레이닝 실패 흔적이 없다. 3.0을 시도하다 실패하면 보통 SuperSpeed 쪽 버스에서 열거 시도, 리트라이, "device descriptor read error" 같은 흔적이 남고 그 뒤 2.0으로 폴백한다. 위 로그는 그런 흔적 없이 처음부터 2.0 버스로 직행했다.

 

결론: SS 신호 자체가 SoC에 도달하지 않고 있다. 즉 소프트웨어(드라이버/DTS)보다 물리 경로를 먼저 의심해야 한다.

2. Type-C의 숨은 문제: 케이블은 뒤집힌다

USB 2.0의 D+/D-는 커넥터에서 한 쌍뿐이라 방향이 없다. 그런데 Type-C의 SuperSpeed 차동 페어는 커넥터 양면에 두 세트(TX1/RX1, TX2/RX2) 가 있고, 케이블을 어느 방향으로 꽂느냐에 따라 실제로 살아 있는 세트가 달라진다. SoC의 SS 레인은 한 세트뿐이므로, 중간에서 어느 쪽 세트를 SoC로 연결할지 골라주는 스위치가 필요하다. 이게 크로스바(먹스) 스위치다.

 

그리고 방향을 판별하는 것이 CC(Configuration Channel) 로직이다. 우리 보드는 NXP PTN5150A를 썼는데, 이 IC가 CC1/CC2 핀 전압으로 케이블 방향과 역할(DFP/UFP)을 감지하고, 그 결과를 SEL 신호로 출력해 크로스바를 조종하는 구조다.

Type-C 커넥터 ──SS TX1/RX1──┐
              ──SS TX2/RX2──┤ [크로스바] ──SS 1세트──> SoC (xHCI)
                             ↑ SEL
PTN5150A (CC1/CC2 감지) ─────┘

이 체인 어디가 끊겨도 증상은 동일하다: SS 신호가 SoC에 안 오고, 장치는 방향 무관한 2.0 라인으로만 붙는다. 로그에 ptn5150 1-003d: UFP attached가 찍히는 건 CC 감지 자체는 동작한다는 뜻이지, SEL→크로스바 경로가 옳다는 보장은 아니다.

3. 점검 체크리스트 (우선순위순)

① PTN5150A의 SEL 출력이 케이블 방향에 따라 토글되는가. 케이블을 정방향/역방향으로 꽂아가며 SEL 핀을 스코프나 GPIO로 관찰한다. 안 바뀌면 CC 감지 결과가 크로스바까지 전달되지 않는 것.

 

② 크로스바의 SEL/출력 인에이블(XSD 등) 핀 레벨. SEL이 고정이면 한 방향에서만 SS가 살아야 정상인데, 우리처럼 양방향 모두 2.0이면 크로스바가 아예 비활성(출력 디스에이블)인지 의심한다.

 

③ VBUS 경로. 커스텀 전원 스위치 구성이면 전류 제한 설정(RILIM)이 낮아 3.0 장치의 요구 전력을 못 대는 경우도 있다. VBUS 5V 실측.

 

④ SS 차동 페어의 물리 품질. 위 셋이 다 정상인데 링크 트레이닝 실패 로그가 있다면 그때 임피던스/배선 길이/ESD 소자 순으로 넘어간다. 우리 케이스처럼 "시도 없음"이면 여기까지 올 필요가 없다 — 신호가 도달하는 문제이지 품질 문제가 아니다.

[SEL 신호 측정 파형 삽입]

4. 곁가지: "LPM 알고리즘을 모른다" 경고는 무시해도 된다

이 디버깅 중에 눈에 밟히는 로그가 하나 있었다.

usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.

USB Link Power Management(절전 기능)를 이 호스트에서 어떻게 다뤄야 할지 몰라 꺼버렸다는 경고인데, 기능에는 영향이 없고 전력 소모가 약간 늘 뿐이다. SuperSpeed 미인식과는 무관하므로 낚이지 말 것.

5. 해결: 크로스바 스위치의 레인 세트 판단 신호가 PTN5150A에겐 반대다.

크로스바 스위치가 케이블 삽입 방향에 대한 SS 레인 세트를 판단하고 CC1/CC2 결정에 대해 PTN5150A에게 High/Low로 신호를 전달한다. 하지만 데이터시트를 통해 알게된 사실로 PTN5150A 입장에서 CC1/CC2 결정이 크로스바 스위치 판단과 반대였던 것.

 

즉, CC1일 경우 High 신호를 전달하나 PTN5150A 입장에서는 CC2로 이해하여 CC 로직 판단 수행. 또는 CC2일 경우 Low 신호를 전달하나 PTN5150A 입장에서는 CC1으로 이해하여 CC 로직 판단 수행한 것이 문제였다.

 

결론: 크로스바 스위치의 SS 레인 세트를 크로스 연결함으로써 크로스바 스위치의 CC1/CC2 결정에 따라 PTN5150A의 CC 로직 판단 결과 USB 3.0 버스에 SuperSpeed(5000Mbps)로 정상 연결되었다.

5. 정리

1. "3.0이 안 된다"는 dmesg에서 어느 버스 번호에 어떤 속도로 붙었는지로 먼저 이분한다 — 시도 후 실패(품질 문제)와 시도 없음(경로 문제)은 다른 세계다
2. Type-C는 케이블 방향 때문에 SS 페어가 두 세트이고, CC 로직 → SEL → 크로스바 체인이 그중 하나를 골라준다 — 커스텀 보드 SS 미인식의 단골 원인은 이 체인이다
3. 점검 순서: SEL 토글 → 크로스바 인에이블 → VBUS → (그래도 안 되면) 신호 무결성
4. 레퍼런스 보드 회로도와 내 보드를 나란히 놓고 CC/SS 경로만 따로 비교하면 차이가 빨리 보인다
5. 크로스바 스위치 같은 별도 서포트 IC가 사용되는 경우 메인 IC(PTN5150A)와 서포트 IC(크로스바 스위치) 간의 신호 판단이 일치하는지 데이터시트를 통해 정확히 확인해야 한다.

---

i.MX8MP 커스텀 보드 브링업에서 겪은 사례입니다.