MB1 Platform Configuration

This topic contains information about configuring Micro Boot stage 1 (MB1) on platforms that are supported by NVIDIA® Jetson™ Linux and that support MB1.

In the boot sequence for Jetson devices, both MB1 and MB2 use the MB1 BCT to configure platform-specific static settings. MB1 executes before any CPUs other than its own are enabled; MB2 executes immediately after MB1 on the same CPU. Both are owned by NVIDIA and are signed by NVIDIA and the OEM.

For more information, see the section Jetson AGX Orin Boot Flow or Jetson Xavier NX and Jetson AGX Xavuer Boot Flow.

About MB1 BCT

The MB1 BCT contains platform-specific data. When TegraFlash is invoked to flash a platform, it calls tegrabct_v2 to create the MB1 BCT. It uses the following data:

  • Platform-specific configuration files

  • tegrabl_mb1_bct.h header file

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

The platform-specific configuration files specify:

  • Pinmux and GPIO configurations

  • Prod setting

  • Pad voltage setting

  • PMIC setting

  • Secure register configuration

The files are kept in the directory at:

Linux_for_Tegra/bootloader/t186ref/BCT/

Pinmux/GPIO Configuration

The pinmux/GPIO configuration file contains pinmux and GPIO configuration information. It is stored at:

Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-pinmux-gpio-p2972<board>-<revision>.cfg

Where:

  • <board> is the device’s board name:

    • p3701 for NVIDIA® Jetson AGX Orin™

    • p3668 for NVIDIA® Jetson Xavier™ NX series

    • p2888 for NVIDIA® Jetson AGX Xavier™ series

  • <revision> is the board revision number, e.g. a01.

Configuration File Format

Each setting in the pinmux/GPIO configuration file specifies a register address and the data to be configured for it. MB1 allows writes in the pinmux/GPIO address range only to the addresses specified in this file.

Each line in this file has the form:

pinmux.<address> = <value>;

Where:

  • pinmux is a domain name that identifies this line as 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 to be configured there.

Device-Side Implementation

write(value, address);

Example

This example shows some entries in a pinmux/GPIO configuration file:

@@@@ 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

A Jetson device’s prod properties configure system characterization and interface and controller settings. These 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.

Each of these properties is configured as a tuple of register address, mask, and data value. MB1 reads data from the address, modifies it based on the property’s 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:

    • p3701 for Jetson AGX Orin

    • p3668 for Jetson Xavier NX series

    • p2888 for Jetson AGX Xavier series

  • <revision> is the board revision number, e.g., a01.

The form of a line in the file is:

prod.<address>.<mask> = <value>;

Where:

  • prod is the domain name that identifies this line as a prod data setting.

  • <address> is a pad control register address.

  • <mask> is a mask value (4 bytes, unsigned).

  • <value> is a data value (4 bytes, unsigned).

Device-Side Implementation

val = read(address)
val = (val & ~mask) | (value & mask);
write(val, address);

Example

This is an example of typical settings from a prod configuration file:

#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/

Each setting in the file has the form:

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

This is an example of a prod configuration file:

#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

Supported Jetson devices’ pins and pads are designed to operate at multiple voltage levels at a given interface. They can operate at 1.2 volts (V), 1.8 V, or 3.3 V, depending on settings in the power tree.

You must configure the power tree to make the software use the correct voltage when it writes to these pads, or the interface may not operate correctly. If a pad’s voltage is higher than that of the corresponding I/O power rail, the pin does not work on that level. If a pad’s voltage is lower, it may damage the SoC pads.

You configure the power tree through the pad configuration file, which is located at:

Linux_for_Tegra/bootloader/t186ref/BCT/t194-mb1-bct-pad-padvoltage-<board>-<revision>.cfg

Each setting in the pad configuration file has the form:

pad-voltage.<address> = <value>;

Where:

  • <address> is an absolute register address.

  • <value> is the 32-bit data value that MB1 is to write to that address.

Device-Side Implementation

write(value, address);

Example

This is an example of some lines from a pad voltage configuration file:

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 rail voltages may require you to configure certain platform-specific settings:

  • I2C command to devices

  • PWM commands to devices

  • MMIO access to Jetson registers (read-modify-write or write-only)

  • Delay after commands

Settings in PMIC configuration files may be of two types: common (applicable to many or all rails) or rail-specific. Rail-specific configurations, such as I2C commands, MMIO access, and delays, are also platform-specific.

PMIC Settings in the MB1 BCT Configuration File

Some PMIC configuration data is stored in the MB1 BCT configuration file:

  • 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 for enabling and configuring the PWM

  • Amount of delay between commands (if any)

  • 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

Some settings are not configured for some rails because MB1 device side code ignores that setting for that rail.

