제9부 로보틱스

9.2 JetPack·L4T I — 플래싱·부팅

9.2.1 이 장에서 배우는 것 / 선수 지식

9.1에서 Jetson 모듈을 골랐다. 이제 그것을 동작시키는 소프트웨어 — JetPack(SDK)과 L4T(Linux for Tegra) — 와 그것을 모듈에 탑재하는 플래싱·부팅 을 본다. Jetson은 PC가 아니라 임베디드 시스템이라, "OS를 설치"가 아니라 완전한 이미지를 플래시한다 — 이 과정·부트 흐름·버전 호환·커스텀 캐리어의 디바이스 트리가 임베디드 개발의 출발점이다.

핵심 통찰: Jetson 소프트웨어는 "버전이 묶인 스택" 이다 — JetPack 버전이 L4T(OS·BSP) + CUDA + TensorRT + 드라이버를 한 묶음으로 고정한다(5.2의 버전 종속과 동형). 그리고 플래싱은 PC와 다르다 — 모듈을 recovery 모드로 두고 호스트 PC에서 부트로더·커널·rootfs·펌웨어 전체를 일괄 플래시한다. 커스텀 캐리어 보드(9.1)를 쓰면 디바이스 트리로 하드웨어를 커널에 알려줘야 한다.

배우는 것:

JetPack — Jetson SDK(L4T + CUDA/TensorRT/VPI/멀티미디어 + 도구), 무엇을 묶나.
L4T(Linux for Tegra) — BSP(커널·부트로더·드라이버·rootfs), JetPack의 OS 층.
플래싱 — recovery 모드·호스트 PC·SDK Manager, PC 설치와 다른 점.
부트 흐름 — 임베디드 다단계 부트(Boot ROM→부트로더→커널→userspace), 파티션·secure boot.
버전 호환 — JetPack=L4T+CUDA+TensorRT 묶음, 모듈·SDK 정합.
디바이스 트리·커스텀 BSP — 커스텀 캐리어 보드의 하드웨어를 커널에 기술.

선수 지식: 9.1(Jetson 모듈·SoM·캐리어 보드)·5.2(TensorRT 버전 종속)·8.2(Tegra SoC). 컨테이너·배포는 9.3, Isaac은 9.7. 환경은 Jetson·호스트 PC.

정직: JetPack·L4T 버전·SDK Manager·플래싱 절차는 세대·모듈·버전 의존이다 — 이 장은 플래싱·부팅·버저닝의 개념·흐름을 가르치고 구체 명령·버전은 "그 시점 문서·모듈로 확인". 모듈마다(eMMC vs SD·세대) 절차가 다르다. secure boot·커스텀 BSP는 고급·제품 단계.

9.2.2 JetPack·L4T — 소프트웨어 스택

JetPack = L4T(OS/BSP) + AI/비전/멀티미디어 라이브러리 + 도구.

L4T(Linux for Tegra): Jetson의 BSP(Board Support Package) — Tegra SoC(8.2)용 리눅스 커널·부트로더·디바이스 드라이버·rootfs. JetPack의 OS 층. (Tegra는 SoC family명.)
JetPack: L4T 위에 CUDA·TensorRT·VPI·멀티미디어·도구를 묶은 SDK — 데이터센터·DRIVE와 같은 CUDA/TensorRT(8.3 연속).
묶음 버전: JetPack 버전이 L4T + CUDA + TensorRT + 드라이버 버전을 함께 고정 — 정합이 중요(9.2.6).

핵심: JetPack은 "Jetson에 까는 전체 스택"이고, L4T는 그 안의 OS·BSP다. 데이터센터에서 익힌 CUDA·TensorRT(제1~5부)가 그대로 들어 있어(8.3), 학습한 모델을 같은 도구로 엣지에 배포. 단 버전이 묶여 있어 정합이 핵심.

9.2.3 플래싱 — PC 설치와 다르다

Jetson은 PC처럼 "OS를 설치"하지 않는다 — 완전한 이미지를 모듈에 플래시한다:

플래싱 흐름(호스트 PC, 개념):

recovery 모드: 모듈을 자기 OS로 부팅하지 않고 호스트의 플래시 명령을 받는 상태. 핀/버튼으로 진입.
SDK Manager: 플래시 + JetPack 라이브러리(CUDA·TensorRT 등) 설치를 GUI로. 호스트 PC(보통 Ubuntu)에서.
호스트 필요: eMMC 모듈은 호스트 PC에서 USB로 플래시(SD처럼 빼서 못 씀). devkit은 SD/간편 플래시도.

