Orin nano mass flash, set BootOrderNvme

[nox.gias]

Hello everyone,

I have a problem what after mass flashing device still trying to check network boot, so people have to manually change settings in boot manager, which is a big problem during mass flashing

Mass flash process:
Step 1, create backup from device with project

./tools/backup_restore/l4t_backup_restore.sh -b -c p3509-a02+p3767-0000

Step 2, create tarball

./tools/kernel_flash/l4t_initrd_flash.sh --use-backup-image --no-flash --network usb0 --massflash 10 p3509-a02+p3767-0000 nvme0n1p1

Step 3, mass flash

./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --massflash 10 --network usb0

I have custom carrier board from seed, device have only nvme inside, so scripts inside backup_restore folder was modified in order to work with nvme

Attempt 1
Remove all others options from bios via boot manager, make full backup restore process again, didnt work

Attempt 2
Make backup restore process with env variable

export ADDITIONAL_DTB_OVERLAY_OPT=BootOrderNvme.dtbo

Didnt work either

Full flashing log attached
flash_5-1.1_0_20240215-141731.log (22.7 KB)

[DaveYYY]

Hi,

First of all, we don’t currently support the workflow of generating massflash packages from images backed up from NVMe/USB drives. I don’t believe the three steps you are trying will work.
Second,

@nox.gias

export ADDITIONAL_DTB_OVERLAY_OPT=BootOrderNvme.dtbo

this option will only work for the first time after the device is re-flashed with a clean BSP, not backup, and UEFI will still scan for all booting options each time the device is booting up.
Therefore, if you want to prevent devices from getting stuck in network boot, please consider the following way to completely disable it in UEFI:

Jetson AGX Orin Long Boot Time

[2023-10-03 13:20:23] SNP:PHY: PhyDxeInitialization () Failed to reset Phy [2023-10-03 13:20:23] DeviceDiscoveryBindingStart, driver returned Device Error to start notification It seems still doing the initialization for phy. Could you try to remove the network stack in the following 2 configuration files? https://github.com/NVIDIA/edk2-nvidia/blob/main/Platform/NVIDIA/NVIDIA.common.dsc.inc https://github.com/NVIDIA/edk2-nvidia/blob/main/Platform/NVIDIA/NVIDIA.fvmain.fdf.inc

[nox.gias]

Hi Dave,

@DaveYYY

First of all, we don’t currently support the workflow of generating massflash packages from images backed up from NVMe/USB drives. I don’t believe the three steps you are trying will work.

You helped me to make this happen in this thread
https://forums.developer.nvidia.com/t/backup-restore-workflow-3-massflash-jetson-orin-nano-problem

I followed instructions from rebuild UEFI thread, I removed network stack and compilation was successful

INFO - ------------------------------------------------
INFO - --------------Cmd Output Finished---------------
INFO - --------- Running Time (mm:ss): 01:56 ----------
INFO - ----------- Return Code: 0x00000000 ------------
INFO - ------------------------------------------------
PROGRESS - Running Post Build
INFO - Generating uefi image nvidia-uefi/images/uefi_Jetson_RELEASE.bin
INFO - Copying boot app nvidia-uefi/images/BOOTAA64_Jetson_RELEASE.efi
INFO - Copying DTB images/BootOrderNvme_Jetson_RELEASE.dtbo
INFO - Copying DTB images/AcpiBoot_Jetson_RELEASE.dtbo
INFO - Copying DTB images/BootOrderEmmc_Jetson_RELEASE.dtbo
INFO - Copying DTB images/BootOrderSata_Jetson_RELEASE.dtbo
INFO - Copying DTB images/BootOrderUfs_Jetson_RELEASE.dtbo
INFO - Copying DTB images/BootOrderPxe_Jetson_RELEASE.dtbo
INFO - Copying DTB images/BootOrderUsb_Jetson_RELEASE.dtbo
INFO - Copying DTB images/BootOrderHttp_Jetson_RELEASE.dtbo
INFO - Copying DTB images/L4TConfiguration_Jetson_RELEASE.dtbo
INFO - Copying DTB images/DgpuDtEfifbSupport_Jetson_RELEASE.dtbo
DEBUG - Plugin Success: Linux GCC5 Tool Chain Support
INFO - Writing BuildToolsReports to nvidia-uefi/Build/Jetson/RELEASE_GCC5/BUILD_TOOLS_REPORT
DEBUG - Plugin Success: Build Tools Report Generator
PROGRESS - End time: 2024-02-19 09:27:51.998829	 Total time Elapsed: 0:01:57
SECTION - Log file is located at: nvidia-uefi/Build/BUILDLOG_Jetson.txt
SECTION - Summary
PROGRESS - Success

