Update and Redundancy

NVIDIA® Jetson™ Linux supports Bootloader update and redundancy on all Jetson platforms.

The Bootloader update process performs a safe Bootloader update and ensures that a workable Bootloader partition remains available during an update. It accomplishes this using A/B update, a feature that maintains two sets of Bootloader partitions, Slot A and Slot B, each of which is a complete set of the partitions that contain boot images.

Root file system redundancy (“rootfs redundancy”) is a feature built upon A/B update, which provides Bootloader redundancy. It automatically maintains the same Bootloader image in both Bootloader slots, allowing a Jetson device to boot from the unused slot if the current slot is corrupted.

A/B update and rootfs redundancy reduce the risk of boot failure when Bootloader is updated and when the images in the current Bootloader slot become corrupted.

Rootfs redundancy is disabled by default. To enable it, see Enabling Bootloader Redundancy.

A/B Slot Layout

The principle of shadow copying enables multiple placeholders. All of the placeholders but one hold backup copies. Each backup copy is a candidate to boot from. However, based on runtime decisions, the correct copy of the binary is loaded to continue with the boot process. These two shadow copies are commonly referred to as Slot A and Slot B. This two-slot implementation is as follows:

The following diagram shows the slot implementation in conceptual form.

../../../_images/SlotImplementationLayout.svg

A/B System Update

An A/B slot update affects these components:

Partition Selection

A/B system updates use two sets of partitions (slots). Each slot has several attributes:

  • The slot that the running system booted from is called the current slot. The other slot is called the unused slot. The system exchanges the roles of the current and unused slot in the course of an update, or when the software fails repeatedly during or immediately after a boot.

  • The slot that the system will use the next time it boots is called the active slot. In “steady state” device the bootable slot is also the active slot. When the system is being updated it may be different.

  • A slot’s bootable attribute indicates whether the slot contains a system from which the device should be able to boot. When the system is running the current slot is bootable; the unused slot may have an older, identical, or newer version of the system, and may or may not be bootable.

  • A slot’s successful attribute indicates whether the system has successfully booted from the slot. The user space Update Engine (UE) sets it the first time a newly updated slot boots successfully to the kernel. It is reset when the slot is updated or a boot attempt from the slot fails (because the slot has been updated with a nonfunctional system or has become corrupted).

    If a bootable slot fails to boot a certain number of times, Bootloader clears its successful and bootable attributes and switches the roles of the current and unused slots. The formerly unused, now current slot normally contains boot software that is either one update old (if the device was just updated with nonfunctional software) or current (if the current slot has suffered data corruption).

Slot status information is kept in a structure stored in the slot metadata (SMD) partition:

../../../_images/SlotMetadataStructure.svg

Where:

  • magic holds a fixed value that identifies the SMD partition.

  • version holds the version number of the software in this slot.

  • num_slots holds the number of slots, which should be 2.

  • boot_slot_info is an array of structures which contain information about the slot. In each slot:

    • priority holds the priority of this slot.

    • suffix holds a string, either "_a" or "_b", that is suffixed to the names of the partitions in this slot to distinguish them from those in the other slot.

    • retry_count holds the number of boot retries remaining before Bootloader clears the current slot’s successful and bootable attributes and tries to boot from the unused slot.

    • boot_successful holds this slot’s successful attribute.

    The bootable slot is the slot whose priority and retry_count are both greater than 0.

The current slot is the slot with the highest priority and a retry_count greater than 0. The next boot operation attempts to boot from this slot.

Update Engine

A/B system update uses the Update Engine to update the A/B slots, and to prepare the system to boot an updated version of Bootloader. The Update Engine performs these actions:

  1. Reads bl_update_payload and writes data to the unused slot’s partitions as instructed by the payload.

  2. Calls the boot_control interface in a predefined workflow.

  3. Switches the roles of the current and unused slots.

  4. Reboots the system.

  5. Updates images on the unused, previously current slot to ensure that both slots contain the update.

For more information, see:

Bootloader Implementation

The A/B system uses the boot slot metadata to store the slot status. It communicates between the Update Engine and Bootloader. Bootloader runs the state machine to select the boot slot. It handles the update failure cases as follows:

../../../_images/UpdateFailure.svg

MB1 uses the slot metadata to find the current slot. It caches the current slot number, 0 (slot A) or 1 (slot B), along with a “valid” flag, in scratch register 99 to be used by MB2, UEFI, or later stage loaders.