핵심: 플래싱은 "recovery 모드 → 호스트 PC에서 완전 이미지 굽기 → 첫 부팅" 이다. PC의 OS 설치와 달리 모듈에 부트로더·커널·rootfs·펌웨어 전체를 일괄 플래시. SDK Manager가 플래시+SDK 설치를 묶어 준다. 모듈·세대마다 절차가 다르니 그 모듈 문서로.

9.2.4 부트 흐름 — 임베디드 다단계

Jetson 부트는 PC(BIOS→부트로더→OS)와 다른 임베디드 다단계 흐름이다:

(옵션) secure boot: 각 단계의 서명을 검증해 변조를 방지한다(제품 단계).

다단계 부트로더: Boot ROM(SoC 내장)이 초기 부트로더를 로드·검증하고, 다단계 부트로더가 펌웨어·디바이스 트리·커널을 로드. PC의 단일 BIOS와 다름.
디바이스 트리: 커널에 하드웨어 구성(어떤 디바이스가 어디에)을 알려주는 데이터 — 부트로더가 로드. 커스텀 캐리어(9.2.7)에 결정적.
secure boot(옵션): 각 단계의 서명을 검증해 변조된 펌웨어·커널을 막음 — 제품 보안(2.11 사이버보안 연결).

핵심: 임베디드 부트는 Boot ROM → 다단계 부트로더 → 커널(디바이스 트리) → userspace 다. 디바이스 트리가 하드웨어를 커널에 기술하므로, 표준 devkit이 아닌 커스텀 하드웨어는 디바이스 트리를 맞춰야 부팅·드라이버가 동작한다(9.2.7).

9.2.5 워크스루 — 플래시·검증

플래싱·검증 흐름(명령·버전은 모듈·시점 의존, 문서로).

   1) 환경: 호스트 PC(보통 Ubuntu) + USB 케이블 + Jetson(devkit/모듈)
   2) recovery 모드 진입: force-recovery 핀/버튼 + 전원 → USB 연결
        lsusb로 호스트가 모듈을 인식하는지 확인(NVIDIA Corp 장치)
   3) SDK Manager(또는 flash.sh)로 플래시 + JetPack 설치:
        SDK Manager: 모듈·JetPack 버전 선택 → 플래시 → 컴포넌트(CUDA·TensorRT) 설치
   4) 첫 부팅: 모듈이 부팅, 초기 설정
   5) 검증(모듈에서):
        cat /etc/nv_tegra_release      # L4T 버전
        dpkg -l | grep nvidia-jetpack  # JetPack 버전(확인 방법 버전별)
        nvcc --version                 # CUDA
        dpkg -l | grep -i tensorrt     # TensorRT 버전 (DLA는 trtexec --useDLACore로 확인, 5.2·8.4)
        jetson_release(또는 jtop)      # 종합 정보(커뮤니티 도구 jtop 유용)

실무: SDK Manager가 플래시+SDK를 묶어 가장 쉬운 출발점이다. 모듈·JetPack 버전을 고르면 정합된 스택을 설치. jtop(커뮤니티) 같은 도구로 GPU·DLA·전력을 모니터(9.4). 첫 부팅 후 버전을 확인해 의도한 JetPack인지 검증.

9.2.6 버전 호환 — 묶음

JetPack의 핵심 주의: 버전이 묶여 있다(5.2의 엔진 종속과 동형):

묶음 정합: JetPack 버전이 L4T·CUDA·TensorRT를 함께 고정 — 임의로 섞으면 호환 깨짐.
모듈 지원 범위: 모듈·세대마다 지원 JetPack이 다름 — 구세대 모듈은 최신 JetPack을 못 쓸 수 있음(확인).
엔진 재빌드(5.2): TensorRT 엔진은 그 JetPack의 TensorRT·GPU·DLA용 — JetPack 업그레이드 시 재빌드. 데이터센터에서 빌드한 엔진을 Jetson에 못 쓰고(GPU 다름), Jetson 타깃으로 빌드.

핵심: "모듈 + JetPack 버전 + 앱/엔진"의 정합이 임베디드 운영의 기본이다 — JetPack이 스택을 묶으므로 버전을 고정·관리하고, TensorRT 엔진은 타깃 JetPack으로 빌드(5.2). 데이터센터-엣지 연속이되 엔진은 타깃별 재빌드(GPU·DLA·버전 종속).

