NVIDIA Tegra
NVIDIA DRIVE OS 5.1 Linux SDK

Developer Guide
5.1.15 Release


 
Configuring MB1 Boot Configuration Table
 
Understanding the MB1 Boot Configuration Table
Configuring the Pinmux and GPIO
Usage
Configuring the Prod Setting
Usage
Configuring Pad Voltage Setting
Usage
Configuring the PMIC Setting
Usage
Generic Format
Configuring the Secure PMC Scratch Register for BootROM
AO Block Parameters
Configuring the Security Configuration Registers
Usage
Miscellaneous Configurations
Use these procedures to customize the Microboot 1 (MB1) Boot Configuration Table (BCT) with static platform-specific settings. The BCT settings that can be customized include:
SDRAM timing
Pinmux configuration
Security
Firmware configuration
During a system boot sequence, MB1 bootloader uses the MB1 BCT to configure platform-specific static settings. MB1 executes before other CPUs are enabled. The MB1 stage is owned by NVIDIA and signed by NVIDIA and the OEM.
For more information, see Boot Flow.
Understanding the MB1 Boot Configuration Table
MB1 BCT specifies platform-specific data. When the bootburn script is called to flash a platform, it calls the tegrabct_v2 tool to create the MB1 BCT using:
Platform configuration files
tegrabl_mb1_bct.h header file
The BCT that is required by this stage is signed by the OEM. The MB1 stage performs platform specific initialization and sets up the secure control register (SCR).
For more information, see Flashing with Bootburn.
The platform-specific configuration files specify:
Configuring the Pinmux and GPIO
Configuring the Prod Setting
Configuring the Pad Voltage Setting
Configuring the PMIC Setting
Configuring the Secure Register for BootROM
The configuration files are available at:
<top>/drive-t186ref-foundation/platform-config/t19x/automotive/bct/<board>/pinmux/
Configuring the Pinmux and GPIO
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 allows writes to the pinmux and GPIO address range from the pinmux configuration table.
The pinmux configuration file is available at:
<top>/drive-t186ref-foundation/platform-config/t19x/automotive/bct/<board>194/pinmux/tegra194-mb1-bct-pinmux-gpio-<board>-<sku_id>-<rev>-t<a|b|c>.cfg
For example:
tegra194-mb1-bct-pinmux-gpio-e3550-0001-b01-ta.cfg
For information on converting the pinmux, GPIO, and pad DTS files to CFG format, see the Pinmux Generation Tool chapter in the NVIDIA DRIVE OS 5.1 Linux PDK Development Guide.
For definitions of the <board>-<sku_id>-<rev>-t<a|b|c>, see the Release Notes.
Usage
The command-line usage syntax is as follows:
pinmux.<address> = <value>;
Where:
pinmux is the domain name for GPIO and pinmux configuration data.
<address> is the absolute register address.
<value> is the 32-bit data value.
Device-side Implementation
The device side implementation is as follows:
write(value, address);
For example:
#### Pinmux for used pins ####
pinmux.0x02434060 = <value1>; # gen1_i2c_scl_pc5.PADCTL_CONN_GEN1_I2C_SCL_0
pinmux.0x02434064 = <value2>; # gen1_i2c_scl_pc5.PADCTL_CONN_CFG2TMC_GEN1_I2C_SCL_0
pinmux.0x02434068 = <value1>; # gen1_i2c_sda_pc6.PADCTL_CONN_GEN1_I2C_SDA_0
pinmux.0x0243406C = <value2>; # gen1_i2c_sda_pc6.PADCTL_CONN_CFG2TMC_GEN1_I2C_DA_0
::::
#### Pinmux for unused pins for low-power configuration ####
pinmux.0x02434040 = <value1>; # gpio_wan4_ph0.PADCTL_CONN_GPIO_WAN4_0
pinmux.0x02434044 = <value2>; # gpio_wan4_ph0.PADCTL_CONN_CFG2TMC_GPIO_WAN4_0
pinmux.0x02434048 = <value1>; # gpio_wan3_ph1.PADCTL_CONN_GPIO_WAN3_0
pinmux.0x0243404C = <value2>; # gpio_wan3_ph1.PADCTL_CONN_CFG2TMC_GPIO_WAN3_0
Configuring the Prod Setting
The prod setting provides the configuration of the settings for:
system characterization
Interface
Controller
These configuration settings are required to ensure the interface works in the platform. The prod setting is set at the controller level, and separately at the pinmux level. The examples provided describe the pinmux configuration.
The format of the configuration is a tuple of register address, mask, and data value. MB1 reads data from address, modifies it based on mask and value, and writes it back to address.
The prod configuration file is available at:
<top>/drive-t186ref-foundation/platform-config/t19x/automotive/bct/<board>/prod/tegra194-mb1-bct-prod-<board>-<sku_id>-<rev>-t<a|b|c>.cfg
For example:
tegra194-mb1-bct-prod-e3550-0001-b01-ta.cfg
For definitions of the <board>-<sku_id>-<rev>-t<a|b|c>, see the Release Notes.
Usage
The command line usage syntax is as follows:
prod.<address>.<mask> = <value>;
Where:
prod is the domain name prefix for the setting
<address> is the pad control register address
<mask> is the mask value with 4 bytes, unsigned
<value> is the data value with 4 bytes, unsigned
Device-side Implementation
The device side implementation is as follows:
val = read(address)
val = (val & ~mask) | (value & mask);
write(val, address);
For example:
prod.0x02436010.0x00006000 = 0x00002000; # SDMMC4_DAT7, DRV_TYPE: DRIVE_2X
prod.0x02436014.0x00006000 = 0x00002000; # SDMMC4_DAT6, DRV_TYPE: DRIVE_2X
prod.0x02436018.0x00006000 = 0x00002000; # SDMMC4_DAT5, DRV_TYPE: DRIVE_2X
prod.0x0243601c.0x00006000 = 0x00002000; # SDMMC4_DAT4, DRV_TYPE: DRIVE_2X
prod.0x02436020.0x00006000 = 0x00002000; # SDMMC4_DAT3, DRV_TYPE: DRIVE_2X
Configuring Pad Voltage Setting
Pins and pads 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, the software must write the correct voltage of these pads to enable the interface. If pad voltage is higher than the Input/Output power rail, the pin does NOT function on that level. If pad voltage is lower than Input/Output power rail, the SOC pads can be damaged. Consequently, it is required to configure the correct pad voltage based on the power tree.
The pad configuration file is available at:
<top>/drive-t186ref-foundation/platform-config/t19x/automotive/bct/<board>/padvoltage/tegra194-mb1-bct-pad-<board>-<sku_id>-<rev>-t<a|b|c>.cfg
For example:
tegra194-mb1-padvoltage-e3550-0001-b01-ta.cfg
For definitions of the <board>-<sku_id>-<rev>-t<a|b|c>, see the Release Notes.
Usage
The command line usage syntax is as follows:
pad-voltage.<address> = <value>;
Where:
pad-voltage is the domain name prefix for the setting
<address> is the absolute register address
<value> is the 32-bit data value
Device-side implementation
The device side implementation is as follows:
write(value, address);
For example:
pad-voltage.0x0c36003c = 0x00000070; # PMC_IMPL_E_18V_PWR_0
pad-voltage.0x0c360040 = 0x00000053; # PMC_IMPL_E_33V_PWR_0
Configuring the PMIC Setting
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 rails
Setting rail voltages
FPS configurations
Enabling and setting of voltages of rails may require:
I2C command to devices
MMIO access to Tegra registers, either read-modify-write or write-only
Delay after the commands
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:
I2C commands and MMIO commands on any sequence.
Any I2C controller instance.
Any 7-bit slave address of the device.
MMIO commands on read-modify-write format to support read only and Read-modify-write format.
I2C commands are read-modify-write format to support read only and Read-modify-write format.
Any amount of delay between commands.
Write only commands for I2C/MMIO.
Any size of device registers address and data size for i2c commands.
I2c command on the 400 KHz.
The sequence may be
1 MMIO, 1 I2C
1 I2C, 1 MMIO
2 MMIO, 1 I2C
1 MMIO, 2 I2C
The typical rail/configurations are divided into these PMIC command domains:
Generic: General PMIC configurations
GPU: Command related to CPU rails
GPU: Commands related to GPU
SRAM: Commands related to SRAM
CORE: Commands related to CORE
MEM: Commands related to Memory
If the configuration for given rail is NOT specified, it is not necessary to provide the command sequence of that rail. MB1 device side code ignores the configuration of that rail.
Each rail is defined with a unique ID to enable the parsing and BCT binary. The unique IDs are as follows:
Rail Name
ID
GENERIC
1
CPU
2
CORE
3
SRAM
4
GPU
5
MEM
6
The PMIC configuration file is available at:
<top>/drive-t186ref-foundation/platform-config/t19x/automotive/bct/<board>/pmic/tegra194-mb1-bct-pmic-<board>-<sku_id>-<rev>-t<a|b|c>.cfg
For example:
tegra194-mb1-bct-pmic-e3550-0001-b01-ta.cfg
For definitions of the <board>-<sku_id>-<rev>-t<a|b|c>, see the Release Notes.
Usage
The command line usage syntax for the common parameters are as follows:
pmic.<parameter> = <value>;
The command line usage syntax for the rail-specific parameters are as follows:
pmic.<rail-names>.<rail-id>.<parameters> = <value>;
Where <parameters> is as follows:
Parameter
Description
command-retries-count
Specifies the number of allowed command attempts.
wait-before-start-bus-clear-us
Specifies the wait timeout, in microseconds, before issuing the bus clear command. The wait time is calculated as:
1 << n microseconds
Where n is as provided by this parameter.
rail-count
Specifies the number of rails in this configuration file that must be configured.
For example:
pmic.command-retries-count = <value>;
pmic.wait-before-start-bus-clear-us = <value>;
pmic.rail-count = <value>;
Rail-Specific Parameters
Rail-specific parameters take the following format:
The rail specific commands are divided into blocks.
Each rail can have one or more blocks. Each block of given rails are indexed starting from 0.
Each block contains either MMIO or I2C commands. If both MMIO and I2C commands are required then commands are broken into multiple blocks.
If block contains I2C type of commands then all commands are sent to same device. If it is require having i2c commands for multiple devices then it needs to split into multiple blocks.
If commands on given blocks are I2C type the device address, register address size, register data size are parameters which is not needed for MMIO commands.
Given block can contain more than one commands but all commands are same type.
Delay is provided after each commands of a given blocks. The delay are same for all commands. If different delay are required then it need to split into multiple blocks.
The details for each paramater are as follows:
Parameter
Description
pmic.<rail-name>.<rail-id>
Specifies the rail specific parameters prefixes.
pmic.<rail-name>.<rail-id>.block-count = <value>;
Specifies the block count.
Where <value> for the block count is the number of command blocks for a given rail.
pmic.<rail-name>.<rail-id>.block[index]
Specifies the block identification, where all blocks are indexed, starting from 0.
type
Specifies the command type. Available types include:
MMIO (0)
I2C (1)
delay
Specifies the delay, in microseconds, after each command in a given block.
count
Specifies the number of commands in a block.
I2C type-specific Parameters
The I2C type specific parameters are as follows:
Parameter
Description
I2c-controller-id
Specifies the controller ID of I2C.
slave-add
Provides the 7-bit slave address.
reg-data-size
Specifies the register size in bits:
0 or 8:1 byte
16: 2 byte
reg-add-size
Specifies the register address size in bits:
0 or 8:1 byte
16: 2 byte
Commands can be 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.
The command syntax is as follows:
commands[command-index].<addr>.<mask> = <data>;
Generic Format
The code snippets show the common and rail specific parameters in a generic format.
The common parameters are:
pmic.command-retries-count = <u32>;
pmic.wait-before-start-bus-clear-us = <u32>;
pmic.rail-count = <u32>;
The rail-specific parameters are:
pmic.<rail-name>.block-count
The generic format is as follows:
##### BLOCK 0 ####
pmic.<rail-name>.<rail-id>.block[0].type = <0 for MMIO, 1 for I2C>
pmic.<rail-name>.<rail-id>.block[0].delay = <u32>
pmic.<rail-name>.<rail-id>.block[0].count = <calculated>;
 
