Unable to Flash NVME Jetson AGX Orin 64GB Dev kit with supplied USB Cable

Right, I understand you want me to test flashing the eMMC, I apologize, I was trying to verify I’m able to check what firmware level is once we get through the process.

Thanks for the clarification on where its getting stuck and the pointer to the https://developer.ridgerun.com/ serial console detail. That confirms I’m reading the right content.

I’m attempting that now and will update.

Ok the flash of only the eMMC using the SDK Manager worked.

The conditions were

rpcbind.service, rpcbind.socket, and rpcbind.target were still disabled/stopped from previous troubleshooting (due to error message previous to the nfs mount failure in my previous attempts)

the FAQ recommendation item was applied to address the USB timeout
echo -1 > /sys/module/usbcore/parameters/autosuspend

Before the flash

Jetson UEFI firmware (version 4.1-33958178 built on 2023-08-01T19:34:02+00:00)
Linux version 5.10.120-tegra (buildbrain@mobile-u64-6422-d7000) (aarch64-buildroot-linux-gnu-gcc.br_real (Buildroot 3

After the flash

Jetson System firmware version 36.4.3-gcid-38968081 date 2025-01-08T01:18:20+00:
Linux version 5.15.148-tegra (buildbrain@mobile-u64-6336-d8000) (aarch64-buildroot-linux-gnu-gcc.br_real (Buildroot )

The previous one was rel-35.4.1 release and the second one is now rel-36.4.3.

If emmc is working, then this module itself is fine.

So we are looking into nvme case now.

We can start from manual flash command first. Please check if sdkmanager install the package to your host PC with path (~/nvidia/)

If there is, then please run this manual command and see what would happen.

Ok so I’m assuming that I need to follow what is detailed at the beginning of that Quick Start article to get this to work (failed first attempt below, going back and doing steps 1-5 from that doc)

agrajag@tor-XPS:~/nvidia$ cd ./nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/
agrajag@tor-XPS:~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0
 jetson-agx-orin-devkit external
Please install the Secureboot package to use initrd flash for fused board
# Entry added by NVIDIA initrd flash tool
/home/agrajag/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/tools/kernel_flash/tmp 127.0.0.1(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
Job for nfs-server.service canceled.

(The download and unpack being unnecessary as I already have everything)

I ran the following

sudo ./tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.sh

and then followed steps 3-5 to put the unit back in recovery mode
verified with lsusb the unit was ready

agrajag@tor-XPS:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 0bda:568b Realtek Semiconductor Corp. Integrated_Webcam_HD
Bus 001 Device 005: ID 04f3:20d0 Elan Microelectronics Corp. Touchscreen
Bus 001 Device 004: ID 0cf3:e301 Qualcomm Atheros Communications
Bus 001 Device 021: ID 0955:7023 NVIDIA Corp. APX
Bus 001 Device 014: ID 0955:7045 NVIDIA Corp. Tegra On-Platform Operator
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

rebooted

and re-ran the command

agrajag@tor-XPS:~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-agx-orin-devkit external

same error message

agrajag@tor-XPS:~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-agx-orin-devkit external
Please install the Secureboot package to use initrd flash for fused board
# Entry added by NVIDIA initrd flash tool
/home/agrajag/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/tools/kernel_flash/tmp 127.0.0.1(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
rpcbind: another rpcbind is already running. Aborting
Job for nfs-server.service canceled.

It looks like I need to fully enable secure boot on this system for this to work… Its not reporting that its fully enabled after enabling it in bios

agrajag@tor-XPS:~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra$ sudo mokutil --sb-state
SecureBoot enabled
SecureBoot validation is disabled in shim

Will start reading up on it here

No, you don’t need to enable secureboot. It is from something else. I will take a look.

Could you check if this thing exist on your host PC BSP directory?

Linux_for_Tegra/bootloader$ ls odmsign.func
odmsign.func

Yes its there

agrajag@tor-XPS:~/nvidia/nvidia_sdk$ sudo find . -name odmsign.func
./JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/bootloader/odmsign.func
agrajag@tor-XPS:~/nvidia/nvidia_sdk$ ls -l $(!!)
ls -l $(sudo find . -name odmsign.func)
-rw-rw-r-- 1 agrajag agrajag 16906 Jan  7 18:42 ./JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/bootloader/odmsign.func

Ok some interesting points, reading:

  1. I have not formatted the nvme, it was mentioned it should not be in some other post I found when troubleshooting originally
  2. /etc/exports exists and can be removed

I’m going to boot into the AGX Orin unit and format the nvme ssd as ext4, and then attempt to re-run the l4t_initrd_flash.sh script with those conditions in place and will update

Nope, that resulted in no change in behavior, I’ll check back in later to see what you found.

Hi,

Could you look into your “l4t_initrd_flash.sh” and see why it keeps going into the logic of “Please install the Secureboot package to use initrd flash for fused board” even though you already got “odmsign.func” on your host PC?

Also, just to clarify. I notice you didn’t get one point. The “secureboot package” is for Jetson secure boot. We totally don’t care about whether your host PC has secure boot or not.

Your attempt of checking "mokutil " on your host PC is not needed.

Yep I did pick that up on the secureboot config of system not needed.

I was thinking maybe the l4t_flash_prerequisits.sh and apply_binaries.sh might act differently when seceureboot was present, but it made no difference.

With regard to the script, line numbering turned on in content below:

     50 check_prerequisite()
     51 {
...
...
     80         # Temporary disable until secureboot rcm boot is fixed - Bug 200727134
     81         if ! [ -f "${BOOTLOADER_DIR}/odmsign.func" ]  && [ "${flash_only}" = "0" ]; then
     82                 echo "Please install the Secureboot package to use initrd flash for fused board"
     83                 # exit 1
     84         fi
     85
     86         if [ "${no_flash}" = "0" ]; then
     87                 network_prerequisite "${network}" "${LINUX_BASE_DIR}"
     88         fi
     89
     90 }

l4t_initrd_flash.txt (9.6 KB)

note that further down “flash_only” is set to 0

    180 flash_only="0"

I’ve attached the script for reference if needed.

I’m not seeing how BOOTLOADER_DIR is being resolved in any of this for the l4t_initrd_flash.sh script…

agrajag@tor-XPS:~/nvidia$ sudo grep -r BOOTLOADER_DIR=
nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/apply_binaries.sh:LDK_BOOTLOADER_DIR="${LDK_DIR}/bootloader"
nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/l4t_sign_image.sh:L4T_BOOTLOADER_DIR="${L4T_DIR}/bootloader"
nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/nv_tegra/nv-apply-debs.sh:L4T_BOOTLOADER_DIR="${L4T_DIR}/bootloader"
nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/tools/l4t_update_initrd.sh:        LDK_BOOTLOADER_DIR="${LDK_DIR}/bootloader"
nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/tools/l4t_generate_qspi_images.sh:BOOTLOADER_DIR="${LINUX_BASE_DIR}/bootloader"
nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh:BOOTLOADER_DIR="${LINUX_BASE_DIR}/bootloader"
nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/tools/kernel_flash/l4t_create_images_for_kernel_flash.sh:BOOTLOADER_DIR="${LINUX_BASE_DIR}/bootloader"
nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/tools/qspi_flash/generate_qspi_for_flash.sh:       BOOTLOADER_DIR="${L4T_DIR}/bootloader"
agrajag@tor-XPS:~/nvidia$

It’s almost like there is an expectation of an environment being established that provides that (and other) values to the script I’m not seeing. I’ll keep looking

so in l4t_initrd_flash.sh it starts here to start establishing the current path

    173 L4T_INITRD_FLASH_DIR="$(cd "$(dirname "${0}")" && pwd)"
    174 L4T_TOOLS_DIR="${L4T_INITRD_FLASH_DIR%/*}"
    175 LINUX_BASE_DIR="${L4T_TOOLS_DIR%/*}"
    176 ROOTFS_DIR="${LINUX_BASE_DIR}/rootfs"
...
...
    195 flash_cmd="${L4T_INITRD_FLASH_DIR}/l4t_initrd_flash_internal.sh"

and then in l4t_initrd_flash_internal.sh

agrajag@tor-XPS:~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/tools/kernel_flash$ grep BOOTLOADER_DIR= l4t_initrd_flash_internal.sh

BOOTLOADER_DIR="${LINUX_BASE_DIR}/bootloader"

I’m going to drop a debug line into the l4t_initrd_flash.sh script to see what’s being returned at that point

Yeah so modifying the script like so (adding line 82 & 83)

     80         # Temporary disable until secureboot rcm boot is fixed - Bug 200727134
     81         if ! [ -f "${BOOTLOADER_DIR}/odmsign.func" ]  && [ "${flash_only}" = "0" ]; then
     82                 echo "debug $BOOTLOADER_DIR"
     83                 exit 1
     84                 echo "Please install the Secureboot package to use initrd flash for fused board"
     85                 # exit 1

Is showing that its empty? Nothing is returning on the debug line for it (I think I’m doing that right…)

agrajag@tor-XPS:~/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-agx-orin-devkit external

debug

Hi @toddg1

Sorry in advance if I didn’t fully understand your comment.

If that “Please install the Secureboot package to use initrd flash for fused board” error by default didn’t stop the flash process, then please go further to check which line stops the flash process on your side.

@WayneWWW it appears the script is failing to properly provide the needed path for the check_prerequisite() function, per the work evaluating it above by inserting the debug. I have reached a dead end.

Hi @toddg1

So where did your flash script stop if we don’t care about that “Please install the Secureboot package to use initrd flash for fused board” print.

It looks like “exit 1” is added by you and original one got commented out, so I believe the script still runs down. Where did it stop if running the original script? or it didn’t run down further?

I mean forget about whether that BOOTLOADER_DIR is present or not. It looks like that is just a print. Not really where the process stops?

And one other things to check here. Did you ever try other host PC to flash?

The only script modification I made is lines 82 and 83 from the example I shared, the exit on line 85 is the original one that was present in the script. It was already commented out and allows the flow it to continue to the “if [ “${no_flash}” = “0” ]; then” statement which we see the output in the original message.

The script stops within the check_prerequisite() function (line #50 from a few posts back). That is where the failure is taking place.

In the version of the script I’m working in, on line 80 it has the comment
# Temporary disable until secureboot rcm boot is fixed - Bug 200727134
What is that referring to? It seems like in the 6.2 SDK manager distribution, this script was modified for this condition. That was part of the reason I was focusing on Secureboot in general as being a possible missing factor.

In January, I started attempting this from multiple hyperV based hosts I set up. I discovered that its impossible to do from virtual ubuntu guests from forums posts here. I then set up a dual boot workstation in early February but had to give back to my coworker, and then finally from a laptop that has ubuntu installed by the manufacturer (dell) before attempting to reach out here for help.