Jetson 양산 OS 개발기 ② · 바이코드(ByCode)
Jetson 기반 제품의 OS를 준비하는 개발자에게 첫 부팅은 출발점이다. 하지만 화면에 로그인 프롬프트가 보인다고 검증이 끝나지는 않는다. 이번 기록에서는 meta-tegra 위에서 만든 Yocto 이미지를 Jetson Orin Nano 개발 키트에 올렸다. 첫 풀빌드는 캐시가 없는 상태에서 8,179개 task를 처리했고, 29분 뒤 오류 없이 끝났다. 그렇다면 무엇을 확인해야 스톡 JetPack이 아니라 의도한 이미지가 부팅됐다고 말할 수 있을까?
이 글의 수치와 로그 판정은 2026년 6월 자체 실측이다. 커뮤니티 BSP인 meta-tegra를 우리가 개발했다고 말하지 않는다. 우리는 그 BSP와 고정한 레이어 조합 위에서 이미지를 빌드하고, 플래시하고, 부팅 결과를 검증했다.
빌드 재현성은 레이어 조합에서 시작한다
Yocto Project에서 BitBake는 recipe와 configuration data를 해석해 task를 실행한다. 여러 data source는 layer로 묶인다. 따라서 bitbake 명령 한 줄만 저장해서는 같은 이미지를 다시 만들기 어렵다. 사용한 layer와 각 revision을 함께 고정해야 한다. Yocto Project Concepts
이번 빌드에서는 scarthgap 계열의 meta-tegra와 demo-image-base를 사용했다. 첫 풀빌드는 sstate cache 일치율 0%에서 시작해 다음 결과를 남겼다.
$ bitbake demo-image-base
...
Tasks Summary: Attempted 8179 tasks of which 0 didn't need to be rerun and all succeeded.
실측 wall-clock 시간은 29분이었다. 이는 다른 호스트에서도 같은 시간이 나온다는 뜻이 아니다. CPU·디스크·네트워크·cache 상태에 따라 달라진다. 이 수치는 이 환경의 첫 빌드 기준선으로만 남겼다.
그래서 빌드에 쓴 레이어를 커밋 해시까지 고정해 기록했다. oe-core db668121, meta-tegra d2613418을 비롯한 다섯 레이어다. 이 값이 왜 중요한지는 뒤의 검증 단계에서 드러난다.
빌드 중 do_fetch 다섯 건은 primary upstream에서 실패한 뒤 mirror로 내려받았다. 이 경험은 source mirror나 DL_DIR 보존을 나중 문제가 아니라 첫 빌드 설계에 넣어야 한다는 뜻이다. 이미지를 다시 만들 수 있어야 보드에서 본 문제도 다시 재현할 수 있다.
플래시는 이미지와 부트 체인을 함께 맞춘다
Jetson Orin 계열의 부트 흐름에는 BootROM, PSCROM, MB1, MB2, UEFI가 포함된다. NVIDIA의 R36.5 문서도 Orin 계열의 부트 흐름을 이 단계로 설명한다. NVIDIA Boot Architecture
이번 플래시에서는 doflash.sh로 QSPI의 부트로더와 SD 카드의 이미지 조합을 맞췄다. recovery mode에서 플래시한 뒤, J14 시리얼 헤더를 USB-TTL 어댑터에 교차 연결해 콘솔을 관찰했다. 배선은 J14 pin 3(RXD)↔어댑터 TXD, pin 4(TXD)↔어댑터 RXD, pin 7(GND)이다.
여기서 보드가 아니라 호스트 도구가 문제를 만들었다. macOS에서 쓴 USB-TTL 어댑터는 클론 장치 또는 driver 문제로 출력이 깨졌다. Linux 호스트로 바꾸자 같은 이미지와 보드에서 정상 로그를 확인했다. 콘솔이 보이지 않을 때 곧바로 이미지 실패로 결론 내리면 안 되는 이유다. 관찰 경로와 대상 보드를 분리해 진단해야 한다.
부팅 로그는 네 단계로 판정한다
첫 부팅 로그에는 MB1, UEFI(EDK II), EFI stub: Booting Linux, systemd, login 순서가 보였다. 하지만 부트 메시지의 존재만으로는 어떤 OS가 올라왔는지 알 수 없다. 우리는 로그인 뒤 아래 네 가지를 확인했다.
cat /etc/os-release
uname -a
systemctl --failed
nvbootctrl dump-slots-info
첫째, /etc/os-release에서 ID=tegrademo, OE4Tegra Demonstration Distro 5.0.17 (scarthgap)을 확인했다. 이 값은 플래시 대상이 스톡 JetPack rootfs가 아니라 빌드한 Yocto 이미지라는 식별 근거다. 더 나아가 os-release의 VERSION 필드는 5.0.17+snapshot-db668121…였다. 빌드 때 고정한 oe-core 커밋 db668121이 이 필드에 그대로 담겨 있다. 빌드와 부팅이 같은 커밋에서 나왔다는 산 증거다. 재현성은 구호가 아니라 이렇게 대조로 확인한다.
둘째, uname은 5.15.185-l4t-r36.5-1033.33과 aarch64를 반환했다. 고정한 Jetson Linux 계열과 커널이 일치하는지 보는 단계다. 셋째, systemctl --failed의 결과는 0이었다. 로그인만 되는 상태와 실패한 서비스가 없는 상태는 다르므로, 이 확인을 통과 조건에 넣었다.
넷째, nvbootctrl은 version 36.5.0, active slot A, 슬롯 2개를 보고했다. NVIDIA의 Jetson Linux 문서에는 root file system redundancy 항목이 있고, A/B 구성은 업데이트 실패 시 이전 상태로 돌아갈 경로를 설계할 때 필요한 기반이다. NVIDIA Root File System 다만 개발 키트에서 두 슬롯을 봤다는 사실이 OTA가 완성됐다는 뜻은 아니다. 실제 업데이트와 롤백은 별도 시나리오로 검증해야 한다.
아직 성능 수치도 양산 준비도 아니다
커널 시작부터 로그인까지의 예비 관찰값은 약 14~15초였다. 전원 인가부터의 공식 측정이 아니며, 성능 목표나 외부 공약으로 쓰지 않는다. 측정 기준·반복 횟수·주변 장치 상태를 정한 뒤 따로 비교해야 한다.
DCE queue 정보 실패, OP-TEE 보안 경고, RTC가 1970-01-01로 시작하는 현상도 확인했다. 헤드리스 환경과 무관한 메시지, 개발 키트 보안 구성, RTC 배터리 부재가 각각 원인 후보다. 어느 것도 이번 첫 부팅을 막지는 않았지만, 양산 보드에서는 그대로 넘길 항목이 아니다. NTP 동기화·보안 구성·실제 디스플레이 요구사항을 제품 조건에 맞춰 다시 점검해야 한다.
정리
이번 단계의 결과는 단순하다. meta-tegra 기반 Yocto 이미지를 빌드해 Jetson Orin Nano에서 부팅했고, OS 식별값·커널·실패 서비스·부트 슬롯으로 그 사실을 확인했다. 그 과정에서 fetch mirror와 시리얼 어댑터처럼 보드 바깥의 재현성 문제도 드러났다.
개발 키트의 첫 부팅은 양산 완료 선언이 아니다. 다만 다음 단계인 컨테이너 GPU 실행과 무인 업데이트를 검증할 수 있는, 확인 가능한 시작점은 만들었다. 다음 편에서는 이 OS 위에서 JetPack에서 뺀 CUDA·TensorRT를 컨테이너로 되돌려, 표준 CDI 모드로 GPU를 붙인다.
참고 자료
- OE4T, meta-tegra — NVIDIA Jetson 플랫폼용 BSP layer
- NVIDIA, Jetson Linux R36.5 Boot Architecture
- NVIDIA, Jetson Linux R36.5 Root File System
- Yocto Project, Scarthgap 5.0.17 Concepts
- 자체 실측(2026년 6월): build log, flash record, serial boot log,
systemctl --failed,nvbootctrl출력
이 글은 바이코드가 Jetson 기반 양산용 Edge OS를 만드는 과정을 공개하는 개발기 시리즈의 두 번째 편입니다.