#For I2C specific
pmic.<rail-name>.<rail-id>.block[0].I2c-controller-id = <u32>;
pmic.<rail-name>.<rail-id>.block[0].slave-add = <u32>;
pmic.<rail-name>.<rail-id>.block[0].reg-data-size = <u32>;
pmic.<rail-name>.<rail-id>.block[0].reg-add-size = <u32>;
 
#I2C and MMIOs
pmic.<rail-name>.<rail-id>.block[0].commands[0].<addr>.<mask> = <data>;
pmic.<rail-name>.<rail-id>.block[0].commands[1].<addr>.<mask> = <data>;
pmic.<rail-name>.<rail-id>.block[0].commands[2].<addr>.<mask> = <data>;
pmic.<rail-name>.<rail-id>.block[0].commands[3].<addr>.<mask> = <data0>;
::::
 
##### BLOCK 1 ####
pmic.<rail-name>.<rail-id>.block[1].type = <0 for MMIO, 1 for I2C>
pmic.<rail-name>.<rail-id>.block[1].delay = <u32>
pmic.<rail-name>.<rail-id>.block[1].count = <Calculated>
#For I2C
pmic.<rail-name>.<rail-id>.block[1].I2c-controller-id
pmic.<rail-name>.<rail-id>.block[1].slave-add
pmic.<rail-name>.<rail-id>.block[1].reg-data-size
pmic.<rail-name>.<rail-id>.block[1].reg-add-size
 