I got uefi_Jetson_RELEASE.bin at the end and replaced it inside my “mfi*” folder, but it didnt make any effect, as I understand its using encrypted version uefi_jetson_with_dtb_sigheader.bin.encrypt

# less bootloader/flashcmd.txt

./tegraflash.py 
--bl uefi_jetson_with_dtb_sigheader.bin.encrypt 
--bct br_bct_BR.bct 
--securedev  
--bldtb tegra234-p3767-0003-p3509-a02.dtb 
--applet rcm_2_encrypt.rcm 
--applet_softfuse rcm_1_encrypt.rcm 
--cmd "rcmboot"  
--cfg secureflash.xml 
--chip 0x23 
--mb1_bct mb1_bct_MB1_sigheader.bct.encrypt 
--mem_bct mem_rcm_sigheader.bct.encrypt 
--mb1_cold_boot_bct mb1_cold_boot_bct_MB1_sigheader.bct.encrypt 
--mb1_bin mb1_t234_prod_aligned_sigheader.bin.encrypt 
--psc_bl1_bin psc_bl1_t234_prod_aligned_sigheader.bin.encrypt 
--mem_bct_cold_boot mem_coldboot_sigheader.bct.encrypt  
--bins "psc_fw pscfw_t234_prod_sigheader.bin.encrypt; mts_mce mce_flash_o10_cr_prod_sigheader.bin.encrypt; mb2_applet applet_t234_sigheader.bin.encrypt; mb2_bootloader mb2_t234_with_mb2_cold_boot_bct_MB2_sigheader.bin.encrypt; xusb_fw xusb_t234_prod_sigheader.bin.encrypt; dce_fw display-t234-dce_sigheader.bin.encrypt; nvdec nvdec_t234_prod_sigheader.fw.encrypt; bpmp_fw bpmp_t234-TE950M-A1_prod_sigheader.bin.encrypt; bpmp_fw_dtb tegra234-bpmp-3767-0003-3509-a02_with_odm_sigheader.dtb.encrypt; sce_fw camera-rtcpu-sce_sigheader.img.encrypt; rce_fw camera-rtcpu-t234-rce_sigheader.img.encrypt; ape_fw adsp-fw_sigheader.bin.encrypt; spe_fw spe_t234_sigheader.bin.encrypt; tos tos-optee_t234_sigheader.img.encrypt; eks eks_t234_sigheader.img.encrypt; kernel boot.img; kernel_dtb tegra234-p3767-0003-p3509-a02.dtb"    
--secondary_gpt_backup  
--bct_backup  
--boot_chain A

root:bootloader# ls -la uefi*
-rw-r--r-- 1 root root 2359296 Feb 19 10:31 uefi_jetson.bin
-rw-r--r-- 1 root root 2818048 Feb 15 13:50 uefi_jetson.bin.backup
-rw-r--r-- 1 root root 3182656 Feb 15 13:50 uefi_jetson_with_dtb_sigheader.bin.encrypt

How I can make encrypted version of uefi_jetson?

[DaveYYY]

@nox.gias

You helped me to make this happen in this thread
https://forums.developer.nvidia.com/t/backup-restore-workflow-3-massflash-jetson-orin-nano-problem

Oh sure, glad it worked.

@nox.gias

GRESS - Success

I got uefi_Jetson_RELEASE.bin at the end and replaced it inside my “mfi*” folder, but it didnt make any effect, as I understand its using encrypted version uefi_jetson_with_dtb_sigheader.bin.encrypt

You should start all over again.
Make a clean flash with the new UEFI binary, backup the image, generate the massflash package again.

