This topic provides guidance on customizing static platform-specific settings in the MB1 boot configuration tables (BCT).

In the boot sequence, MB1 uses the MB1 BCT to configure platform-specific static settings. MB1 executes before all other CPUs are enabled. The MB1 stage is owned by NVIDIA and signed by NVIDIA and the OEM.

For more information, see Boot Flow (Tegra code-name Parker).

MB1 BCT specifies platform-specific data. When Tegraflash is invoked to flash a platform, it calls the tegrabct_v2 tool to create the MB1 BCT. It uses the following data:

The BCT required by this stage is signed by the OEM. The MB1 stage offers to perform platform specific initialization. It also sets up the secure control register (SCR).

Platform-specific configuration files specify:

The pinmux configuration file provides pinmux and GPIO configuration information. The typical format for this data is register address and data, as a pair. MB1 only allows writes to the pinmux and GPIO address range, from this table.

The pinmux configuration file is located at:

Where:

The prod setting is the configuration of system characterization and interface and controller settings. This is needed for the interface to work in given platform reliably. The prod setting is set at the controller level and separately at the pinmux level. The examples below describe pinmux configuration only.

The format of this configuration is a tuple of register address, mask, and data value. MB1 reads data from address, modifies it based on mask and value, and then writes it back to address.

The prod configuration file is located at:

Where

Tegra pins and pads are designed to support multiple voltage levels at a given interface. They can operate at 1.2 volts (V), 1.8 V or 3.3 V. Based on the interface and power tree of a given platform, SW needs to write the correct voltage of these pads to enable interface. If pad voltage is higher than IO power rail then pin will not work on that level. If pad voltage is lower than IO power rail then it can damage the SoC pads. Hence it is require configuring the correct pad voltage based on power tree.

Where:

During system boot, MB1 enables system power rails such as CPU, SRAM, and CORE as well as some system PMIC configurations. The typical configurations are:

Enabling and setting of voltages of rails may require:

Rail-specific configurations, such as I2C commands, MMIO access, and delays, are platform-specific. The MB1 BCT configuration file must provide configuration information.

The MB1-CFG format supports:

The typical rail/configurations are divided into following PMIC command domains:

If there is not any configuration for given rail then there is no need to provide the command sequence of that rails. MB1 device side code ignores the configuration of that rail.

Each rail is defined unique ID to make the parsing and BCT binary to easier. The unique IDs are described in the following table.

The PMIC configuration file is located at:

Common parameters:

Rail-specific parameters:

Where common <parameters> is one of the following:

Rail-specific parameters take the following format:

Rail specific parameters are prefixed by the following:

Where <value>, for block-count, is the number of command blocks for a given rail.

The block identification parameter. All blocks are indexed, starting from 0.

The type parameter specifies the command type, either MMIO (0) or I2C (1).

The delay parameter specifies the delay in microseconds after each command in a given block.

The count parameter is the number of commands in a block.

The following are I2C type specific parameters.

Commands can be either MMIO or I2C. The information is in the format <address>.<mask> = <data>, to support the read-modify-write sequence. All commands are indexed, to facilitate multiple commands in a given block. Commands are sent to device is in sequence, starting from index 0, in the following format:

The following are the PWM specific commands.

For example:

The code excerpts in this section show the common and rail specific parameters in a generic format.

The common parameters shown are:

The rail-specific parameters shown are:

The generic format is as follows:

For example, in usage:

PWM specific example:

The following table lists typical L1 and L2 reset levels.

The I2C commands are provided to the boot ROM via AO scratch registers. MB1 device-side code configures these AO scratch registers based on the platform specific information for boot ROM reset paths in the MB1 BCT.

In configuration format, AO blocks come first, then all reset conditions are initialized with the ID of the AO blocks.

Boot ROM commands are prefixed by bootrom. For each reset condition there are three sets of AO blocks, called aocommand.

Absence of aocommand or reset name in configuration data is treated as if there is no command for that reset condition.

Parameters used in AO block configuration data are described in the following table.

The following are I2C type specific parameters.

Commands can be either MMIO or I2C. The information is in the format <address> = <data>, to support the write-only sequence. All commands are indexed, to facilitate multiple commands in a given block. Commands are sent to the device is in sequence, starting from index 0, in the following format

All reset conditions support three AO blocks, initialized as follows:

Where <reset_name> is one of the following: watchdog5, watchdog4, sc7, sc8, soft-reset, sensor-aotag, vfsensor, or hsm.

Tegra code-name Parker has separate registers for configuring bridge client security, bridge firewalls, known as security configuration registers (SCRs). SCRs are either configured by NVIDIA for Tegra code-name Parker platforms or re-configured for custom platforms. Custom configuration is via MB1 BCT at the MB1 stage.

The list of SCRs for re-configuration for custom platforms is the same in MB1 device-side code and SCR platform data. SCR register addresses hard coded in MB1 can only contain data from the platform. The data cannot be masked, and can only be written to the registers as is.

The SCR configuration file is located at:

Where scr is the domain name prefix for the setting <reg_index> is the matching MB1 and CFG file sequence, beginning at 0; and exclusion-info is one of the following values:

MB1 code lists SCR register absolute addresses in an indexed list.

This section documents several settings that do not fit into any of the other categories.

The miscellaneous configuration file is located at:

The following table describes the fields contained in misc.cfg.

There are debug functionalities which can be enabled disabled via BCT flag.

The AO-TAG register is programmed in the MB1, which controls the maximum temperature at which Tegra Parker is allowed to operate. If the temperature exceeds that limit, auto-shutdown is triggered.

The clock control fields in the following table hold the clock divider values for the various modules that MB1 programs.

These settings contain the initial settings passed to CPU-Init FW. Contact NVIDIA before changing any of these settings.

This contains the AST settings for various firmware loaded by MB1/MB2. These are the virtual addresses of the firmware. MB1/MB2 programs corresponding physical addresses based on the location where it loaded the firmware in memory (DRAM). Normally there is no need to change these settings.

These settings specify the address and size for BL carveout.

These settings specify the operating frequency of the I2C bus in MB1/MB2 (default is 100 KHz).

These are the device settings used by MB1/MB2.

These settings specify watchdog timer controller register values. These values will be configured by MB1.

For information on configuring these components, refer to Configuring Pinmux, GPIO and PAD.

For information on flashing, refer to Flashing the Boot Loader and Kernel.