9.2.7 커스텀 캐리어·디바이스 트리

표준 devkit이 아니라 커스텀 캐리어 보드(9.1 — 자기 로봇의 I/O·센서)에 SoM을 통합하면, 하드웨어가 다르므로 소프트웨어를 맞춰야 한다:

디바이스 트리: 하드웨어를 커널에 기술하는 데이터 — 커스텀 캐리어의 카메라·센서·핀이 devkit과 다르면 디바이스 트리를 수정해야 인식·동작.
커스텀 BSP: L4T를 그 보드에 맞게(커널 설정·드라이버·부트로더 핀). 제품화의 큰 일.
devkit→제품: devkit으로 개발하되, 제품(커스텀 캐리어)은 디바이스 트리·BSP 커스터마이징이 필요 — 이것이 SoM 통합의 소프트웨어 측면.

견해: 표준 devkit은 그대로 부팅·동작하지만, 커스텀 캐리어는 디바이스 트리·BSP를 맞춰야 한다 — 하드웨어(센서·핀)가 다르면 소프트웨어가 그것을 알아야. 이것이 SoM 통합(9.1)의 소프트웨어 작업이고, 제품화의 난점. 표준 카메라·구성을 쓰면 줄지만, 커스텀 하드웨어는 BSP 작업이 따른다.

9.2.8 중간 점검 (체크포인트)

[ ] JetPack(SDK = L4T + CUDA/TensorRT/VPI + 도구) 과 L4T(BSP·OS 층) 를 구분한다.
[ ] Jetson 플래싱이 PC 설치와 다름(완전 이미지·recovery 모드·호스트 PC·SDK Manager)을 안다.
[ ] 임베디드 다단계 부트 흐름(Boot ROM→부트로더→커널(디바이스 트리)→userspace)을 안다.
[ ] JetPack 버전 묶음(L4T·CUDA·TensorRT 정합)과 모듈 지원 범위·엔진 재빌드(5.2)를 안다.
[ ] 커스텀 캐리어에 디바이스 트리·BSP 커스터마이징이 필요함을 안다.

증상→의심: 모듈이 안 부팅 → 플래시 실패·이미지 손상·잘못된 모듈/JetPack → 재플래시·버전 확인. 호스트가 모듈 인식 못 함 → recovery 모드·USB·드라이버 → lsusb·recovery 재진입. CUDA/TensorRT 버전 불일치 → JetPack 묶음 → 정합 버전. TensorRT 엔진 로드 실패 → 다른 GPU/버전 빌드(5.2) → Jetson 타깃 재빌드. 커스텀 보드 카메라 인식 안 됨 → 디바이스 트리 → 맞춤. 구세대 모듈에 신 JetPack 설치 실패 → 지원 범위 → 확인. secure boot로 커스텀 커널 거부 → 서명 → 키·서명.

9.2.9 트레이드오프·대안

결정	트레이드오프
SDK Manager vs 스크립트	쉬움·GUI vs 자동화·CI·제어
표준 devkit vs 커스텀 캐리어	바로 동작 vs 제품·디바이스 트리·BSP
최신 JetPack vs 안정	신기능·CUDA vs 검증·모듈 지원
SD vs eMMC	간편·교체 vs 신뢰·양산
secure boot on/off	보안·복잡 vs 단순·개발

견해: 개발은 devkit + SDK Manager로 빠르게, 제품은 커스텀 캐리어 + 디바이스 트리·BSP + (CI용) flash 스크립트로. JetPack 버전은 모듈 지원·앱 호환으로 고정·관리(묶음). 양산 제품은 eMMC·secure boot. 데이터센터에서 빌드한 모델을 Jetson 타깃으로 엔진 재빌드(5.2·8.3). 임베디드는 버전 정합·BSP가 PC보다 까다로우니 그 모듈 문서로.

비엔비디아 정직: 임베디드 플래싱·BSP·디바이스 트리는 임베디드 리눅스 일반의 개념(다른 SoC·보드도 유사). JetPack/L4T의 강점은 CUDA/TensorRT/VPI·AI 스택을 묶고 SDK Manager로 통합·데이터센터 연속(8.3). 임베디드 리눅스 경험이 있으면 친숙하고, 디바이스 트리·BSP는 다른 SoC와 같은 작업. 구체 절차는 모듈·세대 의존 — 그 시점 문서로.

