The NVIDIA® Jetson™ Nano and Jetson TX1 platforms use the Debian package facility to update Bootloader. The Bootloader update process performs Bootloader updates safely and ensures that a usable Bootloader partition exists at all times during an update.
Note:
Before you study this topic you must become familiar with the following topics:
The BCT is stored in a partition named BCT. The NVIDIA flashing utility tegraflash.py writes up to 64 instances of the BCT, depending on the amount of space allocated for the BCT partition. Instances are aligned on consecutive 16 KiB boundaries.
The Tegra BootROM validates the BCT through an integrated checksum or RSA signature. If the calculated checksum or signature does not match the value in the BCT located at the beginning of the partition, the BootROM attempts to validate the next instances of the BCT. If the checksum or signature again does not match, the BootROM attempts to validate the next instance, and so on, until it finds a valid instance of the BCT or exhausts the available instances.
On platforms that boot from eMMC memory (Jetson TX1, the Jetson Nano production module, and the Jetson Nano development kit module when used with an SD card), L4T uses two groups of files to implement redundancy:
• A boot-file-set (BFS) is a set of all of the files in a group of partitions that are concerned with booting. TegraBoot files are not part of a BFS, since BootROM loads TegraBoot, the TegraBoot loads the BFS.
• A kernel-file-set (KFS) is a set of all of the files in a group of partitions that are concerned with loading the kernel.
A BCT can contain two entries that indicate the locations (offset and size) and checksums or signatures for TegraBoot, the boot files, and the kernel files. The BootROM computes and validates the checksums or signatures for each TegraBoot entry. When it finds a valid set of checksums or signatures, it transfers control to the specified instance of TegraBoot.
TegraBoot computes and validates the checksums for the first BFS and the first KFS and the signatures the individual files. When the checksums and signatures have been validated, TegraBoot loads the appropriate boot files, such as:
• The TegraBoot CPU binary
• DTB files used by Bootloader
• DTB files used by the kernel
• Warmboot binary
• Trusted OS image
When all necessary boot files have been verified and loaded, TegraBoot transfers control to the boot loader, e.g. CBoot. The boot loader validates and loads the next-level software component, such as the Linux kernel or U‑Boot.
If TegraBoot fails to validate the first BFS andKFS, it overwrites itself and resets the board so that the BootROM can validate and load the next set of TegraBoot, BFS, and KFS.
Note:
When Jetson Nano boots from an SD card it doesn’t use redundancy to load the BFS and KFS. It only uses the redundant TegraBoot partition (partition NVC). Because the partitions used by Bootloader are on the SD card, it is easy to replace the SD card to restore a corrupted Bootloader.
Redundancy Boot Firmware
The partition configuration file contains partitioning information for both the Tegra partition table and the GPT. They are at these locations:
• For Jetson TX1: bootloader/t210ref/cfg/gnu_linux_fastboot_emmc_full.xml
• For a Jetson Nano production module (with eMMC storage): bootloader/t210ref/cfg/flash_l4t_t210_emmc_p3448.xml
• For a Jetson Nano development module (with Micro SD storage): bootloader/t210ref/cfg/flash_l4t_t210_spi_sd_p3448.xml
The redundancy layout must contain these partitions, in order:
1. Boot partitions, which are used in the boot process, and are visible only to Bootloader.
Many of the boot partitions have redundant copy partitions. The copy partitions must have the same names as their primaries with the suffix ‘‑1’. For example, the NVC partition’s copy must be named NVC‑1.
The boot partitions are:
• BCT, which contains redundant instances of the Boot Configuration Table. This must be the first partition on the boot device.
• NVC contains TegraBoot. This must be the second boot partition. The following boot partitions, PT through SPF, are part of the BFS.
• PT contains layout information for each BFS, and indicates the beginning of each one. It is the first partition in the BFS.
• TBC contains the TegraBoot CPU-side binary.
• RP1 contains TegraBoot DTBs.
• EBT contains CBoot.
• WB0 contains the warm boot binary.
• BPF contains BPMP microcode.
• NVC‑1 contains a copy of NVC.
• PT‑1 through BPF‑1 are copy partitions for the primaries NVC through BPF, making up a copy of the BFS, denoted BFS‑1.
• PAD is an empty partition which ensures the VER and VER_b are at the very end of the boot partition.
• VER_b contains additional version information for redundancy and version checking.
• VER contains version information.
2. GP1 contains the sdmmc_user device’s primary GPT. All partitions defined after this one are configured in the Linux kernel, and are accessible by standard partition tools such as gdisk and parted.
3. User partitions, which have a variety of uses. Some of them may be deleted, and/or may be mounted and used to store application files.
The following partitions constitute the kernel-file-set (KFS), and have redundant copy partitions:
• DTB contains kernel DTBs.
• TOS contains the trusted OS binary.
• EKS is optional, and is reserved for future use.
• LNX contains either the Linux kernel or U-Boot, depending on your choice of DFLT_KERNEL_IMAGE in the configuration file.
• DTB‑1 through EKS‑1 constitute a copy of the primary KFS, denoted KFS‑1.
• Other partitions, such as APP and BMP, are outside the scope of this document. For information about these partitions, see the appropriate subsection for your Jetson platform in Default Partition Overview.
In summary, the overall layout for a partition configuration file is:
BCT NVC Boot-file-set (BFS): PT, TBC, RP1, EBT, WB0, BPF NVC-1 Boot-file-set copy (BFS-1): PT-1, TBC-1, RP1-1, EBT-1, WB0-1, BPF-1 PAD VER_b VER GP1 APP (not described here) Kernel-file-set (KFS): DTB, TOS, EKS, LNX Kernel-file-set copy (KFS-1): DTB-1, TOS-1, EKS-1, LNX-1 BMP and others (not described here)
While the kernel is booting, the boot partitions are available subject to write protection on these devices:
Partition
Device Name
BCT, NVC, and BFS
/dev/mmcblk0boot0
NVC‑1, BFS‑1, VER_b, and VER
/dev/mmcblk0boot1
Unlike BFS, all KFS partitions are visible from Linux on these devices:
Partition
Device Name
DTB
/dev/disk/by-partlabel/DTB
TOS
/dev/disk/by-partlabel/TOS
EKS
/dev/disk/by-partlabel/EKS
LNX
/dev/disk/by-partlabel/LNX
DTB-1
/dev/disk/by-partlabel/DTB-1
TOS-1
/dev/disk/by-partlabel/TOS
EKS-1
/dev/disk/by-partlabel/EKS-1
LNX-1
/dev/disk/by-partlabel/LNX-1
Generating the Bootloader Update Payload (BUP)
Bootloader Update Payloader (BUP) contains all necessary firmware binaries. It is used to implement bootloader update.
Use these procedures as examples to generate the BUP, which include the new Boot Firmware Set and BCT images for update.
• <top> is the pathname of the directory that contains the PDK installation package. The flash.sh script is in this directory.
• <pkc_key_file>is the RSA private key file for your Jetson carrier board. If it is a relative pathname, it is interpreted relative to the <top>/bootloaderdirectory.
• -d causes the script to run in debug mode, which keeps all boot firmware blob images in bootloader/signed and bootloader/multi-signed
• <target_soc> is:
• For Jetson Nano and Jetson TX1: t21x
• For Jetson TX2 series platforms: t18x
• For Jetson AGX Xavier series platforms: t19x
Locations of Generated BUPs
The procedure generates the following BUPs in the specified locations:
• For Jetson Nano and Jetson TX1: <top>/bootloader/payloads_t21x
• bl_update_payload: Contains all required binaries.
• xusb_only_payload: Contains xusb.
• bl_only_payload: Contains bootloader binaries (only for Jetson Nano booting from an SD card).
• kernel_only_payload: Contains kernel and kernel-dtb (only for Jetson Nano booting from an SD card).
• porg_qspi_only_payload: Contains binaries stored QSPI (only for Jetson Nano booting from an SD card).
• porg_sd_only_payload: Contains binaries stored SD card (only for Jetson Nano booting from an SD card).
• For Jetson TX2 series platforms: <top>/bootloader/payloads_18x
• bl_update_payload: Contains all necessary binaries.
• bl_only_payload: Contains bootloader binaries.
• kernel_only_payload: Contains kernel and kernel-dtb.
• For Jetson AGX Xavier series platforms: <top>/bootloader/payloads_t19x
• bl_update_payload: Contains all necessary binaries.
• bl_only_payload: Contains bootloader binaries.
• kernel_only_payload: Contains the kernel and kernel DTB.
To use new Bootloader firmware to generate the BUP
• Copy the corresponding bootloader firmware binaries to replace the ones in <top>/bootloader/t210ref/, then run l4t_generate_soc_bup.sh to generate the new BUP.
To print out the BUP’s header information and entry tables
When you flash the device, the update tool is stored in /user/sbin/l4t_payload_updater_t210/. You can use it to update all partitions contained in the BUP.
The script stores the bootloader update log in/opt/ota_package/bl_update_payload.log.
Note:
The Bootloader Debian package nvidia-l4t-bootloader_32.3.0-xxx_arm64.deb uses this script to perform the Bootloader update automatically.
To print out device’s bootloader version
• Enter this command:
$ sudo l4t_payload_updater_t210 -v
The command prints a message like this one:
# R32 , REVISION: 3.0
Bootloader Update Flow
The script /user/sbin/l4t_payload_updater_t210 implement the full Bootloader update process.
The following diagram shows the Bootloader update flow:
Sample Logs in BUP Generation, Boot, and Update for BFS/KFS
This section contains examples of logs for common BUP generation, booting, and boot updating cases. They can be used to check whether errors happened in these operations.
Sample Logs in BUP Generation about BFS/KFS
This log shows the BFS/KFS information used in BUP generation, such as binary name, size and BFS/KFS checksum.
