Getting Started
This section contains information to help you get started using this release of NVIDIA® Tegra® Linux Driver Package.
Requirements
The following lists the requirements to use this Tegra Linux Driver Package (L4T) release:
• Host PC running Linux. Ubuntu 12.04 is used in examples in this document, but other distributions should also work.
• A kernel image (zImage). L4T does contain a kernel image (zImage), and you can also download and rebuild from source.
• Boot loader. This can be Fastboot or U-Boot. Flashing on a Tegra K1 32 Bit series (Jetson TK 1) developer board requires a boot loader. This boot loader can be either the Fastboot utility or U-Boot, both of which are included in this release.
• A rootfs device which can be an SD card, a USB hard disk, or USB stick formatted to EXT3. It is also possible to use the target device’s internal memory, or your Linux Host PC hard-drive through NFS.
• A USB cable to plug into the recovery port.
Boot Options
It is currently possible to boot L4T on the Tegra K1 32 Bit series Jetson TK 1 developer board with a root file system from:
• USB stick or USB hard disk
• SD card
• Internal eMMC
• SATA (Fastboot only)
• Network file system (NFS)
Setting Up Your Environment
The following subsections contain information to help you get started using this release of L4T.
Extracting Tegra Linux Driver Package
Note: The procedures in this document assume you extract the release package in ~/.
To extract Tegra Linux Driver Package
• Extract the package manually by executing the following command:
$ sudo tar -vxjf Tegra<SOC>_Linux_<release_num>.<version_num>_<release type>.tbz2
Where:
• <release_num> is the branch number of the release, such as R19.
• <version_num> is the revision number of the build such as 1.0 for the first build.
• <release_type> is
armel (for softfp
ABI) or
armhf (for hardfp ABI).
Setting Up Your Board
L4T requires a supported Tegra developer board as well as a host PC running Linux. Please consult your board documentation for steps on how to setup and configure your board.
Prerequisites
• You have a device specified above in the “Boot Options” topic (supported formats: EXT2, EXT3, or EXT4). (The device can also be a memory card with a USB adapter.)
• You have a USB cable to plug into the board’s recovery port.
Setting Up Your File System
This section describes the steps for setting up your file system. You must set up the root file system and copy the file system to your boot device.
Sample Root File System
The following are the details regarding the creation of the provided sample root file system. The steps were performed on a target board.
To create the sample file system
1. Install debootstrap with the following command.
$ sudo apt-get install debootstrap
2. Run the below command as root.
$ debootstrap --verbose --no-check-gpg --arch=armhf --variant=minbase --include=ubuntu-minimal,xserver-xorg,xserver-xorg-core,xinit,xterm,alsa-utils,wireless-tools,wpasupplicant,x11-xserver-utils,openssh-client,openssh-server,bzip2,less,iputils-ping,isc-dhcp-client,net-tools,lsb-release,sudo,vim,iw,bluez,gdisk,wget language-pack-en-base,xfonts-base,ntp --components=main,restricted,universe trusty rfs
http://ports.ubuntu.com/The hostname used in this procedure is tegra-ubuntu, with the username ubuntu, and the password ubuntu.
Note: The provided sample target file system does not come with pre-generated SSH host keys. These host keys can be re-generated with the following command:
$ ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
View the ssh-keygen man page for other -t options.
If you are using your own Linux distribution, please also view the files included in ~/Linux_for_Tegra/nv_tegra/config.tbz2 file and make appropriate adjustments as made in those files for your root file system.
The following packages are installed by default:
• ubuntu-minimal
• xserver-xorg
• xserver-xorg-core
• x11-xserver-utils
• xinit
• xterm
• alsa-utils
• wireless-tools
• wpasupplicant
• openssh-client
• bzip2
• less
• iputils-ping
• isc-dhcp-client
• net-tools
• lsb-release
• sudo
• vim
• iw
• bluez
• gdisk
• wget
• language-pack-en-base
• xfonts-base
• ntp
Setting Up the Root File System
The next step in booting the target board is to configure the root file system. Follow the procedures in this section to set up the rootfs and to copy the file system to the rootfs device.
Note: The instructions below use the sample file system that is provided by NVIDIA as the base. If you would like to use your own, set the LDK_ROOTFS_DIR environment variable to point to where your rootfs is located and skip Steps 1 and 2.
To set up the rootfs
1. Download the following file to your home directory:
Tegra-Linux-Sample-Root-Filesystem_<release_type>.tbz2
Where
<release_type> is
armel (for softfp
ABI) or
armhf (for hardfp ABI).
This file contains the NVIDIA-provided sample root file system.
2. Extract the compressed file as follows:
• Navigate to the rootfs directory of the extracted NVIDIA driver package with this command:
$ cd <your_L4T_root>/Linux_for_Tegra/rootfs
Where <your_L4T_root> is your L4T root directory, which is assumed to be your home directory (~).
• Extract the sample file system to the rootfs directory with this command:
$ sudo tar jxpf ../../Tegra-Linux-Sample-Root-Filesystem_<release_type>.tbz2
3. Run the apply_binaries.sh script to copy the NVIDIA user space libraries into the target file system:
$ cd ..
$ sudo ./apply_binaries.sh
If you are using a different rootfs, or if you already have configured your rootfs, you can apply the NVIDIA user space libraries by setting the LDK_ROOTFS_DIR environment variable to point to your rootfs. Then run the script, as shown above, to copy the binaries into your target file system.
If the apply_binaries.sh script installs the binaries correctly, the last message output from the script is “Success!”.
5. Load the target file system that you have generated onto the first partition of a device (either a USB stick, an SD card, or a USB hard drive) and attach that device to the target board. Alternatively, you can use the flash.sh script to flash the root file system to the internal eMMC. In this case proceed with the following steps, and then and follow the internal eMMC instructions.
7. Power on the target board.
8. Optionally, use an RS232 serial cable (not included in the development kit) to connect the RS232 port on Jetson TK1 to the Linux host PC to access the debug console. Set up the terminal on the host PC as follows:
• 115200 baud
• 8-bit
• Parity none
• 1 stop bit
To copy the file system to the external rootfs device
1. Plug your rootfs device into the host PC.
2. If your device is not formatted as Ext3, enter the following command to format it with an Ext3 file system:
$ sudo mkfs.ext3 /dev/sd<port><device number>
Where:
• <port> is the port to which your device is mounted.
• <device_number> is the device number of the device attached to the port. You can use the dmesg command to determine the port.
3. If needed, mount your device with the following command:
$ sudo mount /dev/sdX1 <mntpoint>
Where <mntpoint> is your rootfs device’s mount point on the host system.
4. Copy the file system. If LDK_ROOTFS_DIR is set, execute these commands:
$ cd ${LDK_ROOTFS_DIR}
$ sudo cp -a * <mntpoint> && sync
If it is not set, copy the rootfs directory that is included in the release by executing the following commands:
$ cd <your_L4T_root>/Linux_for_Tegra/rootfs
$ sudo cp -a * <mntpoint> && sync
Once you have copied the content to the external disk or device, you can then unmount the disk and plug it to the board. For more information about flashing, see the
Flashing the Boot Loader and Kernel topic in this section. For information about configuring your board setup, see the hardware documentation for your developer board.
To copy the file system to the external rootfs device
Updating Drivers on an Existing Target System
These instructions are for the situation where there was a previous release or driver package loaded onto a target board and that target device is booted.
Prerequisite
You must attach an Ethernet cable to the device through either the Ethernet port (if available) or through a USB Ethernet adaptor.
To update drivers on an existing target system
1. Log into the target device.
2. From the nvidia.com links with wget, download the NVIDIA Tegra Linux driver release and the additional support packages:
wget http://developer.nvidia.com/sites/default/files/akamai/mobile/files/L4T/Tegra<SOC>_Linux_<last_rel_num_RNN>_<release_type>.tbz2
Where:
• <SOC> is the number of the Tegra SOC, such as 124 for Jetson TK1.
• <last_rel_num_RNN> is the number of the release in this format (RNN), such as R19.3.
• <release_type> is
armel (for softfp
ABI) or
armhf (for hardfp ABI).
Note: The release shown in this example is a previous release and not the current release.
4. Set the LDK_ROOTFS_DIR variable to point to the root '/' directory.
$ export LDK_ROOTFS_DIR=/
$ echo ${LDK_ROOTFS_DIR}
5. Go into the Linux_for_Tegra directory.
$ cd Linux_for_Tegra
6. Run the
apply_binaries.sh script to install the NVIDIA drivers onto your target board. For more information, see
Setting Up the Root File System in this section.
7. (Optional) Change your X driver ABI as a variable passed into
apply_binaries. For more information, see
Setting Up the Root File System in this section.
8. For any additional packages, extract the files, being sure to extract them to your root '/' directory. For more information, see
Installing Additional Packages in this section.
Determining the Success of a Driver Update
You can determine whether a driver update on a target board went successfully.
To determine the success of a driver update
• Execute the following command on a booted target device:
$ sha1sum -c /etc/nv_tegra_release
If the driver update is successful, you will see a line similar to:
<file_location>: OK
It will list all files in the release in a format similar to the following:
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK
One reason the driver update might be unsuccessful is if the file is missing. The message in this case is similar to:
sha1sum: /usr/lib/xorg/modules/drivers/ nvidia_drv.so: No such file or directory
/usr/lib/xorg/modules/drivers/ nvidia_drv.so: FAILED open or read
Another reason the driver update might be unsuccessful is if the new file is not the same as the existing file, producing an error similar to:
/usr/lib/xorg/modules/drivers/ nvidia_drv.so: FAILED
Increasing Internal Memory Partition for the Root File System
The suggested rootfs partition size for the Jetson TK1 platform is 1073741824 bytes and is specified by default in the flash.sh script. This 1 GB reserved in internal memory for the rootfs partition may be insufficient for installation of additional packages. Packages such as ubuntu-desktop, gst, and other gnome plug-ins may require additional space.
The “-S <size-in-bytes>” argument to flash.sh can be used to change the partition size.
To flash for a larger partition
• Execute the following command:
$ sudo ./flash.sh <platform> -S <size> <rootdev>
Where:
• <platform> is jetson-tk1.
• <size> is the desired size for the partition, such as 8589934592 (or 8 GiB) for 8 GB.
• <rootdev> is the rootfs partition’s internal memory, for example mmcblk0p1.
Installing Additional Packages
This section explains how to install the additional NVIDIA packages, additional Ubuntu packages, and Google Chrome.
Installing Additional NVIDIA Packages
Additional NVIDIA packages may be posted alongside the release. To make full use of the features in the release, these additional packages must be installed.
Directly after the
apply_binaries step in
Setting Up the Root File System, you can install the package into the configured rootfs.
To install an NVIDIA package when the rootfs is already installed
1. Mount the target rootfs device to /mnt:
$ sudo mount <device> /mnt
Where <device> is the device such as /dev/sda1.
2. Install the package:
$ tar -C /mnt -xjpf <path-to>/$<package_name>
Where <package_name> is one of the packages.
For example, if you have the restricted_codecs.tbz2 file located in:
$HOME/restricted_codecs.tbz2
then your line will look like:
$ tar -C /mnt -xjpf $HOME/restricted_codecs.tbz2
3. Unmount the device with this command:
$ sudo umount <device>
And then attach the device to the target board.
If the rootfs is installed on the device’s internal eMMC, boot and log in to the target and use the scp command to copy the restricted_codecs.tbz2 package to the target, and then extract the restricted_codecs.tbz2 package from the root directory.
Installing Additional Ubuntu Packages
This section explains how to install additional packages from Ubuntu by using the provided sample file-system. For example, you may wish to download the following packages:
• openssh-server for remotely logging in
• ubuntu-desktop for the standard Ubuntu graphical user interface (if not pre-installed)
You can receive notifications from Update Manager when new Ubuntu packages are available.
Note: L4T is tested with base Ubuntu packages only. No updated packages have been tested.
To receive notifications
1. Locate and edit the following file:
/etc/apt/sources.list
2. Add the following line:
Where <distribution> is the name of the Ubuntu distribution your rootfs is based on. For example, for a rootfs based on the Trusty Tahr distribution of Ubuntu, add the line:
Prerequisite
You have attached an Ethernet cable to the device through either the Ethernet port (if available) or through the USB Ethernet adaptor.
To install more packages
1. Boot the target device.
2. Turn on networking by executing:
$ sudo dhclient
Note: You may need to specify eth0/eth1 and other parameters to assign an IP address to the appropriate interface.
3. Install packages using apt-get. For example, to install wget execute this command:
$ sudo apt-get install wget
Configuring NFS Root on the Linux Host
To boot the target device from NFS, you must provide an NFS root mount point on your Linux host machine. The procedure in this section describes the basic steps to do so.
Prerequisites
• You must have an Ethernet connection to install packages on the host.
• You must have an Ethernet connection on the target.
To configure NFS root on the Linux host
1. Install the nfs components on your host machine:
$ sudo apt-get install nfs-common nfs-kernel-server
2. The NFS server must know which directories you want to 'export' for clients. This information is specified in the /etc/exports file.
• Modify /etc/exports to look somewhat like this:
$ /nfsroot *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
• After adding the entry, restart using the following command:
$ sudo /etc/init.d/nfs-kernel-server restart
3. Create an /nfsroot directory on your Linux host machine:
$ sudo mkdir /nfsroot
4. Copy the file system to the nfsroot directory:
$ cd ./rootfs
$ sudo cp -a * /nfsroot
5. Export the root point:
$ sudo exportfs -a
Alternatively, you can export or un-export all directories by using the -a and -u flags. The following command un-exports all directories:
$ sudo exportfs -au
6. (Optional) If the Ubuntu firewall blocks NFS root access, it must be disabled depending upon your configuration. You can do so with the following command:
$ sudo ufw disable
7. If there are issues performing the NFS boot, to separately verify everything on the ‘host’ machine is configured properly, you can perform the following step on a booted target board through USB/SD/internal eMMC. It should be possible to mount the host NFS root point on the target device:
$ mkdir rootfs
$ sudo mount -v -o nfsvers=3 <IP-ADDR>:/nfsroot rootfs
Where <IP-ADDR> is the IP address of the Linux Host machine as taken from the ifconfig command. This proves that the host configuration is correct.
Note: Prior to executing the mount command on the target machine, you must install the nfs-common package using the following command:
$ sudo apt-get install nfs-common
To boot the target with the NFS root point, see the
Flashing the Boot Loader and Kernel topic in this section and be sure to include the
-N option for the nfs root point.
Setting Power Saving Options
This section explains how to enable the hotplug driver and the Tegra CPU power-gated state (LP2) for power savings on the target board.
Enabling the Auto-Hotplug Driver
The auto-hotplug driver implements the policy for when to bring cores online/offline. The auto-hotplug driver also implements the policy for when to switch clusters, i.e. when to switch from companion CPU to main CPU or vice versa. Cluster switching is transparent to the OS. The switch happens when software enters a power-gated state on one CPU core and hardware resumes the execution on a different physical CPU core.
To enable auto-hotplug
• Enter the following command:
echo 1 > /sys/devices/system/cpu/cpuquiet/tegra_cpuquiet/enable
echo "balanced" > /sys/devices/system/cpu/cpuquiet/current_governor
To disable auto-hotplug
• Enter the following command:
echo 0 > /sys/devices/system/cpu/cpuquiet/tegra_cpuquiet/enable
Enabling the Tegra CPU Power-Gated State (LP2)
With the LP2 power state, the CPU core is power-gated if supported by the hardware. If all CPU cores on the VDD_CPU power rail are in LP2, Tegra hardware signals the PMIC to turn off the regulator.
To enable the LP2 power state
• Enter the following command:
$ echo Y > /sys/module/cpuidle/parameters/power_down_in_idle
Controlling Display State
The Linux kernel 3.1 (and later) adds a power saving feature that may blank the display of an idle system even when applications are running. The feature is called console blank (screen saver). It is defined as:
consoleblank= [KNL]
Where [KNL] is the console blank (screen saver) timeout in seconds. This defaults to 10*60 = 10 mins. A value of 0 disables the blank timer.
By passing arguments to the kernel command line, you can:
• Disable this feature, or
• Set the timeout to a longer interval.
With the
flash.sh script, you can override the kernel command line options passed from fastboot to the kernel. For more information, see the
Flash Script Usage topic.
To disable the console blank (screen saver) from the kernel command line
1. Add the following line to the kernel parameters in the grub configuration:
consoleblank=0
2. View the current consoleblank value with the following command:
$ cat /sys/module/kernel/parameters/consoleblank
To disable the console blank feature with an escape sequence
• Enter the following escape sequence:
$ echo -ne "\033[9;0]"
To change the console blank timeout value with an escape sequence
• Enter the following escape sequence:
$ echo -ne "\033[9;<timeout>]"
where <timeout> is the timeout in seconds.
For more information on this escape sequence, see the console_codes(4) man page documents. For information on the input/output controls that provide some of the same functionality, see the console_ioctl(4) man page.
Flashing the Boot Loader and Kernel
This section describes the steps that must be taken to boot the target board by flashing the kernel and boot loader (code-name Jetson TK1 platform) and provides usage information for the flash.sh helper script.
Flash Procedure
The first step is to flash the board with the boot loader and kernel, and, optionally, flash the rootfs to internal eMMC.
Prerequisites
The following directories must be present:
• /bootloader—boot loader plus flashing tools (NvFlash, CFG, BCTs, etc.)
• /kernel—a kernel
zImage /vmlinux.uimg, DTB files, and kernel modules
• /rootfs—the root file system that you download (This directory starts empty and you populate it with the sample file system.)
• /nv_tegra—NVIDIA® Tegra® user space binaries and sample applications
You must also have the USB cable connected to the recovery port prior to running the commands listed in the procedure. For more information, see the
Requirements topic in this section.
To flash the boot loader and kernel
1. Put the target board into reset/recovery mode. Do so by first powering on the board and then holding the recovery button, and then pressing the reset button as described in the Quick Start Guide for the board.
2. Run the flash.sh script that is in the top level directory of this release. The script must be supplied with the target board (jetson-tk1) for the root file system:
$ sudo ./flash.sh <platform> <rootdev>
• If the root file system will be on a USB disk, execute the script as follows:
$ sudo ./flash.sh <platform> sda1
Note: If a SATA device is connected, that device enumerates as sda1.
• If the root file system will be on an SD card, execute the script as follows:
$ sudo ./flash.sh <platform> mmcblk1p1
• If the root file system will be on the internal eMMC, execute the script as follows:
$ sudo ./flash.sh <platform> mmcblk0p1
Where <platform> is jetson-tk1.
The above examples are for fastboot. For U‑Boot, add the following argument:
-L <PATH_TO_U-BOOT_BIN_FILE>
For example:
$ sudo ./flash.sh -L bootloader/<platform>/u-boot.bin <platform> <rootdev>
The boot loader and kernel will load.
For more information on U-Boot, see the
U-Boot Guide chapter of this document.
Flash Script Usage
You can find the most up-to-date usage information by running flash.sh -h (using the flash.sh script included in the release). The basic usage information is as follows.
Usage
sudo ./flash.sh [options] <platform> <rootdev>
Where you specify the required parameters and one or more of the options shown in the following table.
Parameters | Description |
<platform> | Is jetson-tk1. |
<rootdev> | Is one of following: |
| mmcblk0p1 | Specifies internal eMMC. |
mmcblk1p1 | Specifies external SDCARD. |
sda1 | Specifies external USB device (such as, USB memory stick or HDD). |
eth0 | Specifies nfsroot via external USB Ethernet interface. |
Options | Description |
-h | Specifies to print this usage information. |
-b <bctfile> | Specifies the NvFlash Boot Configuration Table (BCT) file. |
-c <cfgfile> | Specifies the NvFlash configuration file. |
-d <dtbfile> | Optionally specifies a device tree file to use instead of the default. |
-e <emmc_file> | Specifies the eMMC size of the target device. |
-f <flashapp> | Specifies the path to flash application: nvflash or tegra-rcm. |
-i | Specifies to pass the user kernel command line to the kernel as-is. |
-k <partition id> | Specifies the kernel partition ID to be updated (minimum = 5). |
-n <nfs args> | Specifies the static NFS network assignments: <Client IP>:<Server IP>:<Gateway IP>:<Netmask> |
-o <odmdata> | Specifies the ODM data value. |
-p | Total eMMC HW boot partition size. |
-r | Specifies to skip building and reuse existing system.img. |
-s <ubootscript> | Specifies the boot script file for U-Boot. |
-C <cmdline> | Specifies the kernel command line. Warning: Each option in this kernel command-line gets higher precedence over the same option from fastboot. In case of NFS booting, this script adds NFS booting related arguments if the -i option is omitted. |
-F <flasher> | Specifies the flash server, such as fastboot.bin. |
-I <initrd> | Specifies initrd file. Null initrd is the default. |
-K <kernel> | Specifies the kernel image, such as zImage. |
-L <bootloader> | Specifies the full path to the boot loader, such as fastboot.bin or u-boot.bin. |
-P <end_of_PPT_plus_1> | Specifies the sum of the primary GPT start address, the size of PPT, plus 1. |
-R <rootfs dir> | Specifies the sample rootfs directory. |
-N <nfsroot> | Specifies the nfsroot, for example: <my IP addr>:/my/exported/nfs/rootfs |
-S <size> | Specifies the rootfs size in bytes. This is valid only for internal rootdev. KiB, MiB, GiB style shorthand is allowed. For example, 1GiB signifies 1024 * 1024 * 1024 bytes. |
-T <ITS file> | ITS file name. Valid only for u-boot. |
Synchronizing the Kernel Sources
You can manually rebuild the kernel used for this package. Internet access is required to do so.
Prerequisites
• You have installed Git. Install Git with the following command:
$ sudo apt-get install git-core
• Your system has the default Git port 9418 open for outbound connections.
To rebuild the kernel
1. Get the kernel source by running the source_sync.sh script:
$ ./source_sync.sh -k
Which will prompt you to enter a ‘tag’ name, which is provided in the release notes.
—Or—
You can also manually sync the sources, as follows:
$ cd <myworkspace>
$ git clone git://nv-tegra.nvidia.com/linux-2.6.git kernel_sources
$ cd kernel_sources
$ git checkout <TAG_NAME>
Where <TAG_NAME> is the ’tag’ name that is available in the release notes.
You can sync to any Linux tag you would like, but the tag provided in the release notes will sync the sources to the same source point of time the release binary was built from. To see a list of the available release tags, use:
$ git tag -l tegra-l4t*
Building the NVIDIA Kernel
Follow the steps in this procedure to build the NVIDIA kernel.
Prerequisites
• You have downloaded the kernel source code.
To build the Tegra Kernel
1. Export the following environment variables:
$ export CROSS_COMPILE=<crossbin>
$ export TEGRA_KERNEL_OUT=<outdir>
$ export ARCH=arm
Where:
• <crossbin> is the prefix applied to form the path to the tool chain for cross compilation, e.g., gcc. For a CodeSourcery tool chain, it will look something like:
<csinstall>/arm-2009q1-203-arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-
Note: This example requires GCC 4.4 or above.
• <outdir> is the desired destination for the compiled kernel.
2. Execute the following commands to create the .config:
$ cd <myworkspace>/<kernel_source>
$ mkdir $TEGRA_KERNEL_OUT
Where <kernel_source> directory containing kernel sources.
• For Tegra K1 32 Bit, Jetson TK 1, use:
$ make O=$TEGRA_KERNEL_OUT tegra12_defconfig
Where <myworkspace> is the parent of the Git root.
3. Execute the following commands to build the kernel:
$ make O=$TEGRA_KERNEL_OUT zImage
4. Execute the following command to create the kernel device tree components:
$ make O=$TEGRA_KERNEL_OUT dtbs
5. Execute the following commands to build the kernel modules (and optionally install them)
$ make modules DESTDIR=<your_destination>
$ make modules_install INSTALL_MOD_PATH=<your_destination>
6. Copy the kernel zImage over the one present in the ‘kernel’ directory of the release.
7. Archive the kernel modules created in Step 4 using the tar command and the filename that is used for the kernel modules TAR file in the same kernel directory of the release. When both of those TAR files are present, you can follow the instructions provided in this document to flash and load your newly built kernel.
OpenGL/EGL Gears Test Application
If you would like to run a sample OpenGL/EGL test application, you can run the open-source Gears application.
To install and run Gears test application
1. Boot the target system with an Ethernet connection.
2. Enable package download from the “universe” repository by editing /etc/apt/sources.list as root:
$ sudo vi /etc/apt/sources.list
3. Uncomment the following line in the file by removing the leading # character:
# deb http://ports.ubuntu.com/ubuntu-ports/ trusty universe
4. Update the repository:
$ sudo apt-get update
5. Install the mesa-utils and mesa-utils-extra packages:
$ sudo apt-get install -y mesa-utils
$ sudo apt-get install -y mesa-utils-extra
6. At this point you should be able to run the application with the following steps:
$ export DISPLAY=:0
$ X&
$ /usr/bin/es2gears
GStreamer-based Multimedia Playback (NvGstPlayer)
You can use the GStreamer open source multimedia framework and the NvGstPlayer utility for testing multimedia local playback and HTTP/RTSP streaming playback use cases. The NvGstPlayer can be used as a reference implementation.
This section tells you how to install and use this application. This section includes the following sub-topics.
For more information about the NvGstPlayer application, refer to the readme file included with the release at .
Installing GStreamer
You install GStreamer from the Internet directly on the target. There is a wrapper library called gst-openmax that is an interface between GStreamer and OpenMAX, which enables accelerated NVIDIA plug-ins in the GStreamer framework
For more information about GStreamer, see the following website:
NvGstPlayer is a multimedia player test application.
Complete prerequisite steps in the file nvgstcapture_README.txt before running the NvGstPlayer and NvGstCapture applications.
Instructions for installing GStreamer are also included in that text file.
Using NvGstPlayer
NvGstPlayer is a command line media file player. It will play audio/video files encapsulated in MP4, 3GP, AVI, ASF, WMA, MKV, M2TS, WEBM, and MOV. NvGstPlayer supports local file playback and playback over RSTP, HTTP, and UDP. For information about NvGstPlayer runtime commands, default settings, and important notes see the nvgstplayer_README.txt file included in the release.
Note: To use the NvGstPlayer application, you must install the restricted codecs available (licensed separately) on the release website. For more information, see
Installing Additional NVIDIA Packages in this guide.
Gstreamer-based Camera Capture (NvGstCapture)
The NvGstCapture application supports GStreamer version 0.10.36 by default. NvGstCapture can capture audio and video data using microphone and camera and encapsulate encoded A/V data in the container file.
To use the NvGstCapture application you must install the restricted codecs package available (licensed separately) on the release website. For more information, see
Installing Additional NVIDIA Packages in this guide.
For NvGstCapture installation and usage information, see the nvgstcapture_README.txt file included with the release at <your_L4T_root>/Linux_for_Tegra/nv_tegra/nv_sample_apps.
NVIDIA Bug Reporting Script
Attaching the log file to communication about issues found with the release is beneficial. Use the nvidia-bug-report-tegra.sh script to generate log files.
To generate a log file for bug reporting
• Log into the target board and enter the below command:
$ sudo /usr/bin/nvidia-bug-report-tegra.sh
To generate a log file for bug reporting with extended logging mode
• Log into the target board and enter the below command:
$ sudo /usr/bin/nvidia-bug-report-tegra.sh -e
By default the logfile generated by both procedures above is located at $HOME/nvidia-bug-report-tegra.log.
Note: Attach a log file when reporting any bugs to NVIDIA, whether through email or the forums.