Each rail has a unique ID to make the parsing and BCT binary easier. The following table lists the IDs.

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-Orin, Jetson-NX, or Jetson-AGX.

  • <partnumber> is the full part number of the device:

    • p3701-0000 for Jetson AGX Orin

  • <revision> is the module’s revision number, e.g. A01.

Note

Review each power rail before you customize the carrier board.

Form of a Setting for Common Parameters

The form for a common parameter setting is:

pmic.<cparameter> = <value>;

Where <cparameter> is one of:

  • command-retries-count: Number of command attempts allowed.

  • wait-before-start-bus-clear-bus: Wait in microseconds before issuing a bus clear command. The wait time is 1<<n microseconds, where n is the value of this parameter.

  • rail-count: Number of rails configured in the configuration file.

These are examples of some common parameter settings in a configuration file:

pmic.command-retries-count = <value>;
pmic.wait-before-start-bus-clear-us = <value>;
pmic.rail-count  = <value>;

Form of a Setting for Rail-Specific Parameters

Each rail-specific parameter setting is in the form:

<pmic>.<railname>.<rparameter> = <value>;

Where:

  • <railname> specifies 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 the block indexed by <bindex>; valid values are 0 (MMIO), 1 (I2C) and 2 (PWM)

      Where <bindex> is the index of the block, counting from 0.

    • block[<bindex>].count: The number of commands in the block

    • block[<bindex>].delay: Delay in microseconds after each command in the block

    • block[<bindex>].type: Type of commands in the block: 0 for MMIO commands, or 1 for I2C commands

    • block[<bindex>].commands[<cindex>].<address>.<mask> is a command in the block, where:

      • <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> is one of these values:

      • i2c-controller-id: I2C controller instance.

      • slave-add: 7-bit I2C slave address.

      • reg-data-size: Register size in bits. Possible values are 0 (one byte), 8 (one byte), and 16 (two byte).

      • reg-add-size: Register address size in bits. Possible 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> is one of these values:

        • 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

Following is an example of a complete PMIC configuration file:

@@@@@@@@@@@@@@@@@@@@@@@@ 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.

A block may contains either MMIO or I2C commands, but not both. MMIO and I2C commands for the same rail must be in separate blocks.

A block that contains I2C commands sends all of its commands to the same device. If two or more devices require I2C commands, the commands must be in separate 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 delay setting is associated with each block. The device observes this delay after sending each command in the block. Commands that require different delays must be in separate blocks.

Form of a Setting for Rail-Specific Commands

All rail-specific parameters must have this prefix:

pmic.<rail-name>.<rail-id>

Parameter

Description

block-count

Specifies the block count. The form of the command is:

pmic.<rail-name>.<rail-id>.block-count = <value>;

Where <value> is the number of command blocks for a given rail.

block

Specifies the block identification parameter. All blocks are indexed, starting from 0. The form of a command is:

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 following table describes the I2C type-specific parameters.

Parameter

Description

I2c-controller-id

Controller ID of I2C.

slave-id

7-bit slave address.

reg-data-size

Register size in bits: 0 or 8 (one byte) or 16 (two bytes).

reg-add-size

Register address size in bits: 0 or 8 (one byte) or 16 (two bytes).

Commands

Commands can be for either MMIO or I2C. The form of each setting is:

<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 this form:

commands[command-index].<addr>.<mask> = <data>;

PWM-Specific Commands

The following table shows the PWM-specific commands.

Command

Value

type

2 (indicates a PWM-specific command)

controller-id

[0, 7] (Depending on the platform)

source-frq-hz

PWM clock source frequency in hertz

period-ns

PWM 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; 0=configure only

This example shows a set of PWM-specific commands in use:

# 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.

Some common parameters:

pmic.command-retries-count = <u32>;
pmic.wait-before-start-bus-clear-us = <u32>;
pmic.rail-count  = <u32>;

Some rail-specific parameters:

pmic.<rail-name>.block-count

The generic format is:

@@@@@ 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;

A 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

Supported Jetson devices have separate registers for configuring bridge client security and bridge firewalls, known as Security Configuration Registers (SCRs). SCRs are configured either by NVIDIA or by the customer for custom platforms.

MB1 and MB2 program most of the SCRs and firewalls. They get 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 an order determined 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 Jetson AGX Orin:

  • For Jetson Xavier NX series: ./hardware/nvidia/platform/t19x/common/bct/scr/bct-scr-cbb-mini.cfg

  • For Jetson AGX Xavier series: ./hardware/nvidia/platform/t19x/common/bct/scr/bct-scr-cbb-mini-p3668.cfg

A setting has the form:

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 cold boot or SC7-exit.

    • Bit 1 = 1: Program in cold boot but skip in SC7-exit.

    • Bit 2 = 1: Program at end of MB2 instead of MB1.

    • Bits 3-7: Unused.

