NVIDIA Tegra
NVIDIA Jetson Linux Developer Guide
32.4.3 Release

 

Jetson Xavier NX and Jetson AGX Xavier Series MB1 Platform Configuration

 
About MB1 BCT
Pinmux and GPIO Configuration
Common Prod Configuration
Controller Prod Configuration
Pad Voltage Configuration
PMIC Configuration
Security Configuration
GPIO Interrupt Mapping Configuration
Storage Device Configuration
UPHY Lane Configuration
OEM-FW Ratchet Configuration
BootROM Reset PMIC Configuration
Miscellaneous Configurations
Applies to: NVIDIA Jetson Xavier NX and Jetson AGX Xavier series devices only.
In this topic the NVIDIA® Jetson Xavier™ NX and Jetson AGX Xavier™ series devices are collectively described as “Jetson Xavier devices.” The term “Jetson Xavier device” should be understood to refer to these two types of devices only.
In the boot sequence for Jetson Xavier devices, both MB1 and MB2 use the MB1 BCT to configure platform-specific static settings. MB1 executes before any other CPUs are enabled; MB2 executes immediately after MB1. Both are owned by NVIDIA and signed by NVIDIA and the OEM.
For more information, see Jetson Xavier NX and Jetson AGX Xavier Boot Flow.

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
These configuration files are at:
Linux_for_Tegra/bootloader/t186ref/BCT/

Pinmux and GPIO Configuration

The Jetson Xavier devices’ 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 at:
Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-pinmux-gpio-P2972<board>-<revision>.cfg
Where:
<board> is the device’s board name: p3668 for Jetson Xavier NX, or p2888 for Jetson AGX Xavier series.
<revision> is the board revision number, e.g. a01.
Usage
pinmux.<address> = <value>;
Where:
pinmux is the domain name for GPIO and pinmux configuration data.
<address> is the absolute PADCTL_A<N>. GPIO_CTL<N>, or AON_GPIO 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

Common Prod Configuration

The Jetson Xavier devices’ prod properties configure system characterization and interface and controller settings. This group of properties must be set correctly for the interface to work reliably on a given platform. The prod properties are set at the controller level, and separately at the pinmux level.
These properties are configured as a tuple of register address, mask, and data value. MB1 reads data from the address, modifies it based on the mask and value, and writes it back to the address.
The prod configuration file is at:
Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-prod-<board>-<revision>.cfg
Where:
<board> is the device’s board name: p3668 for Jetson Xavier NX, or p2888 for Jetson AGX Xavier series.
<revision> is the board revision number, e.g., a01.
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
#I2C
prod.0x02434064.0x01f1f000 = 0x0001f000; # PADCTL_CONN_CFG2TMC_GEN1_I2C_SCL_0 drive settings
prod.0x0243406c.0x01f1f000 = 0x0001f000; # PADCTL_CONN_CFG2TMC_GEN1_I2C_SDA_0 drive settings

Controller Prod Configuration

The controller prod configurations are the system characterized values of interface and controller settings, which are required for the given interface to work reliably for a platform. The prod configuration properties are set separately at controller and pinmux/pad levels. This file contains the controller level prod settings.
The configuration file is at:
hardware/nvidia/platform/t19x/<platform>/bct/
Usage
deviceprod.<controller-name>.<controller-id>.<mode>.<address>.<mask> = <value>;
Where:
<controller-name> is the module’s name: sdmmc, qspi, se, or i2c.
<controller-id> is the module's origin-0 instance number, e.g. 3 for SDMMC4.
<mode> is the controller mode to which the prod setting applies, e.g. default, hs400, etc.
<address> is the absolute register address within the controller and instance.
<mask> is the mask value (four bytes unsigned).
<value> is the data value (four bytes unsigned).
For each entry in the prod configuration file, MB1 reads data from the given address, modifies it based on mask and value, and writes it back to the address.
Device-side implementation
val = read(address);
val = (val & ~mask) | (value & mask);
write(val, address);
Example
#Qspi0
deviceprod.qspi.0.default.0x03270004.0x7C00 = 0x0 #TX Trimmer
deviceprod.qspi.0.default.0x03270004.0xFF = 0x10 #RX Trimmer
#Qspi1
deviceprod.qspi.1.default.0x03300004.0x7C00 = 0x0 #TX Trimmer
deviceprod.qspi.1.default.0x03300004.0xFF = 0x10 #RX Trimmer
#SDMMC
deviceprod.sdmmc.3.default.0x034601e4.0x00003FFF = 0x0 # auto cal pd and pu offsets
deviceprod.sdmmc.3.hs400.0x03460100.0x1FFF0000 = 0x14080000 # tap and trim values
deviceprod.sdmmc.3.hs400.0x0346010c.0x00003F00 = 0x00000028 # DQS trim val
deviceprod.sdmmc.3.ddr52.0x03460100.0x1FFF0000 = 0x14080000 # tap and trim values

Pad Voltage Configuration

