Revision History

Version Date Description

1

2012/12/07

Initial Release.

2

2014/09/26

git URL updates. Point out that bootloaders can be loaded to IRAM rather than SDRAM. Minor updates to cover up to Tegra124.

Introduction

This document explains the basic principles of how Tegra boots. It is intended to provide a high-level overview of the boot process, mainly from a software- or firmware-developer’s perspective, deferring to other sources for details.

This document applies to Tegra20, Tegra30, Tegra114, and Tegra124.

Hardware Architecture

Tegra SoCs contain the following components related to the boot process:

  • The main CPU complex; the dual- or quad-core Cortex A9 or A15.

  • A co-processor known as the AVP (Audio-Video Processor), or sometimes by its legacy name, COP. This processor implements the initial boot process. This processor need not be the same architecture nor implementation as the main CPU complex; on all current Tegra variants, it is an ARM7TDMI.

  • A boot ROM, containing the initial code that implements the boot process. This ROM is embedded into the SoC itself, and is not externally accessible.

  • A small embedded RAM, the IRAM. This RAM is typically dedicated for use by the AVP, and is used for state storage during the boot process, and some flashing processes.

  • Various peripheral controllers, such as eMMC, NAND, and SPI flash.

  • USB controllers.

  • A Power Management Controller, or PMC.

  • Fuses; factory-programmable read-only data embedded into the SoC.

  • Straps; signals on the Tegra package which may be pulled weakly high or low during the boot process to communicate information to Tegra.

Boot Process

When Tegra is powered on, the AVP executes code from the boot ROM. The main CPU complex is not started.

The boot ROM determines which device to boot from, by reading a combination of fuses and/or straps. Many devices are supported, such as eMMC, NAND, or SPI flash.

Production systems will hard-code the boot source. Reference or development boards may support booting from multiple different memory types, and hence provide jumpers or switches to influence the boot device selection.

Once the boot device is determined, the boot ROM will initialize the appropriate peripheral controller, and start reading data from the device. The first piece of information to be read is the BCT.

The BCT indicates:

  • How to configure the boot memory for optimal access.

  • How to configure SDRAM.

  • Where in boot memory the bootloader image is located.

  • The SDRAM location to load the bootloader into.

  • The entry point for the bootloader.

For further details, see BCT Overview.

The boot ROM processes the BCT as follows:

  • Re-programs the boot memory controller according to the parameters specified in the BCT.

  • Programs the SDRAM controller according to the data specified in the BCT. This is the first point at which SDRAM can be accessed.

  • Reads the bootloader from boot memory into RAM, and validates the image.

The bootloader load address will typically be within SDRAM, hence why the BCT contains SDRAM controller configuration data. However, the bootloader load address could also be located within IRAM. In this case:

  • The BCT need not contain valid SDRAM controller configuration data, since the boot ROM need not access SDRAM.

  • If the BCT does not contain valid SDRAM controller configuration data, and SDRAM access is required, the bootloader will need to initialize the SDRAM controller itself.

Finally, the boot ROM simply jumps to the bootloader’s entry point. At this point, all code is still running on the AVP; the boot ROM does not boot the main CPU complex.

BCT Handoff

A copy of the BCT is left in IRAM by the boot ROM. This is useful because of the spare space in the BCT structure; this may be used to communicate device-software-specific data to software components beyond the boot ROM; this information is not used by the boot ROM at all. One example is the ODMDATA field which, purely by software convention, indicates the SDRAM size, and which UART to use as the debug serial port. Note that typical software stacks on more recent SoCs use the SDRAM controller’s configuration registers to determine the SDRAM size, avoiding the need to encode redundant information into the ODMDATA.

Bootloader Responsibilities

The boot ROM loads and executes the BCT-defined bootloader on the AVP. The main CPU complex is left disabled. If the bootloader wishes to execute on the CPU complex, or wishes other software to execute on the main CPU complex, then explicit steps must be taken to activate the main CPU complex and cause it to execute that specific code.

Redundancy

The boot ROM will attempt to read the BCT from the start of the boot memory. If the BCT is missing from that location, or corrupted, the boot ROM continues to search through the boot memory until a valid BCT is found. The details regarding exactly how many read attempts are made, and which locations are attempted, are beyond the scope of this document.

The BCT contains multiple slots for bootloader information, which can point at different copies of the bootloader. This allows the system to boot even if one of the bootloader copies is corrupted.

Error Handling and Recovery Mode

Errors may occur during the boot process, such as a missing BCT, BCT hash validation failure, bootloader hash validation failure, etc. In this case, the boot ROM enters recovery mode (RCM).

Other situations may also cause entry into recovery mode:

  • A recovery mode strap exists. If this is asserted, recovery mode will be entered unconditionally. This would usually be asserted by the user pressing a button, or some system management controller asserting the strap.

  • If Tegra PMC register scratch0 bit 2 is set at power-up, recovery mode will be entered. This register bit is not cleared when Tegra resets, so any software may set this bit, then reboot, to request recovery mode.

On non-engineering parts, recovery mode enables the USB1 port in device mode, and accepts commands in the "Tegra RCM" protocol. This primarily allows code to be downloaded into IRAM, and executed on the AVP. This code may then implement any function desired, e.g. directly re-flashing the boot memory, implementing more advanced USB protocols, or potentially even fully booting the system itself.

Note that when the system enters recovery mode, it is quite likely that a valid BCT has not been processed, and hence SDRAM is not accessible. The downloaded code must somehow configure the SDRAM controller itself, if SDRAM is to be used.

Security

The Tegra SoC supports various security modes. Some of these modes require the BCT, bootloader, and/or RCM protocol messages to be encrypted and/or signed with a potentially device-specific key. Details of these features are beyond the scope of this document. These security features are quite unlikely to be enabled on any developer or reference board.

Further Information

BCT location in IRAM

See the U-Boot source code. In particular, search for any use of NVBOOTINFOTABLE_BCTPTR, bct_start, and/or NVBOOTINFOTABLE_BCTPTR.

Booting the main CPU complex

See the U-Boot source code. For Tegra, the U-Boot SPL executes on the AVP and boots the main CPU complex. The main U-Boot binary executes on the main CPU complex.

U-Boot source code
source browsing

http://git.denx.de/?p=u-boot.git;a=summary

git download

git://git.denx.de/u-boot.git

RCM protocol

See the tegrarcm source code at the URLs below. Note that tegrarcm implements multiple USB protocols; RCM to talk to the boot ROM, and additional protocols (e.g. Nv3p) to communicate with the executable that is downloaded to IRAM.