Scratch register 99 layout

Bits

Contents

31-30

Flag

29-26

Slot A retry count

25-22

Slot B retry count

21-19

Maximum number of slots

18-16

Current slot number

15-0

Magic pattern 0xCAFE

If MB1 does not find a current slot, the device hangs.

The name of the partition that is being loaded is derived as follows:

partition_name = <base_name>_<slot_value>”
slot value = “” for slot 0
slot value = “_b” for slot 1

Partition Settings

The A/B partitions must be named like this:

  • mb1

  • mb1_b

  • mb2

  • mb2_b

  • cpu-bootloader

  • cpu-bootloader_b

  • etc

The empty suffix for Slot A ensures backward compatibility with legacy partition loading mechanisms that are unaware of A/B slots.

Update Engine States

The Update Engine (UE), nv_update_engine, uses the slot metadata to instruct Bootloader what slot to boot from. The following sections describe the possible states of the UE.

  • Normal: The system has booted from the current slot.

    No updates have been applied.

    The current slot is bootable and successful, and is the active slot.

    The unused slot is bootable, and has the same contents as the bootable slot.

    This table shows the status of a system in this state with slot B current and slot A unused. Note that because slot A is current, it has a higher priority than slot B.

    Slot

    Priority

    Retry count

    Bootable

    Successful

    Active

    Slot A

    14

    7

    0 or 1

    1

    0

    Slot B

    15

    7

    1

    1

    1

  • Update in progress: The system has booted from the current slot, and is updating the unused slot.

    The active slot is bootable and successful.

    The unused slot is not Bootable because it is in the process of being updated.

    This table shows the status of a system in this state with slot B current. If the system must reboot in this state, it reboots from slot B.

    Slot

    Priority

    Retry count

    Bootable

    Successful

    Active

    Slot A

    0

    0

    0

    0

    0

    Slot B

    15

    7

    1

    1

    1

  • Update complete, reboot pending: The roles of the current and unused slots are about to be switched. The system will then attempt to boot from the current (formerly unused) slot.

    The updated slot is made bootable and active, but is not yet marked as successful. Bootloader attempts to boot from the updated slot the specified number of times.

    This table shows the status of a system in this state with slot A newly updated and the reboot (from slot A) pending.

    Slot

    Priority

    Retry count

    Bootable

    Successful

    Active

    Slot A

    15

    7

    1

    0

    1

    Slot B

    14

    7

    1

    1

    0

  • System booted from a newly updated slot: The formerly current, now unused slot is still marked bootable and successful. The now current slot is bootable and active, but not yet successful.

    This table shows the status of a system in this state with slot A newly updated and booted for the first time.

    Slot

    Priority

    Retry count

    Bootable

    Successful

    Active

    Slot A

    15

    6

    1

    0

    1

    Slot B

    14

    7

    1

    1

    0

    After a successful boot and some system checks, the Update Engine marks the now current slot successful.

  • Slot duplication in progress: Having successfully booted the updated slot, the system duplicates its contents to the unused slot. The unused slot is marked not bootable before the update begins, and is marked bootable after it concludes successfully.

    If the system must reboot while in this state, it boots from the newly updated, now current slot.

    This table shows the status of a system in this state with slot duplication from slot A to slot B in progress.

    Slot

    Priority

    Retry count

    Bootable

    Successful

    Active

    Slot A

    15

    6

    1

    0

    1

    Slot B

    0

    0

    0

    0

    0

  • Slot duplication complete: The current slot is marked bootable and successful. The unused, newly duplicated slot is marked bootable and successful, but with lower priority.

    This table shows the status of a system in this state.

    Slot

    Priority

    Retry count

    Bootable

    Successful

    Active

    Slot A

    15

    7

    1

    1

    1

    Slot B

    14

    7

    1

    1

    0

  • Boot Failure and Recovery: The system fails to boot from the current slot due to a nonfunctional update, data corruption, or I/O errors.

    After the specified number of failed attempts to boot from the current slot, Bootloader clears the current slot’s bootable successful attributes, and boots from the unused slot.

    This table shows the status of a system that has failed to boot from slot A and has recovered by booting from slot B.

    Slot

    Priority

    Retry count

    Bootable

    Successful

    Active

    Slot A

    0

    0

    0

    0

    0

    Slot B

    14

    7

    1

    1

    1

    In this state the Update Engine is not allowed to duplicate the active slot to the unused slot, nor is it allowed to modify the partition table or the contents of partitions not assigned to slot A or B.

    Duplication is not allowed until the system has updated the unused slot and booted from it successfully.

