NVIDIA Tegra
NVIDIA Jetson Linux Driver Package Software Features
Release 32.3 | December 10, 2019

 
U-Boot Customization
 
Requirements
Placeholders in Commands
Downloading and Building U-Boot
Prerequisite
Before Flashing
Flashing U-Boot Full Jetson Linux Driver Package Image
Flashing U-Boot Only
Changing the Boot Memory Device Partition Layout
eMMC IC Property
Root Filesystem Size
GPT Partitions
LNX Partition
APP Partition
Full Boot Memory Device Partition Layout
Building the Device Tree Compiler
Replacing the Kernel
Copying the Root Filesystem
Boot Sequence and Sysboot Configuration Files
Optimizing U-Boot Boot Time
Disabling PCIe Support
Enabling/Disabling ASPM Support
Disabling USB Support
Environment Configuration
Setting Environment Variables
Compile Time
Manufacturing and Flashing Time
extlinux.conf Modifications
Debugging in the U-Boot Environment
Applies to: NVIDIA® Jetson Nano™ and NVIDIA® Jetson™ TX2 series devices
U-Boot is the default bootloader for NVIDIA® Jetson™ Linux Driver Package (L4T) on Jetson Nano and Jetson TX2 series devices.
Requirements
The software requirements and prerequisites include:
Linux-based host system
Functionality of the U-Boot build and flashing utilities are validated using an Ubuntu <os_ver_host> host system. Later versions of Ubuntu, or alternative Linux distributions, may work with host-specific modifications.
Jetson Linux Driver Package (L4T)
Download and install the latest L4T package from NVIDIA Developer Zone:
http://developer.nvidia.com/linux-tegra
Device Tree Compiler (DTC)
The DTC is used to compile device tree files contained in the U-Boot source tree. For a detailed example of building DTC from source see Building Device Tree Compiler.
You must use the pre-built DTC binary that is included in the kernel directory of the release. Many of the DTC packages available from standard Linux distribution package management systems, like APT, are not updated with a version of DTC that supports the features required by the U‑Boot makefile.
The pre-built DTC binary is built from the kernel sources in this release. The sources are located in the scripts/dtc directory. You build DTC by building the kernel dtbs target.
The Linaro Aarch64 toolchain
The toolchain is available for downloading at:
https://www.linaro.org/downloads/
U‑Boot source
For information, see Downloading and Building U-Boot.
Kernel source
For information, see:
Setting up the Root File System
Downloading and Building U-Boot
Building the NVIDIA Kernel
Adding a Compiled Kernel to the Root File System
Placeholders in Commands
This topic describes many commands that use these placeholders:
<board> identifies the Jetson device in use. Substitute:
For Jetson Nano: p3450-porg
For Jetson TX2 series devices: p2771-0000
<board_and_rev> identifies the Jetson device and revision in use. Substitute:
For Jetson Nano: p3450-porg
For Jetson TX2 series devices: p2771-0000-500
Other placeholders are described in each section that uses them.
Downloading and Building U-Boot
Before flashing U-Boot to your reference platform, you must download and build it on your Linux host system. NVIDIA offers a Git repository containing the source code for a version of U‑Boot suitable for L4T.
Prerequisite
Before overwriting the U-Boot binaries with the extracted L4T release package, back up all of the original U-Boot files in:
Linux_for_Tegra/bootloader/<platform>/<board_and_rev>/
Where:
<platform> is the SoC name or platform.
<board_and_rev> is described in the section Placeholders in Commands.
To download and build U-Boot
1. Perform either of the following steps:
Run the command:
$ git clone -n git://nv-tegra.nvidia.com/3rdparty/u-boot.git
Run the source_sync.sh script from the in which you want to place the L4T release package.
If you run source_sync.sh –u without parameters, the script prompts for the <tag_name>, which is the release tag name as provided in the Release Notes.
The -k option to source_sync syncs the kernel sources. A space between the -u and -k options is allowed. By default, if no option is provided, the script syncs the kernel and U-Boot sources.
Also, you can run the script by passing the <tag_name> as follows:
$ cd <your_L4T_root>/Linux_for_Tegra
$ ./source_sync.sh –u <tag_name>
This syncs the source to the following location, relative to the location of source_sync.sh:
sources/u-boot_source
The U‑Boot source code is placed in this directory, relative to the location of the L4T release package:
Linux_for_Tegra/sources/u-boot_source
Note
The rest of these instructions assume your current working directory is the U-Boot source tree.
2. Check out the Git tag name:
$ git checkout –b <branch_name> <tag_name>
Where:
<branch_name> is the name of your local branch.
<tag_name> is the release tag name as provided in the Release Notes.
3. Set the build environment:
$ export CROSS_COMPILE=<cross_prefix>
Where:
<cross_prefix> is the absolute path to the ARM64 toolchain without the .gcc suffix. For example, for the reference ARM64 toolchain, <cross_prefix> is:
<toolchain_install_path>/bin/aarch64-linux-gnu-
See The Jetson Linux Driver Package Toolchain for information on how to download the reference toolchain.
Note
NVIDIA recommends using the Linaro 7.3.1 2018.05 toolchain.
4. Build U-Boot by executing:
$ make distclean
$ make <board_and_rev>_defconfig
$ make
Where <board_and_rev> is described in the section Placeholders in Commands.
Before Flashing
Before flashing, you must copy the updated U-Boot binary to the L4T tree.
To copy the updated U-Boot for flashing to the reference platform
Run this command on your Linux host system:
$ cp <uboot_src_dir>/u-boot{,.bin,.dtb,-dtb.bin} \
<your_L4T_root>/Linux_for_Tegra/bootloader/<platform>/<board_and_rev>
Where:
<uboot_src_dir> is <your_L4T_root>/Linux_for_Tegra/sources/u-boot_source.
<your_L4T_root> is the location of the L4T release package.
<platform> is the SoC name or platform.
<board_and_rev> is described in the section Placeholders in Commands.
Flashing U-Boot Full Jetson Linux Driver Package Image
At boot time, U-Boot fetches the boot configuration file, kernel and device tree, which can reside on the boot storage device:
An SD card for Jetson Nano
Internal eMMC memory for Jetson TX2
When you execute the script that flashes U-Boot, specify a command line option to identify the storage device containing the root filesystem. This enables the script to select the appropriate boot configuration file. The boot configuration file contains kernel command line parameters that control where the Linux kernel looks for the root filesystem.
To flash U-Boot and select the script to mount the root filesystem from internal eMMC
Select a boot configuration file that causes the kernel to mount the root filesystem from the boot storage device.
For an SD card on Jetson Nano:
$ sudo ./flash.sh <platform> mmcblk0p1
For eMMC memory on Jetson TX2:
$ sudo ./flash.sh <platform> mmcblk0p1
Where <platform> is the SoC name or platform.
To flash U-Boot and select the script to mount the root filesystem from an NFS server
Select a boot configuration file that causes the kernel to mount the root filesystem from an NFS server:
$ sudo ./flash.sh –N <IPA>:/<nfs directory> [-n <target IPA>:<host IPA>:<gateway IPA>:<netmask>] <platform> <interface name>
Where:
<IPA> is the NFS server hosting the root filesystem.
<nfs_directory> is the full pathname of exported root filesystem.
<target IPA> is the static IP address for the target device.
<host IPA> is the static IP address for the NFS server.
<gateway IPA> is the static IP address for the gateway.
<netmask> is the static netmask for the local network.
<platform> is the SoC name or platform.
<interface name> is eth0 for RJ45 connector and eth1 for a USB Ethernet dongle (supported on Jetson TX2 series devices only).
 
