Flashing external NVMe SSD directly on host does not work

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
,
1

Hi,

I’m trying to flash a NVMe ssd on a host pc to later connect it to a Orin NX to boot from it.

I followed the guide here: Flashing Support — Jetson Linux Developer Guide documentation and also looked through the different flash scripts myself.

I boiled what I found down to this command:

sudo \
ROOTFS_AB=1 \
ADDITIONAL_DTB_OVERLAY_OPT=“BootOrderNvme.dtbo” \
BOARDID=3767 \
BOARDSKU=1111 \
FAB=TS1 \
./tools/kernel_flash/l4t_initrd_flash.sh \
–direct sda \
–external-device nvme0n1p1 \
–external-only \
-c ./tools/kernel_flash/flash_l4t_nvme_rootfs_ab.xml \
-S 10GiB \
–showlogs \
jetson-orin-nano-devkit \
external

I want to use a AB partition layout. I have the NVMe ssd connected to the host pc via a usb dongle, thus the --direct sda. Disclaimer: the BOARDID, BOARDSKU and FAB variables are probably wrong, I couldn’t find the real values neither online nor in the table in the README_initrd_flash.txt file and just tried some of the values mentioned in the jetson-orin-nano-devkit.conf file.

The above command successfully creates two boot images (a and b) but fails to actually flashing them to the ssd. It’s giving me the output:

###################### OUTPUT START ###############################

*** no-flash flag enabled. Exiting now… ***

User can run above saved command in factory environment without
providing pkc and sbk keys to flash a device

Example:

$ cd bootloader 
$ sudo bash ./flashcmd.txt

Save initrd flashing command parameters to /home/pascal/Documents/Jetson/build/Linux_for_Tegra/tools/kernel_flash/initrdflashparam.txt
/tmp/tmp.UJUqQibD9y /home/pascal/Documents/Jetson/build/Linux_for_Tegra
writing boot image config in bootimg.cfg
extracting kernel in zImage
extracting ramdisk in initrd.img
/tmp/tmp.UJUqQibD9y/initrd /tmp/tmp.UJUqQibD9y /home/pascal/Documents/Jetson/build/Linux_for_Tegra
56174 blocks
grep: /home/pascal/Documents/Jetson/build/Linux_for_Tegra/tools/kernel_flash/images/internal/flash.idx: No such file or directory
63579 blocks
/tmp/tmp.UJUqQibD9y /home/pascal/Documents/Jetson/build/Linux_for_Tegra
flashimg0=boot0.img
/home/pascal/Documents/Jetson/build/Linux_for_Tegra
Success
Cleaning up…
Finish generating flash package.
/home/pascal/Documents/Jetson/build/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --external-only --direct sda --usb-instance direct --device-instance 0 --flash-only --external-device nvme0n1p1 -c “./tools/kernel_flash/flash_l4t_nvme_rootfs_ab.xml” -S 10GiB --direct sda jetson-orin-nano-devkit external
*************************************************************
* *
* Step 1: Start the host connected device flashing process *
* *
*************************************************************
blockdev: cannot open /dev/mmcblk0boot0: No such file or directory
[ 0]: l4t_flash_from_kernel: Starting to create gpt for external device
Active index file is /home/pascal/Documents/Jetson/build/Linux_for_Tegra/tools/kernel_flash/images/external/flash.idx
Number of lines is 18
max_index=17
[ 0]: l4t_flash_from_kernel: Successfully create gpt for external device
[ 0]: l4t_flash_from_kernel: Starting to flash to external device
Active index file is /home/pascal/Documents/Jetson/build/Linux_for_Tegra/tools/kernel_flash/images/external/flash.idx
Number of lines is 18
max_index=17
[ 0]: l4t_flash_from_kernel: Successfully flash the external device
[ 0]: l4t_flash_from_kernel: Flashing success
Success
Cleaning up…
Log is saved to Linux_for_Tegra/initrdlog/flash_direct_0_20241021-170529.log

###################### OUTPUT END ###############################

I also tried to flash the images afterwards with
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --direct sda --flash-only jetson-orin-nano-devkit external

This gave me the same output. What I find suspicious is that the line
“blockdev: cannot open /dev/mmcblk0boot0: No such file or directory” comes from the file l4t_initrd_flash_internal.sh even though I am using the --external-only flag.
Running “sudo partprobe /dev/sda && sudo parted /dev/sda print” afterwards shows nothing. The ssd hasn’t been touched at all. Is this related to me using an usb dongle for the nvme ssd? Could this be an interface problem?

I’m somewhat desperate as I’m running out of ideas and I really don’t want to partition and flash the the ssd by hand. I appreciate any help!

3

hello p.luh,