When the Update Engine is Launched

The update engine is launched in these situations:

  • The user enters the following command, which launches the Update Engine to update software:

    $ sudo nv_update_engine --install

    The Update Engine updates the software by applying a Bootloader update payload (BUP). The BUP must be named bl_update_payload. and must be placed under the directory /opt/ota_package.

  • The boot service enters the following command to launch the Update Engine during a system boot:

    $ sudo nv_update_engine --verify

    The Update Engine loads the slot metadata, evaluates the current state, and runs a predefined workflow. In a normal boot the Update Engine is in the normal boot state, where no update is applied and a duplicate is not required, so the Update Engine simply exits. If the system is in another boot state, it takes action as appropriate.

Enabling Bootloader Redundancy

There are two ways of enabling Bootloader redundancy:

  • Create an SMD image and configure the redundancy settings.

  • Enable Bootloader redundancy directly with the nv_update_engine tool.

To enable redundancy by creating an SMD image

  1. Modify the SMD configuration file smd_info.cfg to enable A/B slots.

  2. Run nv_smd_generator on the host to generate an SMD image with the updated SMD configuration file.

    Instructions for generating an SMD image are in SMD Image Generator.

  3. Run flash.sh to flash all partitions to the Jetson device.

To enable redundancy with the nv_update_engine

  • Launch nv_update_engine on the Jetson device to enable A/B update on the flashed device with A/B disabled SMD image.

For using nv_update_engine are in Running the Update Engine.

Bootloader Tools

NVIDIA provides tools for ease of use in the Bootloader update process.

Boot Control

nvbootctrl loads the SMD image and dumps the slot information. It is intended for debugging use. You can also use it to set the active slot, forcing the boot slot to change for the next boot.

To display the command usage, enter the command with no parameters:

$ sudo nvbootctrl

Bootloader Update Payload Generator

The Bootloader Update Payload (BUP) is the payload that is applied by the update engine during an update. The BUP is generated by the host tool build_l4t_bup.sh, kept with flash.sh in the Linux for Jetson Board Support Package (BSP).

This section describes procedures for generating a multi-spec BUP or a single-spec BUP.

A multi-spec BUP includes firmware binaries and BCT images for each supported Jetson device. When you run the updater, it uses the appropriate binary of each type for the device you are updating.

A single-spec BUP includes firmware binaries and BCT images for just one type of device). It is appropriate if you are updating just one type of Jetson device.

To generate a multi-spec BUP

  • Enter the commands:

    $ cd <top>
$ sudo ./l4t_generate_soc_bup.sh [-u <pkc_key_file>] [‑p <options>] [-d] <processor>

    Where:

    • <top> is the pathname of the directory that contains the PDK installation package. flash.sh 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 <top>/bootloader/.

    • -d makes the script run in debug mode, which keeps all boot firmware blob images in bootloader/signed and bootloader/multi-signed.

    • <options> is a string that contains command line options to be passed to flash.sh to generate the BUP. If the string contains whitespace characters, it must be enclosed in quotes.

    • <processor> is t234 for an Jetson AGX Orin™ series device, or t19x for an NVIDIA® Jetson Xavier™ NX series or Jetson AGX Xavier™ series device.

The procedure stores the BUP in the file:

<top>/bootloader/<psd>/bl_update_payload

For more information, see Generating the Bootloader Update Payload (BUP).

To generate a single-spec BUP

  • Enter the command:

    $ sudo [env={value}, …] ./build_l4t_bup.sh [options] <board> <rootdev>

    Where:

    • <board> is the value of $(BOARD) for your Jetson module and configuration, as shown by the table in Jetson Modules and Configurations in the topic Quick Start.

    • <rootdev> is the partition where the root file system is to be flashed.

The procedure stores the BUP in the file:

<top>/bootloader/<psd>/bl_update_payload

For more information, see Generating the Bootloader Update Payload (BUP).

Where the BUP File is Stored

Both procedures store the BUP file at:

<top>/bootloader/<payload_dir>/bl_update_payload

Where <payload_dir> is:

  • For Jetson AGX Orin devices: payloads_t23x

  • For Jetson Xavier NX series and Jetson AGX Xavier series devices: payloads_t19x

