Use these guidelines to enable runtime boot firmware updates with data redundancy features as part of a failure-tolerant system update procedure for the NVIDIA® Tegra® Linux Driver Package (L4T) releases on the Jetson™ TX1 Development Kit. Adaptation of these instructions may be required for use on other Tegra X1-based platforms.

Implementation of a specific update mechanism or update procedure is outside the scope of this document.

An understanding of these concepts is required:

The Tegra BootROM validates the BCT through an integrated checksum or RSA signature. If the calculated checksum, or RSA signature, does not match the checksum or signature value within the BCT, the BootROM searches for the next BCT and attempts to validate. Up to 64 copies of the BCT are searched, at mod-16KiB boundaries. The NVIDIA flashing utility, tegraflash, writes up to 64 copies of the BCT based on the space allocated for the BCT partition.

A BCT can contain up to four entries for indicating locations (offset and size) and checksums or signature of the tegraboot, bootfileset (BFS), and kernelfileset (KFS). The BootROM computes and validates the checksum or signature for each tegraboot entry. When the first valid checksum or signature is located, the BootROM transfers control (jumps) to the specified tegraboot.

The tegraboot computes and validates the checksum for its companion BFS and KFS. When the checksums for the BFS and KFS are validated and signature of each boot and kernel files are verified, the tegraboot takes the appropriate action loads boot files such as:

When all necessary boot files are verified and loaded, the tegraboot transfers control (jumps) to the boot loader such as cboot. The boot loader validates and loads next level software such as Linux kernel or U-Boot.

If the tegraboot fails to validate bootfileset and kernelfileset, it overwrites itself and resets the board so that the BootROM can validate and load the next tegraboot, bootfileset, and kernelfiileset combination.

The standard L4T release for Jetson TX1 does NOT enable boot firmware redundancy features. As part of a failure-tolerant boot firmware update, you must:

Enabling boot firmware redundancy requires modification of these components:

Once these modifications are completed, flashed, and deployed, initial boot loader redundancy is enabled.

Modify the Linux kernel to expose the eMMC boot0 and boot1 partitions for runtime access. By default, eMMC boot partitions are NOT exposed during runtime by the Linux kernel.

When the kernel is booted, the write-protected boot partitions are available at:

Populate the BFS to the boot partition configuration file by automatically generating or by modifying the existing default partition configuratin file.

An example of a complete partition configuration file generation is as follows

This modification:

Unlike BFS, all KFS partitions are visible from Linux:

No further modifications are required to inform boot loader and the Linux kernel of the location of the new root file system.

This topic does NOT apply to L4T R28 releases or if SecureBoot is not used.

Enable boot firmware redundancy inter-operability with SecureBoot in L4T R24 releases by adding one line of python code to the tegraflash script as follows:

Congratulations, the L4T R24.x.x BSP can now inter-operate with the Secureboot.

Flash the Jetson TX1 platform with the above modifications to verify proper loading and functioning of boot firmwares, the Linux kernel, and the proper location specified for the root file system.

Because enabling redundancy makes eMMC boot partitions very crowded, you must:

check by commenting out the BOOTPARTSIZE=xxx line in the <device name>.conf file before flashing.

For flashing instructions, see the Development Guide for your device.

For convenience, BCT image names are identified with four appended numeric values to denote the boot firmware version described by the BCT image. The numeric versions are arbitrary but indicate the boot firmware update process.

For example, after flashing, with initial boot firmware redundancy enabled, all boot firmware and kernel file versions are identical and referred to as bct_1111. When boot firmware is updated and the BCT is modified to contain two new images in slots 0 and 1 positions 1 and 2, the boot version is referred to as bct_2211.

Likewise, for descriptive purposes, a similar numeric value is appended to the name of the BCT binary.

Before updating the boot firmware, read and maintain a copy of the BCT (bct_1111) flashed on the production device. This BCT is used for later modifications to update the boot firmware entries (location, size, hash, and signature) within the BCT.

To update boot firmware from newer L4T BSP, prepare a new boot firmware as follows:

 

Upon completion, the mkbctpart utility prints out the download instructions and identifies where to locate the files on the target.

NVIDIA provides a host-based utility, mkbctpart, for offline modifications and updates of the BCT. Use mkbctpart to specify a new location, size, and hash value for an updated boot loader binary.

The mcbctpart utility generates the updated BCT partition file and padded boot loader files from the provided BCT partition file and the new boot loader file as follows:

The mkbctpart syntax is as follows:

The command syntax is as follows:

For example:

Where mkbctpart:

The mkbctpart utility expects all BFS files, signed or unsigned, to exist in the same directory in L4T BSP:

Using the scp command on a removable storage device, copy the updated bct_2211, new kernel dtb file, and new boot file image bfsblob{_signed}.bin to the target device.

The following provides example target commands to overwrite the BCT and bfsblob{_signed}.bin with the updated binaries into BFS instance 0 and 1. This example is for the standard Jetson TX1 eMMC device with 4 MiB boot0 and 4 MiB boot1.

 

The name of KFS files are *.encrypt for non-PKC protected system, and *.signed for PKC protected system.

To execute the updated BCT and boot loader, reboot the system.

The update process is "stateless" so it can be restarted without knowing the previous update status.

Once the BFS/KFS 0 and 1 are updated successfully, the new BFS/KFS is used in next boot cycle. Leave the target as is because BFS/KFS 0 and 1 are new versions and BFS/KFS 2 and 3 are older versions. To update BFS/KFS 2 and 3 to the new versions, repeat same update procedure with some numbers changed.

For example: