Jetson NX Xavier Jetpack 5.1 Flash failure to NVME

Hello ,

I am using a Jetson NX Xavier on a custom board with external SSD (128GB).

I’ve downloaded the new JetPack 5.1 and kernel r35.2.1 and trying to flash my device with using the following command:

sudo ./tools/kernel_flash/ --external-device nvme0n1 -c tools/kernel_flash/flash_l4t_nvme.xml -S 102GiB --showlogs e1060-0000+p3668-0001-qspi-emmc nvme0n1p1 

The same command setup worked for me with JetPack 5.0.2, but now I’m getting an error while flashing:

[  12.5799 ] End sector for recovery_alt, expected at: 30777310, actual: 0

I made sure the device size configured in flash_l4t_nvme.xml is big enough. I get the same error even when attempting to flash with default settings.


Hi chenadi26,

Do you get the BSP package from your vendor of custom board?

Does your board could boot up successfully w/o external SSD?

What’s the sector_size and num_sectors in your flash_l4t_nvme.xml?

Hi ,

I have the BSP package for my custom board , and everything worked fine with JetPack 5.0.2.
Regarding the sizes,
sector_size = 512
num_sectors = 230686720
This adds up to about 110GiB which is less than the amount the SSD can hold

They should be fine in your use case.

Please try the following command to flash your board.

$ sudo ./tools/kernel_flash/ --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_nvme.xml --external-only -S 102GiB --showlogs e1060-0000+p3668-0001-qspi-emmc nvme0n1p1

This time it worked fine until the following stage:

*                                                  *
*  Step 2: Boot the device with flash initrd image *
*                                                  *
/home/user/nvidia/nvidia_sdk/Jetson_Linux_R35.2.1_aarch64/Linux_for_Tegra/temp_initrdflash/bootloader0 /home/user/nvidia/nvidia_sdk/Jetson_Linux_R35.2.1_aarch64/Linux_for_Tegra
./ --bl nvtboot_recovery_cpu_t194_sigheader.bin.encrypt --bct br_bct_BR.bct --securedev  --bldtb tegra194-p3668-0001-elc1060-0000.dtb --applet rcm_2_encrypt.rcm --applet_softfuse rcm_1_encrypt.rcm --cmd "rcmboot"  --cfg secureflash.xml --chip 0x19 --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 --mem_bct_cold_boot mem_coldboot_sigheader.bct.encrypt  --bins "mb2_bootloader nvtboot_recovery_t194_sigheader.bin.encrypt; mts_preboot preboot_c10_prod_cr_sigheader.bin.encrypt; mts_mce mce_c10_prod_cr_sigheader.bin.encrypt; mts_proper mts_c10_prod_cr_sigheader.bin.encrypt; bpmp_fw bpmp-2_t194_sigheader.bin.encrypt; bpmp_fw_dtb tegra194-a02-bpmp-p3668-a00_lz4_sigheader.dtb.encrypt; spe_fw spe_t194_sigheader.bin.encrypt; tos tos-optee_t194_sigheader.img.encrypt; eks eks_t194_sigheader.img.encrypt; kernel boot0.img; kernel_dtb kernel_tegra194-p3668-0001-elc1060-0000.dtb; bootloader_dtb tegra194-p3668-0001-elc1060-0000_sigheader.dtb.encrypt"    --secondary_gpt_backup  --bct_backup  --boot_chain A  --instance 1-1
Traceback (most recent call last):
  File "./", line 1377, in <module>
    exports['--cfg'] = tegraflash_update_img_path(exports['--cfg'], exports['--image_dirs'])
  File "/home/user/nvidia/nvidia_sdk/Jetson_Linux_R35.2.1_aarch64/Linux_for_Tegra/temp_initrdflash/bootloader0/", line 4876, in tegraflash_update_img_path
    xml_tree = ElementTree.parse(file)
  File "/usr/lib/python3.8/xml/etree/", line 1202, in parse
    tree.parse(source, parser)
  File "/usr/lib/python3.8/xml/etree/", line 595, in parse
    self._root = parser._parse_whole(source)
xml.etree.ElementTree.ParseError: no element found: line 1, column 0
Cleaning up... 

Edit: After additional tests i see that the previous error still occurs and fails the image creation process .

[   2.9572 ] End sector for recovery_alt, expected at: 30777310, actual: 0

Are you using standalone Ubuntu 18.04 or 20.04 as your host PC?

Ubuntu 20.04

There’s a similar issue as yours. please help to check if it could help.
Object detection with custom image Could not parse xml file · Issue #1513 · dusty-nv/jetson-inference · GitHub

It seems causing from wrong xml file format.

Hi Kevin,

Unfortunately our cases aren’t the same , the parsing error in my case is a result of the script not being able to generate an image.
When i run the line you suggested i still get the error:

[   2.9572 ] End sector for recovery_alt, expected at: 30777310, actual: 0

But now the script just doesn’t exit there with an error code , it tries to continue even tough the image creation failed , and that is what causes the parsing error.

Let me clarify that the xml i am using is the stock xml with only the num_sectors and sector_size changed to my needs.

Do you have Xavier NX devkit could reproduce the same issue with Jetpack5.1?

I do not.

I believe the root of the problem may lie in the Jetsons inabillity to recognize the SSD.
Which would explain the error because the XML config exceeds the 16GB the jetson has built in.
I use the same custom configuration as i did with Jetpack 5.0.2 (changed pinmux , gpio and padvoltage and placed in /bootloader/BCT) , is there anything different you need to do in JetPack 5.1 that you didn’t in 5.0.2?

I also added specific conf file for the board.

I got the following error when executing:

 sudo ./ e1060-0000+p3668-0001-qspi-emmc external


[  11.2804 ] End sector for recovery_alt, expected at: 30777310, actual: 0
[  11.2804 ] 
Error: Return value 4
Command tegraparser_v2 --storageinfo storage_info.bin --generategpt --pt flash.xml.bin
Failed flashing t186ref.

Were you able to resolve this error?
We are having the same error with a custom board. But flashing the developer SDK seems to go through for some reason.

Can you share your solution?

We would suggest verify with the latest release first. Currently, it is JP5.1.1(R35.3.1) for Xavier NX.

It seems the size issue during flashing image to NVMe.
You should check the physical size of your SSD, the size in XML and determine the size for rootfs through -S parameter in flash command.

You could refer to the following thread for this:
How to solve the issue that ssd are not entiely availiable after full disk encryption - #5 by KevinFFF