may I know what’s your real use-case, are you able to leave the NVMe connected to flash the image successfully?

BTW,
is it bootloader A/B or RootfsA/B?

5

Hello JerryChang,

thanks for your quick reply!
The use case is the following: We want to automate the process of setting up our Jetsons. I would like the endresult to look like this: I connect the NVMe ssd to my host pc. Then run my setup script that will minimize the system image (e.g. remove the desktop environment and any gui packages) and then flash it with the Nvidia flash script to the ssd. After that I want to be able to just plug the ssd in to the Jetson and have a bootable system that I can ssh into.

Concerning A/B: I want to be able to create an updated rootfs in my office, scp it to the Jetson, update B with it, then boot into B and fallback to A if it didn’t work. So I guess I’m talking about rootfs redundancy. But I just read here: Rootfs A/B vs. bootloader A/B - #5 by WayneWWW that I need to enable bootloader redundancy to be able to use rootfs redundancy?

Thanks for your help!

6

hello p.luh,

you should refer to backup/restore package, for instance, $OUT/Linux_for_Tegra/tools/backup_restore
bootloader A/B it’s now enabled by default, anyways, may I double check the Jetpack release version you’re working with.

7

Hi JerryChang,

as soon as I have the Jetson bootable I plan to install Jetpack 5.1.1. The L4T version is 35.3.1.

Do I need the backup_restore for the remote A/B System update? As I understand it correctly for the backup / restore scripts to work I need to have the Jetson in recovery mode. I don’t have easy physical access to the Jetson boards though after I set them up. That’s why I’m trying to implement an OS-level backup process instead of a recovery-level one.

Right now I’m not there yet anyways because the flashing process doesn’t work. I think that’s my main problem right now.

Thank you for your help!!

8

hello p.luh,

don’t you have physical access here?

9

Hello JerryChang,

I think I might not have made my intentions clear. I want to explain it in a better way.
The main thing I’m worried rn is the following:

As it is easier for the development process we go through, I want to be able to:
1.) Plug a NVMe ssd to a host pc (while the Jetson is not plugged in to the host pc)
2.) Flash the minimized OS onto the ssd
3.) Attach the ssd to the Jetson and have it boot from the ssd

Apart from that I am also looking into having an AB partition scheme so I can remotely update the Jetsons.
And the reason why I’m interested in remote updating is that after the initial setup, we use the Jetson boards in different places that are far away from the office. That’s why I want to implement an update procedure that I can
trigger remotely, because driving to every location to update the boards directly is simply not an option. But that is not my main priority as of now.

What I am struggling with right now is the flashing procedure. That’s what I’m asking for. I am confused by how to do it. So far I connected my NVMe ssd via an usb adapter with my host pc and used the following command:

sudo \
ROOTFS_AB=1 \
ADDITIONAL_DTB_OVERLAY_OPT=“BootOrderNvme.dtbo” \
BOARDID=3767 \
BOARDSKU=1111 \
FAB=TS1 \
./tools/kernel_flash/l4t_initrd_flash.sh \
-S 20GiB \
-c ./tools/kernel_flash/flash_l4t_nvme_rootfs_ab.xml \
–direct sda \
–external-device nvme0n1p1 \
–external-only \
jetson-orin-nano-devkit \
nvme0n1p1

Unfortunately this won’t result in the ssd being flashed. It creates the images alright but it doesn’t flash the ssd. And I am afraid this might be because the flashing script excpects the Jetson board to be plugged in to the host pc and not just an ssd, is this correct? Because using --no-flash first and then trying to flash the resulting images afterwards results in an error stating that it didn’t find any devices to flash.

I also just read here Flashing external NVMe SSD directly by host - #2 by DaveYYY that I need to flash the internal memory of the board anyways because otherwise there’s no bootloader?
Does this mean my idea of just flashing the ssd and plugging it in to a fresh Jetson board to make it boot from the ssd is simply not possible to begin with because that’s not how it’s supposed to be done?

Thanks for your help!

10

hello p.luh,

may I know what’s your expectation of remote update.
for instance, were those device already flashed with previous Jetpack release (which L4T version?) images, and you would like to perform an OTA update?

besides, why you need to flash the minimized OS onto the SSD?
don’t those remote targets have external storage connected? or, you need to send those SSDs to ask for replacement?

11

Is this still an issue to support? Any result can be shared?

12

Hi,

yes this is still an issue.

I want to flash the OS onto the SSD because flashing the Jetson directly has proven to be complicated.
By flashing the SSD from the host PC directly we wanted to make the process easier.

Can you tell me anything on how to flash the SSD directly from the host?

Best regards and thanks in advance!

13

please see-also developer guide, Flashing to an External Storage Device.

15

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