Xavier NX Jetpack 32.4.3 to 32.7.3 image-based OTA failure

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

Hi,

We want to update Jetpack 4.4/L4T 32.4.3 to the newest version of L4T/Jetpack 5.1.2 or 5.1.3 on a Xavier NX 16GB emmc model with NVME SSD. We have some units in the field and it’s not possible to flash them with a host PC. That’s why we’re thinking of using image-based OTA to solve this task.

Could you please tell what could be the issue? Let us know if you need for info.

Thanks in advance for your help!

nv_ota_start_20240226-1616.log (9.7 KB)
ota_20240226-1617.log (92.1 KB)

3

Hi vie,

Are you using the devkit or custom board for Xavir NX?

No, please update from R32.4.3 to R32.7.4 first before update to R35.4.1.

It is only available for the devkit.

Do you mean that you have customized the partition layout but you recover it back to default before performing OTA update?

enabling A/B redundancy
A/B Redundancy has been enabled.

Do you enable rootfs A/B in your board?

Do you want to perform OTA update to internal eMMC or external NVMe?

I would like to know the command you used to generate OTA update package and also the log.

4

Hi Kevin,

thanks for your fast reply!

Are you using the devkit or custom board for Xavir NX?

We use a custom Auvidea board but for testing the OTA update, we put the NX and the SSD into a NX developer kit.

No, please update from R32.4.3 to R32.7.4 first before update to R35.4.1.

Ok, then we still need to follow this order.

It is only available for the devkit.

So image-based OTA is the only way to go for us?

Do you mean that you have customized the partition layout but you recover it back to default before performing OTA update?

Exactly. We directly flash the Jetson with the three partitions as separate images using sudo ./flash.sh -r jetson-xavier-nx-devkit-emmc mmcblk0p1 and the SSD separately using dd. The p1 with root fs is split up into three partitions p1-p3 like this:

username@hostname:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p1  6,9G  5,7G  853M  88% /
none            3,5G     0  3,5G   0% /dev
tmpfs           3,8G  4,0K  3,8G   1% /dev/shm
tmpfs           3,8G   38M  3,8G   1% /run
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           3,8G     0  3,8G   0% /sys/fs/cgroup
/dev/mmcblk0p2  3,4G  1,3G  2,0G  40% /home
/dev/mmcblk0p3  3,4G  121M  3,1G   4% /home/username/log
tmpfs           778M   12K  778M   1% /run/user/120
tmpfs           778M     0  778M   0% /run/user/1000

As just the p1 doesn’t have enough storage available for the OTA, we recover it like this:
a. sudo fdisk /dev/mmcblk0
b. d to delete
c. 3 for partition 3
d. Repeat last two steps for partition 2 & 1
e. p to verify deletion of p1-3
f. n to create new partition
g. Enter to confirm default 1
h. 40 for first sector
i. Enter to confirm last sector of 29360167
j. y to remove signature
k. t to change partition type
l. 11 for Microsoft basic data
n. x to enter expert mode
o. f to fix partition order
p. r to return to main menu
q. p to verify new partition order (p1-p11)
r. w to write and save changes
s. sudo resize2fs /dev/mmcblk0p1 to resize file system of p1

Do you enable rootfs A/B in your board?

No we didn’t enable it at the initial flashing of the system. We also wondered why it was appearing in the OTA log.

Do you want to perform OTA update to internal eMMC or external NVMe?

As written above, we originally switched the root fs to the NVMe using the guide jetsonhacks/rootOnNVMe. Before starting the OTA update, the root fs is moved back to internal eMMC by deleting the /etc/setssdroot.conffile and formatting the NVMe using sudo parted /dev/nvme0n1 mklabel gpt. As far was we understand, it’s not possible to directly update via OTA using the NVMe on the Jetpack 4.4 version. Or do you think we could directly use OTA on the NVMe?

I would like to know the command you used to generate OTA update package and also the log.

See attachments (including the commands performed on the host PC).

build_base_recovery_image_20240226.log (1.8 KB)
l4t_generate_ota_package_20240226.log (169.4 KB)

5

Yes, please use image-based OTA for the custom carrier board.

Please noted that there should not be the partition layout change between R32.4.3 and R32.7.3.

/home/power/V4_OTA_Update/R32_4_3/Linux_for_Tegra///bootloader/mkbootimg --kernel /home/power/V4_OTA_Update/R32_4_3/Linux_for_Tegra///kernel/Image --ramdisk /tmp/R32_3_4_recovery/R32_3_4_initrd.img --output /tmp/R32_3_4_recovery/recovery.img --cmdline "root=/dev/initrd rw rootwait console=ttyTCU0,115200n8 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 base_version=R32-4 target_board=jetson-xavier-nx-devkit-emmc"
Copy /tmp/R32_3_4_recovery/recovery_sigheader.img.encrypt to /tmp/R32_3_4_recovery/recovery.img.R32_3_4