#I2C and MMIOs
pmic.<rail-name>.<rail-id>.block[1].commands[0].<addr>.<mask> = <data>;
pmic.<rail-name>.<rail-id>.block[1].commands[1].<addr>.<mask> = <data>;
pmic.<rail-name>.<rail-id>.block[1].commands[2].<addr>.<mask> = <data>;
pmic.<rail-name>.<rail-id>.block[1].commands[3].<addr>.<mask> = <data0>;
::::
For example, the usage is as follows:
pmic.command-retries-count = 1;
pmic.wait-before-start-bus-clear-us = 0;
pmic.rail-count = 6;
 
###############GENERIC RAIL (ID = 1) DATA ###############
pmic.generic.1.block-count = 1;
 
# 1. Set PMIC MBLDP = 1, CNFGGLBL1 bit 6 = 1
pmic.generic.1.block[0].type = 1; # I2C Type
pmic.generic.1.block[0].i2c-controller-id = 4;
pmic.generic.1.block[0].slave-add = 0x78; # 7BIt:0x3c
pmic.generic.1.block[0].reg-data-size = 8;
pmic.generic.1.block[0].reg-add-size = 8;
pmic.generic.1.block[0].delay = 10;
pmic.generic.1.block[0].count = 1;
pmic.generic.1.block[0].commands[0].0x00.0x40 = 0x40;
 