[nox.gias]

@DaveYYY

You should start all over again.

Is there anyway I can modify my current device? and then backup/restore? Install our application from scratch will take a lot of time

[DaveYYY]

@nox.gias

-rw-r--r-- 1 root root 3182656 Feb 15 13:50 uefi_jetson_with_dtb_sigheader.bin.encrypt

I didn’t notice this.
Isn’t it already present here?

[nox.gias]

@DaveYYY

Isn’t it already present here?

Its inside mfi*/bootloader folder
If u mean in nvidia-uefi folder, no

AcpiBoot_Jetson_DEBUG.dtbo       BootOrderEmmc_Jetson_RELEASE.dtbo  BootOrderPxe_Jetson_DEBUG.dtbo     BootOrderUfs_Jetson_RELEASE.dtbo  DgpuDtEfifbSupport_Jetson_DEBUG.dtbo    uefi_Jetson_RELEASE.bin
AcpiBoot_Jetson_RELEASE.dtbo     BootOrderHttp_Jetson_DEBUG.dtbo    BootOrderPxe_Jetson_RELEASE.dtbo   BootOrderUsb_Jetson_DEBUG.dtbo    DgpuDtEfifbSupport_Jetson_RELEASE.dtbo
BOOTAA64_Jetson_DEBUG.efi        BootOrderHttp_Jetson_RELEASE.dtbo  BootOrderSata_Jetson_DEBUG.dtbo    BootOrderUsb_Jetson_RELEASE.dtbo  L4TConfiguration_Jetson_DEBUG.dtbo
BOOTAA64_Jetson_RELEASE.efi      BootOrderNvme_Jetson_DEBUG.dtbo    BootOrderSata_Jetson_RELEASE.dtbo  builddir_Jetson_DEBUG.txt         L4TConfiguration_Jetson_RELEASE.dtbo
BootOrderEmmc_Jetson_DEBUG.dtbo  BootOrderNvme_Jetson_RELEASE.dtbo  BootOrderUfs_Jetson_DEBUG.dtbo     builddir_Jetson_RELEASE.txt       uefi_Jetson_DEBUG.bin

[DaveYYY]

You can add --no-flash to the flashing command, so it will only prepare the image instead of really flashing the device.
Then you can extract the encrypted UEFI binary now.

[nox.gias]

You can add --no-flash to the flashing command

Like that?
./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --no-flash --massflash 10 --network usb0

[DaveYYY]

NO, I mean stuff like this:

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" \
  --showlogs --network usb0 jetson-orin-nano-devkit internal

Add --no-flash to it and adjust it to fit your need.

[nox.gias]

NO, I mean stuff like this

Understood, thanks for guiding me :)

So I run this command ( it was given by carrier board manufacturer ) and added --no-flash

./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" \
  --no-flash --showlogs --network usb0 p3509-a02+p3767-0000 internal

Device was flashed anyway and new UEFI was applied, only SSD remain for booting

At this moment I copy from Linux_for_Tegra/bootloader/uefi_jetson_with_dtb_sigheader.bin.encrypt to my mfi directory Linux_for_Tegra/mfi_p3509-a02+p3767-0000/bootloader/uefi_jetson_with_dtb_sigheader.bin.encrypt

And to be sure file are correct:

$ sha256sum uefi_jetson_with_dtb_sigheader.bin.encrypt
bd066f7291c1b9223564c3461172bea8b9dfedc292898ea1ebbaddb28d489133  uefi_jetson_with_dtb_sigheader.bin.encrypt
$ sha256sum ../../bootloader/uefi_jetson_with_dtb_sigheader.bin.encrypt
bd066f7291c1b9223564c3461172bea8b9dfedc292898ea1ebbaddb28d489133  ../../bootloader/uefi_jetson_with_dtb_sigheader.bin.encrypt

Then I started mass flash again, which was successful, but UEFI still old for some reason, not sure how to resolve this

Attaching full logs
flash_5-1.1_0_20240219-142041.log (22.7 KB)

[DaveYYY]

@DaveYYY

You should start all over again.
Make a clean flash with the new UEFI binary, backup the image, generate the massflash package again.

Then please follow this.