Note
The -n option is recommended on point-to-point network connections where no DHCP server is configured.
Flashing U-Boot Only
To flash the full Jetson Linux Driver Package (L4T) image to the reference platform, see Flashing U-Boot Full Jetson Linux Driver Package Image, above.
To flash the new version of U-Boot
Run the command:
$ sudo ./flash.sh -k LNX <platform> mmcblk0p1
Where <platform> is the SoC name or platform.
Changing the Boot Memory Device Partition Layout
This topic is based on SD card or eMMC hardware and software layout information in the following files.
For Jetson Nano:
Linux_for_Tegra/p3448-0000.conf.common
Linux_for_Tegra/bootloader/<platform>/cfg/flash_l4t_t210_spi_sd_p3448.xml
For Jetson TX2 series devices:
Linux_for_Tegra/p2771-0000.conf.common
Linux_for_Tegra/bootloader/<platform>/cfg/flash_l4t_t186.xml
Where <platform> is the SoC name or platform.
Note
The kernel is installed into the filesystem alongside the boot configuration file. The kernel (LNX) partition contains U-Boot.
eMMC IC Property
Applies to: Jetson TX2 series devices only.
The eMMC IC property is determined by two variables in the Linux_for_Tegra/<target_board>.conf.common:
BOOTPARTSIZE: Specifies the eMMC boot partition size, which is boot0 partition size + boot1 partition size.
EMMCSIZE: Specifies the eMMC usable data size, which is BOOTPARTSIZE + user partition size.
Note
boot0, boot1, and user partition size can be obtained from the eMMC device datasheet.
The eMMC IC property:
Limits the size of the total usable data area
Determines the location of GPT partitions
Root Filesystem Size
The root filesystem partition is the largest of the partitions. The size of this partition is one of the key factors in partition layout determination.
To modify the root filesystem partition size
Modify the value of the ROOTFSSIZE variable in the Linux_for_Tegra/<target_board>.conf.common file.
Note
The total space used by all partitions cannot exceed EMMCSIZE.
GPT Partitions
The flash.sh script creates the primary and secondary GPT partitions automatically, based on the layout of the boot memory device partition.
The protective MBR contains device information to prevent traditional bootloaders from performing destructive actions. It is located at Logical Block Address (LBA) 0.
The primary GPT partition contains the GUID Partition Table. It is located at LBA 1.
The secondary GPT partition contains the same information as the primary GPT and serves as a backup. It is located at the last LBA of the boot device.
The last LBA varies from device to device. Both U-Boot and the kernel are able to obtain the last LBA.
LNX Partition
The LNX partition ordinarily contains the kernel. When the bootloader is U‑Boot, however, this partition contains U-Boot, and U-Boot reads the kernel from the root filesystem.
APP Partition
If root filesystem storage is on the boot storage device, the root filesystem is flashed to this partition. U-Boot expects the boot configuration file and kernel files to exist in the <rootfs>/boot directory. The flash.sh script flashes the following kernel files in the APP partition:
kernel (Image)
boot configuration file (extlinux/extlinux.conf)
Note
The flash.sh script treats the root filesystem-on-IP-network configuration as a special case. It flashes these kernel files in the <APP partition>:/boot directory.
Full Boot Memory Device Partition Layout
For an example of a boot storage device configuration file, see:
For Jetson Nano: flash_l4t_t210_spi_sd_p3448.xml
For Jetson series devices: flash_l4t_t186.xml
Building the Device Tree Compiler
The Device Tree Compiler (DTC) must be built from source code.
Note
If you do not want to pass in the DTC filename as a parameter to the U‑Boot environment, ensure that a local directory which contains DTC, such as /usr/local/bin/, is at the beginning of the shell command path.
To build DTC from source
1. Run these commands to download the DTC source code and go to the directory is the root of the DTC source tree:
$ git clone git://git.kernel.org/pub/scm/utils/dtc/dtc.git
$ cd dtc
The rest of this procedure assumes that your current working directory is the DTC source tree.
2. Run this command to build DTC:
$ make
To build DTC in the default directory $HOME, run:
$ make install
To build DTC in a specific directory, run:
$ make install PREFIX=/usr/local
Where PREFIX specifies the pathname of the directory.
In any case, make builds the following directories below the installation directory:
bin
lib
include
Replacing the Kernel
You can replace the kernel with your own custom kernel. Use the procedure that applies to your device’s type of boot storage device.
To replace the kernel directly on a live system
Applies to: Jetson TX2 series devices only.
You can use this process on SD card and USB storage boot memory devices.
1. Boot the Jetson TX2 and Jetson TX2i system.
2. Copy the new kernel files, using scp, into the /boot directory.
3. Reboot the Jetson TX2 and Jetson TX2i system.
To replace the kernel on a system that boots from an SD card or USB device
Applies to: Jetson TX2 series devices only.
1. Connect the boot memory device (SD card or USB device) to your host system.
2. Copy the new kernel files to the /boot directory on the boot memory device.
3. Disconnect the boot memory device from the host system.
4. Connect the boot memory device to the Jetson system.
5. Reboot the Jetson system.
To replace the kernel in systems that boot from an NFS server
1. Boot the Jetson system.
2. Enter the following command on the target system:
$ sudo mount /dev/mmcblk0p1 /mnt
3. Use scp to copy the new kernel files to the mnt/boot directory.
4. Reboot the Jetson system.
Copying the Root Filesystem
For external media, you must copy the root filesystem to the device after you run the flash.sh command. Then you attach the device to the target system. This is required because the flash.sh script adds the required files to the root filesystem directory on the host when it runs.
Boot Sequence and Sysboot Configuration Files
U-Boot functionality includes a default booting scan sequence. It scans bootable devices in the following order:
External SD card
Internal eMMC (Jetson TX2 series devices only)
USB device (Jetson TX2 series devices only)
NFS device
U‑Boot looks for an extlinux.conf configuration file in the following directory of the bootable partition on each bootable device:
<rootfs>/boot/extlinux
Upon finding the extlinux.conf file, U-Boot performs the following steps:
1. Uses the sysboot command to read out boot configuration from extlinux.conf
2. Loads the kernel Image file
3. Boots the kernel
The Image file is user-accessible in the <rootfs>/boot location after booting. The extlinux.conf file is user-accessible in the <rootfs>/boot/extlinux location. You can easily change these files to test your own kernel without flashing.
The file extlinux.conf is a standard text-format sysboot configuration file that contains all boot information. It indicates the kernel image filename, the device tree blob filename, and the kernel boot command line.
Optimizing U-Boot Boot Time
By default, U-Boot uses a default configuration that enables all supported hardware features. It searches the available devices for boot scripts. This enables out-of-the-box support for the widest possible variety of storage devices and boot configurations.
This flexibility delays execution of the final operating system because hardware support takes time to initialize and scanning all attached storage and network devices takes time. In constrained or pre-configured systems, this flexibility may not be necessary. You may know ahead of time which storage device contains the required files or that certain devices need not be initialized by the bootloader. To optimize boot time, configure U-Boot to reduce system boot time by taking advantage of these constraints.
These changes must be made in the kernel sources.
Disabling PCIe Support
Applies to: Jetson TX2 series devices only.
U-Boot delays enumerating and initializing PCIe devices until the user, or a boot script, explicitly attempts to access a PCIe device. Consequently, disabling PCIe support does not reduce boot time.
To disable PCIe support
1. Remove the following values from include/configs/<board>.h:
CONFIG_PCI_EHCI
CONFIG_PCI_TEGRA
CONFIG_CMD_PCI
2. Remove the following values from configs/<board_and_rev>_defconfig:
CONFIG_PCI_TEGRA
CONFIG_RTL8169
CONFIG_E1000
Where <board> and <board_and_rev> are described in the section Placeholders in Commands.
Enabling/Disabling ASPM Support
U-Boot delays enumerating and initializing Active State Power Management (ASPM) PCIe devices until the user, or a boot device, explicitly attempts to access a PCIe ASPM device. Consequently, disabling ASPM support does not reduce boot time.
To enable ASPM support
1. Remove the following value from configs/<board_and_rev>_defconfig:
CONFIG_PCIEASPM
2. Add the following value:
CONFIG_PCIEASPM_POWERSAVE=y
Where <board_and_rev> is described in the section Placeholders in Commands.
To disable ASPM support
1. Remove the following value from configs/<board_and_rev>_defconfig:
CONFIG_PCIEASPM_POWERSAVE=y
2. Add the following value.
CONFIG_PCIEASPM
Where <board_and_rev> is described in the section Placeholders in Commands.
Disabling USB Support
Applies to: Jetson TX2 series devices only.
U-Boot delays enumerating and initializing USB devices until the user, or a boot script, explicitly attempts to access a USB device. Consequently, disabling USB support does not reduce boot time.
To disable USB support
1. Remove the following values from configs/<board_and_rev>_defconfig:
CONFIG_CMD_USB
CONFIG_CMD_USB_MASS_STORAGE
CONFIG_USB
CONFIG_USB_GADGET
CONFIG_USB_GADGET_DOWNLOAD
2. Edit include/configs/<board>.h to remove the #include of tegra-common-usb-gadget.h.
3. Edit include/configs/tegra-common-post.h to remove the USB entry from BOOT_TARGET_DEVICES.
Where <board> and <board_and_rev> are described in the section Placeholders in Commands.
Environment Configuration
U-Boot runtime behavior is controlled by scripts contained in the U-Boot environment. When U-Boot begins execution, it waits <bootdelay> seconds before executing the automatic boot sequence. During this time, the user may interrupt the boot process to access the U-Boot shell. If not interrupted, U-Boot executes <bootcmd> as a shell command. <bootcmd> contains a series of commands to search storage devices for boot scripts and execute them.
By modifying the values of these variables at compile or manufacturing time, U‑Boot can be directed to boot from a specific device in a specific manner, thereby reducing boot time.
The following table identifies the variables that can be modified.
Variable
Description
bootdelay
Contains the number of seconds that U-Boot pauses to determine whether the user wants to interrupt the boot sequence.
To eliminate the delay, set to 0.
Note: If the user requests to interrupt the boot process before the U-Boot shell is reached, the request is honored even if bootdelay is set to 0.
If the delay is less than 0, U‑Boot displays the boot menu and disables autoboot.
bootcmd
Contains a sequence of U-Boot shell commands to be executed automatically at boot.
Note that many simple customizations, such as selecting a specific storage device for booting, do not require editing this value.
boot_targets
Contains a space-delimited list of storage devices or network protocols that U-Boot scans to find boot scripts.
Valid values include:
mmc0: the built-in eMMC
mmc1: the SD card slot
usb0: any attached USB Mass Storage device
pxe: network, using DHCP to receive an IP address, then PXE to download a syslinux configuration file
dhcp: network using DHCP to receive an IP address, then TFTP to download a U-Boot boot script
This variable can specify a subset of the possible values, and even to a single value if the application does not require alternative boot devices.
scan_dev_for_boot_part
Contains a script to parse the device partition table and determine which partition U-Boot must scan for boot files.
If the partition number is known ahead of time, replace the script with a simpler script that hard-codes the value of <devplist> as a single partition number (in hexadecimal), and then runs either or both of the following variables:
scan_dev_for_extlinux
scan_dev_for_boot_scripts
boot_prefixes
Contains a list of file system directories to scan for boot scripts or configuration files.
File system layouts vary in different installations. For example, the boot directory may be /boot in the file system’s root directory, or it may be in a separate partition mounted elsewhere on the file system.
By default, U-Boot searches the root directory ( / ) and /boot/.
In constrained cases, the user may set this variable to a single directory name so that U-Boot does not search unnecessary directories.
Note: All entries in this variable must contain both a leading and a trailing slash.
scan_dev_for_extlinux
Contains a script to search for extlinux configuration files. If found, boots the system based on their content.
If the system is known not to use extlinux configuration files, set this script to an innocuous command, such as true. Do not leave it empty, which would make U‑Boot complain about an attempt to execute an empty variable as a script.
scan_dev_for_scripts
Contains a script to search for U-Boot boot scripts. If found, loads and executes them.
If the system is known not to use U-Boot boot scripts, replace this script an innocuous command, such as true. (See the explanation for scan_dev_for_extlinux.)
Note: The default boot scripts execute <scan_dev_for_extlinux> prior to executing <scan_dev_for_scripts>. Therefore, modifying this variable does not affect systems that boot using extlinux configuration files because this script is never executed.
boot_scripts
Contains a space-delimited list of U-Boot script names for <scan_dev_for_scripts> to search for.
If the script name is known ahead of time, set this variable to the desired value rather than the default list.
Setting Environment Variables
You can set environment variables at:
Compile time
Manufacturing time
Flashing time
Compile Time
When U-Boot starts executing, it attempts to initialize the environment variables from data stored in flash memory. The location of the data is determined by the U-Boot configuration file on the board. If the data is missing or corrupted, U-Boot uses a default set of values built into the U-Boot binary.
The default L4T flashing process does not write this data into flash memory, so the built-in copy is always used initially. The built-in default values are set in the following places in the U-Boot source code.
Note
In the following table:
Fixed-space names in upper case represent configuration variables in the U‑Boot source code. Example: CONFIG_BOOTDELAY.
Fixed-space names in lower case represent environment variables. Example: bootdelay.
 
