Nvidia-l4t-jetson-orin-nano-qspi-updater Debian

[matt.read]

I have downloaded and unpacked the nvidia-l4t-jetson-orin-nano-qspi-updater_36.4.4-20250616085344_arm64.deb Debian. I am trying to find out how this QSPI update mechanism works.

I can see that after checking the prerequisite it eventually calls the bootloader_updater.sh script with the capsule update payload that gets put in nvme0n1p11 in /boot/efi/EFI/UpdateCapsule/jetson-orin-nano-devkit.Cap

My fist question is: What is in the capsule payload (jetson-orin-nano-devkit.Cap), is it just the exact bytes that are to be loaded onto the QSPI. Is it the same as the UEFI bin in Linux_for_Tegra/bootloader/uefi_jetson.bin in the BSP

My second question is: Is there a way to generate my own .Cap raw binary blob file?

My Final question is why do we set bit 2 of the OsIndications UEFI variable:

Any help would be greatly appreciated

Many thanks,
Matt

[carolyuu]

*** Please note that this reply is generated by LLM automatically ***

I’d be happy to help you understand the QSPI update mechanism and answer your questions.

Overview of the QSPI Update Mechanism

The QSPI update mechanism is used to update the bootloader on NVIDIA Jetson modules, including the Jetson Orin Nano. The update process involves downloading and unpacking a Debian package (e.g., nvidial4t-jetson-orin-nano-qspi-updater_364.42.0-2.5.0.16.085344_arm64.deb) that contains the necessary tools and payloads for the update.

What is in the Capsule Payload (jetson-orin-nano-devkit.cap)?

The capsule payload is a binary blob that contains the updated bootloader image and other metadata required for the update process. The payload is generated using the Bootloader Update Payload Generator tool, which is part of the Bootloader Tools.

The capsule payload is not just the exact bytes that are to be loaded onto the QSPI flash. Instead, it contains a structured format that includes:

1. A header with metadata, such as the update type (e.g., bootloader update) and the target device (e.g., Jetson Orin Nano).
2. The updated bootloader image, which is compressed and encrypted.
3. A digital signature to ensure the authenticity and integrity of the update.

Generating Your Own Cap Raw Binary Blob File

Yes, you can generate your own cap raw binary blob file using the Bootloader Update Payload Generator tool. This tool takes the updated bootloader image and other metadata as input and generates the capsule payload.

To generate a custom capsule payload, you will need to:

1. Obtain the updated bootloader image (e.g., from NVIDIA or by building it yourself).
2. Create a configuration file that specifies the update metadata (e.g., update type, target device).
3. Use the Bootloader Update Payload Generator tool to generate the capsule payload.

Why Set Bit 2 of the OsIndications UEFI Variable?

The OsIndications UEFI variable is used to indicate the operating system’s capabilities and requirements to the firmware. In this case, setting bit 2 of the OsIndications variable is used to indicate that the operating system supports capsule updates.

By setting this bit, the firmware is informed that the operating system can handle capsule updates, which allows the update process to proceed. This is a requirement for the QSPI update mechanism to work correctly.

In summary, the capsule payload is a structured binary blob that contains the updated bootloader image and metadata. You can generate your own cap raw binary blob file using the Bootloader Update Payload Generator tool. Setting bit 2 of the OsIndications UEFI variable is necessary to indicate that the operating system supports capsule updates.

I hope this helps clarify the QSPI update mechanism and answers your questions!

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

[matt.read]

Ok I have found the Update tool from the
Update and Redundancy — NVIDIA Jetson Linux Developer Guide
and I have done the Manually Trigger the Capsule Update:

The following is done on the host machine.

NVIDIA’s L4T scripts assume python exists so install a system-wide symlink:

sudo apt install python-is-python3

Download the R36.4.0 BSP:

sudo wget https://developer.nvidia.com/downloads/embedded/l4t/r36_release_v4.0/release/Jetson_Linux_R36.4.0_aarch64.tbz2

Untar it:

sudo tar xvf Jetson_Linux_R36.4.0_aarch64.tbz2
cd Linux_for_Tegra

Generate bootloader and kernel multi-specification BUP:

sudo ./l4t_generate_soc_bup.sh -e t23x_3767_bl_spec t23x

t23x payload generation complete with 0 failure(s)

Add the 3 FMP capsule image header to the BUP payload:

sudo ./generate_capsule/l4t_generate_soc_capsule.sh -i bootloader/payloads_t23x/bl_only_payload -o ./jetson-orin-nano-devkit.Cap t234

SCP the generated capsule payload to the target file system:

sudo scp ~/nvidia/nvidia_sdk/Linux_for_Tegra/jetson-orin-nano-devkit.Cap user@192.168.1.100:/home/user

The following is now done on the jetson-orin-nano-devkit:

Move the capsule payload into nvme0n1p11 (it is currently mounted as /boot/efi):

sudo mv /home/user/jetson-orin-nano-devkit.Cap /boot/efi/EFI/UpdateCapsule/jetson-orin-nano-devkit.Cap

Initialize the OsIndications UEFI variable:

cd /sys/firmware/efi/efivars/