Are you using 32.3.4 or 32.4.3 as base BSP?

7

Hi Kevin,

sorry for the late reply.

Are you using 32.3.4 or 32.4.3 as base BSP?

32.4.3

We found the issue with the OTA. It was due to the missing APP name of partition p1.

It is possible to change the name with fdisk using the commands from above but also including:

x to enter expert mode
n to change partition name
1 for partition 1
APP for name
→ “Partition name changed from ‘’ to APP.”

1 Like
8

Why you lost the APP name for mmcblk0p1?
How did you flash the board before?

We’ve not tried that.
Can you share the result of ls -al /dev/disk/by-partlabel on your board before and after your run fdisk command?

9

Before running fdisk for repartitioning but after moving the rootfs back to internal eMMC (and after flashing three partitions using three images with sudo ./flash.sh -r jetson-xavier-nx-devkit-emmc mmcblk0p1).

username@hostname:~$ ls -al /dev/disk/by-partlabel
total 0
drwxr-xr-x 2 root root 300 Jän 28  2018 .
drwxr-xr-x 8 root root 160 Mär 20 09:30 ..
lrwxrwxrwx 1 root root  15 Jän 28  2018 APP -> ../../mmcblk0p1
lrwxrwxrwx 1 root root  15 Jän 28  2018 O***HOME -> ../../mmcblk0p2
lrwxrwxrwx 1 root root  15 Jän 28  2018 O***LOG -> ../../mmcblk0p3
lrwxrwxrwx 1 root root  16 Jän 28  2018 RECROOTFS -> ../../mmcblk0p12
lrwxrwxrwx 1 root root  16 Jän 28  2018 UDA -> ../../mmcblk0p13
lrwxrwxrwx 1 root root  15 Jän 28  2018 kernel -> ../../mmcblk0p4
lrwxrwxrwx 1 root root  16 Jän 28  2018 kernel-bootctrl -> ../../mmcblk0p10
lrwxrwxrwx 1 root root  16 Jän 28  2018 kernel-bootctrl_b -> ../../mmcblk0p11
lrwxrwxrwx 1 root root  15 Jän 28  2018 kernel-dtb -> ../../mmcblk0p6
lrwxrwxrwx 1 root root  15 Jän 28  2018 kernel-dtb_b -> ../../mmcblk0p7
lrwxrwxrwx 1 root root  15 Jän 28  2018 kernel_b -> ../../mmcblk0p5
lrwxrwxrwx 1 root root  15 Jän 28  2018 recovery -> ../../mmcblk0p8
lrwxrwxrwx 1 root root  15 Jän 28  2018 recovery-dtb -> ../../mmcblk0p9

After running the fdisk commands.


username@hostname:~$ ls -al /dev/disk/by-partlabel
total 0
drwxr-xr-x 2 root root 280 Mär 20 09:49 .
drwxr-xr-x 8 root root 160 Mär 20 09:49 ..
lrwxrwxrwx 1 root root  15 Mär 20 09:49 APP -> ../../mmcblk0p1
lrwxrwxrwx 1 root root  16 Mär 20 09:49 RECROOTFS -> ../../mmcblk0p10
lrwxrwxrwx 1 root root  16 Mär 20 09:49 UDA -> ../../mmcblk0p11
lrwxrwxrwx 1 root root  15 Mär 20 09:49 kernel -> ../../mmcblk0p2
lrwxrwxrwx 1 root root  15 Mär 20 09:49 kernel-bootctrl -> ../../mmcblk0p8
lrwxrwxrwx 1 root root  15 Mär 20 09:49 kernel-bootctrl_b -> ../../mmcblk0p9
lrwxrwxrwx 1 root root  15 Mär 20 09:49 kernel-dtb -> ../../mmcblk0p4
lrwxrwxrwx 1 root root  15 Mär 20 09:49 kernel-dtb_b -> ../../mmcblk0p5
lrwxrwxrwx 1 root root  15 Mär 20 09:49 kernel_b -> ../../mmcblk0p3
lrwxrwxrwx 1 root root  15 Mär 20 09:49 recovery -> ../../mmcblk0p6
lrwxrwxrwx 1 root root  15 Mär 20 09:49 recovery-dtb -> ../../mmcblk0p7
lrwxrwxrwx 1 root root  15 Mär 20 09:49 ssd -> ../../nvme0n1p1
10

For the image based OTA update from R32.4.3 to R32.7.3., partition layout change is not supported. If you have custom partition layout change, please also customize the partition layout file before you generate OTA package.

11

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