The multi-spec procedure stores a BUP at each of these locations for the respective group of processors. The single-spec procedure stores a BUP at just one location for the appropriate type of processor.

You must place the appropriate BUP file on the target system under this directory before the Update Engine is run:

/opt/ota_package/

SMD Image Generator

Run the SMD image generator, nv_smd_generator, on a host system to generate the default SMD image slot_metadata.bin to be flashed into the SMD partition.

To launch the image generator, enter the command:

$ nv_smd_generator <config_file> <output_file>

Where:

  • <config_file> is the SMD configuration file.

  • <output_file> is the image file that the image generator is to create.

For example:

$ sudo nv_smd_generator smd_info.cfg slot_metadata.bin

In the Linux for Jetson Board Support Package, nv_smd_generator, the default SMD configuration file smd_info.cfg, and the default image file slot_metadata.bin, are installed under the directory <top>/bootloader.

By default, smd_info.cfg is set to make Slot A the only available slot. This effectively disables redundancy:

< VERSION 4 >
# Set the maximum boot slot retry count
# Please make sure this field is set before slot info config
< MAX_BL_RETRY_COUNT 7 >
#
# Config 1: Disable A/B support (Default)
#
# slot info order is important!
# <priority> <suffix> <boot_successful>
15             _a        1
#
# Config 2: Enable redundancy support (by removing comments ##)
#
##< REDUNDANCY_USER 1 >
#
# To disable bootloader autosync, use < BL_AUTOSYNC_DISABLE 1>
# REDUNDANCY_ENABLE or REDUNDANCY_USER must be defined before BL_AUTOSYNC DISABLE!
##< BL_AUTOSYNC_DISABLE 1 >
# slot info order is important!
# <priority> <suffix> <boot_successful>
##15           _a        1
##14           _b        1

Use Config 2 to create the SMD image and enable rootfs redundancy.

To enable A/B update and rootfs redundancy

  1. Comment out the configuration that disables A/B update by adding ‘#’ to the beginning of the parameter line below Config 1:

    15           _a        1

  2. “Uncomment” the configuration that enables A/B update by removing ‘##’ from the beginning of the parameter lines below Config 2:

    ##15           _a        1
##14           _b        1

    Now the Bootloader-related partitions, the kernel partition, and the kernel-dtb partition all have A/B slots.

  3. If you want to enable rootfs redundancy as well as A/B update, uncomment the <REDUNDANCY_USER x> statement. Replace x> with a number that specifies the type of redundancy support you want:

    • 0: For Bootloader only, i.e, from MB1 and MB2 through UEFI.

    • 1: For Bootloader and images in the kernel and kernel-dtb partitions.

  4. Bootloader slot duplication is enabled by default. You can disable it by uncommenting the configuration:

    ##< BL_AUTOSYNC_DISABLE 1 >

Maximum Boot Slot Retry Count

MAX_BL_RETRY_COUNT specifies the maximum boot slot retry count. Its default value is 7. You can set any value between 0 and 7.

Note

Rootfs redundancy is disabled by default because only one file system partition (APP) is created. NVIDIA can provide guidance on enabling rootfs redundancy.

Running the Update Engine

You run the Update Engine script on the Jetson device.

To enable/disable rootfs redundancy

  • To enable redundancy, enter the command:

    $ sudo nv_update_engine –-enable-ab

  • To disable redundancy, enter the command:

    $ sudo nv_update_engine –-disable-ab

The command fails if the current boot slot is not 0.

To Update Bootloader

  1. Enter this command on the Jetson device to switch to superuser mode:

    $ sudo su

  2. Enable rootfs redundancy (a one-time command):

    $ nv_update_engine --enable-ab

  3. If no BUP directory exists, create one by running the command:

    $ mkdir /opt/ota_package

  4. To copy the BUP from the host system to the BUP directory, enter the command:

    $ scp <host_loc:bl_update_payload> /opt/ota_package/

    Where:

    • <host_loc:bl_update_payload> is the location where the BUP is built on the host system. You can also use a USB key to copy the BUP from the host system to the target system.

    • For information about how to generate the BUP, see Generating the Bootloader Update Payload.

  5. To launch the Update Engine to update Bootloader on the unused slot, enter the command:

    $ nv_update_engine --install

Update Engine State Machine

This diagram shows the Update Engine state machine’s flow:

../../../_images/UpdateEngineStateDiagram.svg