For 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 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.

A setting has the form:

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 of the pin in the port. Possible values are [0, 7].

  • <interrupt-id> is the interrupt route for that pin. Possible values are [0, 7].

The GPIO interrupt mapping configuration file is kept at:

./hardware/nvidia/platform/t19x/<platform>/bct/

For 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/

Each setting has the form:

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> is 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 is the frequency of clock source in hertz.

  • interface-frequency: QSPI controller frequency, in hertz.

  • enable-ddr-mode: Specifies the 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 the 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> is 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> is 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) or 1 (enable).

  • able-fast-auto-mode: Specifies whether to enable fast auto mode. <value> may be 0 (disable) or 1 (enable).

  • enable-hs-rate-a: Specifies whether to enable HS rate A. <value> may be 0 (disable) or 1 (enable).

  • enable-hs-rate-b: Specifies whether to enable HS rate B. <value> may be 0 (disable) or 1 (enable).

  • init-state: Initial state of UFS device at MB1 entry. <value> may be:

    • 0: UFS is not initialized by BootROM

    • 1: UFS is initialized by BootROM (MB1 may skip certain steps)

SATA Parameters

If <storage-device> is sata, <parameter> may be:

  • transfer-speed: Specifies transfer speed. <value> may be

    • 0: GEN1

    • 1: GEN2

Example

This example uses storage device configuration settings of each type:

# 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 IPs like XUSB, SATA, MPHY, PCIE, NVLINK, etc. The UPHY lane configuration file defines UPHY lane configuration for MB1.

MB1 supports SATA and UFS as boot devices; UPHY lanes must be configured to let the boot device access storage in MB1 and MB2.

After MB2, the 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 the UPHY configuration file does not apply to BPMP-FW.

The UPHY lane configuration file is kept at:

./hardware/nvidia/platform/t19x/<platform>/bct/

Each setting in the UPHY configuration file has the form:

uphy-lane.<instance-type>.<uphy-component>.<id> = <owner-id>

Where:

  • <instance-type> is the type of UPHY 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.

These are examples of UPHY configuration file settings:

#UPHY
uphy-lane.hsio.lane.10 = 2;
uphy-lane.hsio.lane.11 = 1;

OEM-FW Ratchet Configuration

Ratcheting is a mechanism which prevents a Jetson device from loading 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

A setting in the ratchet configuration file has the form:

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.

These are examples of some ratchet configuration file settings:

#ratchet
ratchet.1.mb1.mb1bct = 3;
ratchet.2.mb1.spefw = 0;
ratchet.11.mb2.cpubl = 5;

BootROM Reset PMIC Configuration

Some Jetson devices may require BootROM to bring the PMIC rails to OTP values in the L1 and L2 reset boot paths. You do this by issuing I2C commands, which MB1 encodes in AO scratch registers 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 of commands, and each block can have multiple commands.

In the configuration file, AO blocks are specified first, then the reset conditions are initialized with the ID of the AO blocks.

Specifying AO Blocks

A setting in the BootROM reset PMIC configuration file has the form:

bootrom.<parameter> = <value>;

Where <parameter> is one of:

  • aoblock-count: Number of AO blocks mentioned in the file.

  • aoblock[<aoblock-index>].command-retries-count: Number of command attempts allowed for the AO block.

    <aoblock-index> identifies the specified AO block, counting from zero.

  • aoblock[<aoblock-index>].delay-between-command-us: 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: Timeout in microseconds before the device issues a bus clear command for the AO block. The wait time is 1<<n microseconds, where n is the value of this parameter.

  • aoblock[<aoblock-index>].block-count: 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: 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. Possible 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. Possible 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 write to the I2c slave register address <reg-addr> for the command indexed by <command-index>.

Specifying Reset Type to AO Block Mapping

Reset types are mapped to previously declared AO blocks using lines in 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).

This example shows the contents of a BootROM reset PMIC file:

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/

Most miscellaneous configuration file settings have the form:

<feature> = <value>;

Most of the miscellaneous configuration file settings have Boolean values, and enable or disable functionality in MB1. The settings are described below by category.

MB1 Feature Settings

The MB1 feature settings are:

  • disable_spe: Boolean; enables or disables MB1 loading of SPE-FW.

  • enable_dram_page_blacklisting: Boolean; enables or disables the DRAM ECC page DenyListing 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: Disabled; VPR carveout is allocated based on the McVideoProtectSizeMb and McVideoProtectWriteAccess properties in the SDRAM configuration file.

    • 1: Enabled; 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) and 1 (disable checks).

    Note

    A value of 0 enables checks, and 1 disables them. Thus 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

