.. _AR.BootArchitecture.Mb1PlatformConfiguration: .. include:: /content/swdocs.rsts .. spelling:: AO aotag bindex bndx cindex cndx Coresight ECC Fll frq frug gsc hz Init init Ldmem mb MTS ns pmic pwm PWM RCM ver cpubl ecc mts rcm tegra tzdram uCode vpr MB1 Platform Configuration !!!!!!!!!!!!!!!!!!!!!!!!!! This topic contains information about configuring Micro Boot stage 1 (MB1) on platforms that are supported by |NVIDIA(r)| |Jetson(tm)| Linux and that support MB1. .. todo:: If all currently supported platforms support MB1, the qualification isn't necessary. 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. .. todo:: From marginal comment, 6/08/2020: "Edited for accuracy based on Jimmy’s input. Please recheck for accuracy." One question. We say “MB1 executes before any other CPUs are enabled,” but we don’t say what CPU it executes on! To avoid referring to something we haven’t explained, we must either identify the CPU or rewrite this to eliminate the word “other.” Please suggest some wording. For more information, see the section :ref:`Jetson AGX Orin Boot Flow ` or :ref:`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). .. todo:: A note on one of the simplifications I made here: "the MB1 stage" was redundant. "MB1" is defined to mean "Micro Boot stage 1," so "the MB1 stage" would mean "the Micro Boot stage 1 stage." I'm making similar simplifications and clarifications throughout. This should make the topic a lot more readable. Please check to ensure that I didn't accidentally change any meanings. The platform-specific configuration files specify: - Pinmux and GPIO configurations - Prod setting - Pad voltage setting - PMIC setting - Secure register configuration .. todo:: We write extensively about prod settings, prod configuration files, etc., but we have never explained what "prod" means. (The explanation under "Common Prod Configuration" is quite vague, and sheds no light on what the term "prod" actually represents.) Can we fix this, please? Newcomers to the Jetson platform will be baffled. 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-.cfg .. todo:: Orin TBD. Where: - ```` is the device’s board name: - ``p3701`` for |NVIDIA(r)| |Jetson AGX Orin(tm)| - ``p3668`` for |NVIDIA(r)| |Jetson Xavier(tm) NX| series - ``p2888`` for |NVIDIA(r)| |Jetson AGX Xavier(tm)| series - ```` is the board revision number, e.g. ``a01``. .. todo:: From marginal comment, 6/08/2020: "Jeetesh gave an example of a .cfg file name in one of his comments, in which was reduced to ‘a01’. However, Bibek gave a different example in one of his comments, in which it was reduced to ‘0000’. Which form is correct -- is it the second part of the part number, or is it the revision number?" 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.
= ; Where: - ``pinmux`` is a domain name that identifies this line as GPIO and pinmux configuration data. .. todo:: This is confusing. If the pinmux/GPIO configuration file contains only pinmux/GPIO configuration settings, why is a domain prefix needed? This makes me wonder (and will make the reader wonder) whether I have understood correctly. The same question applies to some other groups of settings, e.g. prod. - ``
`` is the absolute ``PADCTL_A``. ``GPIO_CTL``, or ``AON_GPIO`` register address. - ```` is the 32-bit data value to be configured there. Device-Side Implementation $$$$$$$$$$$$$$$$$$$$$$$$$$ .. todo:: This section needs an introduction to explain (at least) what the following line means. It can't be function usage, because the write() function's first parameter must be an FD. Also, it seems to me that "Device-Side Implementation" is misplaced between a section that introduces the configuration file and an example of a configuration file. Shouldn't we reorganize each section to put it at the end? .. code:: write(value, address); Example ####### This example shows some entries in a pinmux/GPIO configuration file:: @@@@ Pinmux for used pins @@@@ pinmux.0x02434060 = ; # gen1_i2c_scl_pc5.PADCTL_CONN_GEN1_I2C_SCL_0 pinmux.0x02434064 = ; # gen1_i2c_scl_pc5.PADCTL_CONN_CFG2TMC_GEN1_I2C_SCL_0 pinmux.0x02434068 = ; # gen1_i2c_sda_pc6.PADCTL_CONN_GEN1_I2C_SDA_0 pinmux.0x0243406C = ; # gen1_i2c_sda_pc6.PADCTL_CONN_CFG2TMC_GEN1_I2C_DA_0 . . . @@@@ Pinmux for unused pins for low-power configuration @@@@ pinmux.0x02434040 = ; # gpio_wan4_ph0.PADCTL_CONN_GPIO_WAN4_0 pinmux.0x02434044 = ; # gpio_wan4_ph0.PADCTL_CONN_CFG2TMC_GPIO_WAN4_0 pinmux.0x02434048 = ; # gpio_wan3_ph1.PADCTL_CONN_GPIO_WAN3_0 pinmux.0x0243404C = ; # 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. .. todo:: Can we be more specific about the "interface"? A Jetson device has many interfaces, and a new user will probably be uncertain which one this is talking about. 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. .. todo:: "modifies it based on..." is cryptic. Does it AND the mask into the value? OR it? XOR it? Or something more exotic? The prod configuration file is at:: Linux_for_Tegra/bootloader/t186ref/BCT/tegra186-mb1-bct-prod--.cfg .. todo:: Marginal comment, 6/10/2020: "Bibek, you said to replace "all with tegra186. However, earlier in the document you replaced the first instance of with t186ref. I believe the same symbol should apply in all cases, and I'm guessing that it's t186ref. Is that correct?" In the second instance ('tegra186') was originally “tegra<186|210>194.” I think that was incorrect and this is correct. Where: - ```` is the device’s board name: - ``p3701`` for Jetson AGX Orin - ``p3668`` for Jetson Xavier NX series - ``p2888`` for Jetson AGX Xavier series - ```` is the board revision number, e.g., ``a01``. The form of a line in the file is:: prod.
. = ; Where: - ``prod`` is the domain name that identifies this line as a prod data setting. - ``
`` is a pad control register address. - ```` is a mask value (4 bytes, unsigned). - ```` is a data value (4 bytes, unsigned). Device-Side Implementation $$$$$$$$$$$$$$$$$$$$$$$$$$ .. todo:: Same comment as for the earlier section with the same heading. .. code:: 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//bct/ Each setting in the file has the form:: deviceprod....
. = ; Where: - ```` is the module’s name: ``sdmmc``, ``qspi``, ``se``, or ``i2c``. - ```` is the module's origin-0 instance number, e.g. 3 for ``SDMMC4``. - ```` is the controller mode to which the prod setting applies, e.g. ``default``, ``hs400``, etc. - ``
`` is the absolute register address within the controller and instance. - ```` is the mask value (four bytes unsigned). - ```` 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 $$$$$$$$$$$$$$$$$$$$$$$$$$ .. code:: 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\ |nbsp|\ volts\ |nbsp|\ (V), 1.8\ |nbsp|\ V, or 3.3\ |nbsp|\ 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--.cfg .. todo:: t194, or tegra194? And what about Orin? Each setting in the pad configuration file has the form:: pad-voltage.
= ; Where: - ``
`` is an absolute register address. - ```` 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: .. todo:: To be consistent with other sections and meet the reader's natural expectations, we should explain here where the PMIC configurations are kept. Currently we mention in the next section that some of them are kept in the MB1 BCT configuration file. I'm not sure whether we specify the locations of all of them. Also, I'm not sure it makes sense to say that "MB1 enables... system PMIC configurations." Would it to be accurate to say "MB1 enables... and configures some system PMIC settings"? - 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: .. todo:: At this point the original said "The MB1-CFG format supports:". That term never came up in the discussion of the MB1 BCT config file; I assume it refers to the format of another file, and the following list identifies the settings that are configured there. If that is so, we never do explain which settings are in the MB1 BCT file. In a marginal comment, 1/30/2019, I noted: "This information does not appear to be in the updated BCT wiki. Is it inapplicable information that we should delete, or additional information that we should keep? "Jeetesh replied, “We can delete this section to align with Xavier documentation.” “This section” begins with the heading “PMIC Configuration,” and extends through all of its subsections. I don’t think that’s what you intended, because it’s about nine whole pages of content, and you made several corrections in it. If that’s not you intended, please explain a different way. You may mean to delete the text within the scope of this marginal comment, from “The MB1-CFG format supports…” through the table of rail names." - 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. .. todo:: It's unclear what it means to call read-modify-write and read-only "formats." As I understand the term, "formats" are modes of access, and have nothing to do with data format. It's also unclear what "commands on read-modify-write format" and "commands are read-modify-write format" mean; would it be accurate to say "MMIO/I2C commands for read-modify-write access"? - 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 .. todo:: I can't parse this. Would it be accurate to say "device registers' address size and data size for I2C commands"? - I2C command on the 400KHz .. todo:: Again, unclear. What does this mean? Remember, this is a list of settings that are configured in the MB1 config file -- it isn't supposed to contain other types of information such as what value to set. - The sequence may be: - 1 MMIO, 1 I2C - 1 I2C, 1 MMIO - 2 MMIO, 1 I2C - 1 MMIO, 2 I2C .. todo:: Again, this information does not fit in a list of configurations. Perhaps the list should be presented in some other form, such as a list of configurations set in the MB1 config file *and instructions for setting them*. If so, I will need equivalent information for the other settings. The typical rail/configurations are divided into following PMIC command domains: .. todo:: This is unclear. Would it be accurate to say "PMIC rail settings are divided into the following command domains"? As a related question, what does "domains" mean? If it's being used the same way it was earlier in this topic, setting names are actually prefixed with ``Generic``, ``CPU``, etc. This seems unlikely since all of the other domain prefixes I've seen are in lower case. - 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 .. todo:: From this point forward, are we talking about PMIC configuration files again? If so we should start a new section or move this material into the preceding section. 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. .. todo:: "to make... easier" is unclear. "BCT binary" is a thing, not a process; it's not clear how it could be made "easier." Please clarify. ========= ==== 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/-tegra194-mb1-bct-pmic--.cfg Where: - ```` is the type of device, ``Jetson-Orin``, ``Jetson-NX``, or ``Jetson-AGX``. - ```` is the full part number of the device: - ``p3701-0000`` for Jetson AGX Orin .. - ``p3701-0010`` for Jetson AGX Orin Industrial - ``p3668-0000`` for original Jetson Xavier NX (development module, distributed with Jetson Xavier NX Developer Kit) - ``p3668-0001`` for original Jetson Xavier NX (production module, 8\ |GB| RAM) - ``p3668-0003`` for Jetson Xavier NX 16GB (16\ |GB| RAM) - ``p2888-0001`` for original Jetson AGX Xavier (16\ |GB| RAM) - ``p2888-0004`` for original Jetson AGX Xavier (32\ |GB| RAM) - ``p2888-0005`` for Jetson AGX Xavier 64GB (64\ |GB| RAM) - ``p2888-0008`` for Jetson AGX Xavier Industrial (32\ |GB| RAM) - ```` 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. = ; Where ```` 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<; pmic.wait-before-start-bus-clear-us = ; pmic.rail-count = ; .. todo:: With instead of actual values, these are not examples; they are just illustrations of the form of a setting with specific rail names. If we can't give actual examples here, we should delete the section. I'm inclined to think we should delete it anyway; the setting form is too simple to need examples! Some discussion of the range of permitted or typical values in the list above would be helpful, though. Form of a Setting for Rail-Specific Parameters $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Each rail-specific parameter setting is in the form:: .. = ; Where: .. todo:: is... what? Maybe this means "pmic," not "." - ```` 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 - ```` is one of: - ``block-count``: Number of blocks for the rail - ``block[].type``: Type of commands in the block indexed by ````; valid values are 0 (MMIO), 1 (I2C) and 2 (PWM) Where ```` is the index of the block, counting from 0. - ``block[].count``: The number of commands in the block - ``block[].delay``: Delay in microseconds after each command in the block - ``block[].type``: Type of commands in the block: 0 for MMIO commands, or 1 for I2C commands .. todo:: The original described this setting as a separate unnumbered paragraph under the next setting, and said it specifies the type of "an MMIO command" or "an I2C command." Without a I don't see how it can specify the type of a specific command; it can only specify the type of all of the commands in the block. - ``block[].commands[].
.`` is a command in the block, where: - ```` is the command index, counted from 0. To write several commands, specify them in parameters with consecutive values of ````. - ``
`` is the absolute address of the MMIO register or the address of the I2C slave register. - ```` 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[].``: Specifies an I2C parameter. Valid only if ``block[].type = 1``. .. todo:: We've switched from to . I think they're the same thing. If so, which is preferred? (I'd prefer for consistency with , but since they're both used so much, perhaps we can shorten them to and .) ```` 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[].``: Specifies a PWM parameter. Valid only if ``block[].type`` = 2. - 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``: V\ :sub:`out` from PWM regulator if duty cycle is 0. - ``max-microvolts``: V\ :sub:`out` from PWM regulator if duty cycle is 100. - ``init-microvolts``: V\ :sub:`out` 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: .. todo:: I assume it's a complete file, since it's so long. It's not clear to me how we choose when to reproduce a complete file and when selected settings, or how we choose the settings (and the number of settings) in the latter case. If this hasn't been done intentionally, the document will be improved if we go back and do it now. .. code:: @@@@@@@@@@@@@@@@@@@@@@@@ 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 .. todo:: We're shifting from an example back to a discussion of how the file is organized without a new heading. Perhaps this text belongs in the preceding section, and example should follow it. As a separate issue, I question the need for such a lengthy example here. If it is a complete file, we could as easily tell the reader where to find it instead of reproducing it. If it is not, why does the reader need it, as opposed to one or a few examples of settings? There are many other lengthy examples in this topic, both above and below, that should be re-evaluated too. 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. .. todo:: Does this mean "Each rail's blocks are indexed..."? 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. .. todo:: The meaning is unclear, since I2C and MMIO commands must be in different blocks. Does it mean that if a device has one or more blocks of I2C commands, MMIO commands for that device do not need these parameters? What if an MMIO command *does* specify those parameters -- do they override the ones in the I2C block, or are they ignored, or do they trigger an error? 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 $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ .. todo:: The following text purports to describe the syntax of a command (something already done above), but it is profoundly different from the earlier section with the same title. Many of the same parameters and property names appear, but they're organized differently; it's as if the two sections describe completely different implementations of a PMIC configuration file. What should I make of this? If the two sections actually describe different things, it's not clear what the difference is. All rail-specific parameters must have this prefix:: pmic.. .. todo:: How does the table relate to the "prefix"? Is the parameter simply appended to it? That seems most likely, but the mere fact that we have a table, where every previous description used a bulleted list, implies that nothing I've grown accustomed to up to now, necessarily applies. +-------------+----------------------------------------------------------------+ | Parameter | Description | +=============+================================================================+ | block-count | Specifies the block count. The form of the command is:: | | | | | | pmic...block-count = ; | | | | | | Where ```` 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...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. | +-------------+----------------------------------------------------------------+ .. todo:: The space after the code blocks in the table's first two rows is much too large. The second row is a glaring example of what how the space looks with no text following the code block! The style sheet should be modified to change the spacing in code blocks inside tables. I tried to fix this by changing swdocs.css's .rst-content div[class^="highlight"] to "margin: 1px 0 1 px 0;", but the div still composes with a bottom margin of 24px. I2C Type-Specific Parameters $$$$$$$$$$$$$$$$$$$$$$$$$$$$ .. todo:: Up to this point we've elaborated a simple fundamental classification: there are common parameters and there are rail-specific parameters. Now are there "type-specific parameters" too? Changing the basic organization of a concept in the middle of the explanation is tremendously confusing. Perhaps "I2C type-specific parameters" are part of some different classification scheme, but if so it's not clear and the name is misleading. This section follows the descriptive format of 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). | +--------------------+---------------------------------------------------------+ .. todo:: I suspect that "I2c-controller-id" should be "i2c-controller-id." This passed review for a previous release, though, so I want to check. Commands $$$$$$$$ .. todo:: Commands haven't been mentioned since we left rail-specific parameters. We need some context here: what kind of settings are these commands in? Presumably not rail-specific settings, since this section is in the wrong place for that and it repeats information that the rail-specific parameter section already provided. Commands can be for either MMIO or I2C. The form of each setting is::
. = ...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].. = ; .. todo:: What does "...to support the read-modify-write sequence" have to do with the first part of the sentence? I must be missing something, because the form of a setting and supporting the read-modify-write sequence seem completely unrelated. I also wonder whether the paragraph means what it says: that commands are sent *to a device* with an index in each one, even though the order of transmission should define the order of execution, and with a semicolon after each one. PWM-Specific Commands $$$$$$$$$$$$$$$$$$$$$ .. todo:: This comment applies to the entire topic, not this section. Much of the topic seems to be "flattened" so that sections that should be in a section/subsection relationship are at the same level. For instance, this section should be a subsection of the preceding one. Another: Some sections have an example as a final subsection; others inconsistently have an example at the end of their own content. These things happen because the sections are all at level 5, and our style guidelines do not allow level 6 sections. The fact that we can't have a subsection here makes the lack no less confusing. I suggest that the whole topic needs to be reorganized to reduce the number of levels used. If "Commands" were at level 4, for example, this section could go down to level 5. 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) .. todo:: This isn't sufficient. How can the reader determine what value to use for their platform? If that information is in some other document, we should refer them to it. ---------------- -------------------------------------------------------------- source-frq-hz PWM clock source frequency in hertz ---------------- -------------------------------------------------------------- period-ns PWM period in nanoseconds ---------------- -------------------------------------------------------------- min-microvolts V\ :sub:`out` from PWM regulator if duty cycle is 0 ---------------- -------------------------------------------------------------- max-microvolts V\ :sub:`out` from PWM regulator if duty cycle is 100 ---------------- -------------------------------------------------------------- init-microvolts V\ :sub:`out` 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 $$$$$$$$$$$$$$ .. todo:: What is generic format? How do these commands differ from the same commands shown earlier, which presumably were in some other format? The following code snippets show the common and rail-specific parameters in a generic format. Some common parameters:: pmic.command-retries-count = ; pmic.wait-before-start-bus-clear-us = ; pmic.rail-count = ; Some rail-specific parameters:: pmic..block-count .. todo:: Why show three examples for one, and one for the other? This forces us to introduce an inconsistency in the text: First "Some...," then "A..." The inconsistency is minor, but seems entirely unnecessary. It's also puzzling that the rail-specific example shows a command name with no value. The reader is led to think this means that rail-specific parameters don't *have* values, although that makes no sense and conflicts with the same command in earlier examples. The generic format is:: @@@@@ BLOCK 0 @@@@ pmic...block[0].type = <0 for MMIO, 1 for I2C> pmic...block[0].delay = pmic...block[0].count = ; #For I2C specific pmic...block[0].I2c-controller-id = ; pmic...block[0].slave-add = ; pmic...block[0].reg-data-size = ; pmic...block[0].reg-add-size = ; #I2C and MMIOs pmic...block[0].commands[0].. = ; pmic...block[0].commands[1].. = ; pmic...block[0].commands[2].. = ; pmic...block[0].commands[3].. = ; . . . @@@@@ BLOCK 1 @@@@ pmic...block[1].type = <0 for MMIO, 1 for I2C> pmic...block[1].delay = pmic...block[1].count = #For I2C pmic...block[1].I2c-controller-id pmic...block[1].slave-add pmic...block[1].reg-data-size pmic...block[1].reg-add-size #I2C and MMIOs pmic...block[1].commands[0].. = ; pmic...block[1].commands[1].. = ; pmic...block[1].commands[2].. = ; pmic...block[1].commands[3].. = ; . . . .. todo:: The preceding code block is baffling. It doesn't describe the generic format; it just shows some more examples in addition to the common and rail-specific examples above. What is it trying to convey? The purpose of the following code blocks are also unclear. They are accurately described as examples, but they too add nothing to the examples at the start of the section. To illustrate a command format a single example of a command is sufficient, unless the reader might have questions about how to apply the format to specific cases. I've noted elsewhere that very long examples are disfavored; where the complete contents of file is needed it's better to tell the reader where to find the file, and when only a portion is used the portion can almost always be made reasonably short. The code blocks above and below are extreme examples of excessive length. 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. .. todo:: We use "platform" to refer to a type of Jetson device, e.g. Jetson Xavier NX or Jetson AGX Orin. What is a custom platform? I suspect this refers to the carrier board. 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. .. todo:: But they aren't documented here, and we don't say where they can be found. .. todo:: The paragraph above appears to conflict with the one below: Is the order predetermined, or is it determined by the indexes? Or are these referring to different kinds of order? 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. .. todo:: The last sentence appears to mean that if an SCR is set by the configuration file it is read-write, else it is read-only. Is that correct? It seems odd. The security configuration files are kept at: - For Jetson Jetson AGX Orin: .. todo:: TBD - 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.. = <32-bit value>; Where: - ```` is the index of the SCR or firewall in the predefined list. - ```` 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..pin. = ; Where: - ```` is the port name, e.g. A, B, C, … Z, AA, or BB. .. todo:: Does it actually stop at BB? Or is this a continuing series: ...ZZ, AAA, BBB,...? - ```` is the pin ID of the pin in the port. Possible values are [0, 7]. - ```` 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//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//bct/ Each setting has the form:: device... = ; Where: - ```` identifies the storage device controller: ``qspiflash``, ``ufs``, ``sdmmc``, or ``sata``. - ```` is the instance of the storage controller. - ```` is a controller-specific parameter as shown below. QSPI Flash Parameters $$$$$$$$$$$$$$$$$$$$$ If ```` is ``qspi``, ```` may be: - ``clock-source-id``: Identifies the clock source. ```` 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. ```` may be: - 0: QSPI SDR mode - 1: QSPI DDR mode - ``maximum-bus-width``: Maximum QSPI bus width. ```` may be: - 0: QSPI x1 lane - 2: QSPI x4 lane - ``fifo-access-mode``: Specifies the FIFO access mode. ```` 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 ```` is ``sdmmc``, ```` may be: - ``clock-source-id``: SDMMC controller clock source. ```` 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. ```` 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 ```` is ``ufs``, ```` may be: - ``max-hs-mode``: Highest HS mode supported by UFS device. ```` may be: - 1: ``HS GEAR1`` - 2: ``HS GEAR2`` - 3: ``HS GEAR3`` - ``max-pwm-mode``: Highest PWM mode supported by UFS device. ```` may be: - 1: ``PWM GEAR1`` - 2: ``PWM GEAR2`` - 3: ``PWM GEAR3`` - 4: ``PWM GEAR4`` - ``max-active-lanes``: Maximum number of UFS lanes ```` 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. ```` may be 0 (disable) or 1 (enable). - ``able-fast-auto-mode``: Specifies whether to enable fast auto mode. ```` may be 0 (disable) or 1 (enable). - ``enable-hs-rate-a``: Specifies whether to enable HS rate A. ```` may be 0 (disable) or 1 (enable). - ``enable-hs-rate-b``: Specifies whether to enable HS rate B. ```` may be 0 (disable) or 1 (enable). - ``init-state``: Initial state of UFS device at MB1 entry. ```` may be: - 0: UFS is not initialized by BootROM - 1: UFS is initialized by BootROM (MB1 may skip certain steps) SATA Parameters $$$$$$$$$$$$$$$ If ```` is ``sata``, ```` may be: - ``transfer-speed``: Specifies transfer speed. ```` 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. .. todo:: Can you explain this more completely, please? If BPMP-FW "can keep the configuration programmed by MB1," it's hard to understand how the lane configuration defined by the UPHY configuration file could *not* apply to it. The UPHY lane configuration file is kept at:: ./hardware/nvidia/platform/t19x//bct/ Each setting in the UPHY configuration file has the form:: uphy-lane... = Where: - ```` is the type of UPHY to be configured. It may be ``hsio`` or ``nvhs``. - ```` specifies whether this setting configures lane or PLL. It may be ``lane`` or ``pll``. - ```` is the lane or PLL number to be configured. - ```` 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). .. todo:: This description seems to be inaccurate or outdated. We have a 30-page document which describes ratcheting, `Rollback Protection through Ratcheting `__, and it doesn't mention "OEM-FW." 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//bct/ratchet .. todo:: Distribution pathnames start in a variety of ways. Some begin with ````. Some begin with ``Linux_for_Tegra``. A few begin with a dot, like this one. Don't all of these mean the same thing, "the location of the unpacked contents of the BSP archive"? If so, we should choose one form and stick to it. I recommend ````, which is short but distinctive, and doesn't use the deprecated name ``Tegra``. A setting in the ratchet configuration file has the form:: ratchet... = Where: - ```` is the unique index for an OEM-FW component. .. todo:: I infer that these indexes have predefined meanings. Where can the reader find their definitions? - ```` is the name of the boot stage binary which loads firmware corresponding to ````. - ```` is the name of the firmware. - ```` 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. .. todo:: "with the ID" implies that all of the blocks have the same ID. Is that how it works? If not, we say "with the IDs." Specifying AO Blocks $$$$$$$$$$$$$$$$$$$$ A setting in the BootROM reset PMIC configuration file has the form:: bootrom. = ; Where ```` is one of: - ``aoblock-count``: Number of AO blocks mentioned in the file. .. todo:: "mentioned" is an odd word choice. Can we say "defined" or "specified"? - ``aoblock[].command-retries-count``: Number of command attempts allowed for the AO block. ```` identifies the specified AO block, counting from zero. - ``aoblock[].delay-between-command-us``: Delay between commands, in microseconds. The delay is 1<].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<].block-count``: Number of blocks in the AO block. - ``aoblock[].block[].type``: Must be −1, indicating an I2C command block. - ``aoblock[].block[].count``: Number of commands in the block. - ``aoblock[].block[].i2c-controller-id``: Identifies the I2C controller instance. - ``aoblock[].block[].slave-add``: A 7\ |nbhy|\ bit I2C slave address. - ``aoblock[].block[].reg-data-size``: Register size in bits. Possible values are 0 (one byte), 8 (one byte), and 16 (two byte). - ``aoblock[].block[].reg-add-size``: Register address size in bits. Possible values are 0 (one byte), 8 (one byte), and 16 (two byte). - ``aoblock[].block[].commands[].``: Value to write to the I2c slave register address ```` for the command indexed by ````. Specifying Reset Type to AO Block Mapping $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ Reset types are mapped to previously declared AO blocks using lines in the form:: bootrom..aocommand[] = ; Where: - ```` specifies the reset type. It must have one of the values ``watchdog5``, ``watchdog4``, ``sc7``, ``sc8``, ``soft-reset``, ``sensor-aotag``, ``vfsensor``, or ``hsm``. - ```` is the index of the AO command. It must be 0, 1 or 2. - ```` is one of the ```` values defined in an AO block specification (above). This example shows the contents of a BootROM reset PMIC file: .. todo:: Is this a complete file? A part of a file? I commented earlier about the need to describe examples accurately, and the desirability of keeping them short. .. code:: 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/ .. todo: The first sentence says there is one file, which makes sense. The second says there are "files," which also makes sense, but requires further explanation: how many, how are they named, and what are they for? (For example, does each group of "miscellaneous" properties have its own file? If so, only the "Other Properties" are truly miscellaneous; the rest are in the MB1 feature properties file, the MB2 feature properties file, etc.! I question whether the "miscellaneous Configurations" classification is meaningful at all.) Most miscellaneous configuration file settings have the form:: = ; .. todo:: "Most" merely informs the reader that this section is incomplete. What other forms are used, and what are they used for? (This may be explained later, but the reader is going to start wondering about it here.) 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 $$$$$$$$$$$$$$$$$$$$ .. todo:: Where can the reader find information about the features mentioned here? I know that most of them are never mentioned in the Developer Guide. Does one of the hardware manuals explain them? 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. .. todo:: The relationship of the last sentence to the preceding ones is unclear. Does it mean that some of the fuses subject to this setting are enabled by default and some are disabled? And what does it mean for a fuse to be disabled? That it has been blown -- or hasn't been blown? - ``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 .. todo:: From marginal comment, 1/31/2019: "Do TZDRAM, etc. refer to the encryption keys, or the carveouts? Does this really depend on bits 1-3? It seems odd to start with bit 1 rather than bit 0. - ``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``: .. todo:: No description is provided for ``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. .. todo:: Here's another reference to "miscellaneous configuration file" in the singular, which may or may not be correct. 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). .. todo:: I assume that CMD0 and CMD1 are commands. Will the reader know what they are and how to use them? They aren't mentioned anywhere else in the document. 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\ |degC|. 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\ |degC|. 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\ |nbhy|\ 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. .. todo:: Marginal comment, 1/31/2019: "Please clarify this. It appears to say that they must be aligned to themselves. 5/22: Bibek referred this to Sukanto and Vinod." MB2 AST Properties $$$$$$$$$$$$$$$$$$ MB1 and MB2 use the address translation (AST) module to map the DRAM carveout for different firmware components into the 32\ |nbhy|\ 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.. = ; Where: - ````: 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). - ```` 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 | | | | | | | | pref_base | size | alignment | 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 | +---------------+-----------+------+-----------+-----------+-------------------+ .. todo:: Elsewhere in this topic, "ecc-protected" is spelled ``ecc_protected``. In view of the context, I think that spelling is correct. Coresight Properties $$$$$$$$$$$$$$$$$$$$ The Arm\ |reg| Coresight\ |tm| 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. .. todo:: For this property, and probably others, we have failed to tell the reader what values are accepted or, if necessary, how to choose one. - ``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.``: Frequency of I2C controller instance in kilohertz, where ```` 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; .. todo:: Another instance of an extremely long block of code which would be better shortened or referenced in a file. Also, I'm puzzled by the way settings with the same prefix are scattered throughout the file. For example, there are two separate blocks of carveout.* settings. Some of the MB1 feature settings are at the start of the example and the rest are at the end.