#####################CORE RAIL (ID = 3) DATA ############
pmic.core.3.block-count = 2;
 
# 1. Set 950mV voltage.
pmic.core.3.block[0].type = 1; # I2C Type
pmic.core.3.block[0].i2c-controller-id = 4;
pmic.core.3.block[0].slave-add = 0x70; # 7BIt:0x38
pmic.core.3.block[0].reg-data-size = 8;
pmic.core.3.block[0].reg-add-size = 8;
pmic.core.3.block[0].delay = 1000;
pmic.core.3.block[0].count = 1;
pmic.core.3.block[0].commands[0].0x07.0xFF = 0x2E;
 
# 2. Set GPIO3 Power down slot to 6.
pmic.core.3.block[1].type = 1; # I2C Type
pmic.core.3.block[1].i2c-controller-id = 4;
pmic.core.3.block[1].slave-add = 0x78; # 7BIt:0x3c
pmic.core.3.block[1].reg-data-size = 8;
pmic.core.3.block[1].reg-add-size = 8;
pmic.core.3.block[1].delay = 10;
Configuring the Secure PMC Scratch Register for BootROM
A cold boot path for L1 and L2, it may be required to program I2C and MMIO commands and bring PMIC rails to OTP values.
Typical L1 and L2 reset levels are as follows:
Reset Cause
Reset Level
Context Preservation Required
Trigger New Reset Event?
Cold Power On
L0
No
No
Fifth WDT expiration
L1
No
Yes, Trigger L0 BR
Sensor/AO tag
L1
No
Yes, trigger shut down from boot ROM
VF Sensor
L1
No
No
SW_MAIN
L1
No
Depends on AO scratch setting
HSM
L1
AO scratch
Yes, Trigger L0/L1 from MB1
Fourth WDT expiration
L2
DRAM, internal RAM, L1 reset logic
No
SC7
Warm
DRAM, AO scratch
No
SC8
Warm
AO scratch, AO context
No
The I2C/MMIO commands are provided to the boot ROM using the 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.
The boot ROM requires the data on AO secure scratch registers. Each reset cause can have three AO blocks of blocks of commands. 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 boot ROM. For each reset condition there are three sets of AO blocks, called aocommand.
bootrom.<reset-name>.aocommand[0] = <ao block ID>
bootrom.<reset-name>.aocommand[1] = <ao block ID>
bootrom.<reset-name>.aocommand[2] = <ao block ID>
Absence of aocommand or reset name in configuration data is treated as if there is no command for that reset condition.
AO Block Parameters
Parameters used in AO block configuration data are as follows:
Parameter
Description
aoblock-count
Specifies the number of AO sets described in the file.
command-retries-count
Specifies the number of allowed command attempts.
delay-between-commands-us
Specifies the wait timeout, in microseconds, before issuing the bus clear command. The wait time is calculated as:
1 << n microseconds
Where n is provided by this parameter.
wait-before-start-bus-clear-us
Specifies the wait time, in microseconds, before issuing the bus clear command.
block-count
Specifies the number of blocks in the AO block.
I2C type-specific parameters
The I2C type specific parameters are as follows:
Parameter
Description
I2c-controller-id
Specifies the controller ID of I2C.
slave-add
Specifies the 7-bit slave address.
reg-data-size
Specifies the register size in bits:
0 or 8:1 byte
16: 2 byte
reg-add-size
Specifies the register address size in bits:
0 or 8:1 byte
16: 2 byte
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
The command syntax is as follows:
commands[command-index].<addr> = <data>;
All reset conditions support 3 AO blocks, initialized as follows:
bootrom.<reset-name>.aocommand[0] = <ao block ID>
bootrom.<reset-name>.aocommand[1] = <ao block ID>
bootrom.<reset-name>.aocommand[2] = <ao block ID>
Where <reset_name> is one of the following: watchdog5, watchdog4, sc7, sc8, soft-reset, sensor-aotag, vfsensor, or hsm.
For example:
bootrom.aoblock-count = 2;
 
