MB1 Platform Configuration
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.
About MB1 BCT
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:
•Platform configuration files
•tegrabl_mb1_bct.h header file
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:
•Pinmux and GPIOs configuration
•Prod setting
•Pad voltage setting
•PMIC setting
•Secure register configuration
Location of Configuration Files
These configuration files located at:
<
top>/bootloader/<platform|ver>/BCT/
The following sections describe these configuration files.
Pinmux, and GPIO Configuration
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:
<top>/bootloader/<platform|ver>/BCT/tegra<t-arch>-mb1-bct-pinmux-gpio-<board>-<board_revision>.cfg
Usage
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
write(value, address);
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
Prod Configuration
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:
<top>/bootloader/<platform|ver>/BCT/tegra<
t-arch>-mb1-bct-prod-<
board>-<board_revision>.cfg
Usage
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 (4 bytes, unsigned).
•<value> is the data value (4 bytes, unsigned).
Device-side implementation
val = read(address)
val = (val & ~mask) | (value & mask);
write(val, address);
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
Pad Voltage Configuration
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.
The pad configuration file is located at:
<top>/bootloader/<platform|ver>/BCT/tegra<t-arch>-mb1-bct-pad-quill-<board>-<board_revision>.cfg
Usage
pmc.<address> = <value>;
Where:
•pmc is the domain name prefix for the setting.
•<address> is the absolute register address.
•<value> is the 32-bit data value.
Device-side implementation
write(value, address);
Example
pmc.0x0c36003c = 0x0000003e; # PMC_IMPL_E_18V_PWR_0
pmc.0x0c360040 = 0x00000079; # PMC_IMPL_E_33V_PWR_0
PMIC Configuration
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, PWM commands and MMIO commands on any sequence.
•Any I2C/PWM 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.
•PWM commands are for enabling and configuring the PWM.
•Any amount of delay between commands.
•Write only commands for PWM/I2C/MMIO.
•Any size of device registers address and data size for i2c commands.
•I2c command on the 400KHz.
•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 following PMIC command domains:
•Generic: General PMIC configurations.
•CPU: Command related to CPU rails only.
•GPU: Commands related to GPU only.
•SRAM: Commands related to SRAM only.
•CORE: Commands related to CORE only.
•MEM: Commands related to Memory only.
•THERMAL: For thermal configurations.
•SHUTDOWN: For shutdown related configurations.
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.
Rail Name | ID |
GENERIC | 1 |
CPU | 2 |
CORE | 3 |
SRAM | 4 |
GPU | 5 |
MEM | 6 |
THERMAL | 7 |
SHUTDOWN | 8 |
The PMIC configuration file is located at:
<top>/bootloader/<platform|ver>/BCT/tegra<t-arch>-mb1-bct-pmic-vcm31-<board>-<board_revision>.cfg
Usage
Common parameters:
pmic.<parameter> = <value>;
Rail-specific parameters:
pmic.<rail-names>.<rail-id>.<parameters> = <value>;
Where common <parameters> is one of the following:
Parameter | Description |
command-retries-count | The number of allowed command attempts. |
wait-before-start-bus-clear-us | 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. |
rail-count | Number of rails in this configuration file that need to be configured. |
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 is the same for all commands. If different delay are required then it need to split into multiple blocks.
Rail specific parameters are prefixed by the following:
pmic.<rail-name>.<rail-id>.
block-count
pmic.<rail-name>.<rail-id>.block-count = <value>;
Where <value>, for block-count, is the number of command blocks for a given rail.
block
The block identification parameter. All blocks are indexed, starting from 0.
pmic.<rail-name>.<rail-id>.block[index]
type
The type parameter specifies the command type, either MMIO (0) or I2C (1).
delay
The delay parameter specifies the delay in microseconds after each command in a given block.
count
The count parameter is the number of commands in a block.
I2C type-specific parameters
The following are I2C type specific parameters.
Parameter | Description |
I2c-controller-id | Controller ID of I2C. |
slave-add | 7-bit slave address. |
reg-data-size | Register size in bits: 0 or 8:1 byte 16: 2 byte |
reg-add-size | Register address size in bits: 0 or 8:1 byte 16: 2 byte |
Commands
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:
commands[command-index].<addr>.<mask> = <data>;
PWM specific commands
The following are the PWM specific commands.
Command | Value |
type | 2 (for PWM =2) |
controller-id | <0 to 7> /* Based on the platform */ |
source-frq-hz | <PWM clock source freq> /* In Hz */ |
period-ns | <Period in Nano Seconds> /* PWM periods */ |
min-microvolts | <Vout from PWM regulator if duty cycle is 0> |
max-microvolts | <Vout from PWM regulator if duty cycle is 100> |
init-microvolts | <Vout from PWM regulator after initialization. |
enable | <1/0> /* Enable the PWM or just configure */ |
For example:
# 1. Set 950mV voltage.
pmic.core.3.block[0].type = 2; # PWM Type
pmic.core.3.block[0].controller-id = 5; #GP_PWM6
pmic.core.3.block[0].source-frq-hz = 102000000; #102MHz
pmic.core.3.block[0].period-ns = 2600; # 384K is period.
pmic.core.3.block[0].min-microvolts = 600000;
pmic.core.3.block[0].max-microvolts = 1200000;
pmic.core.3.block[0].init-microvolts = 950000;
pmic.core.3.block[0].enable = 1;
Generic Format
The code excerpts in this section show the common and rail specific parameters in a generic format.
The common parameters shown are:
pmic.command-retries-count = <u32>;
pmic.wait-before-start-bus-clear-us = <u32>;
pmic.rail-count = <u32>;
The rail-specific parameters shown 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, in usage:
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;
PWM specific example:
pmic.core.3.block-count = 1;
# 1. Set 950mV voltage.
pmic.core.3.block[0].type = 2; # PWM Type
pmic.core.3.block[0].controller-id = 5; #GP_PWM6
pmic.core.3.block[0].source-frq-hz = 102000000; #102MHz
pmic.core.3.block[0].period-ns = 2600; # 384K is period.
pmic.core.3.block[0].min-microvolts = 600000;
pmic.core.3.block[0].max-microvolts = 1200000;
pmic.core.3.block[0].init-microvolts = 950000;
pmic.core.3.block[0].enable = 1;
::::
Secure PMC Scratch Register Configurations for BootROM
Note: | In the Tegra Parker cold boot path for L1 and L2, it may be required to program I2C and MMIO commands to bring PMIC rails to OTP values. Contact NVIDIA for more information. |
The following table lists typical L1 and L2 reset levels.
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 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.
1. The boot ROM requires the data on AO secure scratch registers.
2. There are 8 reset cases on which bootrom issue the commands. These are:
•Watchdog 5 expiry
•Watchdog 4 expiry
•SC7 exit
•SC8 exit
•SW-Reset
•AO-Tag/sensor reset
•VF Sensor
•HSM
3. Each reset case can have three sets of AO blocks of commands.
4. Each AO block has multiple blocks and each block can have multiple 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 bootrom. 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 described in the following table.
Parameter | Description |
aoblock-count | Number of AO sets described in the file. |
command-retries-count | The number of allowed command attempts. |
delay-between-commands-us | 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 | Wait time in microseconds before issuing the bus clear command. |
block-count | Number of blocks in the AO block. |
type | Command type whether MMIO or I2C. Use value as 0 for MMIO and 1 for I2C. |
count | Number of commands in this block. |
I2C type-specific parameters
The following are I2C type specific parameters.
Parameter | Description |
I2c-controller-id | Controller ID of I2C. |
slave-add | 7-bit slave address. |
reg-data-size | Register size in bits: 0 or 8:1 byte 16: 2 byte |
reg-add-size | Register address size in bits: 0 or 8:1 byte 16: 2 byte |
Commands
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
commands[command-index].<addr> = <data>;
All reset conditions support three 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.
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;
Security Configuration Register Configurations
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:
<top>/bootloader/<platform|ver>/BCT/auto_scr.cfg
Usage
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; and exclusion-info is one of the following values:
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.
Example
# SCR register configurations
scr.134.1 = 0x20000000; # GPIO_M_SCR_00_0
scr.135.1 = 0x20000000; # GPIO_M_SCR_01_0
Miscellaneous Configurations
This section documents several settings that do not fit into any of the other categories.
The miscellaneous configuration file is located at:
<top>/bootloader/<platform|ver>/BCT/tegra186-mb1-bct-misc-vcm31-p2382.cfg
The following table describes the fields contained in misc.cfg.
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 |
Disable_el3_bl | Used for eliminate execution of EL3 Bl after secure os and can start EL2 bootloader | Disable_el3_bl = 1 |
Debug
There are debug functionalities which can be enabled disabled via 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 Parker is allowed to operate. If the temperature exceeds that limit, auto-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; |
cooldown_temp_timeout | Contains max time MB1 should wait for system temperature to go down below “cooldown_temp_threshold”. | Cooldown_temp_timeout = 30000 |
enable_shutdown | If set to 1, enables shutdown using aotag if temperature is above boot temperature threshold. | aotag.enable_shutdown = 1; |
Clock
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; |
CPU Parameters
These settings contain the initial settings passed to CPU-Init FW. Contact NVIDIA before changing any of 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; |
AST 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.
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; |
SW Carveout
These 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; |
I2C Settings
These settings specify the operating frequency of the I2C bus in MB1/MB2 (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; |
Dev Parameters
These 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 |
Watchdog timer controller settings
These settings specify watchdog timer controller register values. These values will be configured by MB1.
Field | Description | Configuration Example |
bpmp_wdtcr | Contains the bpmp processer watchdog timer register value | wdt.bpmp_wdtcr = 0x710640; configures for 100sec |
Sce_wdtcr | Contains the SCE processer watchdog timer register value | wdt.sce_wdtcr = 0x707103; |
aon_wdtcr | Contains aon’s watchdog timer register value | wdt.aon_wdtcr = 0x700000; |
rtc2_ao_wdtcr | Contains rtc2_ao watchdog timer register value | wdt.rtc2_ao_wdtcr = 0x700000; |
top_wdt0_wdtcr | Contains top_wdt0 watchdog timer register value | wdt.top_wdt0_wdtcr = 0x715016; |
top_wdt1_wdtcr | Contains top_wdt1 watchdog timer register value | wdt.top_wdt1_wdtcr = 0x710640; |
top_wdt2_wdtcr | Contains top_wdt2 watchdog timer register value | wdt.top_wdt2_wdtcr = 0x707103; |
Generating MB1 Configuration Files
This topic provides details on how to generate different MB1 configuration files.
Pinmux, GPIO, and Pad
For information on configuring these components, refer to
Configuring Pinmux, GPIO and PAD.
PMIC
The PMIC configuration file is created manually. Here are the steps:
1. Get information about the set of commands to enable and setting voltage of each rail. If OTP values are in desired voltage, do not reprogram voltage register. Also do not enable all rails, only do what is recommended by boot sequence. The voltage for rail need to be set per the boot sequence recommendation.
2. Get information about generic setting needed from the MB1.
3. Once all information is there, split these commands per rail.
4. Make the list of commands sequence, delay between commands and then make blocks. Blocks can contain multiple commands if they are same type (i2C or MMIO), having same delay and communicating to same device. If any think different then it will be in the different blocks.
5. Create configuration file based on above details.
BootROM
The BOOTROM configuration file is created with manually. Here are the steps:
1. Get information about the set of commands to send to device in different reset path. There may be possibility that there is same type for commands for different reset paths. Collect all such information from system team.
2. Make the sets of commands needed for each reset path independently.
3. Pickup commands for one reset path, make the list of commands sequence, delay between commands and then make blocks out of these. Blocks can contain multiple commands if they are same type (i2C or MMIO), having same delay and communicating to same device. If any think different then it will be in the different blocks.
4. Put all blocks in one aoblocks.
5. Similarly make all aoblocks for all reset paths.
6. Initialize the different reset path’s aocommand with these aoblock indexes.
7. Create configuration file based on above details.
Flashing
For information on flashing, refer to
Flashing the Boot Loader and Kernel.