Booil Jung

NVIDIA Jetson Orin 플랫폼에 Preempt-RT 적용을 위한 종합 가이드

이 파트는 “어떻게”에 앞서 “왜”와 “무엇을”에 대한 기반을 구축합니다. 이는 전체적인 맥락을 설정하고, 핵심 용어를 정의하며, 사용자가 초기에 어떤 구현 경로를 선택할지에 대한 중요한 결정을 내리도록 안내합니다.

로보틱스, 산업 자동화, 전문 오디오 시스템과 같은 분야에서는 결정론적(deterministic) 작업 수행이 필수적입니다. 표준 운영 체제는 평균 처리량 최적화에 중점을 두므로, 특정 시간 내에 작업 완료를 보장하지 못합니다. 이러한 시스템은 표준 커널이 제공하는 “소프트(soft)” 실시간 요구사항을 충족할 수는 있지만, PREEMPT_RT가 목표로 하는 밀리초 또는 마이크로초 단위의 엄격한 “하드(hard)” 실시간 보장은 제공하지 못합니다.1

PREEMPT_RT(Real-Time Preemption)는 리눅스 커널을 실시간 운영 체제(RTOS)로 변환하는 것을 목표로 하는 패치 모음입니다. 이 패치의 핵심 기능은 커널 코드의 임계 구역(critical sections)에서 선점을 허용하는 것입니다. 기존 커널에서는 스핀락(spinlock)이나 인터럽트 핸들러가 실행되는 동안 다른 고우선순위 작업이 실행을 시작할 수 없어 예측 불가능한 지연(latency)이 발생했습니다. PREEMPT_RT는 이러한 구성 요소들을 대부분 선점 가능하게 만들어, 시스템의 최악 실행 시간(worst-case latency)을 획기적으로 줄입니다. 이 패치셋은 점진적으로 메인라인 리눅스 커널에 통합되고 있습니다.2

Jetson 장치에 PREEMPT_RT를 적용하는 것은 일반적인 PC 환경과는 근본적으로 다릅니다. 가장 큰 도전은 NVIDIA의 독점적인 OOT(Out-of-Tree) 모듈과의 깊은 통합 문제입니다. GPU(nvgpu), 디스플레이(nvdisplay), 멀티미디어 가속기 등 Jetson의 핵심 기능을 담당하는 이 모듈들은 특정 커널 버전과 설정에 맞춰 컴파일됩니다.3 따라서 커널 소스를 수정하고 PREEMPT_RT 패치를 적용하면, 이 독점 모듈들과의 호환성이 깨져 부팅 실패, 디스플레이 비활성화 등 심각한 문제를 야기할 수 있습니다. 이것이 Jetson에서 RT 커널을 구축할 때 가장 빈번하게 마주치는 실패의 원인입니다.4

Jetson Orin에서 실시간 커널을 구현하는 방법은 크게 두 가지로 나뉩니다. 각 방법은 장단점이 명확하므로, 사용 사례와 기술적 요구사항에 따라 신중하게 선택해야 합니다.

  1. 패키지 기반 방법 (apt): NVIDIA가 제공하는 사전 빌드된 데비안 패키지를 통해 설치하는 방식입니다. 빠른 평가나 복잡한 커널 커스터마이징이 필요 없는 경우에 적합합니다.6
  2. 소스 컴파일 방법: 커널 소스를 직접 다운로드하고 패치하여 빌드하는 방식입니다. 과정이 복잡하지만, 커널의 모든 설정을 제어할 수 있어 고급 사용 사례나 특정 하드웨어 드라이버 통합에 필수적입니다.6

apt를 이용한 패키지 설치 방식이 존재한다는 사실은 이 과정이 간단한 명령어 하나로 해결될 것이라는 인상을 줄 수 있습니다. 그러나 개발자 커뮤니티 포럼에는 이 “공식적인” 방법으로도 부팅 실패를 겪는 사례들이 다수 보고됩니다.9 이는 커널, UEFI 부트로더, 그리고 루트 파일 시스템 간의 상호작용이 설치 방법에 관계없이 매우 민감하다는 것을 시사합니다. NVIDIA의 공식 문서 6는 apt 설치를 간단한 절차로 소개하지만, 실제로는 사용자가 검은 화면이나 부팅 중단 현상을 겪고 UEFI 부트 메뉴에서 수동으로 복구해야 하는 경우가 발생합니다.9 이러한 불일치는 패키지 설치가 파일 배치는 처리하지만, 특히 NVMe SSD와 같은 비표준 저장 장치 구성에서 부트 설정을 항상 안정적으로 업데이트하지는 못한다는 점을 암시합니다. 따라서 “쉬운 경로”를 선택하더라도 부팅 프로세스에 대한 이해와 시리얼 콘솔 준비는 필수적입니다. 복잡성은 단순히 커널을 빌드하는 데 있는 것이 아니라, Jetson의 특정 부트 아키텍처에 통합하는 과정 전체에 존재합니다.