9.2.10 흔한 함정

PC처럼 OS 설치 가정. Jetson은 완전 이미지를 플래시 — recovery 모드·호스트 PC·SDK Manager.
JetPack 버전 섞기. L4T·CUDA·TensorRT가 묶임 — 임의로 섞으면 호환 깨짐. 정합 버전.
모듈 지원 범위 무시. 구세대 모듈에 최신 JetPack이 안 될 수 있음 → 지원 매트릭스 확인.
데이터센터 엔진을 Jetson에. TensorRT 엔진은 GPU·버전 종속(5.2) — Jetson 타깃 재빌드.
커스텀 캐리어에 devkit 이미지. 디바이스 트리가 안 맞아 하드웨어 인식 실패 → 디바이스 트리·BSP.
recovery 모드 안 들어감. force-recovery 핀/버튼·전원 순서 — 모듈별 절차.
secure boot 무시(제품). 변조 방지가 필요한 제품은 secure boot — 단 키·서명 관리.
절차를 버전 불문. 플래싱·SDK Manager가 세대·모듈마다 다름 — 그 모듈 문서.

9.2.11 연습문제

연습 1 (JetPack·L4T). JetPack과 L4T의 관계를 설명하고, 왜 "버전이 묶여 있다"가 임베디드 운영에 중요한지 답하라.

정답

관계: L4T(Linux for Tegra) = Jetson의 BSP — Tegra SoC(8.2)용 리눅스 커널·부트로더·디바이스 드라이버·rootfs(OS 층). JetPack = L4T 위에 CUDA·cuDNN·TensorRT(5.2)·VPI(8.5)·멀티미디어·개발 도구를 묶은 SDK. 즉 JetPack = L4T(OS) + AI/비전/멀티미디어 라이브러리 + 도구. "버전이 묶여 있다"의 중요성: JetPack 버전이 L4T + CUDA + cuDNN + TensorRT + 드라이버를 함께 고정한다 — 정합된 묶음. 임의로 한 컴포넌트만 바꾸면(예: TensorRT만 다른 버전) 호환이 깨질 수 있다. 임베디드 운영에 중요한 이유: ① 앱·엔진이 그 버전에 빌드 — TensorRT 엔진은 그 JetPack의 TensorRT·GPU·DLA용(5.2)이라 JetPack 바뀌면 재빌드, 라이브러리도 그 CUDA에 링크. ② 모듈 지원 범위 — 모듈·세대마다 지원 JetPack이 달라(구세대는 최신 미지원 가능) "모듈+JetPack+앱"의 정합을 맞춰야. ③ 재현·관리 — production에서 JetPack 버전을 고정·관리해야 빌드·배포가 일관. 데이터센터에서 빌드한 엔진을 Jetson에 못 쓰고(GPU 다름) Jetson 타깃으로 빌드(8.3 연속이되 엔진은 타깃별). 그래서 임베디드는 PC보다 버전 정합이 까다롭고, JetPack 버전을 핀하고 그에 맞춰 앱·엔진을 빌드·관리한다.

연습 2 (플래싱). Jetson 플래싱이 PC OS 설치와 어떻게 다른지, recovery 모드·SDK Manager의 역할과 함께 설명하라.

정답

차이: PC는 OS 설치 프로그램이 BIOS/UEFI 위에서 디스크에 OS를 설치한다. Jetson(임베디드)은 모듈(SoC+스토리지)에 완전한 이미지 전체를 일괄 플래시 — 이미지 = 부트로더 + 커널 + rootfs + 펌웨어 + 파티션. PC처럼 "설치"가 아니라 모듈 스토리지에 전체 시스템을 플래시한다. recovery 모드의 역할: Jetson을 자기 OS로 부팅하지 않고 호스트 PC의 플래시 명령을 받는 상태로 둠 — force-recovery 핀/버튼 + 전원으로 진입, USB로 호스트 연결. eMMC 모듈은 SD처럼 빼서 못 쓰므로 recovery 모드로 호스트에서 플래시해야. SDK Manager의 역할: NVIDIA의 GUI 도구로 ① 모듈·JetPack 버전 선택, ② 이미지 플래시(부트로더·파티션·커널·rootfs), ③ JetPack 컴포넌트 설치(CUDA·TensorRT 등)를 한 번에 — 호스트 PC(보통 Ubuntu)에서. 흐름: recovery 모드 진입 → 호스트가 모듈 인식(lsusb) → SDK Manager로 플래시+SDK 설치 → 첫 부팅·초기 설정 → 버전 검증. 즉 "OS 설치"가 아니라 "recovery 모드에서 호스트가 완전 이미지를 굽고 SDK를 설치". devkit은 SD 카드·간편 플래시도 있으나, 일반 eMMC 모듈은 호스트+recovery. 모듈·세대마다 절차가 달라 그 모듈 문서로(확인 필요). SDK Manager가 가장 쉬운 출발점, CI엔 flash 스크립트.

