Image configurations
IMAGO currently provides a single image configuration for the VisionCam XM2:
| Configuration | Description |
| a | Basic image
- Ubuntu base system
- Additional packages: openssh-server, openssh-client, ntp, snmpd, avahi-daemon, screen, htop, python3, ...
- Software development packages: gcc, g++, gdb, make, ...
- NVIDIA Jetson Linux Driver Package
- Packages provided by IMAGO:
- Bootloader for the VisionCam XM2: bootloader-visioncam-xm2
- NVIDIA Linux kernel with customized kernel configuration and device tree:
- Standard kernel (default): linux-image-…-visioncam-xm2-…, linux-headers-…-visioncam-xm2-…
- Real-time kernel (PREEMPT_RT): linux-image-…-visioncam-xm2-rt-…, linux-headers-…-visioncam-xm2-rt-…
- IMAGO Linux SDK: imago-sdk
- imago-snmpd-update: Linux service which updates the file /etc/snmp/snmpd.conf.local to make the device discoverable by the VIBFinder tool. The service additionally sets the host name to the device's serial number during boot.
- imago-archive-keyring: public IMAGO APT repository deb.imago.tech for online SDK updates
- gige-discovery-reply: adds support for device discovery in different subnet and for changing the IP configuration with the VIBFinder 2 tool (uses the GigE GVCP protocol).
|
- Note
- The Nvidia JetPack SDK is currently not pre-installed. See Installing JetPack for more information.
- The FPGA firmware is not part of the Linux image and will therefore not be updated by image recovery.
Mass storage devices
The VisionCam XM2 primarily uses a NVMe SSD as mass storage device:
| Device | Partition | Mount point | Filesystem | Description |
| NVMe SSD | /dev/nvme0n1p1 | / | Ext4 | Root filesystem |
/dev/nvme0n1p2 ...
/dev/nvme0n1p14 | | | Firmware partitions |
| USB flash drive | /dev/sd* | | | Can be attached to the 17-pin power and I/O cable |
- Note
- The mount points and options are configured in the file /etc/fstab.
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
- gige-discovery-reply
- viewit-light
Example for installing or updating ViewIT Light:
apt update
apt install viewit-light
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 specific development or runtime components only:
JetPack meta-packages
- Note
- It's highly recommended to install only the required runtime packages for production (nvidia-jetpack-runtime or sub-packages). Development packages will increase storage requirements on the device and the size of backup images substantially.
See also: List of JetPack Debian Packages
Installing / upgrading CUDA
Ubuntu 22.04 / Jetpack 6
The CUDA 12.2 toolkit is provided by the JetPack SDK 6 meta-package nvidia-cuda-dev:
apt update
apt install nvidia-cuda-dev
A more recent version can be installed independently from the version provided by JetPack, see:
- Note
- JetPack 6 can't be installed after the additional CUDA repository is installed on the system. JetPack has to be installed first to avoid dependency problems.
Ubuntu 20.04 / Jetpack 5
The CUDA 11.4 toolkit is included in JetPack SDK 5.x. CUDA version 12.2 can be installed independently from the version provided by JetPack. The required APT repository is already prepared in the system. Issue the following commands on the target system to install the newest compatible CUDA version:
apt update
apt install cuda
CUDA samples
The CUDA samples can be downloaded from the following GitHub repository:
github.com/NVIDIA/cuda-samples
Clone and checkout cuda-samples repository for CUDA 12.2:
apt install git
git clone https://github.com/NVIDIA/cuda-samples.git
cd cuda-samples
git checkout v12.2
Build samples:
make
ls bin/aarch64/linux/release/
Run the deviceQuery example:
bin/aarch64/linux/release/deviceQuery
Real-time Linux kernel
The real-time Linux kernel (PREEMPT_RT) is provided by the packages linux-image-…-visioncam-xm2-rt-… and linux-headers-…-visioncam-xm2-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-rt-1.0
1: Linux 5.10.104-rt63-visioncam-xm2-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
1.8.18