8. DTS 컴파일과 디컴파일
8.1 Live DT를 디컴파일 하는 이유
실행 중인 시스템의 Live DT(Live Device Tree)를 디컴파일하는 이유는 한마디로 "최종적으로 커널이 보고 있는 하드웨어 설계도가 무엇인지 확인하기 위해서"입니다.
여러 장의 설계도(.dtsi, .dts)와 포스트잇(.dtbo)이 복잡하게 얽혀 있는 상황에서, "결국 지금 하드웨어 상태가 어떤데?"라는 질문에 답을 주는 가장 확실한 진실이기 때문이죠.
상세한 이유는 다음과 같습니다.
1. Overlay 합체 결과 확인 (The Final Merge)
여러 개의 Device Tree Overlay(.dtbo)를 로드한 경우, 각 조각이 의도한 위치에 올바르게 붙었는지 확인해야 합니다.
- 이유: 소스 코드만 봐서는 오버레이가 덮어쓰기에 성공했는지, 아니면 경로가 틀려서 씹혔는지 알기 어렵습니다. Live DT를 보면 모든 오버레이가 반영된 '최종 통합본'을 볼 수 있습니다.
2. 부트로더(U-Boot)의 수정 사항 확인
부트로더는 커널을 실행하기 직전에 DT를 메모리에 올리고 일부 내용을 동적으로 수정합니다.
- 이유: * chosen 노드의 bootargs가 올바르게 전달되었는가?
- 이더넷의 MAC 주소가 부트로더에서 제대로 주입되었는가?
- 실제 가용 메모리(RAM) 사이즈가 시스템에 맞게 수정되었는가?
- 이런 정보는 소스 코드에는 없고, 실행 중인 시스템의 DT에만 존재합니다.
3. 드라이버 프로빙(Probing) 이슈 디버깅
분명 드라이버를 올렸는데 probe() 함수가 호출되지 않는다면, 십중팔구 Live DT의 compatible 문자열이 드라이버와 맞지 않기 때문입니다.
- 이유: status = "okay"로 바뀌었는지, 혹은 interrupt 번호가 다른 장치와 충돌하여 값이 변하지 않았는지 실시간으로 확인하여 디버깅 시간을 단축할 수 있습니다.
4. 소스 코드가 없는 시스템의 역공학 (Reverse Engineering)
제조사로부터 바이너리(DTB)만 받고 소스 코드(DTS)를 받지 못한 경우입니다.
- 이유: 시스템이 하드웨어를 어떻게 정의하고 있는지 파악하기 위해 /proc/device-tree를 긁어와서 사람이 읽을 수 있는 .dts로 변환하여 분석합니다.
💡 Live DT를 추출하는 방법
리눅스 시스템에서는 dtc(Device Tree Compiler) 도구를 이용해 아주 간단하게 현재 상태를 덤프할 수 있습니다.
# /proc/device-tree 디렉토리(파일 시스템)를 읽어서 dts 형식으로 출력
$ dtc -I fs -O dts /proc/device-tree > live_system.dts
이 명령어를 실행하면, 수많은 파일로 쪼개져 있던 설정들이 하나의 거대한 .dts 파일로 합쳐져서 나옵니다. 개발자들은 이 파일을 열어보고 "아, 결국 내 I2C 센서가 0x3c 주소로 잘 등록됐구나!" 하고 안심하게 되는 것이죠.

참고: https://www.minzkn.com/linuxkernel/pages/device-tree.html#dt-device-node
'Embedded : : Linux > : : Device Tree' 카테고리의 다른 글
| [Device Tree] 10. Device Tree + Platform Driver 통합 (0) | 2026.03.04 |
|---|---|
| [Device Tree] 9. 커널 OF(Open Firmware) API (0) | 2026.03.04 |
| [Device Tree] 7. Device Tree Bindings (0) | 2026.03.04 |
| [Device Tree] 6. Device Tree Overlay (DTBO) (0) | 2026.03.04 |
| [Device Tree] 5. .dtsi 인클루드 구조와 오버라이드 (0) | 2026.03.04 |