연습 3 (부트 흐름). Jetson의 임베디드 다단계 부트 흐름을 단계로 설명하고, 디바이스 트리의 역할을 강조하라.

정답

부트 흐름(다단계): ① Boot ROM — SoC에 내장된 변경 불가 코드, 전원 시 가장 먼저 실행, 초기 부트로더를 로드·검증(secure boot면 서명 확인). ② 부트로더(다단계) — 예 MB1/MB2/CBoot/UEFI 등(세대 의존), 펌웨어·디바이스 트리·커널을 로드. PC의 단일 BIOS와 달리 다단계. ③ 리눅스 커널(Tegra, L4T) — 디바이스 트리로 하드웨어를 인식하고 드라이버 로드. ④ init(systemd) → userspace(rootfs) — 서비스·앱(JetPack 런타임·CUDA·앱). (옵션 secure boot: 각 단계 서명 검증으로 변조 방지.) 디바이스 트리의 역할(강조): 디바이스 트리(Device Tree)는 커널에 "이 보드의 하드웨어 구성" (어떤 디바이스가 어느 주소·핀에, 카메라·센서·버스)을 기술하는 데이터 — 부트로더가 로드해 커널에 전달. 왜 중요: 커널은 하드웨어를 직접 모르고 디바이스 트리로 알므로, 하드웨어가 표준 devkit과 다르면(커스텀 캐리어, 9.1) 디바이스 트리를 맞춰야 카메라·센서·핀이 인식·동작한다. 디바이스 트리가 틀리면 그 디바이스가 부팅돼도 인식 안 됨. 그래서 표준 devkit은 그대로 부팅하지만, 커스텀 캐리어는 디바이스 트리(+BSP) 커스터마이징이 필수 — 제품화의 소프트웨어 작업(9.2.7). 임베디드 부트는 PC와 다른 다단계 + 디바이스 트리 기반 하드웨어 기술이 핵심.

연습 4 (커스텀 캐리어). 표준 devkit으로 개발하다 커스텀 캐리어 보드(다른 카메라·I/O)로 제품화할 때 소프트웨어 측면에서 무엇을 해야 하나?

정답

커스텀 캐리어는 devkit과 하드웨어(카메라 수·종류·핀·포트·전원·센서)가 다르므로, 소프트웨어가 그 하드웨어를 알도록 맞춰야: ① 디바이스 트리(Device Tree) 수정 — 커널에 "이 보드의 하드웨어 구성"을 기술하는데, devkit과 다른 카메라(CSI 레인·I2C 주소)·센서·핀·디바이스를 디바이스 트리에 반영해야 커널이 인식·드라이버 로드. devkit 디바이스 트리 그대로면 커스텀 카메라가 인식 안 됨. ② 커스텀 BSP — L4T(커널·부트로더)를 그 보드에 맞게: 커널 설정(필요 드라이버·모듈), 부트로더 핀·전원 설정, 보드별 드라이버(커스텀 센서·카메라 드라이버 추가). ③ 커스텀 rootfs — 앱·설정·서비스. ④ 카메라/센서 드라이버 — devkit과 다른 카메라 센서면 그 센서의 드라이버·튜닝(ISP). ⑤ 플래시 이미지 빌드 — 위를 반영한 커스텀 L4T 이미지를 빌드해 플래시. ⑥ 검증 — 커스텀 보드에서 모든 디바이스·카메라·센서가 인식·동작하는지. 이것이 SoM 통합(9.1)의 소프트웨어 측면이자 제품화의 난점 — 하드웨어(SoM)는 검증됐지만 캐리어가 다르면 BSP·디바이스 트리 작업이 따른다. 줄이는 법: 표준 카메라·구성을 쓰면 디바이스 트리 작업이 줄고, NVIDIA/파트너의 카메라 모듈·레퍼런스를 쓰면 드라이버 재사용. 임베디드 리눅스의 일반 작업(다른 SoC도 디바이스 트리·BSP)이라 임베디드 경험이 도움. devkit으로 빠르게 개발하되 제품은 BSP 커스터마이징을 계획. 자격·시간이 드는 일이라 제품 일정에 반영.

