This topic describes the boot flow for NVIDIA® Tegra® code-name Parker for native environments.

The primary functionality of the different components of boot software is initialization of SOC (System On a Chip), including MC/EMC initialization and CPU initialization; setting up the security parameters; loading different firmware; maintaining Chain of Trust; setting memory carveouts for different firmware; flashing the device; and booting to the OS. Boot software also performs other operations defined by product requirements, including but not limited to display (HDMI/DSI), displaying the boot logo, boot OS specific update mechanisms and OS specific boot methods.

The following diagram illustrates the flow of control in the boot software.

 

The 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 BR-BCT (Boot Configuration Table) are 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:

The BootROM uses this information to verify and load the boot loader. The following diagram shows the boot flow.

The boot loader and flash components are:

MB1, TegraBoot-BPMP, and TegraBoot-CPU/CBoot 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).

The following diagram shows the software design architecture using CDF:

CDF consists of the following:

The CDF is in the following location:

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:

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.

TegraBoot is the boot loader component that executes after MB1. This component is divided into two portions: TBoot-BPMP (MB2) and TBoot-CPU, depending on the processor on which they are executing. Both are released to OEMs as source code for reference implementation.

This portion of TegraBoot runs on BPMP. There are two variants of TegraBoot-BPMP (MB2), one used for cold boot and the other for recovery boot. Both are generated using different configuration files and make files.

TBoot-BPMP is responsible for:

The following block diagram shows the components of TBoot-BPMP:

TegraBoot-CPU is a component of TegraBoot that runs on the CPU. Use TegraBoot-CPU to flash the device. You can also use TegraBoot-CPU for “RCM boot,” whose flow is very similar to a cold boot except that the binaries are transferred from the host over USB and are loaded directly to SDRAM. TOS and BPMP-FW are not loaded in this path.

TegraBoot-CPU is responsible for:

As soon as the CPU starts running, the CPU starts in EL3 mode. TegraBoot-CPU executes a trampoline code which changes the processor mode from EL3 to EL2. It then initializes 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 case of RCM boot, it takes the binaries from the blob downloaded by MB1. The binaries are not flashed on to the device.

TBoot-CPU can also support cold boot by integrating the relevant libraries (linuxboot, etc.). However this version of TBoot-CPU is not tested or maintained.

The following block diagram shows the components of TBoot-CPU:

CBoot is the primary CPU boot loader used on mobile platforms in the cold boot path. CBoot is feature-rich boot loader used for cold boot. In addition to booting the kernel, it also supports display, boot logo, and verified boot.

CBoot is based on the Little Kernel (LK) open source boot loader. CBoot primarily uses the interrupt and scheduling frameworks of LK. Cboot uses CDF for frameworks, drivers, and libraries.

As soon as the CPU starts running, CBoot starts in EL3 mode and begins executing TOS. TOS completes its initialization and passes control to CBoot in EL2 mode.

BL and Kernel will use separate device trees stored in separate partitions. CBoot is responsible for:

The following block diagram shows the components of CBoot:

U-Boot is the default boot loader for NVIDIA® Tegra® Linux Driver Package (L4T). For information on U-Boot, refer to U-Boot Customization.

TegraFlash is the host software component primarily responsible for flashing binaries onto the device.

For more information about TegraFlash, see the following:

This section explains the security in the BDK.

All of the binaries involved in the boot process have a generic header (except MB1). The binary is appended to the generic header. The header stores the signature of the binary, which is used for validation in secure boot.

The following table summarizes the boot binaries available in Tegra Code-name Parker and their respective signing authorities.

Secure boot provides a system of cryptographic checks at each stage of the boot process. These checks ensure the integrity of all of the system software that is executed, preventing any unauthorized or maliciously modified software from being run.

The secure BootROM is responsible for initializing the hardware root of trust (RoT) in the Tegra BSP.

Cryptography is enabled as follows:

Supported boot devices include:

The following diagram shows the flow of secure boot functionality.

If authentication fails, the Boot ROM automatically goes into USB Recovery mode and waits for input via the USB. The Boot ROM never yields control from Recovery Mode except to authenticated code or error messages.

The following three diagrams show the flow of secure boot stage by stage. Light colored blocks indicate transitions from one diagram to the next.

Each element marked with an asterisk (“*”) has a note below the diagram.

TBoot-BPMP: This is the main binary loader in the boot flow. It loads the binaries that are required to start CPU execution. These binaries are owned by the OEM, and are verified and decrypted using the OEM authority.

After the CPU has started executing the main boot path, TBoot-BPMP loads the coprocessor FWs. Each of these FWs may be verified and decrypted by the OEM authority or the NVIDIA authority, but not by both.

After all components have been loaded, the boot path BPMP code exits and the CPU software resets it into execution of the BPMP FW.

In the distributed BSP, TBoot-BPMP loads the following binaries:

The OEM controls loading of these binaries, and may include or exclude components as appropriate.

SPE, APE, and SCE/CPE FWs: This firmware is loaded by TBoot-BPMP, but is later started by CBoot. Each firmware may be verified and decrypted by the OEM authority or the NVIDIA authority, but not by both.

TBD - Need build instructions in tmp mentioned by Tom Warren for this section.