# Automatic power cycling: Set MAX77620
# Register ONOFFCNFG2, bit SFT_RST_WK = 1 (default is "0" after cold boot),
# Register ONOFFCNFG1, bit SFT_RST = 1
bootrom.aoblock[0].command-retries-count = 1;
bootrom.aoblock[0].delay-between-commands-us = 1;
bootrom.aoblock[0].wait-before-start-bus-clear-us = 1;
bootrom.aoblock[0].block-count = 1;
 
bootrom.aoblock[0].block[0].type = 0; # I2C Type
bootrom.aoblock[0].block[0].slave-add = 0x3c; # 7BIt:0x3c
bootrom.aoblock[0].block[0].reg-data-size = 8;
bootrom.aoblock[0].block[0].reg-add-size = 8;
bootrom.aoblock[0].block[0].count = 2;
bootrom.aoblock[0].block[0].commands[0].0x42 = 0xda;
bootrom.aoblock[0].block[0].commands[1].0x41 = 0xf8;
 
# Shutdown: Set MAX77620
# Register ONOFFCNFG2, bit SFT_RST_WK = 0
# Register ONOFFCNFG1, bit SFT_RST = 1
bootrom.aoblock[1].command-retries-count = 1;
bootrom.aoblock[1].delay-between-commands-us = 1;
bootrom.aoblock[1].wait-before-start-bus-clear-us = 1;
bootrom.aoblock[1].block-count = 1;
 
