Jetson Orin Nano Developer board: UEFI update: Self or from Host PC

Jetson Orin Nano Developer board and installed a 256G SSD on it. I already used JetPack 6.0 on a X86 host machine to flash these boards. All boards booted up with Ubuntu 22.04.
I installed ‘EdkRepo v3.2.2’ on the host PC.

I am trying to understand how to update UEFI image only. I am reading the ‘Bootloader’ section on Developer Guide. Here are my understandings:

  1. All UEFI related source code are under ‘edkrepo/nvidia-uefi’.

  2. I used ‘Build-without-docker’ to build the UEFI images and saw ‘uefi_Jetson_DEBUG.bin’ and ‘uefi_Jetson_RELEASE.bin’ under ‘images’ subdirectory.

  3. I need to copy one of the above uefi_Jetson_*.bin’ file to overwrite the ‘nvidia_sdk/…/Linux_for_Tegra/bootloader/uefi_jetson.bin’.

  4. If I want to update the UEFI from host PC, I need to put the target board (Orin Nano) in Recovery mode. Then, run
    $sudo ./flash.sh jetson-orin-nano-devkit nvme0n1
    from ‘Linux_for_Tegra’ subdirecotry on Host PC. Then, it will update the bootloader on ‘not-current’ slot and boot from it the next reboot.

Am I right here?

I am also trying to understand what this section: Update and Redundancy — NVIDIA Jetson Linux Developer Guide 1 documentation
is for.
To my understanding, this is for updating the UEFI (or bootloader) on the target itself.
Like the followings:

  1. After the above step 3, generate Capsule Payload on the Host PC.
  2. Copy the Capsule payload to the target system.
  3. Run necessary steps to update the UEFI (bootloader) without Host PC involvement.

Do I understand here?

Thanks,

Steven

Hi stevenc,

Are you using JP6.0DP or JP6.0GA?
Please share the result of the following command on your board.

$ cat /etc/nv_tegra_release

Please use a x86 host PC and refer to the sources and steps in Build with docker · NVIDIA/edk2-nvidia Wiki · GitHub to build UEFI binary.

After you replace the uefi_jetson.bin in the BSP package, you can run the following command to update it independantly.

$ sudo ./flash.sh -k A_cpu-bootloader -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit nvme0n1p1

Hi,
Thanks for the reply.

  1. For JP6.0DP or JP6.0GA? I ran the command on the target machine:
    ~$ cat /etc/nv_tegra_release

R36 (release), REVISION: 2.0, GCID: 35084178, BOARD: generic, EABI: aarch64, DATE: Tue Dec 19 05:55:03 UTC 2023

KERNEL_VARIANT: oot

TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

  1. For update UEFI only,
    $ sudo ./flash.sh -k A_cpu-bootloader -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit nvme0n1p1

To my understanding, the above command will update the UEFI on Slot A. If slot A is the current slot (booting one), can I still do it?

In other words, should I update the non-boot slot?

  1. Can I update the UEFI without Host PC? I need a way to update the product on the field.
    To my understanding, this section is for it:
    Update and Redundancy — NVIDIA Jetson Linux Developer Guide 1 documentation

Am I correct?

Thanks,

Steven

It would be fine since you should enter into force recovery mode for your Jetson device before running that command from host. It will still boot from the same slot before update.

It depends on your use case. If you always work on the current slot, then you don’t need to update for un-used slot. If you have the chance to switch slot and you want to have the same state as the original slot, then you should update both of them.

Yes, please perform capsule update for this use case.

Hi,
Thanks for the reply. Last question (just curious), if

  1. I do not specify the slot number, like the following command
    $ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit nvme0n1p1

Which slot will be flashed?

  1. I don’t specify configuration file either, like the following:
    $ sudo ./flash.sh jetson-orin-nano-devkit nvme0n1p1

What will happen?

Thanks,

Steven

Both slots. For the flash, it will create and flash every partitions according to your partition layout XML.

It is not the expected command to be used.
Then it may not find the correct XML for QSPI.