UEFI behaviour differs between nv_bootloader_capsule_updater.sh and flash.sh

Hello, NVIDIA representative.

I have a question regarding UEFI updates.

There is a difference in the UART logs between when I update UEFI using nv_bootloader_capsule_update.sh and when I write UEFI to Orin NX using flash.sh.

A: When written using flash.sh

PrintBootOrder: Current BootOrder:
PrintBootOrder: BootOrder[0] = 0x0001 = UEFI TS128GMTE470A H701050010 1
PrintBootOrder: BootOrder[1] = 0x0000 = Enter Setup
PrintBootOrder: BootOrder[2] = 0x0002 = BootManagerMenuApp
PrintBootOrder: BootOrder[3] = 0x0003 = UEFI Shell
Jetson System firmware version 202402.1-81336553-dirty date 2024-10-24T08:06:32+
00:00

A_flash.log (130.3 KB)

B: When updated using nv_bootloader_capsule_update.sh

PrintBootOrder: Current BootOrder:
PrintBootOrder: BootOrder[0] = 0x0001 = UEFI TS128GMTE470A H701050010 1
PrintBootOrder: BootOrder[1] = 0x0000 = Enter Setup
PrintBootOrder: BootOrder[2] = 0x0006 = BootManagerMenuApp
PrintBootOrder: BootOrder[3] = 0x0007 = UEFI Shell
Jetson System firmware version 202402.1-81336553-dirty date 2024-10-24T08:06:32+
00:00

B_nv_bootloader_capsule_updater.log (85.8 KB)

When comparing the logs of A and B, it seems that in case B, the system retains information from before the update while it operates.

I would like the system to behave the same way when using both flash.sh and nv_bootloader_capsule_update.sh.
Could you provide some advice on this?
Additionally, could you explain why this difference occurs?

Enviroment

OS : Jetson Linux 36.3

UEFI

Hi yyamamoto,

Are you using the devkit or custom board for Orin NX?
Could you also verify with the latest JP6.1(R36.4.0)?

It seems you use the exact same custom build UEFI binary in both methods.

Jetson System firmware version 202402.1-81336553-dirty date 2024-10-24T08:06:32+

Is you issue about the bootorder getting changed?
Could you also share the result of the following command in both cases after boot up?

$ sudo efibootmgr 

Hi KevinFFF

Thank you comment.
I am using devkit(OrinNano devkit with OrinNX 8GB SOM) .
The bootloader confirmed by this behaviour is the one I have changed, as described in my top comment.
My change is only this.

edk2-nvidia/Platform/NVIDIA/Kconfig
Kconfig.zip (4.8 KB)

I am developing a product with version 36.3 and would like to see a solution in version 36.3.

I haven’t checked it works with Jetpack 6.1, so I’m going to create an environment to check it .

update efibootmgr log.

A_flash.txt (182 Bytes)
B_ nv_bootloader_capsule_update.txt (182 Bytes)

The following behavior was also tested for experimentation and resulted in strange outcomes. Two types of TEGRA_BL.Cap were prepared for operational checks:

‘TEGRA_BL_before.Cap’: UEFI before the update.(r36.3 Jetpack 6.0)
‘TEGRA_BL_after.Cap’: UEFI after the update. ( Disable network, logo, and shell )
From the previous state B, the following command was executed:

nv_bootloader_capsule_updater.sh -q TEGRA_BL_before.Cap

Initially, BootOrder[0] was ‘UEFI TS128GMTE672A I391380787 1’, but it changed to ‘UEFI HTTPv6 (MAC:48B02DD8CC39)’.

PrintBootOrder: Current BootOrder:
PrintBootOrder: BootOrder[0] = 0x0005 = UEFI HTTPv6 (MAC:48B02DD8CC39)
PrintBootOrder: BootOrder[1] = 0x0004 = UEFI HTTPv4 (MAC:48B02DD8CC39)
PrintBootOrder: BootOrder[2] = 0x0003 = UEFI PXEv6 (MAC:48B02DD8CC39)
PrintBootOrder: BootOrder[3] = 0x0002 = UEFI PXEv4 (MAC:48B02DD8CC39)
PrintBootOrder: BootOrder[4] = 0x0001 = UEFI TS128GMTE672A I391380787 1
PrintBootOrder: BootOrder[5] = 0x0000 = Enter Setup
PrintBootOrder: BootOrder[6] = 0x0006 = BootManagerMenuApp
PrintBootOrder: BootOrder[7] = 0x0007 = UEFI Shell
Jetson System firmware version 202402.1-81336553 date 2024-10-24T07:47:49+00:00

What does this mean?

I performed the following sequence:
“UEFI before the update” → “UEFI after the update” → “UEFI before the update”,
it won’t revert.

Hello @KevinFFF

I tried it with R36.4, and the results were the same as with R36.3; the behavior differed between flash.sh and nv_bootloader_capsule_updater.sh.

Additionally, I conducted an experiment to verify if the UEFI firmware binary was updated as intended. I added a log statement, Print (L"L4T new image.\r\n");, to the ProcessExtLinuxConfig function in edk2-nvidia/Silicon/NVIDIA/Application/L4TLauncher/L4TLauncher.c and performed the same tests.
L4TLauncher.zip (14.2 KB)

As a result, “L4T new image.” was displayed when using flash.sh, but it did not appear when using nv_bootloader_capsule_updater.sh. This means the update was not successful.

This is a significant issue because it implies that even if there is a bug in the UEFI, it cannot be updated.
For example, it would not be possible to upgrade the bootloader from Jetpack 6 to Jetpack 6.4 (which is expected to be released in the future).