연습 5 (연속 스택). 데이터센터에서 학습·빌드한 TensorRT 엔진을 Jetson에 그대로 못 쓰는 이유와, 올바른 배포 흐름을 설명하라.

정답

못 쓰는 이유(5.2 엔진 종속): TensorRT 엔진(plan)은 빌드 시 그 GPU 아키텍처·TensorRT 버전·정밀도에 특화되어 굳혀진다(5.2 오토튜닝). 데이터센터 GPU(예: H100, Hopper)와 Jetson GPU(임베디드 Ampere급 등)는 아키텍처가 다르고, TensorRT 버전(JetPack 묶음 9.2.6)도 다르며, Jetson은 DLA(8.4)도 있다. 그래서 데이터센터에서 빌드한 엔진은 Jetson에서 로드 실패나 미동작 — GPU·버전·DLA가 안 맞음. 올바른 배포 흐름(8.3 연속이되 엔진은 타깃별): ① 데이터센터에서 학습(제4~6부, NeMo 6.2) — 모델을 ONNX 등 이식 가능한 포맷으로(가중치·구조). ② Jetson 타깃으로 엔진 빌드 — 그 Jetson의 JetPack(TensorRT 버전)·GPU·DLA를 타깃으로 TensorRT 엔진을 빌드(trtexec/API, 5.2), DLA 오프로드(--useDLACore, 8.4)·정밀도(INT8/FP16, 5.4)를 엣지에 맞게. 빌드는 그 Jetson에서(또는 같은 구성에서). ③ 배포 — 빌드한 엔진을 Jetson 앱에 탑재해 추론(JetPack 런타임). ④ 검증 — 정확도(5.4)·성능·전력. 핵심: 모델(이식 가능)은 데이터센터-엣지 연속이되, 엔진은 타깃별로 재빌드(GPU·DLA·버전 종속). CUDA·TensorRT가 같은 스택이라(8.3) 코드·워크플로는 재사용하되 엔진만 타깃 빌드. 데이터센터(학습·개발)→Jetson(엣지 배포)이 단절이 아니라 이어지는 것이 엔비디아 풀스택의 가치이되, 엔진 종속(5.2)은 임베디드에서도 동일. JetPack 버전을 핀하고 그에 맞춰 빌드.

9.2.12 요약 · 다음 장

JetPack(SDK) = L4T(BSP·OS: 부트로더·커널·드라이버·rootfs) + CUDA/TensorRT/VPI/멀티미디어 + 도구. 데이터센터·DRIVE와 같은 CUDA/TensorRT(8.3), 단 버전이 묶여 정합이 중요.
Jetson 플래싱은 PC 설치와 다르다 — 완전 이미지를 recovery 모드에서 호스트 PC(SDK Manager)로 플래시한다. 모듈·세대마다 절차가 다름.
부트는 임베디드 다단계(Boot ROM→부트로더→커널(디바이스 트리)→userspace) — 디바이스 트리가 하드웨어를 커널에 기술. secure boot 옵션.
JetPack 버전 묶음(L4T·CUDA·TensorRT 정합)·모듈 지원 범위를 관리하고, TensorRT 엔진은 Jetson 타깃으로 재빌드(5.2). 데이터센터-엣지 연속이되 엔진은 타깃별.
커스텀 캐리어는 디바이스 트리·BSP 커스터마이징이 필요(하드웨어가 devkit과 다르면) — SoM 통합(9.1)의 소프트웨어 측면·제품화 난점.
정직: 플래싱·버전·BSP는 세대·모듈 의존(그 모듈 문서), 임베디드 리눅스 일반 개념(도구 중립).

다음 장: 9.3 JetPack·L4T II — 컨테이너·배포. 플래시·부팅한 Jetson에 애플리케이션을 컨테이너로 배포·운영하는 법 — NGC 컨테이너·L4T 베이스 이미지·엣지 컨테이너 런타임·OTA 업데이트를, 데이터센터 컨테이너(제7부)와의 공통·차이와 함께 본다(실습).