U-Boot Source Code
Environment Variable Value
include/config_distro_bootcmd.h
Defines variables and scripts related to the automatic boot process.
include/config/auto.conf
CONFIG_BOOTDELAY sets the value of bootdelay.
include/configs/tegra‑common‑post.h
BOOT_TARGET_DEVICES sets the value of boot_targets.
BOOT_TARGET_DEVICES also determines the set of legal values that can appear in boot_targets. Removing entries from this variable prevents the use of those values in <boot_targets> at all.
To modify this value at compile time:
1. Modify include/config_distro_bootcmd.h to avoid setting boot_targets if the board-specific configuration file has already defined this value.
2. Modify include/config/<board>.h to set boot_targets.
(Where <board> is described in the section Placeholders in Commands.)
Manufacturing and Flashing Time
Applies to: Jetson TX2 series devices only.
You can modify your manufacturing flow to write a saved copy of the environment variables to flash memory. Here are some alternative ways to modify your manufacturing flow:
After flashing the board, arrange for the board to execute U-Boot, and cause U-Boot to execute commands that modify and save the environment:
Reset the board so that U-Boot runs and executes commands sent using the serial console. You must write and execute a program on your host system which detects when U-Boot begins running, interrupts the U-Boot automatic boot process, and sends commands to U-Boot.
Execute a sequence of commands similar to these:
$ env default –f –a; setenv boot_targets mmc0; saveenv
Manually edit the U-Boot environment, save it, and extract the appropriate flash memory region to a file on your host system. Then modify the Jetson L4T partition layout XML file so that the data is written to flash during any subsequent flashing process.
You may also use this technique if your manufacturing process programs flash chips directly, rather than using the L4T flashing tools on each board. You must merge the saved, extracted environment data into your flash image file, rather than reference it from the L4T partition layout XML file.
Generate a set of saved environment data using the U-Boot fw_env tool, located in the tools/env directory in the U-Boot source code. Then modify the L4T partition layout XML file so that data is written to flash during any subsequent flashing process.
You may also use this technique if your manufacturing process programs flash chips directly, rather than using the L4T flashing tools on each board. You must merge the saved, extracted environment data into your flash image file, rather than reference it from the L4T partition layout XML file.
extlinux.conf Modifications
L4T includes an extlinux.conf file that tells U-Boot which kernel filenames to load. This file also includes the command line to pass to the kernel. The file is configured to display a boot menu to the user for three seconds before booting. To reduce boot processing time, you can remove this timeout.
To remove the extlinux.conf timeout boot menu
Edit extlinux.conf to remove the lines containing these keywords:
TIMEOUT
MENU
On an installed L4T target system, this file is located at:
/boot/extlinux/extlinux.conf
Prior to flashing, this file is located in the host L4T flashing directory in the bootloader directory.
Debugging in the U-Boot Environment
Use these debugging tips to help you debug your U-Boot environment. These examples do not represent a comprehensive listing of U-Boot functionality. For a full list of supported commands and their usage by U-Boot, consult U-Boot documentation and source.
To interrupt U-Boot
1. Connect a terminal application to the serial port of the board.
2. Power on or reset the board.
3. Wait for the U-Boot sign-on message to appear. Key presses before this message appears may be ignored.
4. Press any key to interrupt the automatic boot process.
To see the U-Boot Help text
To see the U-Boot help text enter the following command:
# help
To list the directory structure of a device
To list the directory structure of eMMC device 0 partition 1, enter this command on the target:
# ls mmc 0:1
This command functions correctly on EXT2/3/4 and FAT file systems.
Example output follows:
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 4096 bin
<DIR> 4096 boot
<DIR> 4096 dev
<DIR> 4096 etc
<DIR> 4096 home
<DIR> 4096 lib
<DIR> 4096 lost+found
<DIR> 4096 media
<DIR> 4096 mnt
<DIR> 4096 opt
<DIR> 4096 proc
<DIR> 4096 root
<DIR> 4096 sbin
<DIR> 4096 selinux
<DIR> 4096 srv
<DIR> 4096 sys
<DIR> 4096 tmp
<DIR> 4096 usr
<DIR> 4096 var
To list the contents of a directory
Run this command:
# ls mmc 0:1 <directory>
Where <directory> is a pathname in the filesystem.
For example, to list contents of the /boot directory where the Image file should be, (as shown in the example output below), use the following command:
# ls mmc 0:1 /boot
<DIR>       1024 .
<DIR>       1024 ..
             908 extlinux
         5910248 Image
If you know the type of file system the directory is in, you may use one of the file system-specific directory listing commands implemented in U‑Boot: ext2ls, fatls, etc.
To print the U-Boot environment
Run this command:
# printenv
To print an environment variable
Run this command:
# printenv <environment_variable>
Where <environment_variable> is an environment variable in U‑Boot.
For example, to print the list of devices to which U-Boot sends console output, run:
# printenv stdout
The output looks like this:
stdout=serial
To set an environment variable
Run this command:
# setenv <environment_variable> <new_value>
Where <environment_variable> is an environment variable in U‑Boot and <new_value> is the new value for that variable.
For example, to modify the set of devices to which U-Boot sends console output, run:
# setenv stdout serial
To save the modified environment
Applies to: Jetson TX2 series devices only.
Run this command:
# saveenv
The command preserved the saved modified environment in case of resets and reboots.