printf "\x07\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00" > /tmp/var_tmp.bin

sudo dd if=/tmp/var_tmp.bin of=OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c bs=12;sync

Reboot the system:

sudo reboot

After reboot I check the Capsule update status from the nvbootctrl command:

sudo nvbootctrl dump-slots-info

I get 0 indicating No Capsule update happened. I have also tried the fwupdtool Method to Trigger the Capsule Update and I get the same results.

Please can anyone advise,

Thanks

[KevinFFF]

Hi matt.read,

Are you using the devkit or custom board for Orin Nano?
What’s your requirement and use case? to update bootloader?

@matt.read

Is it the same as the UEFI bin in Linux_for_Tegra/bootloader/uefi_jetson.bin in the BSP

No, UEFI binary is just inside A_cpu-bootloader/B_cpu-bootloader partitions.
There’re other partitions for bootloader will be updated.

Can you refer to the following steps which have been verified from us?

[Host: Ubuntu]
$ sudo ./l4t_generate_soc_bup.sh -e t23x_3767_bl_spec t23x
$ ./generate_capsule/l4t_generate_soc_capsule.sh -i bootloader/payloads_t23x/bl_only_payload -o ./TEGRA_BL.Cap t234
$ scp TEGRA_BL.Cap <username>@<IP address>:~/

[Target: Orin Nano devkit]
$ ll /dev/disk/by-partlabel/esp
lrwxrwxrwx 1 root root 16 Sep 18 02:40 /dev/disk/by-partlabel/esp -> ../../nvme0n1p10
$ sudo mount /dev/nvme0n1p10 /mnt/
$ sudo su
# mkdir -p /mnt/EFI/UpdateCapsule
# cp /home/<username>/TEGRA_BL.Cap /mnt/EFI/UpdateCapsule/TEGRA_BL.Cap

# cd /sys/firmware/efi/efivars/
# printf "\x07\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00" > /tmp/var_tmp.bin
# dd if=/tmp/var_tmp.bin of=OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c bs=12;sync
# reboot

[matt.read]

Hi @KevinFFF

Thanks for your help, Yes im on the Orin Nano (8G) devkit on the JP6.1 BSP. I will try the steps you gave me and will get back to you

[matt.read]

@KevinFFF

dd if=/tmp/var_tmp.bin of=OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c bs=12;sync

Hi @KevinFFF,

The steps are very similar to my steps above. I have run through you steps and here are my results:

[Host: Ubuntu] $ sudo ./l4t_generate_soc_bup.sh -e t23x_3767_bl_spec t23x 
$ ./generate_capsule/l4t_generate_soc_capsule.sh -i bootloader/payloads_t23x/bl_only_payload -o ./TEGRA_BL.Cap t234 

$ scp TEGRA_BL.Cap <username>@<IP address>:~/

This all worked here are the outputs from l4t_generate_soc_bup.sh and l4t_generate_soc_capsule.sh

l4t_generate_soc_bup_output.txt (460.1 KB)

l4t_generate_soc_capsule_output.txt (2.9 KB)

[Target: Orin Nano devkit] 
$ ll /dev/disk/by-partlabel/esp lrwxrwxrwx 1 root root 16 Sep 18 02:40 /dev/disk/by-partlabel/esp -> ../../nvme0n1p10

$ sudo mount /dev/nvme0n1p10 /mnt/ 
$ sudo su
$ mkdir -p /mnt/EFI/UpdateCapsule 
$ cp /home/<username>/TEGRA_BL.Cap /mnt/EFI/UpdateCapsule/TEGRA_BL.Cap  
$ cd /sys/firmware/efi/efivars/ 
$ printf "\x07\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00" > /tmp/var_tmp.bin 
$ dd if=/tmp/var_tmp.bin of=OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c bs=12;sync # reboot

Here are my results:
I Have AB booting so 2 rootfs’s so my /boot/efi is on p11 and not p10:

Here is the rest of the commands you sent:

After a reboot it still didn’t update:

[KevinFFF]

@matt.read

After a reboot it still didn’t update:

Please share the full serial console log after you run reboot.

[matt.read]

@matt.read

dd if=/tmp/var_tmp.bin of=OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c bs=12;sync

Hi @KevinFFF

here is my boot log:

UartSerialBoot.log (85.9 KB)

[KevinFFF]

@matt.read

l4t_generate_soc_bup_output.txt (460.1 KB)

l4t_generate_soc_capsule_output.txt (2.9 KB)

You logs here look good to me to create the capsule payload.

@matt.read

UartSerialBoot.log (85.9 KB)

In this log, I see it just shutdown(w/o performing capsule update process) with unknown reason as following.

Jetson System firmware version 36.4.0-gcid-37537400 date 2024-09-13T04:02:39+00:
00
ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.
â–’â–’â–’â–’Shutdown state requested 1
Rebooting system ...
â–’â–’
[0000.063] I> MB1 (version: 1.4.0.4-t234-54845784-e89ea9bc)

We can not reproduce the similar issue on the devkit.
Do you have other customization in your case?
Could you also use debug UEFI binary to flash and verify again? It could help to output more logs and debug further.