.. _AR.BootArchitecture.JetsonAgxOrinBootFlow: .. include:: /content/swdocs.rsts .. spelling:: Coldboot Microboot Tegraflash CBoot Jetson AGX Orin Boot Flow !!!!!!!!!!!!!!!!!!!!!!!!! **Boot flow** is the sequence of operations that the Bootloader performs to initialize the SoC and boot |NVIDIA(r)| |Jetson(tm)| Linux. Here are the major operations that the Bootloader performs: * Initializing the storage devices, memory controller (MC), external memory controller (EMC), and CPU * Setting up security parameters * Loading and authenticating firmware components * Maintaining the chain of trust * Creating memory carveouts for various firmware components * Flashing the storage device * Booting to the operating system Additionally, the Jetson boot software may perform other operations defined by product requirements, including but not limited to: * Initializing |HDMI(r)| or DisplayPort * Displaying a boot logo The following diagram shows the flow of control in the boot software. .. figure:: JetsonAgxOrinBootFlow/FlowOfControl.svg :figwidth: 650px BootROM @@@@@@@ **BootROM** (BR) is hard-wired into the SoC. It starts executing as BPMP leaves the reset state. It initializes the boot media and loads BR-BCT, PSCBL1, Microboot1 (MB1) and MB1-BCT from storage, and then halts. Up to four copies of the **BootROM Boot Configuration Table** (BR-BCT) can be stored at the start of the boot media. Each copy of BR-BCT is aligned on a *device erase sector size* boundary, with empty space between copies if necessary. The BR-BCT contains configuration parameters that BootROM uses for hardware initialization. .. todo:: The original said "Each BR-BCT is kept device “erase sector size” apart." Does this reflects the intended meaning? The BCT also contains information about Bootloader (MB1, MB1-BCT, and PSCBL), including: * Size * Entry point * Load address * Hash BootROM uses this information to verify and load the components of Bootloader and MB1-BCT. The following diagram shows the boot flow: .. image:: JetsonAgxOrinBootFlow/BootRom.png :width: 650px PSCROM @@@@@@ **Platform security controller** (PSC) ROM is a hardware component in the SoC, and it starts running as soon as the processor is reset. PSCROM holds all of the keys required for NVIDIA and OEM authentication and decryption. It provides authentication and decryption services to BootROM, and audits the next stage boot on BPMP (for example, MB1) and PSC (for example, PSC-BL1). .. figure:: JetsonAgxOrinBootFlow/Pscrom.svg :figwidth: 650px MB1 @@@ **Microboot1** (MB1) runs on BPMP and is the first boot software component loaded by BR in AOTZRAM. It initializes certain parts of the SoC, including the CPU, and performs security configuration. MB1 is signed and encrypted by an NVIDIA-owned key. The following diagram shows its flow of control: .. figure:: JetsonAgxOrinBootFlow/Mb1.svg :figwidth: 650px .. todo:: The signage that begins "Load firmware..." is unusually long and very awkward. It says "firmware... firmware... firmware... over and over, and the first item seems to encompass all of the others except "BPMP firmware DTB." It would be more compact and easier to read as "Load firmware for BPMP, PSC, NVDEC, & TSEC; load BPMP firmware DTB." That's 66 characters instead of 94. Is there a reason we can't write it that way? It would be even briefer to say "Load firmware; load BPMP firmware DTB" (37 characters) if you think that's sufficiently clear. MB1 is responsible for: * Platform configuration, including pinmux, GPIO, pad voltage, SCRs, and firewalls * Initializing the SDRAM based on the Memory BCT * Loading firmware, including the components that initialize the CPU complex (CCplex) * Programming the PMIC for enabling the ``VDD_CPU`` rail * Creating memory carveouts * Loading MB2, which is the next stage Bootloader NVIDIA owns MB1, and provides it as a binary in the Jetson BSP package. You can configure its behavior for a specific platform through its Boot Configuration Table, MB1-BCT. MB2 @@@ MB2 is the Bootloader component that executes after MB1 and has the following variants: * MB2 Applet * MB2 for flashing, RCM (Development), and Coldboot The processor on which MB2 runs determines which variant runs. .. todo:: This does not make sense! It suggests that the system figurative flips a coin to decide which processor to run MB2 on, then according runs one of the two variants, performing one of two sets of functions. Perhaps it means that boot flow runs *both* on their respective processors, then proceeds when both have finished. MB2 Applet ########## The MB2 applet runs on BPMP (R5). It is responsible for detecting the type of Jetson device in use and fetching information about it. Tegraflash (running on host) uses this information to select the proper configuration files for re-flashing the device. The key pieces of information that the applet retrieves include: * Chip information such as BR revision, SKU, sample, and RAM code based on fuse reads .. todo:: This sounds confusing -- maybe because I'm not familiar with the subject matter, or maybe not. "Sample" must not have its customary meaning here, which wouldn't make sense; will the reader know what it means? Even if they have the information, can we count on them being able to retrieve it when needed? If not, we should reword or explain. "RAM code based on fuse reads" is mysterious. Does this mean code that executes in RAM, but is retrieved from fuses? Or code that is loaded into RAM from disk, but is selected or configured by information from fuses? In either case (or some other), what characteristic determines that this is the proper place to retrieve it? * Board related information stored in EEPROM .. todo:: The original said "...on L4T platforms." Note that we're not using the "L4T" nickname any more, since Jetson Linux no longer runs on Tegra processors. But apart from that, what does "on Jetson Linux (L4T) platforms" mean? Is this refer to the SoC EEPROM, the carrier board EEPROM, or both (in whih case it's "stored in the EEPROMs")? * Customer section information of BCT on Auto platforms .. todo:: Again, this isn't clear to me. "Of BCT" is not good idiomatic English; does it mean "from the BCT," "for the BCT," "about the BCT," etc.? "Customer section" implies the customer-overwritable section of the EEPROM(s), but I reviewed that section, and it doesn't contain anything remotely related to the BCt -- except possibly bytes 179–199, described as "Reserved for future use." What does "auto" mean? The only thing I can think of is "automotive," but the Jetson platform is for embedded applications, *not* automotive ones! Please explain. MB2 ### .. todo:: This needs a more specific name. We can't say that MB2 has two variants, one of which is called MB2. MB2 runs on CCPLEX, and is responsible for: * Flashing. * Cold-boot flashing: MB2-CCPLEX receives binaries from the host and flashes them one by one to the device. .. todo:: The original listed three items, "flashing," "cold boot," and "RCM boot." I figured out that "cold boot" actually refers to flashing software *to be used for* cold boot, but that raises the question: If item 2 is flashing for cold boot, what is item 1? Flashing for something else? Redundant? * RCM boot: MB2-CCPLEX receives binaries from the host and loads them directly into SDRAM for the boot flow components to execute. The following diagram shows the components of MB2-CCPLEX. .. figure:: JetsonAgxOrinBootFlow/Mb2.svg :figwidth: 550px UEFI @@@@ **Unified Extensible Firmware Interface** (UEFI) is an industry specification that describes standard interfaces between platform firmware and the operating system. It replaces CBoot in the Jetson boot flow as the CPUBL for Jetson Linux devices. Features of UEFI include: - With other specifications (SMBIOS, ACPI), it can load a generic OS without requiring any platform customization of the operating system. - It defines a standardized secure boot mechanism for authenticating third-party software (for example, operating systems and PCIe option ROMs). - It supports add-in card drivers via option ROMs, and integrates them with the system configuration user interface. - It defines standard methods for updating firmware. The following diagram describes the major aspects of UEFI boot flow. .. figure:: JetsonXavierNxAndJetsonAgxXavierBootFlow/UefiBootFlow.png :figwidth: 650px UEFI sources and compilation details for this release are available at https://github.com/NVIDIA/edk2-nvidia/wiki. Cold Boot Sequence @@@@@@@@@@@@@@@@@@ The following graphic shows the Boot firmware loading sequence and dependency during cold boot: .. image:: JetsonAgxOrinBootFlow/ColdBootSequence.png :width: 700px