NVIDIA Tegra Linux Driver Package

Development Guide
28.3 Release

TX2 Boot Flow
Boot Loader Components
Common Driver Framework
The primary function of the Jetson TX2 boot software is to initialize the SOC (System On a Chip), including:
Initializing MC/EMC/CPU
Setting up security parameters
Loading different firmware
Maintaining Chain of Trust
Setting memory carveouts for different firmware
Flashing the device
Booting to the operating system
Additionally, the Jetson TX2 boot software also performs other operations defined by product requirements, including but not limited to:
Initialization of HDMI™/DP
Displaying the boot logo
The flow of control in the boot software is as follows.
The Jetson TX2 BootROM (BR) is hard-wired in the Tegra chip. 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 boot loader (BL), including:
Entry point
Load address
The BootROM uses this information to verify and load the boot loader. The boot flow is as follows:
Boot Loader Components
The Jetson TX2 boot loader and flash components are:
Common Driver Framework (CDF)
Microboot1 (MB1)
TBoot-BPMP (MB2)
Common Driver Framework
MB1, TegraBoot-BPMP, and TegraBoot-CPU/C‑Boot each needs to use one of several drivers. Moreover, some libraries are common across the boot loader 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).
Since U-Boot is built separately from the NVIDIA-proprietary bootloader software, it does not support or use CDF.
The software design architecture using the Common Driver Framework is as follows:
Common Driver Framework consists of:
Storage drivers like eMMC, QSPI, mSATA, and UFS
Host interface drivers like UART, USB
Display drivers
Debug and Console library
Libraries of other modules such as:
Software libraries such as:
Partition manager
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:
Jetson TX2 Microboot1 (MB1) is the first boot software component loaded by BR in SysRAM, and runs on BPMP. MB1 is considered as an extension to BR. MB1 provides extensive flexibility to alter or fix the boot sequence. This component also implements some delicate functionality like Denver initialization and security fabric changes.
Because MB1 is an extension to BootROM, it is signed and encrypted by an NVIDIA owned key (separate keys residing in BootROM). The following diagram shows the flow of control in MB1.
MB1 is responsible for:
Firmware initialization, include MTS preboot, SPE, and CAN
Platform configuration which includes:
Configuring pinmux
Configuring GPIO
Pad settings
Prod settings
Initializing rails including those required by CPU, memory, GPU, etc.
PMIC commands required by BR
Configuring SCR
Initialize the SDRAM based on the MB1 boot configuration table (MB1-BCT)
Load the firmware that initializes the CPU complex (CCplex)
Set the security settings
Configure pinmux/GPIO for the SoC
Program the PMIC for the VDD_CPU and VDD_DDR rails
Create carveouts
Support flashing, available as a different mb1_recovery.bin binary
Support RCM boot by downloading a blob that contains the binaries, and loading binaries from that blob
Load the next stage boot loader, TBoot-BPMP (MB2)
Support SC7
MB1 is owned by NVIDIA, and so is provided as a binary in the 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. MB1 reads MB1-BCT to configure the platform.
For information on MB1, see MB1 BCT .
Jetson TX2 TegraBoot is the boot loader component that executes after MB1. This component is divided into two portions:
TBoot-BPMP (MB2)
The processor on which they are executing determines which component runs. Both are released to OEMs as source code for reference implementation.
This portion of Jetson TX2 TegraBoot runs on BPMP (tboot-BPMP). There are two variants of TegraBoot-BPMP (MB2):
One used for cold boot
One for recovery boot
Both are generated using different configuration files and make files.
TBoot-BPMP is responsible for:
Loading and initializing firmware (FW) components For details see Security.
Creating carveouts
Completing CPU initialization
Loading the next stage boot loader
Supporting flashing
Supporting RCM boot; which is the TegraBoot-BPMP (MB2) recovery boot
Reading PMIC reset reason
Loading the bootloader device tree and passing the device tree load address to CPU-BL
Giving control to BPMP-FW
The components of TBoot-BPMP are as follows:
A screenshot of a video game Description generated with high confidence
Jetson TX2 TegraBoot-CPU is responsible for:
RCM boot
The flow for RCM boot 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.
As soon as the CPU starts running, it starts in EL3 mode. The TOS monitor code completes its initialization and gives control to the TegraBoot-CPU. 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 from the blob downloaded by MB1. The binaries are not flashed onto the device.
TBoot-CPU can also support cold boot by integrating the relevant libraries such as linuxboot, etc.. However this version of TBoot-CPU is not tested or maintained.
The components of TBoot-CPU are as follows:
Jetson TX2 C‑Boot is the primary CPU boot loader used on mobile platforms in the cold boot path. C‑Boot is feature-rich boot loader that:
Boots the kernel
Supports display, boot logo, and Verified boot
Based on the Little Kernel (LK) open source boot loader
Uses the interrupt and scheduling frameworks of LKC
Uses CDF for frameworks, drivers, and libraries
As soon as the CPU starts running, it starts in EL3 mode and begins executing TOS. TOS completes its initialization and passes control to C‑Boot in EL2 mode.
BL and Kernel use separate device trees stored in separate partitions. C‑Boot is responsible for:
Parsing the CPU-BL parameters and initializing the boot loader device tree
Booting to the kernel or chaining to U-Boot to boot the kernel
Supporting the update mechanism
Loading the recovery kernel
Verified boot
The components of C‑Boot are as follows:
A screenshot of a cell phone Description generated with very high confidence
The source code for C‑Boot is available to the public at:
The source code is in a file named cboot_src.tbz2. It includes instructions for users.
U-Boot is the default boot loader for NVIDIA® Tegra® Linux Driver Package.
For more information, see:
U-Boot Customization
TX2 MB1 Platform Configuration