Jetson Xavier NX and Jetson AGX Xavier Series Boot Flow

Applies to: Jetson Xavier NX and Jetson AGX Xavier series only
The flow of control in the boot software is as follows.
A screenshot of a cell phone Description generated with very high confidence

BootROM

The BootROM (BR) is hard-wired in the processor. It initializes the Boot Media and loads Microboot1 (MB1) from the Boot Media.
Multiple copies of the BootROM Boot Configuration Table (BR-BCT) may be stored at the start of the Boot-Media. The BR-BCT contains configuration parameters used by the BootROM for hardware initialization.
The BCT also contains information about the bootloader (BL), including:
Size
Entry point
Load address
Hash
The BootROM uses this information to verify and load the bootloader. The boot flow is as follows:
C:\sw\swdocs\mobile\tegra\images\bdk_bootrom_flow.jpg

Bootloader Components

For NVIDIA® Jetson™ Xavier NX and Jetson AGX Xavier™ series, the bootloader and flash components are:
Microboot1 (MB1)
TBoot-BPMP
CPU-BL
TBoot-CPU (used in flashing)
CBoot (used in cold boot)
Common Driver Framework
TBoot-BPMP, Tboot-CPU, and CBoot need to use a common set of drivers. Moreover, some libraries are common across the bootloader components. Instead of using separate sets of drivers and libraries, the binaries share a common pool of drivers and libraries called the Common Driver Framework (CDF).
The software architecture of the Common Driver Framework is as follows:
A screenshot of a cell phone Description generated with very high confidence
Common Driver Framework consists of:
Storage drivers like eMMC, QSPI-NOR, mSATA, and UFS
Host interface drivers like UART, USB
Display drivers (HDMI™, DP, and eDP)
Debug and Console library
Libraries of other modules such as:
Clock
SE
PMIC
Timer
Fuse
GPIO
PWM
EEPROM
Keyboard
PSCI
USB host mode (2.0 mode only)
USB host class drivers (only mass storage devices, no hub or HID support)
Software libraries such as:
Cryptographic
Transport
Partition manager
Sparse
Transport libraries
A decompression library that supports LZF, Zlib, and LZ4
clib, a dynamic memory allocation library, and a cache library
The CDF is provided at:
<top>/vendor/nvidia/tegra/bootloader/partner/common/
<top>/vendor/nvidia/tegra/bootloader/partner/t18x/common/
Microboot1
For Jetson Xavier NX and Jetson AGX Xavier series, Microboot1 (MB1) is the first boot software component loaded by BR in SysRAM, and runs on BPMP. This component implements certain platform initialization (including CPU) and security configuration.
MB1 is signed and encrypted by an NVIDIA owned key. The following diagram shows the flow of control in MB1.
C:\sw\swdocs\mobile\tegra\images\bdk_microboot.jpg
MB1 is responsible for:
Platform configuration, including pinmux, GPIO , pad voltage, SCRs, and firewalls
Initializing the SDRAM based on the MB1 boot configuration table (MB1-BCT)
Loading firmwares, including the ones that initialize the CPU complex (CCplex)
Programming the PMIC for enabling the VDD_CPU rail
Creating memory carveouts
Loading the next stage bootloader, TBoot-BPMP
MB1 is owned by NVIDIA, and so is provided as a binary in the Jetson BSP package. Although it is provided as a binary, you can configure its behavior for a specific platform using its Boot Configuration Table, called MB1-BCT.
For information on MB1, see MB1 BCT.

TegraBoot