Jetson Xavier devices’ 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, the software must write to the correct voltage of these pads to enable interface. If pad voltage is higher than the I/O power rail, then the pin does not work on that level. If pad voltage is lower than the I/O power rail, then it can damage the SoC pads. Consequently, configuring the correct pad voltage is required based on the power tree.
The pad configuration file is located at:
Linux_for_Tegra/bootloader/t186ref/BCT/t194-mb1-bct-pad-padvoltage-<board>-<revision>.cfg
Usage
pad-voltage.<address> = <value>;
Where:
<address> is the absolute register address.
<value> is the 32-bit data value.
For each entry in the PAD configuration, MB1 writes the specified <value> to the specified <address>.
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 rail voltages may require certain platform-specific configurations:
I2C command to devices
PWM commands to devices
MMIO access to Jetson registers, either read-modify-write or write-only
Delay after the commands
Entries in PMIC configuration files may be either common or rail-specific. 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, Pulse Width Modulation (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.
GPU: Commands related to GPU.
SRAM: Commands related to SRAM.
CORE: Commands related to CORE.
MEM: Commands related to Memory.
THERMAL: Commands for thermal configurations.
SHUTDOWN: Commands for shutdown related configurations.
If a configuration is NOT identified for given rail, the command sequence of that rail is not required because MB1 device side code ignores the configuration of that rail.
Each rail is defined with a unique ID to make the parsing and BCT binary easier. The unique IDs are as follows:
Rail Name
ID
GENERIC
1
CPU
2
CORE
3
SRAM
4
GPU
5
MEM
6
THERMAL
7
SHUTDOWN
8
The PMIC configuration file is:
Linux_for_Tegra/bootloader/t186ref/BCT/<device>-tegra194-mb1-bct-pmic-<partnumber>-<revision>.cfg
Where:
<device> is the type of device, Jetson-NX or Jetson-AGX.
<partnumber> is the full part number of the device:
p3668-0000 for the Jetson Xavier NX development module, distributed with the Jetson Xavier NX Developer Kit
p3668-0001 for the Jetson Xavier NX production module
p2888-0001 for the original Jetson AGX Xavier module (with 16 GB of memory)
p2888-0004 for the Jetson AGX Xavier module with 32 GB of memory
p2888-0006 for the Jetson AGX Xavier module with 6 GB of memory
<revision> is the module’s revision number, e.g. A01.
Note:
Review each power rail before customizing the carrier board.
Usage for Common Parameters
pmic.<cparameter> = <value>;
Where <cparameter> is one of:
command-retries-count: The number of allowed command attempts.
wait-before-start-bus-clear-us: Determines the wait timeout before issuing the bus clear command. The wait timeout is 1<<n microseconds, where n is the value of this parameter.
rail-count: The number of rails in the configuration file.
Example
pmic.command-retries-count = <value>;
pmic.wait-before-start-bus-clear-us = <value>;
pmic.rail-count = <value>;
Usage for Rail-Specific Parameters
<pmic>.<railname>.<rparameter> = <value>;
Where:
<railname> identifies a rail, and is one of:
generic or system: Generic PMIC configuration.
cpu or cpu0: CPU 0 rail configuration.
cpu1: CPU 1 rail configuration.
core: Core/SoC rail configuration.
memio: Memory rail configuration.
thermal: External thermal sensor configuration.
platform: Other platform I2C configuration.
<rparameter> is one of:
block-count: Number of blocks for the rail.
block[<bindex>].type: Type of commands in a specified block. Valid values are 0 (MMIO), 1 (I2C) and 2 (PWM).
<bindex> is the index of the block, counting from 0.
block[<bindex>].count: The number of commands in a specified block.
block[<bindex>].delay: Delay after each command in the block, in microseconds.
block[<bindex>].commands[<cindex>].<address>.<mask>: Specifies a command in a block.
If block[<bindex>].type is 0, specifies an MMIO command. If 1, specifies an I2C command.
<cindex> is the command index, counted from 0. To write several commands, specify them in parameters with consecutive values of <cindex>.
<address> is the absolute address of the MMIO register or the address of the I2C slave register.
<mask> is a 32-bit MMIO mask or an I2C slave mask. It is applied to values read from the MMIO register or I2C slave register to facilitate read-modify-write operations.
block[<index>].<i2c-parameter>: Specifies an I2C parameter. Valid only if block[<index>].type = 1.
<i2c-parameter> must be one of the following:
i2c-controller-id: I2C controller instance.
slave-add: 7-bit I2C slave address.
reg-data-size: Register size in bits. Valid values are 0 (one byte), 8 (one byte), and 16 (two byte).
reg-add-size: Register address size in bits. Valid values are 0 (one byte), 8 (one byte), and 16 (two byte).
block[<index>].<pwm-command>: Specifies a PWM parameter. Valid only if block[<index>].type = 2.
<pwm-parameter> must be one of the following:
controller-id: PWM controller instance (0-7).
source-frq-hz: PWM clock source frequency, in Hertz.
period-ns: PWM time period, in nanoseconds.
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 (enable PWM after configuring) or 0 (configure but do not enable).
Example
######################## System Configurations ####
# PMIC FPS to turn SD4 (VDD_DDR_1V1) on in time slot 0
# PMIC FPS to set GPIO2 (EN_DDR_VDDQ) high in time slot 1
# Set SLPEN = 1 and CLRSE on POR reset
pmic.system.block[0].type = 1; #I2C
pmic.system.block[0].controller-id = 4;
pmic.system.block[0].slave-add = 0x78; # 7BIt:0x3c
pmic.system.block[0].reg-data-size = 8;
pmic.system.block[0].reg-add-size = 8;
pmic.system.block[0].block-delay = 10;
pmic.system.block[0].commands[0].0x53.0x38 = 0x00; # SD4 FPS UP slot 0
pmic.system.block[0].commands[1].0x55.0x38 = 0x10; # GPIO2 FPS UP slot 2
pmic.system.block[0].commands[2].0x41.0x1C = 0x1C; # SLPEN=1, CLRSE = 11
# PMIC FPS programming to reassign SD1, SD2, LDO4 and LDO5 to
# FPS0 to leave those rails on in SC7
pmic.system.block[1].type = 1; #I2C
pmic.system.block[1].controller-id = 4;
pmic.system.block[1].slave-add = 0x78; # 7BIt:0x3c
pmic.system.block[1].reg-data-size = 8;
pmic.system.block[1].reg-add-size = 8;
pmic.system.block[1].block-delay = 10;
pmic.system.block[1].commands[0].0x50.0xC0 = 0x00; # SD1 FPS to FPS0
pmic.system.block[1].commands[1].0x51.0xC0 = 0x00; # SD2 FPS to FPS0
pmic.system.block[1].commands[2].0x4A.0xC0 = 0x00; # LDO4 FPS to FPS0
pmic.system.block[1].commands[3].0x4B.0xC0 = 0x00; # LDO5 FPS to FPS0
pmic.system.block[1].commands[4].0x4C.0xC0 = 0x00; # LDO6 FPS to FPS0
# VDDIO_DDR to 1.1V, SD4 to 1.1V
pmic.system.block[2].type = 1; #I2C
pmic.system.block[2].controller-id = 4;
pmic.system.block[2].slave-add = 0x78; # 7BIt:0x3c
pmic.system.block[2].reg-data-size = 8;
pmic.system.block[2].reg-add-size = 8;
pmic.system.block[2].block-delay = 10;
pmic.system.block[2].commands[0].0x1A.0xFF = 0x28; # SD4 to 1.1V
######################## #CORE(SOC) RAIL Configurations ###############
# 1. Set 850mV voltage.
pmic.core.block[0].type = 2; # PWM Type
pmic.core.block[0].controller-id = 6; #SOC_GPIO10: PWM7
pmic.core.block[0].source-frq-hz = 204000000; #204MHz
pmic.core.block[0].period-ns = 1255; # 800KHz.
pmic.core.block[0].min-microvolts = 400000;
pmic.core.block[0].max-microvolts = 1200000;
pmic.core.block[0].init-microvolts = 850000;
pmic.core.block[0].enable = 1;
# 2. Make soc_gpio10 pin in non-tristate
pmic.core.block[1].type = 0; # MMIO TYPE
pmic.core.block[1].block-delay = 3000;
pmic.core.block[1].commands[0].0x02434080.0x10 = 0x0; # soc_gpio10: tristate (b4) = 0
######################## #CPU0 RAIL configurations ###############
# 1. Set 800mV voltage.
pmic.cpu0.block[0].type = 2; # PWM Type
pmic.cpu0.block[0].controller-id = 5; #soc_gpio13; PWM6
pmic.cpu0.block[0].source-frq-hz = 204000000; #204MHz
pmic.cpu0.block[0].period-ns = 1255; # 800KHz.
pmic.cpu0.block[0].min-microvolts = 400000;
pmic.cpu0.block[0].max-microvolts = 1200000;
pmic.cpu0.block[0].init-microvolts = 800000;
pmic.cpu0.block[0].enable = 1;
# 2. CPU PWR_REQ cpu_pwr_req_0_pb0 to be 1
pmic.cpu0.block[1].type = 0; # MMIO TYPE
pmic.cpu0.block[1].block-delay = 3;
pmic.cpu0.block[1].commands[0].0x02214e00.0x3 = 0x00000003; # CONFIG B0
pmic.cpu0.block[1].commands[1].0x02214e0c.0x1 = 0x00000000; # CONTROL B0
pmic.cpu0.block[1].commands[2].0x02214e10.0x1 = 0x00000001; # OUTPUT B0
pmic.cpu0.block[1].commands[3].0x02446008.0x400 = 0x00000000; # cpu_pwr_req_0_pb0 to GPIO mode
pmic.cpu0.block[1].commands[4].0x02446008.0x10 = 0x00000000; # cpu_pwr_req_0_pb0 tristate(b4)=0
# 3. Set soc_gpio13 to untristate
pmic.cpu0.block[2].type = 0; # MMIO Type
pmic.cpu0.block[2].commands[4].0x02434098.0x10 = 0x00; # soc_gpio13 to be untristate
######################## Platform Configurations ###############
# Configure pin4/pin5 as output of gpio expander(0x40)
# Configure pin4 low and pin5 high of gpio expander(0x40)
pmic.platform.block[0].type = 1; #I2C
pmic.platform.block[0].controller-id = 1; #gen2
pmic.platform.block[0].slave-add = 0x40; # 7BIt:0x20
pmic.platform.block[0].reg-data-size = 8;
pmic.platform.block[0].reg-add-size = 8;
pmic.platform.block[0].block-delay = 10;
pmic.platform.block[0].commands[0].0x03.0x30 = 0x00; #Configure pin4/pin5 as output
pmic.platform.block[0].commands[1].0x01.0x30 = 0x20; #Configure pin4 low and pin5 high
The rail-specific commands are divided into blocks.
Each rail can have one or more blocks. Each block of given rails is 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 a block contains I2C type of commands, then all commands are sent to the same device. If I2C commands are required for multiple devices, then it must be split into multiple blocks.
If commands on given blocks are I2C type, then the device address, register address size, and register data size parameters are not required for MMIO commands.
A given block can contain more than one command, but all commands must be of the same type.
A delay is provided after each command of a given block. The delay is the same for all commands. If different delay is required, it must be split into multiple blocks.
Rail-specific parameters are prefixed by the following:
pmic.<rail-name>.<rail-id>
Parameter
Description
block-count
Specifies the 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
Specifies the block identification parameter. All blocks are indexed, starting from 0.
pmic.<rail-name>.<rail-id>.block[index]
type
Specifies the command type, either MMIO (0) or 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
Controller ID of I2C.
slave-add
7-bit slave address.
reg-data-size
Register size in bits:
0 or 8:1 byte
16: 2 bytes
reg-add-size
Register address size in bits:
0 or 8:1 byte
16: 2 bytes
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 the device in sequence, starting from index 0, in the following format:
commands[command-index].<addr>.<mask> = <data>;
PWM-Specific Commands
The PWM-specific commands are as follows:
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 nanoseconds> /* 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 following 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, 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;
::::

Security Configuration

The Jetson Xavier devices have separate registers for configuring bridge client security and bridge firewalls, known as Security Configuration Registers (SCRs). SCRs are either configured by NVIDIA for Jetson Xavier platforms or are configured by the customer for custom platforms.
MB1 and MB2 program most of the SCRs and firewalls in T19x. They take the configuration values from the SCR configuration file.
The list of SCRs and firewalls, with their order and addresses, is predetermined.
The values of the SCRs are programmed in order by the configuration file property indexes, not in the order they appear in the configuration file. SCRs and firewalls that are not specified in the configuration file are locked without restricting the access to the registers they protect.
The security configuration files are kept at:
For Jetson Xavier NX: ./hardware/nvidia/platform/t19x/common/bct/scr/bct-scr-cbb-mini.cfg
For Jetson AGX Xavier: ./hardware/nvidia/platform/t19x/common/bct/scr/bct-scr-cbb-mini-p3668.cfg
Usage
scr.<reg_index\>.<exclusion-info> = <32-bit value>;
Where:
<reg_index> is the index of the SCR or firewall in the predefined list.
<exclusion-info> is bit field:
Bit 0 = 1: Do not program in coldboot or SC7-exit.
Bit 1 = 1: Program in coldboot but skip in SC7-exit.
Bit 2 = 1: Program at end of MB2 instead of MB1.
Bits 3-7: Unused.
Example
scr.161.7 = 0x3f008080; # TKE_AON_SCR_WDTSCR0_0
scr.162.4 = 0x18000303; # DMAAPB_1_SCR_BR_INTR_SCR_0
scr.163.4 = 0x18000303; # DMAAPB_1_SCR_BR_SCR_0

GPIO Interrupt Mapping Configuration

To reduce the interrupt hunt time for GPIO pins from single ISR, each GPIO controller on T19x has eight interrupt lines to LIC. This enables you to map a GPIO pin to any of eight interrupts. Interrupt mapping is defined in the GPIO interrupt configuration file.
Usage
gpio-intmap.port.<port-name>.pin.<pin-id> = <interrupt-id>;
Where:
<port-name> is the port name, e.g. A, B, C, … Z, AA, or BB
<pin-id> is the pin ID in the port. Valid values are 0-7.
<interrupt-id> is interrupt route for that pin. Valid values are 0-7.
The GPIO interrupt mapping configuration file is kept at:
./hardware/nvidia/platform/t19x/<platform>/bct/
Example
gpio-intmap.port.B.pin.1 = 0; # GPIO B1 to INT0
gpio-intmap.port.AA.pin.0 = 0; # GPIO AA0 to INT0
gpio-intmap.port.AA.pin.1 = 0; # GPIO AA1 to INT0
gpio-intmap.port.AA.pin.2 = 0; # GPIO AA2 to INT0

Storage Device Configuration

The Storage Device configuration file contains platform-specific settings for storage devices in MB1 and MB2.
The storage device configuration file is kept at:
./hardware/nvidia/platform/t19x/<platform>/bct/
Usage
device.<storage-device>.<instance>.<parameter> = <value>;
Where:
<storage-device> identifies the storage device controller: qspiflash, ufs, sdmmc, or sata.
<instance> is the instance of the storage controller.
<parameter> is a controller-specific parameter as shown below.
QSPI Flash Parameters
If <storage-device>=qspi, <parameter> may be:
clock-source-id: Identifies the clock source. <value> may be:
1: CLK_M
3: PLLP_OUT0
4: PLLM_OUT0
5: PLLC_OUT0
6: PLLC4_MUXED
clock-source-frequency: Frequency of clock source, in Hertz.
interface-frequency: QSPI controller frequency, in Hertz.
enable-ddr-mode: Specifies QSPI data rate. <value> may be:
0: QSPI SDR mode
1: QSPI DDR mode
maximum-bus-width: Maximum QSPI bus width. <value> may be:
0: QSPI x1 lane
2: QSPI x4 lane
fifo-access-mode: Specifies FIFO access mode. <value> may be:
0: PIO mode
1: DMA mode
ready-dummy-cycle: Number of dummy cycles per QSPI flash.
trimmer1-val: TX trimmer value.
trimmer2-val: RV trimmer value.
SDMMC parameters
If <storage-device>=sdmmc, <parameter> may be:
clock-source-id: SDMMC controller clock source. <value> may be:
0: PLLP_OUT0
1: PLLC4_OUT2_LJ
2: PLLC4_OUT0_LJ
3: PLLC4_OUT2
4: PLLC4_OUT1
5: PLLC4_OUT1_LJ
6: CLK_M
7: PLLC4_VCO
clock-source-frequency: Frequency of clock source (in Hz)/
best-mode: Highest supported mode of operation. <value> may be:
0: SDR26
1: DDR52
2: HS200
3: HS400
pd-offset: Pull-down offset.
pu-offset: Pull-up offset.
enable-strobe-hs400: Enable HS400 strobe.
dqs-trim-hs400: HS400 DQS trim value.
UFS parameters
If <storage-device>=ufs, <parameter> may be:
max-hs-mode: Highest HS mode supported by UFS device. <value> may be:
1: HS GEAR1
2: HS GEAR2
3: HS GEAR3
max-pwm-mode: Highest PWM mode supported by UFS device. <value> may be:
1: PWM GEAR1
2: PWM GEAR2
3: PWM GEAR3
4: PWM GEAR4
max-active-lanes: Maximum number of UFS lanes <value> may be 1 or 2.
page-align-size: Alignment of pages used for UFS data structures (in bytes).
enable-hs-mode: Specifies whether to enable UFS HS modes. <value> may be:
0: Disable
1: Enable
enable-fast-auto-mode: Specifies whether to enable fast auto mode. <value> may be:
0: Disable
1: Enable
enable-hs-rate-a: Specifies whether to enable HS rate A. <value> may be:
0: Disable
1: Enable
enable-hs-rate-b: Specifies whether to enable HS rate B. <value> may be:
0: Disable
1: Enable
init-state: Initial state of UFS device at MB1 entry. <value> may be:
0: UFS not initialized by BootROM
1: UFS is initialized by BootROM (MB1 can skip certain steps)
SATA parameters
If <storage-device>=sata, <parameter> may be:
transfer-speed: Specifies transfer speed. <value> may be:
0: GEN1
1: GEN2
Example
# QSPI flash 0
device.qspiflash.0.clock-source-id = 6;
device.qspiflash.0.clock-source-frequency = 13000000;
device.qspiflash.0.interface-frequency = 13000000;
device.qspiflash.0.enable-ddr-mode = 0;
device.qspiflash.0.maximum-bus-width = 2;
device.qspiflash.0.fifo-access-mode = 1;
device.qspiflash.0.read-dummy-cycle = 8;
device.qspiflash.0.trimmer1-val = 0;
device.qspiflash.0.trimmer2-val = 0;
# Sdmmc 3
device.sdmmc.3.clock-source-id = 3; #PLLP_OUT0
device.sdmmc.3.clock-source-frequency = 52000000;
device.sdmmc.3.best-mode = 3; #1=DDR52, 3=HS400
device.sdmmc.3.pd-offset = 0;
device.sdmmc.3.pu-offset = 0;
device.sdmmc.3.enable-strobe-hs400 = 0;
device.sdmmc.3.dqs-trim-hs400 = 0;
# Ufs 0
device.ufs.0.max-hs-mode = 3;
device.ufs.0.max-pwm-mode = 4;
device.ufs.0.max-active-lanes = 2;
device.ufs.0.page-align-size = 4096;
device.ufs.0.enable-hs-mode = 1;
device.ufs.0.enable-fast-auto-mode = 0;
device.ufs.0.enable-hs-rate-b = 1;
device.ufs.0.enable-hs-rate-a = 0;
device.ufs.0.init-state = 0;

UPHY Lane Configuration

UPHY lanes can be configured to be owned by various IP's like XUSB, SATA, MPHY, PCIE, NVLINK, etc. MB1 supports SATA and UFS as boot devices for which UPHY lanes must be configured to access the storage in MB1 and MB2. This file defines UPHY lane configuration for MB1.
After MB2, bootloader loads the BPMP firmware (BPMP-FW), which can keep the configuration programmed by MB1 and do additional lane configuration to support other clients. The lane configuration defined in this file does not apply to BPMP-FW.
The UPHY lane configurations are kept at:
./hardware/nvidia/platform/t19x/<platform>/bct/
Usage
uphy-lane.<instance-type>.<uphy-component>.<id> = <owner-id>
Where:
<instance-type> is the type of UPHY which needs to be configured. It may be hsio or nvhs.
<uphy-component> specifies whether this setting configures lane or PLL. It may be lane or pll.
<id> is the lane or PLL number to be configured.
<owner-id> is the unique ID of the owner to which lane or PLL is assigned.
Example
#UPHY
uphy-lane.hsio.lane.10 = 2;
uphy-lane.hsio.lane.11 = 1;
 

OEM-FW Ratchet Configuration

Ratcheting is a mechanism which prevents loading of an old version of firmware. It is governed by the OEM-FW ratchet version, kept in the boot configuration table (BCT).
The ratchet version of a firmware component is incremented after security bugs are fixed. Before MB1 loads the component, it compares the component’s ratchet version to the version stored in the Boot Component Header (BCH) of the software. If the version in the BCH is lower than the ratchet version number in the BCT, MB1 will not load the firmware.
The ratchet configuration file is kept at:
./hardware/nvidia/platform/t19x/<platform>/bct/ratchet
Usage
ratchet.<fw_index>.<loader_name>.<fw_name> = <ratchet_value>
Where:
<fw_index> is the unique index for an OEM-FW component.
<loader_name> is the name of the boot stage binary which loads firmware corresponding to <fw_index>.
<fw_name> is the name of the firmware.
<ratchet_value> is the ratchet version number for the firmware.
Example
#ratchet
ratchet.1.mb1.mb1bct = 3;
ratchet.2.mb1.spefw = 0;
ratchet.11.mb2.cpubl = 5;

BootROM Reset PMIC Configuration

Some T194 platforms may require BootROM to bring PMIC rails to OTP values in L1 and L2 reset boot paths. This is done by issuing I2C commands, which are encoded in AO scratch registers by MB1 based on the BootROM reset configuration in the MB1 BCT.
The reset cases where the BootROM issues these commands include:
Watchdog 5 expiry
Watchdog 4 expiry
SC7 exit
SC8 exit
SW-Reset
AO-Tag/sensor reset
VF Sensor reset
HSM reset
Each reset case can have three sets of AO blocks of commands. Each AO block can have multiple blocks and each block can have multiple commands.
In the configuration file, AO blocks are specified first, then all the reset conditions are initialized with the ID of the AO blocks.
Usage for Specifying AO Blocks
bootrom.<parameter> = <value>;
Where <parameter> is one of:
aoblock-count: Number of AO blocks mentioned in the file.
aoblock[<aoblock-index>].command-retries-count: Specifies the number of command attempts allowed for the specified AO block.
<aoblock-index> identifies the specified AO block, counting from zero.
aoblock[<aoblock-index>].delay-between-command-us: Specifies the delay between commands, in microseconds. The delay is 1<<n microseconds, where n is the value of this parameter.
aoblock[<aoblock-index>].wait-before-start-bus-clear-us: Specifies the wait timeout before issuing the bus clear command for given AO block, in microseconds. The wait time is 1<<n microseconds, where n is the value of this parameter.
aoblock[<aoblock-index>].block-count: Specifies the number of blocks in the AO block.
aoblock[<aoblock-index>].block[<block-index>].type: Must be −1, indicating an I2C command block,
aoblock[<aoblock-index>].block[<block-index>].count: Specifies the number of commands in the block.
aoblock[<aoblock-index>].block[<block-index>].i2c-controller-id: Identifies the I2C controller instance.
aoblock[<aoblock-index>].block[<block-index>].slave-add: A 7‑bit I2C slave address.
aoblock[<aoblock-index>].block[<block-index>].reg-data-size: Register size in bits. Valid values are 0 (one byte), 8 (one byte), and 16 (two byte).
aoblock[<aoblock-index>].block[<block-index>].reg-add-size: Register address size in bits. Valid values are 0 (one byte), 8 (one byte), and 16 (two byte).
aoblock[<aoblock-index>].block[<block-index>].commands[<command-index>].<reg-addr>: Value to be written to the I2c slave register address <reg-addr> for the command indexed by <command-index>.
Usage for Specifying Reset Type to AO Block Mapping
The reset types are mapped to previously declared AO blocks using lines of the form:
bootrom.<reset-name>.aocommand[<AO-command-index>] = <AO-block-ID>;
Where:
<reset-name> specifies the reset type. It must have one of the values watchdog5, watchdog4, sc7, sc8, soft-reset, sensor-aotag, vfsensor, or hsm.
<AO-command-index> is the index of the AO command. It must be 0, 1 or 2.
<AO-block-ID> is one of the <aoblock-index> values defined in an AO block specification (above).
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 = 1; # 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 = 1; # 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;

Miscellaneous Configurations

Settings that do not fit into another category are specified in the miscellaneous configuration file.
The miscellaneous configuration files are kept at:
./bct/t194/misc/
Usage
Most of the groups of properties in are set by parameters in this form:
<feature> = <value>;
Most of the properties set Boolean flags that enable or disable certain functionality in MB1. The properties are described below by category.
MB1 Feature Properties
disable_spe: Boolean; enables or disables MB1 loading of SPE-FW.
enable_dram_page_blacklisting: Boolean; enables or disables the DRAM ECC page blacklisting feature.
disable_sc7: Boolean; enables or disables SC7-entry/exit support.
disable_fuse_visibility: Boolean; enables or disables fuse visibility. When fuse visibility is disabled, certain fuses are not visible and so cannot be read or written. Some fuses are enabled by default, others disabled.
enable_vpr_resize: Boolean; enables or disables the video protected region (VPR) resize feature.
0: Disable; VPR carveout is allocated based on the McVideoProtectSizeMb and McVideoProtectWriteAccess properties in the SDRAM configuration file.
1: Enable; VPR carveout is allocated by MB1, and TZ write access to VPR carveout is enabled.
l2_mss_encrypt_regeneration: Specifies which MSS encryption keys are to be regenerated for carveouts on L2 RAMDUMP reset.
Bit 1: 1 = regenerate TZDRAM keys
Bit 2: 1 = regenerate VPR keys
Bit 3: 1 = regenerate GSC keys
disable_mb2_glitch_protection: Boolean; enables or disable checks on DCLS faults, TCM parity error, TCM, and cache ECC. Possible values are:
0: Enable checks
1: Disable checks
Note that a value of 0 enables checks, and 1 disables them. That is why the property name begins with “disable.”
enable_dram_error_injection: Boolean; enables or disables DRAM error injection tests.
enable_dram_staged_scrubbing: Boolean; enables or disables staged DRAM scrubbing.
0: Disabled; if DRAM ECC is enabled, scrub the entire DRAM.
1: Enabled; if DRAM ECC is enabled, scrub DRAM in stages. Each BL is responsible for the DRAM portions that it uses.
wait_for_debugger_connection: Boolean; enables or disables waiting for a debugger connection.
0: Disabled; don't wait for a debugger connection at end of MB1.
1: Enabled; spin in a while(1) loop at end of MB1 until debugger connection occurs.
pmc_rst_req_cfg:
MB2 Feature Properties
These properties configure certain features of MB2. Although they apply to MB2 rather than MB1, they are documented here because they are defined in the miscellaneous configuration file along with several groups of MB1 properties.
disable_cpu_l2ecc: Boolean; enables or disables CPU L2-ECC.
enable_sce: Boolean; enables or disables loading of SCE-FW by MB2.
enable_rce: Boolean; enables or disables loading of RCE-FW by MB2.
enable_ape: Boolean; enables or disables loading of APE-FW by MB2.
enable_combined_uart: Boolean; enables or disables the combined UART feature in MB2.
enable_emmc_send_cmd0_cmd1: Boolean; controls whether to send CMD0 and CMD1 to the SDMMC4 controller in MB2. This feature can be used to optimize SDMMC4 initialization in CPU-BL.
0: Don't send SDMMC4 CMD0/CMD1.
1: Send SDMMC4 CMD0/CMD1.
AOTAG Properties
MB1 uses AOTAG (Always-on thermal alarm generator) for thermal protection during boot. These properties control the knobs for AOTAG.
aotag.boot_temp_threshold: Boot temperature threshold in units of 0.001° C. If the SoC temperature measured at the AOTAG sensor is higher than the temperature specified in this field, MB1 waits or shuts down the device.
aotag.enable_shutdown: Boolean; specifies ction to take if boot temperate exceeds aotag.boot_temp_threshold.
0: Wait in boot.
1: Enable shutdown using AOTAG.
aotag.cooldown_temp_threshold: Cooldown temperature threshold in units of 0.001° C. MB1 resumes booting when the device cools down to this temperature.
Clock Properties
clock.bpmp_cpu_nic_divider: Controls programming of the BPMP CPU frequency through CLK_SOURCE_BPMP_CPU_NIC[BPMP_CPU_NIC_CLK_DIVISOR].
0: Do not program.
non-zero: Program to this value minus 1.
clock.bpmp_apb_divider: Controls programming of the BPMP APB frequency through CLK_SOURCE_BPMP_APB[BPMP_APB_CLK_DIVISOR].
0: Do not program.
non-zero: Program to this value minus 1.
clock.axi_cbb_divider: Controls programming of the control backbone (CBB) frequency through CLK_SOURCE_AXI_CBB[AXI_CBB_CLK_DIVISOR].
0: Do not program.
non-zero: Program to this value minus 1.
clock.se_divider: Controls programming of the security engine (SE) frequency through CLK_SOURCE_SE[SE_CLK_DIVISOR].
0: Do not program.
non-zero: Program to this value minus 1.
clock.aon_cpu_nic_divider: Controls programming of the AON/SPE CPU frequency through CLK_SOURCE_AON_CPU_NIC[AON_CPU_NIC_CLK_DIVISOR].
0: Do not program.
non-zero: Program to this value minus 1.
clock.aon_apb_divider: Controls programming of the AON APB frequency through CLK_SOURCE_AON_CPU_NIC[AON_CPU_NIC_CLK_DIVISOR].
0: Do not program.
non-zero: Program to this value minus 1.
clock.aon_can0_divider: Controls programming of the AON CAN1 frequency through CLK_SOURCE_CAN1[CAN1_CLK_DIVISOR].
0: Do not program.
non-zero: Program to this value minus 1.
clock.aon_can1_divider: Controls AON CAN2 frequency through CLK_SOURCE_CAN2[CAN2_CLK_DIVISOR].
0: Do not program.
non-zero: Program to this value minus 1.
clock.osc_drive_strength: Oscillator drive strength.
clock.pllaon_divn: Specifies DIVN value of PLLAON.
0: Use PLLAON_DIVN = 30, PLLAON_DIVM = 1, and PLLAON_DIVP = 2.
non-zero: Program PLLAON_BASE[PLLAON_DIVN] to this value minus 1.
clock.pllaon_divm: Controls DIVM value of PLLAON through PLLAON_BASE[PLLAON_DIVM].
Sets PLLAON_BASE[PLLAON_DIVM] to this value minus 1.
Ignored when clock.pllaon_divn = 0.
clock.pllaon_divp: Controls DIVP value of PLLAON through PLLAON_BASE[PLLAON_DIVP].
Sets PLLAON_BASE[PLLAON_DIVP] to this value minus 1.
Ignored when clock.pllaon_divn = 0.
clock.pllaon_divn_frac: Value to be programmed in PLLAON_MISC_1[PLLAON_DIVN_FRAC].
MB1/MB2 AST Properties
MB1 and MB2 use the address-translation (AST) module to map the DRAM carveout for different firmware components into the 32‑bit virtual address space of the various auxiliary processor clusters.
These properties are read by MB1 and configure the use of AST for both MB1 and MB2.
ast.mb2_va: Virtual address for the MB2 carveout in BPMP-R5 address space.
ast.spe_fw_va: Virtual address for the SPE-FW carveout in AON-R5 address space.
ast.misc_carveout_va: Virtual address for the MISC carveout in SCE-R5 address space.
ast.rcm_blob_carveout_va: Virtual address for the RCM-blob carveout in SCE-R5 address space.
ast.temp_map_a_carveout_va: Virtual address for temporary mapping A used while loading binaries.
ast.temp_map_a_carveout_size: Size for temporary mapping A used while loading binaries.
ast.temp_map_a_carveout_va: Virtual address for temporary mapping B used while loading binaries.
ast.temp_map_a_carveout_size: Size for temporary mapping B used while loading binaries.
Note:
None of the virtual address spaces above may overlap with the MMIO region or with each other.
All size properties must be powers of 2.
All virtual address properties must be aligned to their mapping/carveouts.
MB2 AST Properties
MB1 and MB2 use the address-translation (AST) module to map the DRAM carveout for different firmware components into the 32‑bit virtual address space of the various auxiliary processor clusters. These properties configure MB2’s use of AST.
carveout.ape_ast_va: Virtual address for the APE carveout in BPMP-R5 address space.
carveout.apr_ast_va: Virtual address for the APR carveout in BPMP-R5 address space.
carveout.bpmp_ast_va: Virtual address for the BPMP carveout in BPMP-R5 address space.
carveout.sce_ast_va: Virtual address for the SCE carveout in BPMP-R5 address space.
carveout.rce_ast_va: Virtual address for the RCE carveout in BPMP-R5 address space.
carveout.camera_task_ast_va: Virtual address for the Camera Task carveout in BPMP-R5 address space.
Memory Controller (MC) Carveout Properties
Although the SDRAM configuration file specifies the MC carveout's preferred base, size, and permissions, it does not provide all information required for MB1 to allocate the carveouts. The miscellaneous configuration file specifies the additional information required.
For carveouts that are not protected by MC, all information (including size and preferred base address) is specified by the miscellaneous configuration file.
MC carveout properties are set by parameters in the form:
carveout.<carveout-type>.<parameter> = <value>;
Where:
<carveout-type> identifies the carveout, and must be one of:
gsc[1-31]: GSC carveout for various purposes.
mts: MTS/CPU-uCode carveout.
vpr: VPR carveout.
tzdram: TZDRAM carveout used for SecureOS.
mb2: MB2 carveout used for executing MB2 (a temporary boot carveout).
cpubl: CPU-BL carveout used for executing MB2 (a temporary boot carveout).
misc: Miscellaneous carveout used for various data structures shared across boot stages.
os: OS carveout used for loading the OS kernel.
rcm: RCM carveout used for loading the RCM-blob during RCM mode (a temporary boot carveout).
<parameter> is one of the following parameters:
pref_base: Preferred base address of carveout.
size: Size of carveout in bytes.
alignment: Alignment of base address of carveout in bytes.
ecc_protected: When DRAM region-based ECC is enabled and there are non-ECC protected DRAM regions, specifies whether to allocate the carveout from the ECC protected region.
0: Allocate from non-ECC protected region.
1: Allocate from ECC protected region.
bad_page_tolerant: When DRAM page blacklisting is enabled, specifies whether bad pages are allowed in the carveout. This is possible only for very large carveouts which are handled completely by a component that can avoid bad pages using SMMU/MMU.
0: Bad pages are not allowed for the carveout.
1: Bad pages are allowed for the carveout. (Allocation can be done without filtering bad pages.)
Valid combinations of carveouts and their parameters are shown in the following table.
<carveout-type>
pref_base
size
alignment
ecc_protected
bad_page_tolerant
gsc[1-31], mts, vpr
N/A
N/A
Yes
Yes
Yes
tzdram, mb2, cpubl, misc, os, rcm
Yes
Yes
Yes
Yes
Yes
Coresight Properties
coresight.cfg_system_ctl: Use value to program CORESIGHT_CFG_SYSTEM_CTL.
coresight.cfg_csite_mc_wr_ctrl: Use value to program CORESIGHT_CFG_CSITE_MC_WR_CTRL.
coresight.cfg_csite_mc_rd_ctrl: Use value to program CORESIGHT_CFG_CSITE_MC_RD_CTRL.
coresight.cfg_etr_mc_wr_ctrl: Use value to program CORESIGHT_CFG_ETR_MC_WR_CTRL.
coresight.cfg_etr_mc_rd_ctrl: Use value to program CORESIGHT_CFG_ETR_MC_RD_CTRL.
coresight.cfg_csite_cbb_wr_ctrl: Use value to program CORESIGHT_CFG_CSITE_CBB_WR_CTRL.
coresight.cfg_csite_cbb_rd_ctrl: Use value to program CORESIGHT_CFG_CSITE_CBB_RD_CTRL.
Firmware Load and Entry Properties
mb2_load_offset: Offset in MB2 carveout where MB2 binary is loaded.
mb2_entry_offset: Offset of MB2 entry point in MB2 carveout.
tzram_el3_load_offset: Offset in TZRAM carveout where EL3 binary is loaded.
tzram_el3_entry_offset: Offset of EL3 binary entry point in TZRAM carveout.
cpubl_load_offset: Offset in CPUBL carveout where CPUBL binary is loaded.
cpubl_entry_offset: Offset of CPUBL entry point in CPUBL carveout.
ape_fw_load_offset: Offset in APE carveout where APE-FW binary is loaded.
ape_fw_entry_offset: Offset of APE-FW entry point in APE carveout.
bpmp_fw_load_offset: Offset in BPMP carveout where BPMP-FW binary is loaded.
bpmp_fw_entry_offset: Offset of BPMP-FW entry point in BPMP carveout.
sce_fw_load_offset: Offset in SCE carveout where SCE-FW binary is loaded.
sce_fw_entry_offset: Offset of SCE-FW entry point in SCE carveout.
rce_fw_load_offset: Offset in RCE carveout where RCE-FW binary is loaded.
rce_fw_entry_offset: Offset of RCE-FW entry point in RCE carveout.
CPU Properties
cpu.ccplex_platform_features: CPU platform features; must be 0.
cpu.clock_mode.clock_burst_policy: CCPLEX clock burst policy.
cpu.clock_mode.max_avfs_mode: Highest CCPLEX AVFS mode.
nafll_cfg2.fll_init: CCPLEX NAFLL CFG2 [Fll Init].
nafll_cfg2.fll_ldmem: CCPLEX NAFLL CFG2 [Fll Ldmem].
nafll_cfg2.fll_switch_ldmem: CCPLEX NAFLL CFG2 [Fll Switch Ldmem].
nafll_cfg3: CCPLEX NAFLL CFG3.
nafll_ctrl1: CCPLEX NAFLL CTRL1.
nafll_ctrl2: CCPLEX NAFLL CTRL2.
cpu.lut_sw_freq_req.sw_override_ndiv: SW override for CCPLEX LUT frequency request.
cpu.lut_sw_freq_req.ndiv: NDIV for CCPLEX LUT frequency request.
cpu.lut_sw_freq_req.vfgain: VFGAIN for CCPLEX LUT frequency request.
cpu.lut_sw_freq_req.sw_override_vfgain: VFGAIN override for CCPLEX LUT frequency request.
cpu.nafll_coeff.mdiv: MDIV for NAFLL coefficient.
cpu.nafll_coeff.pdiv: PDIV for NAFLL coefficient.
cpu.nafll_coeff.fll_frug_main: FLL frug main for NAFLL coefficient.
cpu.nafll_coeff.fll_frug_fast: FLL frug fast for NAFLL coefficient.
cpu.adc_vmon.enable: Enable CCPLEX ADC voltage monitor.
cpu.min_adc_fuse_rev: Minimum ADC fuse revision.
cpu.pllx_base.divm: PLLX DIVM.
cpu.pllx_base.divn: PLLX DIVN.
cpu.pllx_base.divp: PLLX DIVP.
cpu.pllx_base.enable: Enable PLLX.
cpu.pllx_base.bypass: PLLX Bypass Enable.
Other Properties
spe_uart_instance: UART controller used for combined UART by SPE.
aocluster.evp_reset_addr: AON/SPE reset vector (in SPE BTCM).
carveout_alloc_direction: Carveout allocation direction.
0: From end of DRAM
1: From end of 2GB DRAM (32b address space)
2: From start of DRAM
se_oem_group: Value to program to SE0_OEM_GROUP_0 and SE_RNG1_RNG1_OEM_GROUP_0 (NVHS / NVLS / Lock bits are forced set).
i2c.<N>: Frequency of I2C controller instance in kilohertz, where <N> is the I2C controller instance, a number in the range [0, 8].
pmc_rst_req_cfg: configures WDT_RESET_OUT signal generation on watchdog expiry:
Bit 0: 1 = Toggle WDT_RESET_OUT on expiry of WDT.
Bit 1: 1 = Toggle WDT_RESET_OUT on expiry of AOWDT.
Bit 3: 1 = Toggle WDT_RESET_OUT on software-initiated reset.
Example
disable_spe = 0;
enable_vpr_resize = 0;
disable_sc7 = 1;
disable_fuse_visibility = 0;
disable_mb2_glitch_protection = 0;
carveout_alloc_direction = 2;
##### cpu variables #####
cpu.ccplex_platform_features = 0x00000;
cpu.clock_mode.clock_burst_policy = 15;
cpu.clock_mode.max_avfs_mode = 0x2E;
cpu.lut_sw_freq_req.sw_override_ndiv = 3;
cpu.lut_sw_freq_req.ndiv = 102;
cpu.lut_sw_freq_req.vfgain = 2;
cpu.lut_sw_freq_req.sw_override_vfgain = 3;
cpu.nafll_coeff.mdiv = 3;
cpu.nafll_coeff.pdiv = 0x1;
cpu.nafll_coeff.fll_frug_main = 0x9;
cpu.nafll_coeff.fll_frug_fast = 0xb;
cpu.nafll_cfg2.fll_init = 0xd;
cpu.nafll_cfg2.fll_ldmem = 0xc;
cpu.nafll_cfg2.fll_switch_ldmem = 0xa;
cpu.nafll_cfg3 = 0x38000000;
cpu.nafll_ctrl1 = 0x0000000C;
cpu.nafll_ctrl2 = 0x22250000;
cpu.adc_vmon.enable = 0x0;
cpu.pllx_base.divm = 2;
cpu.pllx_base.divn = 104;
cpu.pllx_base.divp = 2;
cpu.pllx_base.enable = 1;
cpu.pllx_base.bypass = 0;
cpu.min_adc_fuse_rev = 1;
wp.waypoint0.rails_shorted = 1;
wp.waypoint0.vsense0_cg0 = 1;
##### sw_carveout variables #####
carveout.misc.size = 0x800000; # 8MB
carveout.misc.alignment = 0x800000; # 8MB
carveout.os.size = 0x08000000; #128MB
carveout.os.pref_base = 0x80000000;
carveout.os.alignment = 0x200000;
carveout.cpubl.alignment = 0x200000;
firmware.cpubl_load_offset = 0x600000;
carveout.cpubl.size = 0x04000000; # 64MB
carveout.rcm.size = 0x0;
carveout.rcm.alignment = 0;
carveout.mb2.size = 0x01000000; #16MB
carveout.mb2.alignment = 0x01000000; #16MB
carveout.tzdram.size = 0x01000000; #16MB
carveout.tzdram.alignment = 0x00100000; #1MB
##### mc carveout alignment #####
carveout.vpr.alignment = 0x100000;
carveout.gsc[6].alignment = 0x400000;
carveout.gsc[7].alignment = 0x800000;
carveout.gsc[8].alignment = 0x100000;
carveout.gsc[9].alignment = 0x100000;
carveout.gsc[10].alignment = 0x800000;
carveout.gsc[12].alignment = 0x100000;
carveout.gsc[17].alignment = 0x100000;
carveout.gsc[19].alignment = 0x200000;
carveout.gsc[24].alignment = 0x2000000;
carveout.gsc[27].alignment = 0x200000;
carveout.gsc[28].alignment = 0x200000;
carveout.gsc[29].alignment = 0x200000;
##### mb1 ast va #####
ast.mb2_va = 0x52000000;
ast.misc_carveout_va = 0x70000000;
ast.rcm_blob_carveout_va = 0x60000000;
ast.temp_map_a_carveout_va = 0x80000000;
ast.temp_map_a_carveout_size = 0x40000000;
ast.temp_map_b_carveout_va = 0xc0000000;
ast.temp_map_b_carveout_size = 0x20000000;
##### MB2 AST VA #####
carveout.bpmp_ast_va = 0x50000000;
carveout.ape_ast_va = 0x80000000;
carveout.apr_ast_va = 0xC0000000;
carveout.sce_ast_va = 0x70000000;
carveout.rce_ast_va = 0x70000000;
carveout.camera_task_ast_va = 0x78000000;
##### clock variables #####
clock.pllaon_divp = 0x3;
clock.pllaon_divn = 0x1F;
clock.pllaon_divm = 0x1;
clock.pllaon_divn_frac = 0x03E84000;
# For bpmp_cpu_nic, bpmp_apb, axi_cbb and se,
# specify the divider with PLLP_OUT0 (408MHz) as source.
# For aon_cpu_nic, aon_can0 and aon_can1,
# specify the divider with PLLAON_OUT as source.
# In both cases, BCT specified value = (1 + expected divider value).
clock.bpmp_cpu_nic_divider = 1;
clock.bpmp_apb_divider = 1;
clock.axi_cbb_divider = 1;
clock.se_divider = 1;
##### aotag variables #####
aotag.boot_temp_threshold = 97000;
aotag.cooldown_temp_threshold = 87000;
aotag.cooldown_temp_timeout = 30000;
aotag.enable_shutdown = 1;
#Specify i2c bus speed in KHz
i2c.4 = 918;
#### aocluster data ####
aocluster.evp_reset_addr = 0xc480000;
#### mb2 feature flags ####
enable_sce = 1;
enable_rce = 1;
enable_ape = 1;
enable_combined_uart = 1;
spe_uart_instance = 2;