이 방법은 NVIDIA가 제공하는 사전 빌드된 RT 커널 패키지를 사용하여 시스템을 신속하게 구성하는 절차를 설명합니다.

가장 중요하고 첫 번째 단계는 현재 시스템에 설치된 Jetson Linux, 즉 L4T(Linux for Tegra)의 정확한 버전을 확인하는 것입니다. 사용자는 종종 SDK 설치 프로그램인 JetPack 버전은 알고 있지만, NVIDIA의 저장소(repository)와 소스 코드는 L4T 버전을 기준으로 관리됩니다.13 다음 명령어를 사용하여 L4T 버전을 정확히 확인할 수 있습니다.

$ cat /etc/nv_tegra_release

14

이 명령의 출력 첫 줄에서 # R36 (release), REVISION: 4.3 과 같은 정보를 통해 L4T 버전을 알 수 있습니다. 커뮤니티에서 개발한 jetson_stats 유틸리티는 더 사용자 친화적인 정보를 제공하기도 합니다.16

사용자가 자신의 JetPack 버전을 L4T 버전으로 변환할 수 있도록 다음 표를 제공합니다. 이 정보는 올바른 저장소 주소와 소스 코드를 선택하는 데 필수적입니다. 예를 들어, 사용자가 “JetPack 6.2”를 설치했다는 것을 알고 있다면, 이 표를 통해 해당 L4T 버전이 “r36.4”임을 즉시 확인할 수 있습니다. 이는 잘못된 저장소를 사용하여 발생할 수 있는 의존성 오류나 호환되지 않는 커널 설치를 방지합니다.

JetPack 버전 L4T 버전 지원 Orin 모델
6.2.1 36.4.3 AGX Orin, Orin NX, Orin Nano
6.2 36.4 AGX Orin, Orin NX, Orin Nano
6.0 36.3 AGX Orin, Orin NX, Orin Nano
5.1.2 35.4.1 AGX Orin, Orin NX, Orin Nano
5.1.1 35.3.1 AGX Orin, Orin NX, Orin Nano
5.1 35.2.1 AGX Orin, Orin NX
5.0.2 35.1 AGX Orin

이 표는 13의 정보를 기반으로 작성되었습니다.

  1. 텍스트 편집기를 사용하여 /etc/apt/sources.list.d/nvidia-l4t-apt-source.list 파일을 엽니다.

  2. 파일의 끝에 다음 줄을 추가합니다. <rel> 부분은 위에서 확인한 L4T 버전(예: r36.4)으로 대체해야 합니다.6

    $ deb https://repo.download.nvidia.com/jetson/rt-kernel r<rel> main

  3. 패키지 목록을 업데이트합니다.

    $ sudo apt update

  4. 실시간 커널과 관련된 모든 패키지를 설치합니다. nvidia-l4t-display-rt-kernel 패키지는 RT 커널 환경에서 디스플레이 드라이버가 정상적으로 작동하는 데 필수적입니다.6

    $ sudo apt install nvidia-l4t-rt-kernel nvidia-l4t-rt-kernel-headers nvidia-l4t-rt-kernel-oot-modules nvidia-l4t-display-rt-kernel

  5. 설치가 완료되면 시스템을 재부팅합니다.

    $ sudo reboot

설치 후, 시스템은 기본적으로 새로 설치된 RT 커널로 부팅됩니다. 원본 커널과 RT 커널 사이를 전환하려면 /boot/extlinux/extlinux.conf 파일을 수정해야 합니다. 이 파일에서 DEFAULT 속성의 값을 real-time (RT 커널) 또는 primary (원본 커널)로 변경하여 부팅할 커널을 선택할 수 있습니다.6 이는 RT 커널에 문제가 발생했을 때 시스템을 복구하는 중요한 메커니즘이기도 합니다.

이 방법은 빠르고 편리하지만 다음과 같은 한계가 있습니다.