On Jetson Xavier NX and Jetson AGX Xavier series, TegraBoot is the bootloader component that executes after MB1. This component is divided into two portions:
TBoot-BPMP
TBoot-CPU
The processor on which they are executing determines which component runs.
TegraBoot-BPMP
This portion of TegraBoot runs on BPMP (TBoot-BPMP). There are two variants of TegraBoot-BPMP:
One for cold boot
One for flashing and RCM (recovery) boot
TBoot-BPMP is responsible for:
Loading and initializing firmware (FW) components.
Creating memory carveouts
Unhalting the CPU
Loading the next stage bootloader
Supporting flashing
Supporting RCM boot
The components of TBoot-BPMP are as follows:
A screenshot of a video game Description generated with high confidence
TegraBoot-CPU
TegraBoot-CPU is responsible for:
Flashing
RCM boot
The RCM boot flow is similar to a cold boot except that the binaries are transferred from the host over USB and loaded directly to SDRAM. TOS and BPMP-FW are not loaded in this path.
Note:
The CPU starts execution in EL3 mode, and executes the TOS monitor. The TOS monitor completes its initialization and gives control to the TegraBoot-CPU in EL2 mode. It then initializes the USB and starts the 3P protocol to flash the device.
For normal flashing, TegraBoot-CPU takes the binaries from the host one-by-one and flashes them to the device.
In RCM boot, TegraBoot-CPU takes the binaries downloaded over USB. The binaries are not flashed onto the device.
The components of TBoot-CPU are as follows:

CBoot

On Jetson Xavier NX and Jetson AGX Xavier series, CBoot is the primary CPU bootloader used on mobile platforms in the cold boot path. CBoot is feature-rich bootloader based on Little Kernel (LK) that:
Boots the kernel
Supports display, boot logo, and Secureboot
Uses the interrupt and scheduling frameworks of LK
Note:
The CPU starts in EL3 mode and executes the TOS monitor. The TOS completes its initialization and passes control to CBoot in EL2 mode.
BL and Kernel use separate device trees stored in separate partitions.
The components of CBoot are as follows:
A screenshot of a cell phone Description generated with very high confidence
Kernel Boot Sequence Using extlinux.conf
CBoot functionality includes a default booting scan sequence. It scans bootable devices in the following order:
1. External SD card
2. USB device
3. Internal eMMC
4. NFS device
CBoot looks for an extlinux.conf configuration file in the following directory on each bootable device (except an NFS device):
<rootfs>/boot/extlinux
The file extlinux.conf is a standard text-format file that contains all kernel boot information. It contains a section for each kernel selection which indicates the kernel binary file’s name, the kernel-dtb binary file’s name, and the kernel boot command line.
Upon finding the extlinux.conf file, CBoot performs the following steps:
1. Reads the boot configuration from extlinux.conf
2. Displays the kernel selections
3. Waits for the user to choose a kernel selection
4. Selects the DEFAULT selection if the user does not respond before expiration of the TIMEOUT period (3 seconds)
5. Loads the kernel binary file from the LINUX entry
6. Loads the kernel-dtb binary file from FDT entry
7. Boots the kernel
The kernel and kernel-dtb binary files are user-accessible after booting at the location <rootfs>.
If there is no LINUX entry, the kernel binary is loaded from the kernel partition.
If there is no FDT entry, the kernel-dtb binary is loaded from the kernel-dtb partition. The default extlinux.conf file has no FDT entry.
For example, to replace the dtb binary, add this command to /boot/extlinux/extlinux.conf:
FDT /boot/<dtb_file>
Where <dtb_file> is the name of the file.
To support Secureboot, each kernel binary and kernel-dtb binary must be signed with a signature file. CBoot authenticates the kernel binary and kernel-dtb binary with their respective signature files. CBoot assumes that a signature file is in the same folder as the corresponding binary file, and has the same filename with the extension .sig.
For instance, if the kernel binary is /boot/Image, the kernel signature filename is /boot/Image.sig.
If CBoot cannot authenticate a binary file (kernel or kernel-dtb), it continues to load the binary from its corresponding partition.
Note:
if the board’s security fuse has not been burned, CBoot ignores the authentication result and continues to load/boot the kernel. In this way CBoot loosens this Secureboot policy so kernel developers can easily modify their kernel binary without going through signing procedure every time.