In the boot sequence for Jetson TX2, MB1 uses the MB1 BCT to configure platform-specific static settings. MB1 executes before any other CPUs are enabled. The MB1 stage is owned by NVIDIA and signed by NVIDIA and the OEM.
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:
<top>/bootloader/<platform|ver>/BCT/
Jetson TX2 Pinmux and GPIO Configuration
The Jetson TX2 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 Jetson TX2 prod setting is the configuration of system characterization and interface, and controller settings. This is required for the interface to work reliably in a given platform. The prod setting is set at the controller level, and separately at the pinmux level.
The format of this configuration is a tuple of register address, mask, and data value. MB1 reads data from address, modifies it based on mask and value, and then writes it back to address.
Jetson TX2 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.
During system boot, Jetson TX2 MB1 enables system power rails such as CPU, SRAM, CORE, as well as some system PMIC configurations. The typical configurations are:
• Enabling rails
• Setting rail voltages
• FPS configurations
Enabling and setting of voltages of rails may require:
• I2C command to devices
• MMIO access to SoC registers, either read-modify-write or write-only
• Delay after the commands
Rail-specific configurations, such as I2C commands, MMIO access, and delays, are platform-specific. The MB1 BCT configuration file must provide configuration information.
The MB1-CFG format supports:
• I2C, 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:
Where common <parameters> is one of the following:
Parameter
Description
command-retries-count
The number of allowed command attempts.
wait-before-start-bus-clear-us
Wait timeout, in microseconds before issuing the bus clear command. The wait time is calculated as 1 << n microseconds where n is provided by this parameter.
rail-count
Number of rails in this configuration file that need to be configured.
Example
pmic.command-retries-count = <value>;
pmic.wait-before-start-bus-clear-us = <value>;
pmic.rail-count = <value>;
Rail-specific parameters take the following format:
• The rail specific commands are divided into blocks.
• Each rail can have one or more blocks. Each block of given rails are indexed starting from 0.
• Each block contains either MMIO or I2C commands. If both MMIO and I2C commands are required, then commands are broken into multiple blocks.
• If 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 byte
reg-add-size
Register address size in bits: 0 or 8:1 byte
16: 2 byte
Commands
Commands can be either MMIO or I2C. The information is in the format <address>.<mask> = <data>, to support the read-modify-write sequence. All commands are indexed, to facilitate multiple commands in a given block. Commands are sent to the device in sequence, starting from index 0, in the following format:
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;
::::
Configuring Generic Rails
When configuring generic rails for PMIC, consider the following:
• Correcting the PMIC default configuration without the OTP is required. However, if the configuration is on the default OTP, reconfiguration is not required.
• To configure some devices in the system using I2C, platform specific configuration is not required.
• Write the configuration of devices, such as PMIC in the Jetson TX2 module (the System on a Module, or SOM), then perform the configuration for the baseboard devices. This ensures that if the setup includes different configurations, all PMIC configurations for that the SOM is performed successfully.
• To assist in removing blocks if a module is not used, use a property comment in each block as follows:
<module_name>:<device>
For a SOM used for PMIC configuration:
# P3310: PMIC: Set PMIC MBLDP = 1, CNFGGLBL1 bit 6 = 1
For an expander configuration in the P2597 baseboard:
# baseboard (P2597): Expander: 5V0_HDMI_EN
Configuring Security Configuration Registers
Jetson TX2 devices have separate registers for configuring bridge client security, bridge firewalls, known as Security Configuration Registers (SCRs). SCRs are either configured by NVIDIA for Jetson TX2 platforms or re-configured for custom platforms. Custom configuration uses MB1 BCT at the MB1 stage.
The list of SCRs for re-configuration for custom platforms is the same in MB1 device-side code and SCR platform data. SCR register addresses, hard coded in MB1, can only contain data from the platform. The data cannot be masked, and can only be written to the registers as is.
The SCR configuration file is at:
<top>/bootloader/<platform|ver>/BCT/auto_scr.cfg
Usage
scr.<reg_index>.<exclusion-info> = <32 bit value>; # <reg_name>
Where:
• scr is the domain name prefix for the setting.
• <reg_index> is the matching MB1 and CFG file sequence, beginning at 0.
• <exclusion-info> is one of the following values:
Value
Description
0
Include: regular SCRs loaded from BCT in cold boot, from stored context in warm boot.
1
Exclude: Present data in the CFG file but do not load data from the BCT. Allows SCR programming in MB2 or later.
2
SC7 resume: Program from BCT in cold boot, but exclude for warm boot.
MB1 code lists SCR register absolute addresses in an indexed list.
Certain fuses cannot be read or written by default because they are not visible. If this field is set, MB1 enables fuse visibility for such fuses.
fuse_visibility = 1;
enable_vpr_resize
Controls enablement of VPR resize functionality.
enable_vpr_resize=0
Disable_el3_bl
Used to eliminate execution of EL3 Bl after secure os and can start EL2 bootloader
Disable_el3_bl = 1
AOTAG
The AO-TAG register is programmed in MB1 which controls the maximum temperature Jetson TX2 systems are allowed to operate. If the temperature exceeds that limit, auto-shutdown is triggered.
AOTag Control Fields
Description
Configuration Example
boot_temp_threshold
Boot temperature threshold in millicentigrade. If temperature is higher than the temperature specified in this field, MB1 waits or shuts down the device.
aotag.boot_temp_threshold = 105000;
cooldown_temp_threshold
Cool down temperature threshold in millicentigrade. MB1 resumes booting when the device has cooled to this threshold temperature.
aotag.cooldown_temp_threshold = 85000;
cooldown_temp_timeout
Contains max time MB1 should wait for system temperature to go down below “cooldown_temp_threshold”.
Cooldown_temp_timeout = 30000
enable_shutdown
If set to 1, enables shutdown using aotag if temperature is above boot temperature threshold.
aotag.enable_shutdown = 1;
Clock
The clock control fields hold the clock divider values for the various modules that MB1 programs.
Clock Control Fields
Description
Configuration Example
bpmp_cpu_nic_divider
Program the cpu nic divider to control the BPMP CPU frequency.
A value 1 less than the value in the field is directly written to the register.
clock.bpmp_cpu_nic_divider = 1;
bpmp_apb_divider
Program the apb divider to control the APB bus frequency.
A value 1 less than the value in the field is directly written to the register.
clock.bpmp_apb_divider = 1;
axi_cbb_divider
Program the axi_cbb divider to control the AXI-CBB bus frequency.
A value 1 less than the value in the field is directly written to the register.
clock.axi_cbb_divider = 1;
se_divider
Program the se divider to control the SE Controller frequency.
A value 1 less than the value in the field is directly written to the register.
clock.se_divider = 1;
aon_cpu_nic_divider
Program the cpu_nic divider to control the AON(SPE) CPU frequency.
A value 1 less than the value in the field is directly written to the register.
clock.aon_cpu_nic_divider = 1;
aon_apb_divider
Program the apb divider to control the AON(SPE) APB frequency.
A value 1 less than the value in the field is directly written to the register.
clock.aon_apb_divider = 1;
aon_can0_divider
Program the can0 divider to control the CAN0 controller frequency.
A value 1 less than the value in the field is directly written to the register.
clock.aon_can0_divider = 1;
aon_can1_divider
Program the can1 divider to control the CAN1 controller frequency.
A value 1 less than the value in the field is directly written to the register.
clock.aon_can1_divider = 1;
osc_drive_strength
Unused
-
pllaon_divp
Program the P value of PLL-AON.
A value 1 less than the value in the field is directly written to the register.
clock.pllaon_divp = 2;
pllaon_divn
Program the N value of PLL-AON.
A value 1 less than the value in the field is directly written to the register.
clock.pllaon_divn = 25;
pllaon_divm
Program the M value of PLL-AON.
A value 1 less than the value in the field is directly written to the register.
clock.pllaon_divm = 1;
CPU Parameters
These settings contain the initial settings passed to CPU-Init FW. Do not change these settings.
Field
Description
Configuration Example
Bootcpu
Specify Boot CPU. 4 means A57 cpu0 and 0 mean Denver0. For automotive applications use A57-cpu0.
cpu.bootcpu = 4
ccplex_platform_features
Platform feature passed to the CPU-Init FW.
cpu.ccplex_platform_features = 0x581;
lsr_dvcomp_params_b_cluster
Contains setting for initializing ADC and DVC, which need to be functional before CPU rails are brought up
cpu.lsr_dvcomp_params_b_cluster = 0xC0780F05C;
lsr_dvcomp_params_m_cluster
Contains setting for initializing ADC and DVC, which need to be functional before CPU rails are brought up
cpu.lsr_dvcomp_params_m_cluster = 0xC0780F05C;
nafll_m_cluster_data
Initial NAFLL settings for cluster for Denver
cpu.nafll_m_cluster_data = 0x11F04461;
nafll_b_cluster_data
Initial NAFLL settings for cluster for A57
cpu.nafll_b_cluster_data = 0x11F04461;
AST Settings
The AST settings are for various firmware loaded by MB1/MB2. These are the virtual addresses of the firmware. MB1/MB2 programs corresponding physical addresses based on the location where it loaded the firmware in memory (DRAM). Normally there is no need to change these settings.
Fields
Description
Configuration Example
bpmp_fw_va
Virtual address for BPMP-FW
ast.bpmp_fw_va = 0x50000000;
mb2_va
Virtual address for MB2-FW
ast.mb2_va = 0x52000000;
sce_fw_va
Virtual address for SCE-FW
ast.sce_fw_va = 0x70000000;
apr_va
Virtual address for Audio-protected region used by APE-FW
ast.apr_va = 0xC0000000;
ape_fw_va
Virtual address for APE-FW
ast.ape_fw_va = 0x80000000;
SW Carveout
These settings specify the address and size for BL carveout.
Field
Description
Configuration Example
cpubl_carveout_addr
Start location of the CPU-BL Carveout
sw_carveout.cpubl_carveout_addr = 0x96000000;
cpubl_carveout_size
Size of the CPU-BL Carveout
sw_carveout.cpubl_carveout_size = 0x02000000;
mb2_carveout_size
Size of the MB2 Carveout
sw_carveout.mb2_carveout_size = 0x00400000;
Debug
The debug functionality can be enabled disabled using BCT flag.
Debug Control Fields
Description
Configuration Example
uart_instance
Configures the UART instance for console prints.
debug.uart_instance = 1;
enable log
Enables/disables console logging.
debug.enable_log = 1;
enable_secure_settings
Unused.
-
I2C Settings
These settings specify the operating frequency of the I2C bus in MB1/MB2 (default is 100 KHz).
Field
Description
Configuration Example
0
Specify the clock for I2C controller instance 0
i2c.0 = 400;
4
Specify the clock for I2C controller instance 4
i2c.4 = 1000;
Dev Parameters
These are the device settings used by MB1/MB2.
Field
Description
Configuration Example
qspi.clk_src
Specify the clock source. The value corresponds to what is mentioned in the QSPI CLK SRC register.
0 : 1 bit (x1 mode) 1 : 2 bit (x2 mode) 2 : 4 bit (x4 mode)
devinfo.qspi.width = 2
qspi.dma_type
Specify which DMA to use for transfer if mode of transfer is DMA. For QSPI, in MB1/MB2, BPMP-DMA should be used.
0 : GPC-DMA 1 : BPMP-DMA
devinfo.qspi.dma_type = 1
qspi.xfer_mode
Specify mode of transfer 0: PIO
1: DMA
devinfo.qspi.xfer_mode = 1;
qspi.read_dummy_cycles
The dummy cycles allow the device internal circuits additional time for accessing the initial address location. During the dummy cycles the data value on IOs are “don’t care” and may be high impedance.
devinfo.qspi.read_dummy_cycles = 9
qspi.trimmer_val1
tx_clk_tap_delay for QSPI
devinfo.qspi.trimmer_val1 = 0
qspi.trimmer_val2
rx_clk_tap_delay for QSPI
devinfo.qspi.trimmer_val2 = 0
Watchdog Timer Controller Settings
These settings specify watchdog timer controller register values. These values will be configured by MB1.
Field
Description
Configuration Example
bpmp_wdtcr
Contains the bpmp processer watchdog timer register value
wdt.bpmp_wdtcr = 0x710640; configures for 100sec
Sce_wdtcr
Contains the SCE processer watchdog timer register value
wdt.sce_wdtcr = 0x707103;
aon_wdtcr
Contains aon’s watchdog timer register value
wdt.aon_wdtcr = 0x700000;
rtc2_ao_wdtcr
Contains rtc2_ao watchdog timer register value
wdt.rtc2_ao_wdtcr = 0x700000;
top_wdt0_wdtcr
Contains top_wdt0 watchdog timer register value
wdt.top_wdt0_wdtcr = 0x715016;
top_wdt1_wdtcr
Contains top_wdt1 watchdog timer register value
wdt.top_wdt1_wdtcr = 0x710640;
top_wdt2_wdtcr
Contains top_wdt2 watchdog timer register value
wdt.top_wdt2_wdtcr = 0x707103;
PMIC
The PMIC configuration file is created manually as follows:
1. Get information about the set of commands to enable and setting voltage of each rail.
• If OTP values are in desired voltage, do not reprogram voltage register.
• Do not enable all rails, perform the recommended by boot sequence.
• The voltage for rail must be set per the boot sequence recommendation.
2. Get information about generic setting required from the MB1.
3. Once all information is collected, split these commands per rail.
4. Make the list of commands sequence, delay between commands and then make blocks. Blocks can contain multiple commands if they:
• Are of the same type such as I2C or MMIO
• Have the same delay
• Communicate to the same device
If anything is different, it will be in different blocks.
5. Create configuration file based on the above details.
BootROM
The BOOTROM configuration file is created manually as follows:
1. Get information about the set of commands to send to device in different reset path.
• It is possible that the same type for commands are used for different reset paths. Collect all such information from system team.
2. Make the sets of commands required for each reset path independently.
3. Pickup commands for one reset path.
4. Make the list of commands sequence.
5. Delay between commands and then make blocks out of these. Blocks can contain multiple commands if they:
• Are of the same type such as I2C or MMIO
• Have the same delay
• Communicate to same device
If anything is different, it will be in different blocks.
6. Put all blocks in one aoblocks.
7. Similarly, make all aoblocks for all reset paths.
8. Initialize the different reset paths aocommand with these aoblock indexes.
9. Create configuration file based on above details.