bootrom.aoblock[1].block[0].type = 0; # I2C Type
bootrom.aoblock[1].block[0].slave-add = 0x3c; # 7BIt:0x3c
bootrom.aoblock[1].block[0].reg-data-size = 8;
bootrom.aoblock[1].block[0].reg-add-size = 8;
bootrom.aoblock[1].block[0].count = 2;
bootrom.aoblock[1].block[0].commands[0].0x42 = 0x5a;
bootrom.aoblock[1].block[0].commands[1].0x41 = 0xf8;
 
# Shutdown in sensor/ao-tag
#reset in soft reset.
# no commands for other case
bootrom.sensor-aotag.aocommand[0] = 1;
bootrom.soft-reset.aocommand[0] = 0;
Configuring the Security Configuration Registers
Tegra has separate registers for configuring bridge client security, bridge firewalls, known as security configuration registers (SCRs). SCRs are either configured by the platform or re-configured for custom platforms. Custom configuration is are provided using 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 contain data from the platform. The data cannot be masked, and is written to the registers as is.
The SRC configuration file is available at:
<top>/drive-t186ref-foundation/platform-config/platform/t19x/common/bct/scr/tegra194-mb1-bct-src-cbb-mini.cfg
Usage
The command line usage syntax is as follows:
scr.<reg_index>.<exclusion-info> = <32 bit value>; # <reg_name>
Where:
scr is the domain name prefix for the setting.
<reg_index> is the matching MB1 and CFG file sequence, beginning at 0.
<exclusion-info> is one of the values as follows:
Value
Description
0
Include:regular SCRs loaded from BCT in cold boot, from stored context in warm boot.
1
Exclude: Present data in the CFG file but do not load data from the BCT. Allows SCR programming in MB2 or later.
2
SC7 resume: Program from BCT in cold boot, but exclude for warm boot.
MB1 code lists SCR register absolute addresses in an indexed list.
For example:
# SCR register configurations
scr.134.5 = 0x3f008080; # APS_AST_SCR_AST_REG_3_SEC_CONTROL_0
scr.135.5 = 0x3f008080; # APS_AST_SCR_AST_REG_4_SEC_CONTROL_0
Miscellaneous Configurations
The miscellaneous configuration file is available at:
<top>/drive-t186ref-foundation/platform-config/bct/t194/misc/tegra194-mb1-bct-misc-<auto>.cfg
The fields contained in misc<auto>.cfg are as follows:
Field
Description
Configuration Example
enable_can_boot
Controls early CAN initialization. If set, spe-can firmware loading spe-r5 processor boot is done.
enable_can_boot = 1;
enable_blacklisting
Controls DRAM ECC blacklisting:
0: Disable ECC blacklisting
1: Enable ECC blacklisting
enable_blacklisting = 0;
disable_sc7
Controls SC7 state entry:
0: Enable sc7
1: Disable sc7
disable_sc7 = 0;
fuse_visibility
Certain fuses cannot be read or written by default because they are not visible. If this field is set, MB1 enables fuse visibility for such fuses.
fuse_visibility = 1;
enable_vpr_resize
Controls enablement of VPR resize functionality.
enable_vpr_resize=0
Debug
There are debug functionality which can be enabled or disabled using BCT flag.
Debug Control Fields
Description
Configuration Example
uart_instance
Configures the UART instance for console prints.
debug.uart_instance = 1;
enable log
Enables/disables console logging.
debug.enable_log = 1;
enable_secure_settings
Unused.
-
AOTAG
The AO-TAG register is programmed in the MB1, which controls the maximum temperature at which Tegra platform is allowed to operate. If the temperature exceeds that limit, an automatic shutdown is triggered.
AOTag Control Fields
Description
Configuration Example
boot_temp_threshold
Boot temperature threshold in millicentigrade. If temperature is higher than the temperature specified in this field, MB1 waits or shuts down the device.
aotag.boot_temp_threshold = 105000;
cooldown_temp_threshold
Cool down temperature threshold in millicentigrade. MB1 resumes booting when the device has cooled to this threshold temperature.
aotag.cooldown_temp_threshold = 85000;
enable_shutdown
If set to 1, enables shutdown using aotag if temperature is above boot temperature threshold.
aotag.enable_shutdown = 1;
The clock control fields in the following table hold the clock divider values for the various modules that MB1 programs.
Clock Control Fields
Description
Configuration Example
bpmp_cpu_nic_divider
Program the cpu nic divider to control the BPMP CPU frequency.
A value 1 less than the value in the field is directly written to the register.
clock.bpmp_cpu_nic_divider = 1;
bpmp_apb_divider
Program the apb divider to control the APB bus frequency.
A value 1 less than the value in the field is directly written to the register.
clock.bpmp_apb_divider = 1;
axi_cbb_divider
Program the axi_cbb divider to control the AXI-CBB bus frequency.
A value 1 less than the value in the field is directly written to the register.
clock.axi_cbb_divider = 1;
se_divider
Program the se divider to control the SE Controller frequency.
A value 1 less than the value in the field is directly written to the register.
clock.se_divider = 1;
aon_cpu_nic_divider
Program the cpu_nic divider to control the AON(SPE) CPU frequency.
A value 1 less than the value in the field is directly written to the register.
clock.aon_cpu_nic_divider = 1;
aon_apb_divider
Program the apb divider to control the AON(SPE) APB frequency.
A value 1 less than the value in the field is directly written to the register.
clock.aon_apb_divider = 1;
aon_can0_divider
Program the can0 divider to control the CAN0 controller frequency.
A value 1 less than the value in the field is directly written to the register.
clock.aon_can0_divider = 1;
aon_can1_divider
Program the can1 divider to control the CAN1 controller frequency.
A value 1 less than the value in the field is directly written to the register.
clock.aon_can1_divider = 1;
osc_drive_strength
Unused
-
pllaon_divp
Program the P value of PLL-AON.
A value 1 less than the value in the field is directly written to the register.
clock.pllaon_divp = 2;
pllaon_divn
Program the N value of PLL-AON.
A value 1 less than the value in the field is directly written to the register.
clock.pllaon_divn = 25;
pllaon_divm
Program the M value of PLL-AON.
A value 1 less than the value in the field is directly written to the register.
clock.pllaon_divm = 1;
AST setting
The AST settings for various firmware is 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, it is not necessary to change these settings.
Fields
Description
Configuration Example
bpmp_fw_va
Virtual address for BPMP-FW
ast.bpmp_fw_va = 0x50000000;
mb2_va
Virtual address for MB2-FW
ast.mb2_va = 0x52000000;
sce_fw_va
Virtual address for SCE-FW
ast.sce_fw_va = 0x70000000;
apr_va
Virtual address for Audio-protected region used by APE-FW
ast.apr_va = 0xC0000000;
ape_fw_va
Virtual address for APE-FW
ast.ape_fw_va = 0x80000000;
I2C setting
The I2C settings specify the operating frequency of the I2C bus in MB1/MB2. The default is 100 KHz.
Field
Description
Configuration Example
0
Specify the clock for I2C controller instance 0
i2c.0 = 400;
4
Specify the clock for I2C controller instance 4
i2c.4 = 1000;
SW Carveout
The SW carveout settings specify the address and size for BL carveout.
Field
Description
Configuration Example
cpubl_carveout_addr
Start location of the CPU-BL Carveout
sw_carveout.cpubl_carveout_addr = 0x96000000;
cpubl_carveout_size
Size of the CPU-BL Carveout
sw_carveout.cpubl_carveout_size = 0x02000000;
mb2_carveout_size
Size of the MB2 Carveout
sw_carveout.mb2_carveout_size = 0x00400000;
CPU Param
The CPU parameter settings contain the initial settings passed to CPU-Init FW. Contact NVIDIA before changing these settings.
Field
Description
Configuration Example
Bootcpu
Specify Boot CPU. 4 means A57 cpu0 and 0 mean Denver0. For automotive applications use A57-cpu0.
cpu.bootcpu = 4
ccplex_platform_features
Platform feature passed to the CPU-Init FW.
cpu.ccplex_platform_features = 0x581;
lsr_dvcomp_params_b_cluster
Contains setting for initializing ADC and DVC, which need to be functional before CPU rails are brought up
cpu.lsr_dvcomp_params_b_cluster = 0xC0780F05C;
lsr_dvcomp_params_m_cluster
Contains setting for initializing ADC and DVC, which need to be functional before CPU rails are brought up
cpu.lsr_dvcomp_params_m_cluster = 0xC0780F05C;
nafll_m_cluster_data
Initial NAFLL settings for cluster for Denver
cpu.nafll_m_cluster_data = 0x11F04461;
nafll_b_cluster_data
Initial NAFLL settings for cluster for A57
cpu.nafll_b_cluster_data = 0x11F04461;
Dev-param
The DEV parameters are the device settings used by MB1/MB2.
Field
Description
Configuration Example
qspi.clk_src
Specify the clock source. The value corresponds to what is mentioned in the QSPI CLK SRC register.
0: pllp_out0
4: pllc4_muxed
devinfo.qspi.clk_src = 0; #
 