이 파트는 가장 강력하고 유연한 방법인 소스 컴파일에 대한 세분화된 단계별 가이드를 제공합니다. 모든 지침은 최신 JetPack 6 / L4T 36.x 버전을 기준으로 합니다.

Jetson Orin의 커널을 빌드하는 가장 안정적인 방법은 강력한 x86 호스트 PC에서 교차 컴파일(cross-compilation)하는 것입니다.

Jetson의 사용자 공간(user space)과 일치하는 Ubuntu 22.04 LTS를 호스트 OS로 사용하는 것이 권장됩니다. 다음 명령을 사용하여 커널 빌드에 필요한 필수 패키지들을 설치합니다.10

$ sudo apt update
$ sudo apt install build-essential bc libncurses5-dev flex bison libssl-dev qemu-user-static git-core

올바른 버전의 툴체인을 사용하는 것은 컴파일 실패를 방지하는 데 매우 중요합니다. NVIDIA는 각 L4T 버전에 맞는 특정 Linaro 또는 Bootlin aarch64 툴체인을 지정합니다. NVIDIA 개발자 사이트에서 대상 L4T 버전에 맞는 툴체인을 다운로드합니다.7 다운로드 후, 적절한 위치에 압축을 풀고 CROSS_COMPILE 환경 변수를 설정합니다.

$ mkdir $HOME/l4t-gcc
$ tar -xf <toolchain-archive-name>.tar.xz -C $HOME/l4t-gcc
$ export CROSS_COMPILE=$HOME/l4t-gcc/<toolchain-directory>/bin/aarch64-buildroot-linux-gnu-

이 export 명령은 터미널 세션에만 유효하므로, .bashrc 파일에 추가하여 영구적으로 설정하는 것이 편리합니다.21

  1. 웹 브라우저에서 NVIDIA L4T Archive 페이지로 이동합니다.6
  2. 목표 L4T 버전에 맞는 “Driver Package (BSP) Sources” (public_sources.tbz2)를 다운로드합니다.
  3. 다운로드한 아카이브의 압축을 풀고, 그 안에 있는 kernel_src.tbz2 파일의 압축을 다시 풀어 커널 소스 트리를 얻습니다.6
$ tar -xjf public_sources.tbz2
$ cd Linux_for_Tegra/source/public/
$ tar -xjf kernel_src.tbz2

체계적인 작업을 위해 호스트 머신에 툴체인, 소스, 빌드 결과물을 보관할 명확한 디렉토리 구조를 구성하는 것이 좋습니다. 예를 들어 $HOME/jetson_build 와 같은 상위 디렉토리를 만들고 그 아래에 sources, toolchain, images 등의 하위 디렉토리를 구성합니다.10

NVIDIA는 이 과정을 단순화하는 스크립트를 제공합니다. 커널 소스 디렉토리로 이동하여 다음 스크립트를 실행합니다. L4T 버전에 따라 스크립트 이름이 다를 수 있습니다 (rt-patch.sh 또는 generic_rt_build.sh).

$ cd <kernel_source_dir>/kernel/kernel-5.15
$./scripts/rt-patch.sh apply-patches (구버전 L4T)

또는

$./generic_rt_build.sh "enable" (신버전 L4T)

6

이 스크립트가 없다면, 잘못된 소스 패키지를 다운로드했을 가능성이 높습니다.

이 단계는 빌드의 성패를 좌우하는 매우 중요한 과정입니다. 커널 설정을 시작하기 전에, PREEMPT_RT 패치가 반드시 먼저 적용되어야 합니다. 많은 사용자들이 menuconfig에서 “Fully Preemptible Kernel (RT)” 옵션을 찾지 못하는 문제를 겪는데 12, 이는 거의 항상

menuconfig 실행 전에 패치를 적용하지 않았기 때문입니다. RT 선점 모델 옵션은 패치 자체에 의해 추가되므로, 패치 적용 없이는 해당 옵션이 나타나지 않습니다.

먼저, 빌드 출력 디렉토리를 생성하고 기본 설정을 복사합니다.

$ TEGRA_KERNEL_OUT=$PWD/kernel_out
$ mkdir -p $TEGRA_KERNEL_OUT
$ make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig

이제 menuconfig를 실행하여 커널을 세부적으로 설정합니다.

$ make ARCH=arm64 O=$TEGRA_KERNEL_OUT menuconfig

10

menuconfig는 수천 개의 옵션을 제공하여 초보자를 압도할 수 있습니다. 성공적인 RT 빌드를 위해 다음 표에 명시된 필수 옵션들을 반드시 확인하고 설정해야 합니다.

