BCT Overview

This document explains the general structure of the Tegra BCT, or Boot Configuration Table.

The BCT is a data structure that provides basic system initialization parameters, and defines the bootloader to execute. The BCT contains:

The BCT contains a cryptographic hash or signature of the overall BCT itself, and each individual copy of the bootloader. This allows the boot ROM to validate that the BCT, and later the bootloader, has been successfully located, and read from boot memory without corruption or tampering.

When a chip has an RSA public key (PKC) programmed into its flash, it expects the BCT to contain RSA-PSS signatures created/validated using that key pair. When a chip has an AES key (SBK; Secure Boot Key) programmed into its flash, it expects the BCT to contain AES-CMAC hashes created/validated using that key. Chips without either a PKC or SBK programmed act as if an "all zeroes" SBK is enabled. PKC and SBK are typically not programmed on developer/reference boards, and even some production systems.

For this reason, whenever the bootloader is modified, the BCT must be re- generated and re-programmed, so that the bootloader hash is up-to-date.

The BCT contains space for four copies (known as "sets" or "parameter sets") of both the SDRAM and boot memory (or "device") configuration. Fuses and/or straps encode which set is used. This allows, for example, the same software image to be used across multiple builds of a board, each using a different SDRAM chip and/or boot memory configuration; the SDRAM chip and/or boot memory selection, and strap selection would be altered in tandem during the board manufacturing process to select the appropriate data set within the BCT.

If a particular board never uses fuse or strap values that would select a particular parameter set, there is no need to fill it in. It is common for only one set to be filled in, or for the same values to be duplicated into all sets.

When reading the BCT, the relevant boot memory controller is programmed with conservative timings and/or uses a boot-specific protocol. The boot memory configuration in the BCT allows the controller to be reprogrammed with optimal timings and/or accessed using a more general-purpose protocol.

Various versions of Tegra supports reading the BCT and bootloader from varying subsets of NAND, SPI flash, or eMMC/SD. For each of these device types, a different set of configuration information is required by the relevant device controller.

For each boot memory configuration, there is also a field that defines which memory type it represents. This field is solely an error-check; the value in the BCT must match the memory type that the BCT was read from. In other words, it is not possible, for example, for the boot ROM to read the BCT from SPI flash, but then read the bootloader from eMMC.

Tegra does not support SPD for SDRAM identification, but rather expects that a specific size and configuration of memory device be attached. Equally, correct configuration of the memory controller requires careful qualification of an individual board design’s signal timing properties across a wide range of operating conditions. As such, some aspects of the SDRAM controller configuration may vary between boards using an identical SDRAM device.

Tegra’s SDRAM controller itself contains many registers that must be programmed based on the selected SDRAM device, and board-specific signal timing parameters. The clock controller must be programmed to provide the correct clock frequency to the SDRAM controller. The pinmux controller may need to be programmed for some aspects of SDRAM signal timing, such as drive strength.

The BCT’s SDRAM configuration is mostly a raw dump of the registers, or fields within registers, that need to be programmed.

The BCT may choose to omit valid SDRAM configuration data if the bootloader is to be loaded into IRAM rather than SDRAM. In such a case, if the bootloader needs access to SDRAM, it must program the SDRAM controller itself.

The BCT defines the location and size of the bootloader in boot memory, along with the intended load and execution address (typically in SDRAM), and a cryptographic validation hash.

The BCT contains four copies of bootloader information. This allows automatic fallback to the second or later copy of the bootloader, if present, if the first copy cannot be read, or the hash validation fails.

The BCT also contains a bad block table. This indicates which areas of the boot memory device are known to be bad. Any blocks listed in this table are automatically skipped when reading the bootloader.

Most of the BCT is interpreted solely by the boot ROM. However, the BCT also includes a "customer data area". This area is ignored by the boot ROM, and its purpose and layout is not defined by hardware. The customer, OEM, or device software author is free to use it for whatever purpose they desire.

The ODMDATA field is very similar to the customer data area; it is also not used or interpreted by the boot ROM, nor is its purpose or layout defined by hardware.

However, NVIDIA-supplied software expects a certain layout and usage for this field. In particular, this field is used to indicate which UART to use for the debug console, and as a simple representation of system memory size on older SoCs, and so on.

The ODMDATA layout can vary per board. Some fields, such as those mentioned above, have fixed position and meaning since they are often interpreted by generic software. Other fields are board-specific.

For a complete example for the Harmony development board at one point in time, see http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=arch/arm/mach-tegra/odm_kit/query/harmony/tegra_devkit_custopt.h;h=1ec7010911454f19a5018952fd245785a62c59ad;hb=0e52d7fe25b11a656c376a37890be219470661fb.

For details of the fields assumed by upstream software such as U-Boot, see the U-Boot source code.

In particular, see the following files: