UEFI Boot Order not preserved after JetPack 5 -> 6 upgrade with httpv4

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

I’ve configured a Orin AGX to boot via httpv4 boot method and running Jetpack 5. I tried to perform a capsule update on it to upgrade it to Jetpack 6 and after the upgrade, I noticed that it prefers to drop into UEFI Shell before http boot.

After some digging into the edk2 code, I believe this is because the ethernet base memory address changed from 0x6810000 → 0x6800000, so UEFI boot (EfiBootManagerRefreshAllBootOption) deletes the “stale” option and inserts the “new” one at the back of the boot order behind local disk and UEFI shell.

How can I be sure that the preferred boot order is preserved during a capsule update?

3

Hi eberman,

As my understanding, you should perform image-based OTA rather than capsule update or you will get version mis-match can cause boot failed.

Boot-order is stored in UEFI variable and there’s a partition in QSPI.

4

Hi Kevin, thanks for the quick reply!

I don’t see example for the HTTPv4 boot flow in the image-based OTA, so I have adapted the scripts there for my httpv4 boot flow. I’m able to ensure that kernel/userspace versions match after the capsule update. I see that image-based OTA scripts also do capsule update for the bootloader.

With respect to UEFI boot order, does image-based OTA do additional steps compared to only a capsule update?

5

Correct, capsule update is part of image-based OTA upate.

For image-based OTA update, it will also update rootfs.

If you’ve confirmed the bootloader, kernel, rootfs are all from same release, there may be no boot issue.

6

I can confirm bootloader, kernel, and rootfs are from same release. I’m observing the boot issue.

I’ve dug into the edk2 sources and I’m confident that the issue is within EfiBootManagerRefreshAllBootOption() function. It looks for stale boot options, removes them, and then adds new boot options. I haven’t found any logic that is aware to preserve the boot order for changed base address of ethernet port. My workaround is to patch SetBootOrder() in edk2-nvidia/Silicon/NVIDIA/Library/PlatformBootOrderLib/PlatformBootOrderLib.c by removing the PlatformBootOrderSet variable and thus always apply the default boot priority. I’m curious if this is a known issue and there is a better solution/approach.

7

Boot-order should be stored in efi variable, and you can simply run the following command to check.

$ sudo efibootmgr

Please share the full serial console log when you hit the boot issue.

8

I’m not able to upload such a large file. I think these are the relevant snippets:

Before capsule update:

Jetson UEFI firmware (version 35.6.1 built on 1980-01-01T00:00:00+00:00)
ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.
Failed to find memory test protocol
HandleCapsules: processing capsules ...
BootChainExecuteUpdate: Active boot chain=0
BCGetVariable: Read BootChainFwNext=255: Not Found
BCGetVariable: Read AutoUpdateBrBct=1: Success
BootChainExecuteUpdate: Booting OS, FW BootChain=0, Status=-1
**********************************
**  WARNING: Test Key is used.  **
**********************************
**  WARNING: Test Key is used.  **
[Bds]OsIndication: 0000000000000000
[Bds]=============Begin Load Options Dumping ...=============
  Driver Options:
  SysPrep Options:
  Boot Options:
    Boot0005: UEFI HTTPv4 (MAC:48B02D78926E) 		 0x0001
    Boot0006: UEFI HTTPv6 (MAC:48B02D78926E) 		 0x0001
    Boot0003: UEFI PXEv4 (MAC:48B02D78926E) 		 0x0001
    Boot0004: UEFI PXEv6 (MAC:48B02D78926E) 		 0x0001
    Boot0001: UEFI Samsung SSD 970 EVO Plus 1TB S6S1NS0W314378B 1 		 0x0001
    Boot0002: UEFI eMMC Device 		 0x0001
    Boot0000: Enter Setup 		 0x0109
    Boot0007: BootManagerMenuApp 		 0x0109
    Boot0008: UEFI Shell 		 0x0001
  PlatformRecovery Options:
    PlatformRecovery0000: Default PlatformRecovery 		 0x0001
[Bds]=============End Load Options Dumping=============

After capsule update:

Jetson System firmware version 36.4.3 date 1980-01-01T00:00:00+00:00
ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.
Failed to find memory test protocol
HandleCapsules: processing capsules ...
HandleSavedCapsules: no protocol: Not Found
BootChainExecuteUpdate: Active boot chain=1
BCGetVariable: Read BootChainFwNext=255: Not Found
BCGetVariable: Read AutoUpdateBrBct=1: Success
BootChainExecuteUpdate: Booting OS, FW BootChain=1, Status=4294967295
[Bds]OsIndication: 0000000000000000
[Bds]=============Begin Load Options Dumping ...=============
  Driver Options:
  SysPrep Options:
  Boot Options:
    Boot0001: UEFI Samsung SSD 970 EVO Plus 1TB S6S1NS0W314378B 1 		 0x0001
    Boot0002: UEFI eMMC Device 		 0x0001
    Boot0000: Enter Setup 		 0x0109
    Boot0007: BootManagerMenuApp 		 0x0109
    Boot0008: UEFI Shell 		 0x0001
    Boot0003: UEFI PXEv4 (MAC:48B02D78926E) 		 0x0001
    Boot0004: UEFI PXEv6 (MAC:48B02D78926E) 		 0x0001
    Boot0005: UEFI HTTPv4 (MAC:48B02D78926E) 		 0x0001
    Boot0006: UEFI HTTPv6 (MAC:48B02D78926E) 		 0x0001
  PlatformRecovery Options:
    PlatformRecovery0000: Default PlatformRecovery 		 0x0001
[Bds]=============End Load Options Dumping=============

Separately, I’d added some prints into the edk2 source and I see that it is taking this function to delete the PXE/HTTP options:

EfiBootManagerFindLoadOption:557 OptionType(2 == 2) Attributes(1 == 1) Description(UEFI HTTPv4 (MAC:48B02D78926E) == UEFI HTTPv4 (MAC:48B02D78926E)) FilePath (VenHw(1E5A432C-0466-4D31-B009-D4D9239271D3)/MemoryMapped(0xB,0x6810000,0x681FFFF)/MAC(48B02D78926E,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri() == VenHw(1E5A432C-0466-4D31-B009-D4D9239271D3)/MemoryMapped(0xB,0x6800000,0x680FFFF)/MAC(48B02D78926E,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri()) OptionalDataSize(16 == 16)

The key difference here is that: MemoryMapped(0xB,0x6810000,0x681FFFF) != MemoryMapped(0xB,0x6800000,0x680FFFF).

EfiBootManagerFindLoadOption is called from:

This explained to me why the option was deleted.

It is later added few lines below:

“-1” indicates end of list. I have not found any code later which should attempt to resort the boot options.

9

Please run this command before and after you performed capsule update.

Have you tried to configure the new added boot device to the top instead of bottom for current use case?

11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.