메뉴 경로 Kconfig 플래그 권장 설정 설명 및 근거
General setup –» Preemption Model CONFIG_PREEMPT_RT Fully Preemptible Kernel (Real-Time) RT 패치의 핵심 기능. 커널을 완전 선점형으로 변경합니다.10
Kernel Features –» Timer frequency CONFIG_HZ_1000 1000 HZ 타이머 인터럽트 주파수를 1000Hz로 설정하여 스케줄링 정밀도를 높입니다.10
General setup –» Timers subsystem –» Timer tick handling CONFIG_NO_HZ_FULL Full dynticks system (tickless) 유휴 CPU 코어에서 주기적인 타이머 틱을 제거하여 지연을 줄입니다.10
Kernel hacking –» Tracers CONFIG_DEBUG_PREEMPT (비활성화) 선점 관련 디버깅 코드를 비활성화합니다. 활성화 시 심각한 성능 저하나 부팅 충돌을 유발할 수 있습니다.24

설정을 마친 후 저장하고 menuconfig를 종료합니다.

다음 명령을 실행하여 커널 이미지와 내장(in-tree) 모듈을 컴파일합니다. -j$(nproc) 옵션은 호스트 PC의 모든 CPU 코어를 사용하여 빌드 시간을 단축시킵니다.7

$ make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j$(nproc)

빌드가 성공하면 $TEGRA_KERNEL_OUT/arch/arm64/boot/Image 경로에 커널 이미지 파일이 생성되고, 소스 트리 전역에 걸쳐 커널 모듈(.ko 파일)들이 생성됩니다.

사용자는 단일 커널을 빌드하는 것이 아니라, 사실상 두 개의 개별적이면서도 연결된 소스 트리, 즉 오픈 소스 리눅스 커널과 NVIDIA의 독점 OOT 모듈을 관리해야 합니다. 이 두 가지는 별도의 빌드 프로세스를 가지며 정확하게 조율되어야 합니다. 새로운 RT 커널에 맞춰 OOT 모듈을 재빌드하지 않는 것은 디스플레이 미작동과 같은 주요 시스템 장애를 보장하는 지름길입니다. 사용자가 메인 커널 Image 빌드에 성공하고 이를 플래싱했지만 NVIDIA 모듈 재빌드를 잊었다면, 시스템 부팅 시 새로운 커널이 이전 버전의 NVIDIA 디스플레이 드라이버 모듈 로드를 시도할 것입니다. 이때 커널 버전 불일치로 인한 vermagic 오류가 발생하며 3, 결과적으로 검은 화면이 나타나거나 시스템이 텍스트 콘솔로 부팅됩니다.5 따라서 OOT 모듈 컴파일은 선택 사항이 아닌, 메인 커널 빌드와 동등한 필수 단계로 다루어져야 합니다.

  1. L4T 소스 패키지에서 kernel_oot_modules_src.tbz2와 nvidia_kernel_display_driver_source.tbz2 아카이브의 압축을 풉니다.6

  2. 다음 환경 변수를 설정합니다. 이는 RT 커널 설정으로 인해 디스플레이 드라이버 소스가 컴파일을 거부하는 것을 방지하는, 매우 중요하면서도 잘 알려지지 않은 단계입니다. 이 플래그는 독점 빌드 시스템에 PREEMPT_RT 설정을 무시하도록 지시합니다.6

    $ export IGNORE_PREEMPT_RT_PRESENCE=1

NVIDIA OOT 모듈 소스 디렉토리로 이동하여 make 명령을 실행합니다. 이때 KERNEL_HEADERS 또는 SYSSRC 변수가 앞서 빌드한 커스텀 커널의 소스 경로를 정확히 가리키도록 해야 합니다.6

$ cd <nvidia_display_driver_source_dir>
$ make modules SYSSRC=<path_to_kernel_source> SYSOUT=<path_to_kernel_out>...

내장 모듈과 OOT 모듈을 모두 호스트 측의 rootfs 디렉토리에 스테이징하기 위해 make modules_install 명령을 실행합니다. INSTALL_MOD_PATH 변수를 사용하여 설치 경로를 지정합니다.6

$ sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=<path_to_l4t_rootfs>
$ cd <oot_module_source_dir>
$ sudo make modules_install INSTALL_MOD_PATH=<path_to_l4t_rootfs>

빌드된 커널과 모듈을 실제 장치에 배포하는 방법은 여러 가지가 있습니다.