MB2 feature properties configure certain features of MB2. Although they apply to MB2 rather than MB1, they are documented in the topic “MB1 Platform Configuration” because they are defined in the miscellaneous configuration file along with several groups of MB1 properties.

The MB2 feature property settings are:

  • 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. Possible values are 0 (don’t send commands) and 1 (send commands).

AOTAG Properties

MB1 uses AOTAG (Always-On Thermal Alarm Generator) for thermal protection during boot. AOTAG properties control the knobs for AOTAG.

The AOTAG property settings are:

  • 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 by this field, MB1 waits or shuts down the device.

  • aotag.enable_shutdown: Boolean; specifies action to take if boot temperate exceeds aotag.boot_temp_threshold. Possible values are: 0 (wait in boot) and 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

The clock property settings are:

  • clock.bpmp_cpu_nic_divider: Controls programming of the BPMP CPU frequency through CLK_SOURCE_BPMP_CPU_NIC[BPMP_CPU_NIC_CLK_DIVISOR]. Possible values are 0 (do not program) and non-zero (program to the specified value minus 1).

  • clock.bpmp_apb_divider: Controls programming of the BPMP APB frequency through CLK_SOURCE_BPMP_APB[BPMP_APB_CLK_DIVISOR]. Possible values are 0 (do not program) and non-zero (program to the specified value minus 1).

  • clock.axi_cbb_divider: Controls programming of the control backbone (CBB) frequency through CLK_SOURCE_AXI_CBB[AXI_CBB_CLK_DIVISOR]. Possible values are 0 (do not program) and non-zero (program to the specified value minus 1).

  • clock.se_divider: Controls programming of the security engine (SE) frequency through CLK_SOURCE_SE[SE_CLK_DIVISOR]. Possible values are 0 (do not program) and non-zero (program to the specified 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]. Possible values are 0 (do not program) and non-zero (program to the specified 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]. Possible values are 0 (do not program) and non-zero (program to the specified value minus 1).

  • clock.aon_can0_divider: Controls programming of the AON CAN1 frequency through CLK_SOURCE_CAN1[CAN1_CLK_DIVISOR]. Possible values are 0 (do not program) and non-zero (program to the specified value minus 1).

  • clock.aon_can1_divider: Controls AON CAN2 frequency through CLK_SOURCE_CAN2[CAN2_CLK_DIVISOR]. Possible values are 0 (do not program) and non-zero (program to the specified 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. Sets PLLAON_BASE[PLLAON_DIVM] to the specified value minus 1. Ignored when clock.pllaon_divn==0.

  • clock.pllaon_divp: Controls DIVP value of PLLAON. Sets PLLAON_BASE[PLLAON_DIVP] to the specified 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 settings 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 property values must be powers of 2.

All virtual address property values 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 of the information required for MB1 to allocate the carveouts. The miscellaneous configuration file specifies the additional required information.

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 property settings are in the form:

carveout.<carveout-type>.<parameter> = <value>;

Where:

  • <carveout-type>: Identifies the carveout; 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 carveout base address in bytes.

  • ecc_protected: Boolean; 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. Possible values are 0 (allocate from non-ECC protected region) and 1 (allocate from ECC protected region).

  • bad_page_tolerant: Boolean; when DRAM page DenyListing 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. Possible values are 0 (bad pages are not allowed in the carveout and 1 (bad pages are allowed).

    Allocation can be done without filtering bad pages.

Valid combinations of carveouts and their parameters are shown in the following table.

Value of <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

The Arm® Coresight™ property settings are:

  • coresight.cfg_system_ctl: Value to program CORESIGHT_CFG_SYSTEM_CTL.

  • coresight.cfg_csite_mc_wr_ctrl: Value to program CORESIGHT_CFG_CSITE_MC_WR_CTRL.

  • coresight.cfg_csite_mc_rd_ctrl: Value to program CORESIGHT_CFG_CSITE_MC_RD_CTRL.

  • coresight.cfg_etr_mc_wr_ctrl: Value to program CORESIGHT_CFG_ETR_MC_WR_CTRL.

  • coresight.cfg_etr_mc_rd_ctrl: Value to program CORESIGHT_CFG_ETR_MC_RD_CTRL.

  • coresight.cfg_csite_cbb_wr_ctrl: Value to program CORESIGHT_CFG_CSITE_CBB_WR_CTRL.

  • coresight.cfg_csite_cbb_rd_ctrl: Value to program CORESIGHT_CFG_CSITE_CBB_RD_CTRL.

Firmware Load and Entry Properties

The firmware load and entry property settings are:

  • 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

The CPU property settings are:

  • 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

The other property settings are:

  • 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.

This example shows how to set many of the miscellaneous configuration settings:

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;