Manually Modifying Boot Slots

The NVIDIA tool nvbootctrl switches the boot slots and modifies the SMD partition as needed for testing and development purposes. However, you may also want to switch boot slots or modify the SMD partition manually from user space.

To manually modify the boot slots

  1. Enter this command to switch to superuser mode:

    $ sudo su

  2. Enter this command:

    $ nvbootctrl <command>

    Where <command> one of the values in the following table.

    Command

    Description

    get-number-slots

    Printer the number of slots.

    get-current-slot

    Prints the currently running slot.

    mark-boot-successful

    Marks the current slot as GOOD.

    set-active-boot-slot <slot>

    On next boot, loads and executes <slot>.

    set-slot-as-unbootable <slot>

    Marks <slot> as invalid.

    is-slot-bootable <slot>

    Returns 0 if <slot> is bootable.

    is-slot-marked-successful <slot>

    Returns 0 if <slot> is marked GOOD.

    get-suffix <slot>

    Prints the suffix for <slot>.

    is-autosync-enabled

    Prints enablement status of slot duplication. (It is enabled by default.)

    toggle-autosync

    Toggles enablement of slot duplication.

    dump-slots-info

    Prints information about the slots.

    <slot>` is the zero-based slot number.

The default setting for both slot 0 and slot 1 is “bootable,” with slot 0 having higher priority.

To show the current boot slot

  • Enter this command:

    # root@tegra-ubuntu:/home/nvidia# nvbootctrl get-current-slot

The command displays a single digit, 0 (slot A) or 1 (slot B).

To show the slot status

  • Before enabling rootfs redundancy, enter the command:

    # root@tegra-ubuntu:/home/nvidia# nvbootctrl dump-slots-info

    The command displays the status of the current boot slot:

    magic:0x43424e00, version: 3 features: 0 num_slots: 1
slot: 0, priority: 15, suffix: \_a, retry_count: 7, boot_successful: 1
slot: 1, priority: 0, suffix: , retry_count: 0, boot_successful: 0

  • After enabling rootfs redundancy. enter the command:

    # nvbootctrl dump-slots-info

    The command displays the status of the current boot slot:

    magic:0x43424e00, version: 3 features: 3 num_slots: 2
slot: 0, priority: 15, suffix: \_a, retry_count: 7, boot_successful: 1
slot: 1, priority: 14, suffix: \_b, retry_count: 7, boot_successful: 1

Sample Boot Log

The boot slot is selected by MB1. MB1 can produce a log that records the selection process. To produce the log, use a debug build of MB1 with messages enabled.

The following sample log shows that slot 1 (slot B) is selected as the boot slot:

[0000.040] I> Welcome to MB1-coldboot(dev-version : 14.00.170822-t186-M-00.00-96e265a3)
[0000.048] I> rst_source : 0xb
[0000.051] I> rst_level : 0x1
[0000.053] I> Read lock all AES keyslots
[0000.057] I> Read lock all RSA keyslots
[0000.061] I> Clear SE keyslots left open by BR
[0000.065] I> Last mts-fallback status: 0x00000000
[0000.070] I> Boot-device: eMMC
[0000.094] I> sdmmc ddr50 mode
[0000.098] I> A/B: bin_type (19) slot 0
[0000.102] I> Binary(19) of size 512 is loaded @ 0x40043400
[0000.108] I> Boot chain chosen: 1
[0000.111] I> Boot chain chosen: 1
[0000.114] I> magic:0x43424e00, version: 259, num_slots: 2
[0000.119] I> slot: 0, pri: 14, suffix: \_a, retry: 7, boot_succ: 1
[0000.125] I> slot: 1, pri: 15, suffix: \_b, retry: 6, boot_succ: 1
[0000.131] I> Loading MB1-BCT to SysRAM
[0000.135] I> A/B: bin_type (0) slot 1
[0000.138] I> Boot-device: eMMC
 . . .
 . . .
[0000.888] I> Welcome to MB2(TBoot-BPMP)(version: 01.00.160913-t186-M-00.00-mobile-09b4fbd4)
[0000.897] I> Default Heap @ [0xd486400 - 0xd488400]
[0000.901] I> DMA Heap @ [0x84a00000 - 0x85300000]
[0000.906] I> bit @ 0xd480000
[0000.909] I> BR-BCT relocated to 0xd7020000
[0000.913] I> Boot-device: eMMC
[0000.917] I> sdmmc bdev is already initialized
[0000.922] I> pmic: reset reason (nverc) : 0x0
[0000.926] I> Reading GPT from 512 for device 00000003
[0000.932] I> Reading GPT from 8388096 for device 00000003
[0000.939] I> Found 13 partitions in 00000003 device
[0000.944] I> Reading GPT from 512 for device 00010003
[0000.950] I> Found 27 partitions in 00010003 device
[0000.956] I> A/B: bin_type (16) slot 1
[0000.959] I> Loading partition bpmp-fw_b at 0xd7800000
[0000.964] I> Reading two headers - addr:0xd7800000 blocks:1
[0000.970] I> Addr: 0xd7800000, start-block: 58762425, num_blocks: 1
[0000.985] I> Binary(16) of size 528848 is loaded @ 0xd7800000
 . . .
 . . .

Generating the Bootloader Update Payload (BUP)

A Bootloader Update Payload (BUP) is used to implement Bootloader update. It contains firmware binaries of each type needed to update a Jetson device.

This section describes the procedure for generating a single-spec BUP, which contains just one binary of each type and can be used to update just one Jetson device configuration.

There is also a procedure for generating a multi-spec BUP, which includes multiple firmware binaries and BCT images of each type, and can be used to update any supported type of Jetson device. When you run the updater, it uses the appropriate binary of each type for the device you are updating. See the section To generate a multi-spec BUP, below, for information.

To generate a single-spec BUP

  • To create a BUP image to be stored in a file for a carrier board that is not connected to the host system:

    • For a Jetson AGX Orin carrier board:

    • For a Jetson Xavier NX carrier board with the indicated values of FAB, BOARDID, FUSELEVEL, and BOARDSKU:

      $ cd <top>
$ sudo FAB=100 BOARDID=3668 FUSELEVEL=fuselevel_production BOARDSKU=0001 ./build_l4t_bup.sh jetson-xavier-nx-devkit-emmc mmcblk0p1

    • For a Jetson AGX Xavier carrier board with the indicated values of FAB, BOARDID, and FUSELEVEL:

      $ cd <top>
$ sudo FAB=400 BOARDID=2888 FUSELEVEL=fuselevel_production BOARDSKU=0001 BOARDREV=H.0 ./build_l4t_bup.sh jetson-agx-xavier-devkit mmcblk0p1

  • To create a BUP image for a board that is connected to the host system:

    1. Place the target board into Force Recovery Mode.

    2. Enter the commands:

      $ cd <top>
$ sudo ./build_l4t_bup.sh <device> mmcblk0p1

    Where <device> is:

    • For Jetson AGX Orin: TBD

    • For Jetson Xavier NX series: jetson-xavier-nx-devkit-emmc

    • For Jetson AGX Xavier series: jetson-agx-xavier-devkit

  • To create the PKC signed BUP image for a carrier board connected to the host system:

    1. Place the target board into Force Recovery Mode.

    2. Enter the commands:

      $ cd <top>
$ sudo ./build_l4t_bup.sh -s <pkc_key_file> -u <pkc_key_file> <device> mmcblk0p1

      Where:

      • <top> is the location of the parent directory of the PDK installation package, in which flash.sh is stored.

      • <pkc_key_file> is the RSA private key file for your board. It must be located under <top>/bootloader directory or you must specify its absolute pathname.

      • <device> is:

        • For Jetson AGX Orin series: TBD

        • For Jetson Xavier NX series: jetson-xavier-nx-devkit-emmc

        • For Jetson AGX Xavier series: jetson-agx-xavier-devkit

To generate a multi-spec BUP

  • Enter the commands:

    $ cd <top>
$ sudo ./l4t_generate_soc_bup.sh [-u <pkc_key_file>] [-p <options>] [-d] t19x

    Where:

    • <top> is the pathname of the directory that contains the PDK installation package. flash.sh 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>/bootloader/ directory.

    • <options> is a string of command line options to be passed to flash.sh to generate the BUP. If the string contains whitespace characters, it must be enclosed in quotes.

    • -d causes the script to run in debug mode, which keeps all boot firmware blob images in bootloader/signed and bootloader/multi-signed.

Location of Generated BUP Files

Both procedures store the generated BUP(s) in the director(ies):

  • For Jetson Xavier NX series and Jetson AGX Xavier series: <top>/bootloader/payloads_t19x