가장 안정적이고 권장되는 방법입니다. 컴파일된 Image, 장치 트리 블롭(DTB), 그리고 새로운 모듈이 포함된 전체 rootfs를 호스트의 Linux_for_Tegra 디렉토리에 배치합니다.

  1. 빌드된 Image 파일을 $L4T_DIR/kernel/Image로 복사합니다.

  2. 빌드된 DTB 파일들을 $L4T_DIR/kernel/dtb/로 복사합니다.

  3. rootfs가 새로운 모듈들로 채워졌는지 확인합니다.

  4. $L4T_DIR에서 apply_binaries.sh 스크립트를 실행하여 NVIDIA 사용자 공간 라이브러리를 적용합니다.10

    $ sudo./apply_binaries.sh

  5. Jetson Orin을 강제 복구 모드(Force Recovery Mode)로 전환하고 flash.sh 스크립트를 실행하여 전체 시스템을 플래싱합니다.11

    $ sudo./flash.sh jetson-agx-orin-devkit mmcblk0p1

JetsonHacks와 같은 커뮤니티의 훌륭한 결과물을 활용하는 방법입니다.3 이 접근법은 Jetson 장치 위에서 직접 커널과 모듈을 빌드합니다. JetsonHacks가 제공하는 스크립트들은 소스 다운로드, 빌드, 커널 Image 및 모듈 설치, 부트 설정 업데이트까지의 과정을 자동화합니다.28 이 방법은 반복적인 개발 주기에 더 빠르지만, 장치를 부팅 불능 상태로 만들 위험이 더 높습니다. 시도하기 전에 반드시 루트 파일 시스템의 전체 백업을 수행해야 합니다.

교차 컴파일을 완료한 고급 사용자가 전체 플래싱 없이 장치를 업데이트하고자 할 때 사용합니다.

  1. 새로운 Image 파일을 대상 장치의 /boot/ 디렉토리로 복사합니다.
  2. 새로운 DTB 파일들을 대상 장치의 /boot/dtb/ 디렉토리로 복사합니다.29
  3. 새롭게 컴파일된 모듈 트리 전체 (/lib/modules/<new-kernel-version>)를 대상 장치의 /lib/modules/ 디렉토리로 복사합니다.
  4. 대상 장치의 /boot/extlinux/extlinux.conf 파일을 수정하여 새로운 커널 Image를 가리키도록 LINUX 항목을 변경합니다.
  5. 가장 중요한 마지막 단계: 대상 장치에서 sudo depmod -a 명령을 실행하여 모듈 의존성 맵을 다시 생성합니다.5 이 단계를 생략하면 커널이 새로 설치된 모듈을 찾지 못해 “검은 화면” 문제가 발생할 가능성이 매우 높습니다.

이 파트는 사용자가 겪을 가능성이 높은 실패 상황과 진정한 실시간 성능을 달성하기 위해 필요한, 명확히 드러나지 않는 단계들을 다루므로 가장 가치가 높습니다.

부팅 문제를 디버깅할 때 시리얼 콘솔(UART) 없이는 사실상 원인 파악이 불가능합니다. NVIDIA의 공식 가이드를 참조하여 시리얼 콘솔을 연결하는 방법을 숙지해야 합니다.5 여기서 캡처된 부팅 로그는 진단의 가장 중요한 정보 소스입니다.23

이 표는 흔히 발생하는 암호 같은 오류 메시지와 그 원인, 그리고 구체적인 해결책을 연결하는 빠른 참조 매뉴얼 역할을 합니다. 이를 통해 사용자의 혼란을 체계적인 디버깅 프로세스로 전환할 수 있습니다.

