VisionBox AI Linux  2023-12-12
Linux Information

Table of Contents

Mass storage devices

The VisionBox AI supports the following mass storage devices:

Device Partition Mount point Filesystem Description
eMMC flash /dev/mmcblk0p1 / Ext4 Root filesystem
/dev/mmcblk0p2 ...
/dev/mmcblk0p14 		Firmware partitions
SD card /dev/mmcblk1p1 /media/sdcard Auto Mounted during first access to /media/sdcard
M.2 NVMe SSD /dev/nvme0n1p* The M.2 SSD is optional
USB flash drive /dev/sd*
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

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:

VisionBox AI boot options
0: Linux 5.10.120-rt70-visionbox-ai-rt-35.4.1
1: Linux 5.10.120-rt70-visionbox-ai-35.4.1
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
99°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/share/nvpmodel_indicator/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 AGX Orin 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 30W for the AGX Orin 32GB:

< POWER_MODEL ID=2 NAME=MODE_30W >
CPU_ONLINE CORE_0 1
CPU_ONLINE CORE_1 1
CPU_ONLINE CORE_2 1
CPU_ONLINE CORE_3 1
CPU_ONLINE CORE_4 1
CPU_ONLINE CORE_5 1
CPU_ONLINE CORE_6 1
CPU_ONLINE CORE_7 1
TPC_POWER_GATING TPC_PG_MASK 240
GPU_POWER_CONTROL_ENABLE GPU_PWR_CNTL_EN on
CPU_A78_0 MIN_FREQ 729600
CPU_A78_0 MAX_FREQ 1728000
CPU_A78_1 MIN_FREQ 729600
CPU_A78_1 MAX_FREQ 1728000
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 1369600000
DLA1_CORE MAX_FREQ 1369600000
DLA0_FALCON MAX_FREQ 729600000
DLA1_FALCON MAX_FREQ 729600000
PVA0_VPS MAX_FREQ 512000000
PVA0_AXI MAX_FREQ 358400000

Predefined power modes for the AGX Orin 32GB and AGX Orin 64GB module are described in the NVIDIA Jetson Linux Developer Guide: Supported Modes and Power Efficiency

Note
The default power mode for the VisionBox AI is MAXN (mode 0), which means no restrictions in cores and frequency, but hardware throttling may be used to limit the power consumption to the following TDP budgets:
  • AGX Orin 32GB: 40W
  • AGX Orin 64GB: 60W

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: MAXN
0
~# nvpmodel -m 3
~# nvpmodel -q
NV Power Mode: 40W
3
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 mmcblk0p1 in the eMMC 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/mmcblk0p1/options | grep "data="
data=journal

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

~# tune2fs -o journal_data_ordered /dev/mmcblk0p1

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

~# tune2fs -o journal_data /dev/mmcblk0p1

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