Log when updating the UEFI with flash.sh

PrintBootOrder: Current BootOrder:
PrintBootOrder: BootOrder[0] = 0x0001 = UEFI TS128GMTE672A I391380787 1
PrintBootOrder: BootOrder[1] = 0x0000 = Enter Setup
PrintBootOrder: BootOrder[2] = 0x0002 = BootManagerMenuApp
PrintBootOrder: BootOrder[3] = 0x0003 = UEFI Shell
Jetson System firmware version r36.4.0-5de7ef09-dirty date 2024-10-25T14:09:33+0
0:00
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
Failed to find memory test protocol
!!! enter DisableFRB2Handler()!!!
GetParentPcieControllerPrivate: cannot retrieve device path protocol from device handle: Unsupported
[Bds]Booting UEFI TS128GMTE672A I391380787 1
add-symbol-file /work/nvidia-uefi/Build/Jetson/DEBUG_GCC5/AARCH64/Silicon/NVIDIA/Application/L4TLauncher/L4TLauncher/DEBUG/L4TLauncher.dll 0x2601E4000
Loading driver at 0x002601E3000 EntryPoint=0x002601EB72C L4TLauncher.efi

L4TLauncher: Attempting Direct Boot
L4T new image.
Loading driver at 0x0025D530000 EntryPoint=0x0025F352A18
Loading driver at 0x0025D530000 EntryPoint=0x0025F352A18
root=PARTUUID=c5b0175c-8055-4075-a521-b7adf5242f8d rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=tty0 bl_prof_dataptr=2031616@0x271E10000 bl_prof_ro_ptr=65536@0x271E00000 ExtLinuxBoot: Cmdline:

r36.4_flash_log.txt (51.8 KB)

Log when updating the UEFI with nv_bootloader_capsule_updater.sh

PrintBootOrder: Current BootOrder:
PrintBootOrder: BootOrder[0] = 0x0001 = UEFI TS128GMTE672A I391380787 1
PrintBootOrder: BootOrder[1] = 0x0000 = Enter Setup
PrintBootOrder: BootOrder[2] = 0x0006 = BootManagerMenuApp
PrintBootOrder: BootOrder[3] = 0x0007 = UEFI Shell
Jetson System firmware version r36.4.0-5de7ef09-dirty date 2024-10-25T14:09:33+0
0:00
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
Failed to find memory test protocol
!!! enter DisableFRB2Handler()!!!
GetParentPcieControllerPrivate: cannot retrieve device path protocol from device handle: Unsupported
[Bds]Booting UEFI TS128GMTE672A I391380787 1
add-symbol-file /work/nvidia-uefi/Build/Jetson/DEBUG_GCC5/AARCH64/Silicon/NVIDIA/Application/L4TLauncher/L4TLauncher/DEBUG/L4TLauncher.dll 0x2601E4000
Loading driver at 0x002601E3000 EntryPoint=0x002601EB72C L4TLauncher.efi

L4TLauncher: Attempting Direct Boot
Loading driver at 0x0025D530000 EntryPoint=0x0025F352A18
Loading driver at 0x0025D530000 EntryPoint=0x0025F352A18
root=PARTUUID=33284479-79a2-4f56-9a32-5b678291a334 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=tty0 bl_prof_dataptr=2031616@0x271E10000 bl_prof_ro_ptr=65536@0x271E00000 ExtLinuxBoot: Cmdline:

r36.4_swup_log.txt (51.1 KB)

Please share the detailed steps and related logs how you create the capsule payload and perform capsule update.
And I would like to check the serial console log when you run sudo reboot to trigger update process.

Hello @KevinFFF

sorry late response.

I got my control log. Please check this.

log.zip (41.1 KB)

  • hostpclog.txt : Operation log on host PC until flash Software to Devkit.
  • devkit_terminallog.txt : Logs on devkit and after updates
  • seriallog.txt : serial log

uefi.zip (1.7 KB)
UEFI build enviroment

May I know why you used p3768-0000-p3767-0000-a0-nvme as board config?

From your serial console log, it seems you can boot the board as expected.

Are you trying to performing capsule update on the board itself or use initrd flash script to flash the board from host directly?

Could you help to state your current issue again?

Hello, @KevinFFF

May I know why you used p3768-0000-p3767-0000-a0-nvme as board config?

I do not understand the intent of this question, but my usage environment is as follows

  • I replaced the OrinNano in the Jetson Orin Nano Developer Kit with the OrinNX 8GB model.
  • I connected a 128GB SSD NVMe to the M.2 slot on the back of the Developer Kit and wrote Jetson Linux into that SSD to operate it.

With this config, the writing of Jetson Linux was successful, and I believe there are no issues with its operation.

From your serial console log, it seems you can boot the board as expected.
Are you trying to perform a capsule update on the board itself or use the initrd flash script to flash the board from the host directly?

I executed the capsule update by booting the Jetson Orin Nano Developer Kit, connecting a monitor via DisplayPort, and running the terminal on the Ubuntu GUI displayed on the monitor. The operation log is in devkit_terminallog.txt.

Could you help to state your current issue again?

My issue is that when updating UEFI with a capsule update, it may not be updated correctly. I conducted an operation experiment using a modified L4TLauncher(source code is in uefi.zip) within UEFI and concluded that the L4TLauncher within UEFI is not updated with the capsule update.

  • When updating UEFI with a capsule update, the log “L4T new image.” does not appear, and my modified UEFI L4TLauncher does not run.
  • When writing UEFI using flash.sh, the log “L4T new image.” appears, indicating that my modified UEFI L4TLauncher is running.

The log related to my issue is in this post.