증상 / 오류 메시지 유력한 원인 진단 단계 해결책  
부팅 후 검은 화면 또는 GUI 비활성화 5 NVIDIA 디스플레이 드라이버 모듈 불일치 또는 로드 실패 시리얼 콘솔에서 dmesg를 확인하여 nvdisplay 관련 오류 검색 대상 장치에서 sudo depmod -a 실행 후 재부팅.5 호스트에서 chroot를 이용한 고급 depmod 실행.5
“ERROR: nvme0n1p1 not found”와 함께 부팅 중단 24 initrd 또는 부트로더가 NVMe 드라이버를 로드하지 못함. 커널 설정에서 NVMe 지원 누락. 커널 .config 파일에서 CONFIG_BLK_DEV_NVME 활성화 여부 확인. initrd를 재빌드 (sudo./tools/l4t_update_initrd.sh).6 커널 재설정 및 재빌드.  
부팅 중 커널 패닉 또는 콜 트레이스(Call trace) 발생 24 불안정한 커널 설정 (예: CONFIG_DEBUG_PREEMPT 활성화), DTB 불일치, 하드웨어 문제. 시리얼 콘솔 로그에서 패닉 메시지 분석. 안정적인 tegra_defconfig로 되돌려 테스트. CONFIG_DEBUG_PREEMPT와 같은 디버깅 옵션 비활성화 후 재빌드.24 DTB 파일이 올바르게 복사되었는지 확인.  
“Board cannot boot normal” 또는 부팅 루프 23 커널 이미지, DTB, 모듈 간의 전반적인 불일치. 잘못된 extlinux.conf 설정. 시리얼 콘솔 로그에서 초기 부트 실패 지점 확인. 전체 플래싱(방법 A)으로 돌아가거나, extlinux.conf 파일의 경로가 올바른지 확인.  
모듈 로드 시 vermagic 불일치 오류 커널 Image와 모듈이 다른 설정 또는 소스 버전으로 빌드됨. CONFIG_LOCALVERSION 불일치. uname -r로 실행 중인 커널 버전 확인. /lib/modules/ 아래의 모듈 디렉토리 이름과 비교. CONFIG_LOCALVERSION을 일관되게 설정하고 커널과 모듈을 모두 재빌드.3  

가장 중요하고 직관에 반하는 발견 중 하나는, 성공적으로 설치된 PREEMPT_RT 커널이 초기 상태에서는 종종 순정 커널보다 더 나쁜 지연 시간 성능을 보인다는 점입니다.30 낮은 지연 시간을 달성하는 것은 설치의 수동적인 결과가 아니라, 능동적인 튜닝 과정의 산물입니다. 사용자가 RT 커널을 설치하고

uname -a로 확인한 뒤 cyclictest를 실행하면, 수천 마이크로초에 달하는 높은 최대 지연 시간을 보고 혼란에 빠질 수 있습니다.30 그 이유는 CPU 동적 주파수 스케일링(DVFS)이나 공격적인 절전 모드와 같은 하드웨어 수준의 기능들이 여전히 활성화되어 있기 때문입니다. 이러한 기능들은 PREEMPT_RT 패치 자체가 제어할 수 없는 크고 비결정적인 지연을 유발합니다.2 따라서 이 섹션에서는 설치 후 튜닝 과정을 상세히 설명합니다. 패치는 실시간 성능을 위한 잠재력을 제공할 뿐이며, 하드웨어를 제어하는 튜닝 과정을 통해 그 잠재력을 실현해야 합니다.

RT 커널이 활성화되었는지 확인합니다. 출력에 PREEMPT_RT 문자열이 포함되어야 합니다.30

$ uname -a

rt-tests 도구를 설치하고, 실제 부하 상황에서 최악 지연 시간을 측정하기 위해 stress-ng와 같은 부하 생성 도구와 함께 실행합니다.2

$ sudo apt install rt-tests stress-ng

한 터미널에서 시스템에 부하를 줍니다.

$ stress-ng --cpu 8 --io 4 --vm 2 --vm-bytes 1G

다른 터미널에서 높은 FIFO 우선순위로 cyclictest를 실행합니다.

$ sudo cyclictest -t1 -p 99 -n -i 1000 -l 1000000

이 가이드에서 다룬 핵심 사항들을 간결한 체크리스트로 요약하면 다음과 같습니다.

JetPack이 새로 출시될 때마다 시스템을 업데이트하려면, 이 가이드에서 설명한 빌드 및 배포 과정을 반복해야 할 가능성이 높습니다. RT 커널은 표준 OTA 업데이트 메커니즘과 호환되지 않을 수 있으므로 17, 유지보수 계획에 이를 반영해야 합니다.

성공적인 RT 시스템 구축을 위해서는 공식 문서만으로는 부족할 때가 많습니다. 공식 NVIDIA 문서 6, 귀중한 정보가 오가는 NVIDIA 개발자 포럼 5, 그리고 JetsonHacks 3나 RidgeRun 20과 같은 신뢰할 수 있는 커뮤니티 리소스를 적극적으로 활용하는 것이 공식 매뉴얼에 없는 문제를 해결하는 열쇠입니다. 이 생태계는 복잡한 Jetson 플랫폼에서 개발을 진행하는 데 있어 가장 강력한 자산 중 하나입니다.