VisionCam XM2 Linux  2023-11-02
Linux Information

Table of Contents

IMAGO software updates

The public Debian repository at deb.imago.tech enables online installation and updates of packages provided by IMAGO.

The repository is already prepared in the Linux images.

The following software packages are supported:

  • imago-sdk
  • imago-snmpd-update
  • planned: viewit-light

Example for installing or updating the IMAGO SDK:

apt update
apt install imago-sdk

Installing JetPack

The NVIDIA JetPack SDK is not included in the provided Linux images, but the online APT repository provided by NVIDIA is already prepared.

Issue the following commands on the target system to install all JetPack components:

apt update
apt install nvidia-jetpack

There are also meta-packages available which can be used to install the development or the runtime components only:

  • nvidia-jetpack-dev
  • nvidia-jetpack-runtime

See also: List of JetPack Debian Packages

Installing / upgrading CUDA

The CUDA 11.4 toolkit is included in the JetPack SDK. A newer version can be installed independently from JetPack.

The required APT repository is already prepared in the system. Issue the following commands on the target system to install the newest CUDA version:

apt update
apt install cuda

See also: CUDA Upgradable Package for Jetson

CUDA samples

With CUDA version 11.4 which is included in JetPack SDK, the CUDA samples can be found in the filesystem: /usr/local/cuda-11.4/samples

Beginning with CUDA 11.6, the CUDA samples are provided by a GitHub repository:

apt install git
git clone https://github.com/NVIDIA/cuda-samples.git

New versions of the samples require setting the environment variable LD_LIBRARY_PATH:

cd cuda-samples
export LD_LIBRARY_PATH=/usr/local/cuda/compat
make -j $(nproc)
ls bin/aarch64/linux/release/

Real-time Linux kernel

The real-time Linux kernel (PREEMPT_RT) is provided by the packages linux-image-rt-… and linux-headers-rt-…. It's already pre-installed in the system, but not selected automatically during boot. The kernel can be selected interactively on the serial console during the boot process:

VisionCam XM2 boot options
0: Linux 5.10.104-rt63-visioncam-xm2-1.0
1: Linux 5.10.104-rt63-visioncam-xm2-rt-1.0
Press 0-1 to boot selection within 2.0 seconds.
Press any other key to boot default (Option: 1)

The default setting for the kernel can be changed by modifying the configuration file /boot/extlinux/extlinux.conf and changing the line starting with 'DEFAULT ...'.

Thermal considerations

The maximum operating temperature depends on the configured power mode, the system workload, and the mounting situation. Adequate cooling must be provided to maintain nominal performance. The temperature range should be verified for each application.

Warning
The device's surface can get very hot, there is a risk of injury!

The following thermal trip zones are used for all thermal zones of the Orin SoC:

Temperature threshold Type Description
70°C Active Hot surface warning
90°C Passive Clock throttling is used to reduce power consumption
104.5°C Critical Software shutdown is triggered
Note
  • Take a look at Jetson Power Modes to optimize power consumption for the application.
  • Run the python script /usr/local/bin/thermal_throttle_alert.py to monitor hot-surface and throttling events.
  • The command line tool tegrastats can be used to verify temperatures, frequencies and power consumption.
  • Also take a look at the third-party tool jtop which is provided by the python package jetson-stats.

Jetson Power Modes

The Jetson Orin NX / Nano module can be operating in different power modes. Each mode provides a different power budget by limiting the number of cores and the frequency for CPU, GPU and other SoC units.

Available power mode presets are defined in the configuration file /etc/nvpmodel.conf. Custom modes can be added to optimize the power consumption depending on the application requirements.

Example section in /etc/nvpmodel.conf for Mode 2 at 15W for the Orin NX 16GB:

< POWER_MODEL ID=2 NAME=15W >
CPU_ONLINE CORE_0 1
CPU_ONLINE CORE_1 1
CPU_ONLINE CORE_2 1
CPU_ONLINE CORE_3 1
CPU_ONLINE CORE_4 0
CPU_ONLINE CORE_5 0
CPU_ONLINE CORE_6 0
CPU_ONLINE CORE_7 0
FBP_POWER_GATING FBP_PG_MASK 2
TPC_POWER_GATING TPC_PG_MASK 252
GPU_POWER_CONTROL_ENABLE GPU_PWR_CNTL_EN on
CPU_A78_0 MIN_FREQ 729600
CPU_A78_0 MAX_FREQ 1651200
GPU MIN_FREQ 0
GPU MAX_FREQ 612000000
GPU_POWER_CONTROL_DISABLE GPU_PWR_CNTL_DIS auto
EMC MAX_FREQ 0
DLA0_CORE MAX_FREQ 614400000
DLA1_CORE MAX_FREQ 614400000
DLA0_FALCON MAX_FREQ 294400000
DLA1_FALCON MAX_FREQ 294400000
PVA0_VPS MAX_FREQ 115000000
PVA0_AXI MAX_FREQ 115000000

Predefined power modes for the Orin NX / Nano modules are described in the NVIDIA Jetson Linux Developer Guide: Supported Modes and Power Efficiency

The following modes are used by default:

Orin module Mode ID Power budget
Orin Nano 4GB 0 10 W
Orin Nano 8GB 0 15 W
Orin NX 8GB 2 15 W
Orin NX 16GB 2 15 W
Note
Power mode 0 'MAXN' for the Orin NX (not Nano) removes all restrictions in cores and frequency, but hardware throttling may be applied to limit the power consumption to the following TDP budgets:
  • Orin NX 16GB: 25 W
  • Orin NX 8GB: 20 W

Use the command line tool nvpmodel to query or change the power model, see Power Mode Controls for a detailed description:

~# nvpmodel -q
NV Power Mode: 15W
2
~# nvpmodel -m 1
~# nvpmodel -q
NV Power Mode: 10W
1
Note
  • The selected mode persists across power cycles.
  • A reboot may be required if the number of active cores is changed.

Ext4 journaling filesystem

The ext4 filesystem is used for the root partition nvme0n1p1 in the NVMe flash.

Ext4 supports three data journaling modes:

  • data=writeback
    Journaling is only applied for metadata. Incorrect data may appear in files which were written shortly before a crash.
  • data=ordered
    All data is forced directly out to the main filesystem prior to its metadata being committed to the journal. This technique guarantees that either the old or the new file contents will persist on disk. But ext4's delayed allocation of blocks increases the potential for data loss in programs that have not been specifically written to call fsync() when the programmer wants to ensure data has been flushed entirely to disk.
  • data=journal
    This mode disables delayed allocation of written data. This mode is most robust against data loss, but also has a significant impact on write performance.

The journaling mode is determined during the mount process of the root filesystem. The mode is stored in the ext4 superblock information which is not part of the Linux image. The default mode for delivered devices is data=journal, because data=ordered does not provide the best safeness against data loss.

The active journaling mode can be checked by running the following console command:

cat /proc/fs/ext4/nvme0n1p1/options | grep "data="

The following command can be used to configure data=ordered mode manually:

tune2fs -o journal_data_ordered /dev/nvme0n1p1

data=journal mode can be enabled by running the following command:

tune2fs -o journal_data /dev/nvme0n1p1

The filesystem will be mounted with the new mode after reboot.

The superlock information is initially configured during installation of images by the install scripts (Remote_OS_Install.cmd, Remote_OS_Install.sh, Local_OS_Install.sh). The default mode is data=journal. The scripts accept the parameter -o to change the mode to data=ordered during installation.

References