네, 알겠습니다. 오늘 진행했던 모든 과정, 겪었던 문제들, 그리고 최종적으로 얻어낸 중요한 발견들을 하나의 글로 명확하게 정리해 드리겠습니다.
최종 목표: NXP S32G GoldVIP 플랫폼을 사용하여 TSN(Time-Sensitive Networking)의 핵심 기능, 특히 하드웨어 타임스탬프와 스케줄링 기능을 테스트하고 그 성능을 확인한다.
초기 환경:
ptp4l 실행 시 Failed to register PTP clock 오류가 발생하며 하드웨어 타임스탬프 기능 사용 불가.탐색 과정 및 발견:
1. 기본 네트워크 성능 측정 (iperf3)
pfe2sl 포트를 직접 연결하고 IP를 수동 설정(192.168.10.x 대역). S32G에서 iperf3 서버를, PC에서 클라이언트를 실행.-u)를 통해 Jitter(0.028ms, 28,000ns) 와 Packet Loss(0%)를 측정하며, 일반적인 부하에서는 네트워크 스택이 매우 안정적임을 확인.2. 과부하 테스트를 통한 일반 이더넷의 한계 확인
iperf3 트래픽(총 1.6Gbps)을 전송.3. 하드웨어 직접 제어 시도 (libfci_cli 분석)
libfci_cli 도구를 분석하여 하드웨어 TSN 기능을 직접 제어하는 방법을 모색.eth-slow-path-target.sh: 리눅스 커널의 IP 포워딩 기능을 사용하는 것을 확인.eth-pfe-fast-path-target.sh: libfci_cli를 통해 PFE 하드웨어의 연결 추적(Connection Tracking) 테이블을 직접 설정하여 커널을 우회하는 ‘Fast-Path’를 구현함을 발견.eth-idps-slow-path-target.sh: 컴파일된 linux_someip_idps 바이너리를 실행하는 래퍼(Wrapper) 스크립트임을 확인.libfci_cli의 역할을 이해.4. 하드웨어 TSN 기능 제어 시도의 실패와 최종 결론 도달
libfci_cli를 활용하여 TAS(시간 제어), CBS(대역폭 보장), FRER(이중화) 기능 설정 시도.libfci_cli --help를 통해 사용 가능한 모든 명령어를 확인.tas- 관련 명령어가 없음.cbs- 관련 명령어가 없음. (단, qos-shp는 다른 형태의 Shaper일 수 있음)qos-sch-update --sch-algo=PQ를 통해 전통적인 QoS 우선순위 큐(PQ)를 하드웨어에서 설정하는 것은 가능함을 확인.libfci_cli는 기능이 제한된 버전으로, TSN의 핵심적인 스케줄링 및 이중화 기능을 직접 제어할 수 없다. 하드웨어 타임스탬프 역시 디바이스 트리 설정이 비활성화되어 있어 사용이 불가능하다.오늘의 총평:
초기 목표였던 “나노초 단위 하드웨어 TSN 제어”는 플랫폼의 기능 제한으로 인해 달성하지 못했다. 하지만 그 과정에서, 우리는 iperf3와 C 코드, 쉘 스크립트 분석을 통해 ▲일반 이더넷의 성능과 한계 ▲하드웨어 오프로드(Fast-Path)의 개념과 위력 ▲전통적인 QoS(PQ)의 동작 방식을 직접 테스트하고 증명해냈다. 특히, 과부하 테스트를 통해 TSN이 왜 필요한지에 대한 명확한 해답을 우리 스스로의 실험을 통해 얻어낸 것이 가장 큰 수확이다.
다음 단계는 기능 제한이 없을 수 있는 이전 버전의 GoldVIP 이미지를 테스트하거나, NXP에 직접 문의하여 풀 기능(Full-featured) libfci_cli와 수정된 디바이스 트리를 받아 이 탐색을 계속하는 것이다.
네, 알겠습니다. 마지막 시도마저 Error: Unknown device type. 오류로 실패했네요. 이는 S32G 보드의 리눅스 커널이 본딩(Bonding) 드라이버 모듈 자체를 포함하지 않도록 컴파일되었다는 것을 의미합니다.
이제 확실해졌습니다. 이 보드에 설치된 리눅스 이미지는 네트워킹과 관련된 고급 기능들(tc 필터링, 본딩 등)이 모두 제거된, 정말 최소한의 기능만을 탑재한 상태입니다. 따라서 우리가 원했던 소프트웨어적인 방법으로 802.1CB의 Failover 기능을 구현하는 것은 불가능합니다.
그동안의 길고 험난했던 여정에 마침표를 찍고, 오늘 우리가 함께 시도하고 알아낸 것들을 깔끔하게 글로 정리해 드리겠습니다.
1. 최종 목표
2. 시도했던 방법들과 그로부터 얻은 교훈
| 단계 | 시도했던 방법 | 관찰된 현상 및 문제점 | 알아낸 사실 (교훈) |
|---|---|---|---|
| 1 | 리눅스 브릿지 (brctl) |
- PC와 S32G 양쪽에 브릿지를 생성하니 ping 통신 실패.- “인텔 포트 케이블을 뽑으니 통신이 된다”는 기현상 발생. |
- STP (Spanning Tree Protocol) 가 문제의 핵심. 루프를 방지하기 위해 하나의 활성 경로만 남기고 나머지를 차단하여, 진정한 의미의 동시 경로 이중화(Active-Active)를 방해함. |
| 2 | 라우팅 테이블 제어 (route, ip route) |
- S32G 보드에 동일한 IP 대역을 가진 여러 인터페이스(eth0, br0)가 존재하여 IP 충돌 및 경로 모호성 발생. |
- 네트워크 이중화 구성 시, 통신 경로는 충돌 없이 유일하게 정의되어야 함. eth0의 IP를 제거하여 경로를 단일화하는 것이 필수였음. |
| 3 | PC 인텔 어댑터 설정 변경 | - ‘Priority & VLAN’ 옵션을 끄자, 통신되던 Realtek 포트가 안 되고, 안 되던 Intel 포트가 될 가능성이 생기는 등 문제가 전이됨. | - 특정 하드웨어(Intel I225-V)의 드라이버는 자체적으로 복잡한 패킷 필터링 및 루프 방지 메커니즘을 가질 수 있어, 단순한 L2 브릿지 환경에서 예측 불가능한 동작을 유발함. |
| 4 | PFE 하드웨어 직접 제어 (libfci_cli) |
- PFE 내부에 가상의 스위치(Bridge Domain) 생성에는 성공. - 하지만 pfe 포트를 멤버로 추가하는 과정에서 Invalid hif 오류 발생. |
- S32G의 PFE를 제어하기 위해서는 libfci_cli 와 같은 전용 유틸리티를 사용하는 것이 정석적인 방법임.- 하지만, 리눅스 pfe* 인터페이스와 PFE 하드웨어의 Host Interface ID(HIF ID) 간의 정확한 매핑 정보를 알 수 없어 설정에 실패함. |
| 5 | 리눅스 본딩 (bonding 드라이버) |
- ip link add bond0 type bond ... 명령어 실행 시 Error: Unknown device type. 오류 발생. |
- S32G에 설치된 리눅스 커널에는 본딩(Bonding) 드라이버가 포함되지 않았음. 소프트웨어 기반의 Active-Backup 이중화 구성이 원천적으로 불가능함. |
3. 최종 결론
S32G GoldVIP 보드에 기본으로 설치된 리눅스 이미지는 차량용 게이트웨이의 특정 사용 사례에 맞춰 최적화된 최소 기능 세트(Minimal Feature Set)를 가지고 있다. 이 환경에서는 다음과 같은 제약으로 인해 표준적인 방법으로는 802.1CB의 핵심인 Failover 기능을 구현하고 테스트할 수 없다.
tc 필터링 기능이 없다.bonding 드라이버가 커널에 포함되지 않았다.libfci_cli의 필수 파라미터(HIF ID)에 대한 정보가 부족하여 설정을 완료할 수 없다.4. 향후 방향
이 기능을 테스트하기 위해서는, S32G 보드용 BSP(Board Support Package)를 직접 커스터마이징하여 빌드하는 과정이 필요하다. Yocto Project와 같은 빌드 시스템을 사용하여, 커널 설정(menuconfig)에서 Bonding driver support, Advanced-Router, IP: advanced router, IP: policy routing 등의 네트워킹 옵션을 활성화하고, iproute2-full 패키지를 포함한 새로운 리눅스 이미지를 만들어 보드에 설치해야 한다.
긴 시간 동안 많은 시도를 함께 해주셔서 정말 감사합니다. 비록 최종 목표 달성에는 실패했지만, 그 과정에서 S32G GoldVIP 보드의 네트워크 아키텍처와 현재 설치된 시스템의 제약 사항에 대해 매우 깊이 있게 파악할 수 있었습니다. 이 경험은 분명 다음 단계를 진행하는 데 큰 도움이 될 것입니다.