[JLR] 계기판 디자인 커스터마이징 (클러스터 디자인 변경) #1
2009년, 2010년형 Range Rover (L322)를 위해 디지털 계기판이 처음 도입되었다. 이 계기판에는 기계식 바늘과 램프 대신, 12인치 LCD 디스플레이가 적용되었다. 2009년 당시에는 매우 혁신적인 기술이었으며, 이후 7년 동안 거의 수정 없이 Range Rover 및 JLR의 다른 모델에도 사용되었다. 이후 차세대 전장이 공개된 2015년, 세대교체가 이루어졌는데, 이 글은 15년 이전 디스플레이에 대한 내용을 담고 있다.
2009년 보도 자료에 따르면 디지털 계기판은 QNX의 운영 체제(OS)를 사용한다고 밝혔었다. 이는 계기판에서 자체 애플리케이션을 실행할 수 있는 잠재적인 가능성을 의미한다. L322 계기판과 관련된 VBF 파일을 살펴보면, QNX는 JADE(Fujitsu MB86R01) 프로세서에서 실행되고 있음을 알 수 있다. 추가적인 VBF 파일 검색을 통해 JADE 프로세서가 L322 뿐만 아니라 XJ(X351)에서도 사용되었음을 확인할 수 있었다.
- 출처 : QNX News
JLR 계기판 내부를 살펴보자.
계기판 내부에는 매우 많은 반도체가 집적된 PCB가 존재한다. 차세대 전장이 탑재되기 전 (대부분 2015년 이전) JLR 모델 L322, XJ351, L405, L494의 계기판에서 사용되는 PCB는 동일한데, 주요 구성 요소들은 다음과 같다.
- 그래픽 프로세서: Fujitsu MB86R01(JADE), ARM926EJ-S 333MHz
- RAM: IS46DR16160A, DDR2, 2x32MB
- 플래시 메모리: S29GL512N, 64MB
- 인터페이스 프로세서: TMS470PLFA21, ARM7TDMI, 1MB 플래시
- 디스플레이: TJ123NP01CA, 해상도 1280×480
- MOST25 트랜시버: OS81050
- FPD-Link LVDS to RGB 변환기: DS90UR124
- FPGA/CPLD 칩: LATTICE P750060CFPC002
- 2개의 CAN 트랜시버: TJA1042
- LIN 트랜시버: TJA1020
- I2C EEPROM: 24C16
PCB에는 TMS470 인터페이스 프로세서와 MB86R01 그래픽 프로세서가 존재한다. TMS470 프로세서에는 외부 버스와 연결되어 있고, MB86R01 프로세서에는 계기판 디스플레이가 연결되어 있다.
- CAN 및 LIN 트랜시버
이들은 TMS470 프로세서에 연결되어 있으며, 이 프로세서는 차량의 CAN 및 LIN 버스에 직접 연결되어 다른 차량 모듈들과의 통신을 제어한다. TMS470 프로세서는 MB86R01 그래픽 프로세서의 전원을 관리한다. CAN 버스에서 활동이 감지되면, TMS470은 MB86R01의 전원을 인가하고, 차량이 슬립모드로 진입하면 MB86R01의 전원을 차단한다. TMS470과 MB86R01 사이 통신은 SPI 버스를 통해 이루어지며, TMS470은 그래픽 인터페이스를 렌더링하기 위한 모든 필요한 정보를 전송한다. - LVDS
내비게이션 시스템에서 계기판으로 미니 맵 이미지를 전달할 때 사용된다. DS90UR124는 LVDS시그널을 병렬 RGB 시그널로 바꾸고, 알 수 없는(?) FPGA/CPLD를 통해 MB86R01에 전달된다. - MOST 버스
이 버스는 MB86R01 프로세서에 연결되어 있고, 엔터테인먼트 및 내비게이션 시스템에서 전송된 정보가 계기판에 표시되는데 사용된다. 내비게이션, 라디오, 또는 트랙 정보 등이 포함된다. - JTAG 커넥터
이들은 별도의 패드에 연결되어 있으며, 필요할 경우 프로세서의 메모리를 리프로그래밍 할 수 있다.
인터넷에서 찾아본 L322에서 추출된 계기판의 PCB에 MOST와 LVDS가 없는 경우가 있었는데 옵션의 차이로 추정된다. (다음과 같이 PCB 형상은 동일하다)
PCB를 직접 살펴봐야 했던 이유는 MB86R01 프로세서의 시리얼 포트 핀 포인트를 찾는 것이 목적이었기 때문인데, VBF 파일을 분석한 결과, MB86R01의 시리얼 포트에서 QNX 시스템 콘솔이 실행되고 있다는 것을 확인할 수 있었다. VBF를 찾았기 때문에 더이상 로우레벨 인터페이스를 살펴 볼 필요는 없으나 …
시리얼 포트를 115.2kbps 속도로 설정하고, 포인트에 USB-시리얼 변환기 3V 제품을 사용하면 QNX 콘솔에 접근할 수 있다. 전원을 인가하면, QNX가 로드되는 동안 시리얼 포트를 통해 디버그 정보가 전송된다. QNX가 로드되는 데 몇 초가 걸리며, 이후에는 MB86R01 프로세서에서 직접 프로그램을 실행할 수 있는 명령을 입력할 수 있다. 다음 스크린샷은 MB86R01 시리얼 포트의 부팅 출력과 내가 실행한 몇 가지 프로그램의 출력을 보여주는데 명령어는 조금 다르지만 Linux, BSD, macOS를 사용해 본 사람이라면 큰 어려움이 없을거라 생각된다.
pidin arg 실행 중인 프로그램 목록을 표시하는 명령으로, Linux의 `ps` 명령과 유사하다.
pidin info 시스템 정보를 표시하는 명령으로, Linux의 `uname`, `free`, `uptime` 명령과 유사하다.
위의 리스팅된 목록을 보면 QNX 시스템 프로그램과 JLR 프로그램이 포함되어 있다.
- procnto: QNX 운영 체제의 커널
- devf-einstein: 플래시 드라이브 드라이버
- devf-ser8250: 시리얼 포트 드라이버
- tpo_power: 디스플레이 초기화 및 관리
- hmi: 계기판의 그래픽 인터페이스 제공
pidin info 명령 출력결과를 보면, 계기판에서 사용되는 QNX 커널 버전이 6.3.2인 것을 확인할 수 있는데, 이는 QNX 6.3.0SP3 배포판에서 가져온 것을 확인할 수 있었다. 이 QNX 6.3.0SP3과 6.3.2 배포판은 인터넷에서 찾을 수 있는데, VirtualBox에서 설치할 수 있다. 설치 후, QNX 가상 머신에서는 계기판 애플리케이션 개발에 필요한 모든 도구를 사용할 수 있다.
QEMU의 Windows용 버전은 다음 링크에서 다운로드할 수 있다
- 다운로드: qemu-at91sam9263ek.7z
압축 풀고 qemu.bat를 실행하면 QNX가 에뮬레이터에서 시작된다. 다음 스크린샷은 에뮬레이터에서 실행 중인 QNX 시스템의 정보를 보여주며, 이 정보는 실제 계기판의 QNX 시스템 콘솔에서 보이는 정보와 크게 유사한데, QEMU를 사용하면 계기판을 직접 사용하거나 분해하지 않고 QNX 환경에서 애플리케이션을 개발하고 테스트할 수 있다. 대부분 하드웨어에 직접 접근하기 어렵기 때문에 가상 환경을 통해 접근하는 것을 추천한다.
QEMU를 사용하면 계기판에 물리적으로 접근하지 않고도 애플리케이션을 개발하고 디버깅할 수 있다. 생각해보자.
- 계기판을 포함한 모듈은 OBD를 통해 업데이트 할 수 있다.
- 계기판을 포함한 모듈의 프로그램은 ZIP 형식으로 SDD에 포함되어 있다.
이제 계기판 펌웨어 파일만 찾아 수정하면 된다. 이는 WERS등에서 확인할 수 있기 때문에 결코 어려운 일이 아니다. 펌웨어를 찾아 VBF를 수정하면 된다. 수정은 qvbf 에디터를 사용하면 된다.
- 다운로드: qvbf
SDD에는 기본적인 펌웨어 파일들이 포함되어 있다. 초기 L322는 AH42 헤더(PREFIX)를 갖는다. 계기판 펌웨어를 찾아보면 (SALMF1D41BA354473 기반)
- Assembly (F112) = Unknown -> AH42-10849-AS = AH42-14C026-CB
- Assembly (F113) = AH42-10849-AN -> None
- Calibration (F124) = AH42-14C088-AL -> AH42-14C088-AN
- Calibration (F125) = AH42-14C088-BJ = Up-to-date
- Calibration (F126) = AH42-14C088-XH11 -> None
- Hardware (F111) = AH42-14C226-AE
- Serial = MLS50644K
- Signal (F108) = AH42-14C318-AD -> None
- Signal (F120) = AH42-14C026-BJ = Up-to-date
- Strategy (F188) = AH42-14C026-AL -> AH42-14C026-AN
각각의 펌웨어는 5개 파일로 구성되어 있다는 것을 확인할 수 있다. 예를 들어 L322 펌웨어 파일을 살펴보면.
- AH42-14C026-AN.vbf: TMS470 펌웨어
- AH42-14C088-AN.vbf: TMS470 캘리브레이션
- AH42-14C026-CB.vbf: QNX 운영 체제 커널 파티션
- AH42-14C026-BJ.vbf: 프로그램 파티션 FS0P1 IFS2 b + 로그 파티션 FS0P3
- AH42-14C088-BJ.vbf: 이미지 파티션
참고로 TMS470 프로세서 펌웨어 프로그래밍 과정은 특별히 복잡하지 않다. PBL/SBL 부트로더를 사용하여 TMS470의 플래시 메모리를 업데이트하면 되기 때문이다. 반면 MB86R01의 펌웨어 업데이트는 복잡한 편이다. CAN 버스에 연결되어 있지 않고, TMS470 프로세서를 통해 외부와 상호작용하기 때문이다. MB86R01은 단순한 마이크로컨트롤러가 아니라 파일 시스템을 가진 운영 체제를 실행하는 프로세서이기 때문에 접근성이 좋지 않은 문제가 있는데 VBF 파일 헤더에는 프로그래밍될 블록의 가상 주소로 파일이 인코딩된 정보가 포함되어 있다는 힌트를 얻을 수 있다.
계기판 개발자들은 TMS470의 펌웨어 업데이트를 위해 UDS 프로토콜을 위한 자체 프로토콜을 구현한 것을 확인할 수 있다.
- MB86R01 펌웨어 업데이트를 위해 TMS470의 최대 가능 주소인 1MB를 초과하는 블록 주소가 사용된다 = 해당 블록이 MB86R01로 전송된다.
- 데이터 블록 전송 전에, 파일 이름이 인코딩된 가상 주소를 포함하는 블록이 전송된다.
- MB86R01에서 받은 데이터 블록은 이전 블록에서 인코딩된 이름의 파일로 파일 시스템에 저장된다.
- 저장된 파일은 압축 파일일 수 있으며, 이 경우 압축을 풀고 저장된다. 이는 일반 파일이나 프로그램일 수 있으며, 이 경우 파일 시스템에 저장된 후 실행된다.
- 펌웨어 파일이 포함된 블록에서 MB86R01의 플래시 저장소의 파티션 구조에 대한 추가 정보를 얻을 수 있다.
VBF 파일 정보를 살펴보면 MB86R01의 플래시 메모리 구조가 명확해진다. 전체 플래시 메모리 용량 64MB는 여러 파티션으로 나누어져 있으며, 각 파티션의 내용을 업데이트하기 위해 별도의 VBF 파일이 사용되고 있음을 추정할 수 있다.
파티션으로 나누는 것은 올바른 설계라 생각하는데, 이후 작업할 이미지 에셋이 별도 파티션에 저장되기에 이 파티션만 리프로그래밍한다면 매우 안정적인 작업이 가능하기 때문이다.
메모리 분배 구조
- IPL (Initial Program Loader): 초기 프로그램 로더
- IFS (Image File System): 읽기 전용 파일 시스템 이미지
- EFS (Embedded File System, FFS3 – Flash File System v3): 읽기/쓰기 파일 시스템 이미지
EFS와 IFS는 QNX의 표준 파일 시스템이며, QNX 배포판에는 이 파일 시스템의 내용을 추출하는 도구인 “dumpifs”와 “dumpefs”가 포함되어 있다. ifs/efs 파일 추출 방법은 다음과 같다.
- 다운로드: efsasm.py
dumpifs -x -b file.ifs dumpefs -t file.efs | python efsasm.py
images 파티션에는 계기판에서 사용되는 모든 이미지 파일이 저장되어 있다. 화살표, 스케일, 숫자 등이 포함되어 있다.
L322(AH42-14C088-BJ)에서 추출된 이미지 예제는 다음과 같다.
- L322 다운로드
차세대 계기판 이미지도 크게 다르지 않다. 단지 해상도가 향상됐기 때문에 파일 용량이 10배 가까이 크다.
- L494 다운로드
모든 이미지는 IFS로 저장되며 표준 도구를 이용해 추출할 수 있다. 자, 이제 VBF를 수정하고 클러스터에 직접 씌워보자. (to be continue…)