qspi.clk_div
clk_div = N+1;Hence N = 3 & clk_rate = 163.2 MHz = (408 MHz / ((N / 2) + 1))
devinfo.qspi.clk_div = 4;
 
qspi.width
Specify the width of the QSPI BUS during transfer
0 : 1 bit (x1 mode)
1 : 2 bit (x2 mode)
2 : 4 bit (x4 mode)
devinfo.qspi.width = 2
qspi.dma_type
Specify which DMA to use for transfer if mode of transfer is DMA. For QSPI, in MB1/MB2, BPMP-DMA should be used.
0 : GPC-DMA
1 : BPMP-DMA
devinfo.qspi.dma_type = 1
qspi.xfer_mode
Specify mode of transfer 0: PIO
1: DMA
devinfo.qspi.xfer_mode = 1;
qspi.read_dummy_cycles
The dummy cycles allow the device internal circuits additional time for accessing the initial address location. During the dummy cycles the data value on IOs are  “don’t care” and may be high impedance.
devinfo.qspi.read_dummy_cycles = 9
qspi.trimmer_val1
tx_clk_tap_delay for QSPI
devinfo.qspi.trimmer_val1 = 0
qspi.trimmer_val2
rx_clk_tap_delay for QSPI
devinfo.qspi.trimmer_val2 = 0