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, 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/
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 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 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 configurations are set separately at the controller and pinmux/pad levels. This file contains the controller level prod 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.
• <controller-name> is a predefined module name: sdmmc, qspi, se, or i2c.
• <controller-instance> is module's 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.
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.
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 platformspecific 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:
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
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 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;
::::
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.
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.
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:
./hardware/nvidia/platform/t19x/common/bct/scr
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.
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.
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.
• <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.
• <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:
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.
• enable_vpr_resize: Boolean; enables or disables the 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
• se_ctx_save_tz_lock: Restrict SE context save and SHA_CTX_INTEGRITY operation to TZ.
• 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.
• limit_l1_boot_client_freq: Boolean; enables or disables boot client frequency limiting.
• 0: Disabled; keep boot client frequencies (BPMP, SE, CBB, etc) the same for L0 and L1 reset.
• 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_ccplex_lock_step: Boolean; enables or disables CCPLEX dual-core lock step.
• 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 temperature 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.
• aotag.cooldown_temp_timeout: Time to wait for the device to cool down to aotag.cooldown_temp_threshold.
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].
• 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 AST Properties
MB1 and MB2 use the address-translation (AST) module to map the DRAM carveout for different firmware componentss into the 32‑bit virtual address space of the various auxiliary processor clusters. These properties configure MB1’s use of AST.
• 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 componentss 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.
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.