Image based OTA from 32.7.3 to 35.4.1 failed due to cbo.dtb file missed

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

Hi all.

I’m trying to update my Jetson target devices from 32.7.3 to 35.4.1 following this guideline:
https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/SoftwarePackagesAndTheUpdateMechanism.html?highlight=ota#over-the-air-update

I’ve been successful all the way including creating an ota_payload_package .
However, when I try to finally execute the last step with this command:

sudo ./nv_ota_start.sh /dev/mmcblk0 ${OTADIR}/ota_payload_package.tar.gz

I keep facing the following error. Already tried several different ways but nothing has been successful.

force_booting_from_emmc /ota_work
The file /ota_work/cbo.dtb is not found
Failed to run "force_booting_from_emmc /ota_work"

And here’s the full log

Command: ./nv_ota_start.sh /dev/mmcblk0 /ota/ota_payload_package.tar.gz
Current rootfs is on /dev/nvme0n1
init_ota_log /ota_log
Create log file at /ota_log/ota_20240219-205419.log
OTA_LOG_FILE=/ota_log/ota_20240219-205419.log
Extract /ota/ota_payload_package.tar.gz
update_nv_boot_control_in_rootfs /ota_work
3668-301---1--jetson-xavier-nx-devkit-emmc-
check_prerequisites
decompress_ota_package ota_package.tar /ota_work
decompress_ota_package: start at Pzt Şub 19 20:55:02 +03 2024
Sha1 checksum for /ota_work/ota_package.tar (5135a3692f9fdf21b88adc960e0c5f3c0e04fa8a) matches
decompress_ota_package: end at Pzt Şub 19 20:55:30 +03 2024
nv_ota_update_with_layout_change.sh /dev/nvme0n1
Command: nv_ota_update_with_layout_change.sh /dev/nvme0n1
duplicate_bct_copy
Copied 65536 bytes from address 0x00000000 in flash to /tmp/bct.bin.tmp
Erased 65536 bytes from address 0x00010000 in flash
Copied 65536 bytes from /tmp/bct.bin.tmp to address 0x00010000 in flash
Duplicating BCT image is done
check_bsp_version /ota_work BASE_VERSION
check_target_board /ota_work TARGET_BOARD
set_msi_emmc_min_size jetson-xavier-nx-devkit-emmc MSI_EMMC_MIN_SIZE
ota_check_rollback /ota_work jetson-xavier-nx-devkit-emmc R32-7
OTA_PACKAGE version: branch:35 revision:4.1 major.minor:4.1
65536+0 records in
65536+0 records out
33554432 bytes (34 MB, 32 MiB) copied, 10,4319 s, 3,2 MB/s
boot_device_size=33554432
VER's offset is 33292288 and size is 65536
VER_b's offset is 33357824 and size is 65536
VER_b version: branch:32 revision:7.3 major.minor:7.3
VER version: branch:32 revision:7.3 major.minor:7.3
Check BCT/MB1/MB1_BCT partiton for fresh OTA
Checking BCT partition
Checking MB1 partition
Checking MB1_BCT partition
ver_check_res=0
ota_choose_images /ota_work
COMPATIBLE_SPEC=3668-301---1--jetson-xavier-nx-devkit-emmc-
TEGRA_CHIPID=0x19
_BOARD_SPEC_NAME=3668-301--
Copy files from ./images-R32i/3668-301--/ to ./images-R32i/
Copy files from ./images-R32x-R35i/3668-301--/ to ./images-R32x-R35i/
Copy files from ./images-R35A-R35i/3668-301--/ to ./images-R35A-R35i/
Copy files from ./images-R35-ToT/3668-301--/ to ./images-R35-ToT/
ota_check_free_space_on_emmc
There is enough free space(523336192 bytes > 241172480 bytes) on eMMC
ota_check_partitions /ota_work
65536+0 records in
65536+0 records out
33554432 bytes (34 MB, 32 MiB) copied, 9,23746 s, 3,6 MB/s
boot_device_size=33554432
Checking partitions on the boot device through secondary GPT
Checking partition BCT in the ota index file
The start and end offset for BCT partition matches
Checking partition mb1 in the ota index file
The start and end offset for mb1 partition matches
Checking partition mb1_b in the ota index file
The start and end offset for mb1_b partition matches
Checking partition MB1_BCT in the ota index file
The start and end offset for MB1_BCT partition matches
Checking partition MB1_BCT_b in the ota index file
The start and end offset for MB1_BCT_b partition matches
Checking partition MEM_BCT in the ota index file
The start and end offset for MEM_BCT partition matches
Checking partition MEM_BCT_b in the ota index file
The start and end offset for MEM_BCT_b partition matches
Checking partition spe-fw in the ota index file
The start and end offset for spe-fw partition matches
Checking partition spe-fw_b in the ota index file
The start and end offset for spe-fw_b partition matches
Checking partition mb2 in the ota index file
The start and end offset for mb2 partition matches
Checking partition mb2_b in the ota index file
The start and end offset for mb2_b partition matches
Checking partition mts-preboot in the ota index file
The start and end offset for mts-preboot partition matches
Checking partition mts-preboot_b in the ota index file
The start and end offset for mts-preboot_b partition matches
Checking partition mts-mce in the ota index file
The start and end offset for mts-mce partition matches
Checking partition mts-mce_b in the ota index file
The start and end offset for mts-mce_b partition matches
Checking partition mts-proper in the ota index file
The start and end offset for mts-proper partition matches
Checking partition mts-proper_b in the ota index file
The start and end offset for mts-proper_b partition matches
Checking partition sc7 in the ota index file
The start and end offset for sc7 partition matches
Checking partition sc7_b in the ota index file
The start and end offset for sc7_b partition matches
Checking partition SMD in the ota index file
The start and end offset for SMD partition matches
Checking partition SMD_b in the ota index file
The start and end offset for SMD_b partition matches
Checking partition xusb-fw in the ota index file
The start and end offset for xusb-fw partition matches
Checking partition xusb-fw_b in the ota index file
The start and end offset for xusb-fw_b partition matches
Checking partition cpu-bootloader in the ota index file
The start and end offset for cpu-bootloader_rsv partition matches
Checking partition cpu-bootloader_b in the ota index file
The start and end offset for cpu-bootloader_b partition matches
Checking partition bootloader-dtb in the ota index file
The start and end offset for bootloader-dtb_rsv partition matches
Checking partition bootloader-dtb_b in the ota index file
The start and end offset for bootloader-dtb_b partition matches
Checking partition BMP in the ota index file
The start and end offset for BMP_rsv partition matches
Checking partition BMP_b in the ota index file
The start and end offset for BMP_b partition matches
Checking partition secure-os in the ota index file
The start and end offset for secure-os_rsv partition matches
Checking partition secure-os_b in the ota index file
The start and end offset for secure-os_b partition matches
Checking partition eks in the ota index file
The start and end offset for eks_rsv partition matches
Checking partition eks_b in the ota index file
The start and end offset for eks_b partition matches
Checking partition adsp-fw in the ota index file
The start and end offset for adsp-fw_rsv partition matches
Checking partition adsp-fw_b in the ota index file
The start and end offset for adsp-fw_b partition matches
Checking partition rce-fw in the ota index file
The start and end offset for rce-fw_rsv partition matches
Checking partition rce-fw_b in the ota index file
The start and end offset for rce-fw_b partition matches
Checking partition sce-fw in the ota index file
The start and end offset for sce-fw_rsv partition matches
Checking partition sce-fw_b in the ota index file
The start and end offset for sce-fw_b partition matches
Checking partition bpmp-fw in the ota index file
The start and end offset for bpmp-fw_rsv partition matches
Checking partition bpmp-fw_b in the ota index file
The start and end offset for bpmp-fw_b partition matches
Checking partition bpmp-fw-dtb in the ota index file
The start and end offset for bpmp-fw-dtb_rsv partition matches
Checking partition bpmp-fw-dtb_b in the ota index file
The start and end offset for bpmp-fw-dtb_b partition matches
Checking partition CPUBL-CFG in the ota index file
The start and end offset for CPUBL-CFG_rsv partition matches
Checking partition CPUBL-CFG_b in the ota index file
The start and end offset for CPUBL-CFG_b partition matches
Checking partition VER in the ota index file
The start and end offset for VER partition matches
Checking partition VER_b in the ota index file
The start and end offset for VER_b partition matches
Checking partitions on the user device through primary GPT
Checking partition APP in the ota index file
The start and end offset for APP partition matches
Checking partition kernel in the ota index file
The start and end offset for kernel partition matches
Checking partition kernel_b in the ota index file
The start and end offset for kernel_b partition matches
Checking partition kernel-dtb in the ota index file
The start and end offset for kernel-dtb partition matches
Checking partition kernel-dtb_b in the ota index file
The start and end offset for kernel-dtb_b partition matches
Checking partition recovery in the ota index file
The start and end offset for recovery partition matches
Checking partition recovery-dtb in the ota index file
The start and end offset for recovery-dtb partition matches
Checking partition kernel-bootctrl in the ota index file
The start and end offset for kernel-bootctrl partition matches
Checking partition kernel-bootctrl_b in the ota index file
The start and end offset for kernel-bootctrl_b partition matches
enable_a_b_redundancy
both_slots_valid
write_base_recovery /ota_work
Verifying image /ota_work/recovery.img.R32x with sha1 chksum file /ota_work/recovery.img.R32x.sha1sum
Sha1 checksum for /ota_work/recovery.img.R32x (c6486c424b360df243489f502c55114fcb56ce4c) matches
Verifying image /ota_work/recovery.dtb.R32x with sha1 chksum file /ota_work/recovery.dtb.R32x.sha1sum
Sha1 checksum for /ota_work/recovery.dtb.R32x (6f4d81d4bf6ca74924fd16dcc7d3824d8bba1474) matches
Backed up recovery and recovery-dtb partition under /ota_work before writing them
Writing base recovery image into /dev/mmcblk0p6
Read back base recovery image into /ota_work/image.tmp and verify it
Reading 47554560 bytes from /dev/mmcblk0p6: 1KB block=46440 remainder=0 offset=47554560
Verifying image /ota_work/image.tmp with sha1 chksum file /ota_work/recovery.img.R32x.sha1sum
Sha1 checksum for /ota_work/image.tmp (c6486c424b360df243489f502c55114fcb56ce4c) matches
Writing base recovery dtb into /dev/mmcblk0p7
Read back base recovery dtb into /ota_work/image.tmp and verify it
Reading 208736 bytes from /dev/mmcblk0p7: 1KB block=203 remainder=864 offset=207872
Verifying image /ota_work/image.tmp with sha1 chksum file /ota_work/recovery.dtb.R32x.sha1sum
Sha1 checksum for /ota_work/image.tmp (6f4d81d4bf6ca74924fd16dcc7d3824d8bba1474) matches
write_kernel_bootctrl /ota_work
512+0 records in
512+0 records out
262144 bytes (262 kB, 256 KiB) copied, 0,00814408 s, 32,2 MB/s
Backed up kernel-bootctrl partition under /ota_work before writing them
Writing bootctrl update file into /dev/mmcblk0p8
Read back bootctrl update file into /ota_work/image.tmp and verify it
Reading 20 bytes from /dev/mmcblk0p8: 1KB block=0 remainder=20 offset=0
force_booting_from_emmc /ota_work
The file /ota_work/cbo.dtb is not found
Failed to run "force_booting_from_emmc /ota_work"

If anyone can advise or provide me a proper cbo.dtb file, it’ll be highly appreciated.

3

Hi kang12,

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

Do you have cbo.dtb in your OTA payload?

Please also share the full log when you are generating the OTA package.

4

Hi @KevinFFF

Thanks for your response.

I’m using custom board for Xavier NX. But I don’t need any specific configuration so I just followed Jetson Linux’s default BSP and Sample Root Filesystem.

Here’s the full log when I generate the OTA package with this command.

sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh jetson-xavier-nx-devkit-emmc R32-7

I’ve attached the full log while generating the OTA payload.
kang_ota_payload_log.txt (408.9 KB)

Thank you very much in advance.

5

I also tried to build the ota payload once again this time with the following command by following Image_based_OTA_Examples.txt in the OTA tool.

Command:

sudo -E ROOTFS_AB=1 ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh --external-device nvme0n1 -S 14GiB jetson-xavier-nx-devkit-emmc R32-7

And I’ve got the same cbo.dtb file error this time here with the following log:

Copying mb1 image from /home/username/R35.4.1/Linux_for_Tegra for re-signing
Copying cbo.dts from /home/username/R35.4.1/Linux_for_Tegra for specifying boot order
cp: cannot stat '/home/username/R35.4.1/Linux_for_Tegra/bootloader/cbo.dts': No such file or directory

I installed the Linux_for_Tegra 35.4.1 version by downloading the Driver Package (BSP) from this link: https://developer.nvidia.com/embedded/jetson-linux-r3541
And confirm that cbo.dtb file doesn’t exist from the beginning in this BSP.

What should I do?

6

Could you refer to the following instruction to perform image-based OTA for Xavier NX eMMC to update from R32.7.3 to R35.4.1?
Jetson/L4T/peripheral/ - eLinux.org - Image-Based OTA with layout change

It seems no cbo.dtb in your OTA package.

Do you run build_base_recovery_image.sh before generating the OTA package?

I would also want to confirm the following with you:

  1. Do you connect an external NVMe drive?
  2. Do you want to perform OTA update for internal eMMC or external NVMe?
  3. Do you enable redundancy rootfs (ROOTFS_AB=1) in R32.7.3?
7

Hi @KevinFFF

I checked the link and it seems most of the procedure is identical to how I did.

Here’s my answers to your questions:

Do you run build_base_recovery_image.sh before generating the OTA package?
→ Yes I did with the following command. It was successful.

sudo ./tools/ota_tools/version_upgrade/build_base_recovery_image.sh jetson-xavier-nx-devkit-emmc R32-7 ${BASE_BSP} ${BASE_BSP}/rootfs ${TARGET_BSP}

I would also want to confirm the following with you:

  1. Do you connect an external NVMe drive?
    → Yes I can. Here’s the lsblk command result, which I believe showing that NVMe drive is accessible
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0          7:0    0    16M  1 loop 
mtdblock0     31:0    0    32M  0 disk 
mmcblk0      179:0    0  14,7G  0 disk 
├─mmcblk0p1  179:1    0    14G  0 part /media/username/4f038326-5816-44ff-b543-acefee456e45
├─mmcblk0p2  179:2    0    64M  0 part 
├─mmcblk0p3  179:3    0    64M  0 part 
├─mmcblk0p4  179:4    0   448K  0 part 
├─mmcblk0p5  179:5    0   448K  0 part 
├─mmcblk0p6  179:6    0    63M  0 part 
├─mmcblk0p7  179:7    0   512K  0 part 
├─mmcblk0p8  179:8    0   256K  0 part 
├─mmcblk0p9  179:9    0   256K  0 part 
├─mmcblk0p10 179:10   0   300M  0 part 
└─mmcblk0p11 179:11   0 199,1M  0 part 
mmcblk0boot0 179:32   0     4M  1 disk 
mmcblk0boot1 179:64   0     4M  1 disk 
mmcblk0rpmb  179:96   0     4M  0 disk 
zram0        252:0    0 647,9M  0 disk [SWAP]
zram1        252:1    0 647,9M  0 disk [SWAP]
zram2        252:2    0 647,9M  0 disk [SWAP]
zram3        252:3    0 647,9M  0 disk [SWAP]
zram4        252:4    0 647,9M  0 disk [SWAP]
zram5        252:5    0 647,9M  0 disk [SWAP]
nvme0n1      259:0    0 232,9G  0 disk 
└─nvme0n1p1  259:1    0 232,9G  0 part /
  1. Do you want to perform OTA update for internal eMMC or external NVMe?
    → As you can see the lsblk result above, we are using NVMe as our main device, so would like to update it on NVMe
  1. Do you enable redundancy rootfs (ROOTFS_AB=1) in R32.7.3?
    → No I haven’t. I just additionally followed the guideline just in case that could solve the issue. All the commands that I typed is exactly the same as this document.
    Software Packages and the Update Mechanism — Jetson Linux Developer Guide documentation

Please see below. These are the exact commands and that I executed sequentially:

mkdir R32.7.3
cd R32.7.3 # now we are in /home/username/R32.7.3 path
tar xpf ../Jetson_Linux_R32.7.3_aarch64.tbz2
cd Linux_for_Tegra/rootfs
tar xpf ../../../Tegra_Linux_Sample-Root-Filesystem_R32.7.3_aarch64.tbz2
cd ..
./apply_binaries.sh
BASE_BSP=$PWD #pwd path is set to /home/username/R32.7.3/Linux_for_Tegra

cd ..
cd ..
mkdir R35.4.1 
cd R35.4.1 # now we are in /home/username/R35.4.1 path
tar xpf ../Jetson_Linux_R35.4.1_aarch64.tbz2
cd Linux_for_Tegra/rootfs/
tar xpf ../../../Tegra_Linux_Sample-Root-Filesystem_R35.4.1_aarch64.tbz2 
cd ..
./apply_binaries.sh
TARGET_BSP=$PWD #pwd path is set to /home/username/R35.4.1/Linux_for_Tegra

cd .. # now we are in /home/username/R35.4.1 
tar xpf ../ota_tools_R35.4.1_aarch64.tbz2 
# move to the path /home/username/R35.4.1/Linux_for_Tegra
sudo ./tools/ota_tools/version_upgrade/build_base_recovery_image.sh jetson-xavier-nx-devkit-emmc R32-7 ${BASE_BSP} ${BASE_BSP}/rootfs ${TARGET_BSP}
/home/username/R32.7.3/Linux_for_Tegra /home/username/R35.4.1/Linux_for_Tegra
# this shows the following log

BOARDID=3668 FAB=100 BOARDSKU= BOARDREV= FUSELEVEL=fuselevel_production /home/user/R32.7.3/Linux_for_Tegra/flash.sh --no-flash -Z jetson-xavier-nx-devkit-emmc mmcblk0p1
SUCCESS: get dtbfile name "tegra194-p3668-all-p3509-0000.dtb"
Unpacking initrd ...
30412 blocks
/tmp/R32x_recovery/initrd_tmp/lib /tmp/R32x_recovery/initrd_tmp /home/username/R35.4.1/Linux_for_Tegra
Packing initrd ...
55642 blocks
/home/username/R32.7.3/Linux_for_Tegra/bootloader/mkbootimg --kernel /home/username/R32.7.3/Linux_for_Tegra/kernel/Image --ramdisk /tmp/R32x_recovery/R32x_initrd.img --output /tmp/R32x_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-7 target_board=jetson-xavier-nx-devkit-emmc "
Copy /tmp/R32x_recovery/recovery_sigheader.img.encrypt to /tmp/R32x_recovery/recovery.img.R32x
Copy /tmp/R32x_recovery/recovery_sigheader.dtb.encrypt to /tmp/R32x_recovery/recovery.dtb.R32x
Copy generated recovery image and dtb into /home/username/R35.4.1/Linux_for_Tegra/bootloader/
Finished

# and then I typed this command and got the log that I attached above
sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh jetson-xavier-nx-devkit-emmc R32-7

And the ota_payload_package.tar.gz file is generated.

And then on the target device, I investigated /boot/extlinux/extlinux.conf file and it looks like this.

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet root=/dev/nvme0n1p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 

# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
#      sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot

# LABEL backup
#    MENU LABEL backup kernel
#    LINUX /boot/Image.backup
#    INITRD /boot/initrd
#    APPEND ${cbootargs}

Because it already has INITRD set and also root= in APPEND already has the path /dev/nvme0n1p1, I didn’t change anything in this file.

So I installed the ota_tools and executed the following command

# move to /ota_workdir/Linux_for_Tegra/tools/ota_tools/version_upgrade path
sudo ./nv_ota_start.sh /dev/mmcblk0 /ota/ota_payload_package.tar.gz

Then the result is how I described in the earlier messages.

Thanks very much in advance. We are quite desperate to resolving this as soon as possible.

8

It seems not the expected result for me since you modify the extlinux to use NVMe as rootfs.

Please use the following command to flash the R32.7.3 to your exteranl NVMe SSD to use it as rootfs and then perform image-base OTA update to R35.4.1. (you should create OTA package for external NVMe)

$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -S 200GiB -c ./tools/kernel_flash/flash_l4t_nvme.xml --showlogs jetson-xavier-nx-devkit-emmc nvme0n1p1
9

Hi @KevinFFF Thanks for your response.

I tried to flash the R32.7.3 as you suggested exactly with the same command:

$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -S 200GiB -c ./tools/kernel_flash/flash_l4t_nvme.xml --showlogs jetson-xavier-nx-devkit-emmc nvme0n1p1

But came across the following error:

Error: Return value 4
Command tegraparser_v2 --generategpt --pt flash.xml.bin
Error: /home/bepro/R32.7.3/Linux_for_Tegra/bootloader/signed/flash.idx is not found
Error: failed to relocate images to /home/bepro/R32.7.3/Linux_for_Tegra/tools/kernel_flash/images
Cleaning up...

Please have a look at the full log attached.
flash_log.txt (30.4 KB)

I found a similar post here: Error flashing SSD: /Linux_for_Tegra/bootloader/signed/flash.idx is not found - #3 by KevinFFF
So I’m attaching the flash_l4t_nvme.xml file for your reference.
flash_l4t_nvme.txt (8.3 KB)

Thank you very much for your support.

10

Please refer to the following thread for the relationship about the size.
How to solve the issue that ssd are not entiely availiable after full disk encryption - #5 by KevinFFF

In your case, please modify the num_sectors from 60604416 to 461373440(*512/1024/1024/1024=220GiB) in flash_l4t_nvme.xml.
and flash with the same command.

1 Like
11

Hi @KevinFFF
Thanks for your advice. Now the flashing with this command

$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -S 200GiB -c ./tools/kernel_flash/flash_l4t_nvme.xml --showlogs jetson-xavier-nx-devkit-emmc nvme0n1p1

ends successfully after modifying the flash_l4t_nvme.xml file as you advised.

However, there’s another issue.
While trying to do ota update in the past, the process failed due to the reason that I initially asked in this post (cbo.dtb file was missed).
And since then the board was not booted anymore so I had to reflash it by connecting the problematic board with a host board via a USB cable and using Nvidia SDK Manager to flash. I selected Jetpack 4.6.3 (Jetson Linux 32.7.3) intentionally to set up the same environment with my other boards that are on the site.

By doing this, the board is again successfully booted.
And then I flashed again with the command that we discussed above, which ends successfully as I mentioned right above.

$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -S 200GiB -c ./tools/kernel_flash/flash_l4t_nvme.xml --showlogs jetson-xavier-nx-devkit-emmc nvme0n1p1

And then now I’m trying to run the OTA update once again with the following command:

sudo ./nv_ota_start.sh /dev/nvme0n1p1 /ota/ota_payload_package.tar.gz

But then I got this error now.

Command: ./nv_ota_start.sh /dev/nvme0n1p1 /ota/ota_payload_package.tar.gz
Current rootfs is on /dev/nvme0n1
init_ota_log /ota_log
Create log file at /ota_log/ota_20240228-032847.log
OTA_LOG_FILE=/ota_log/ota_20240228-032847.log
Extract /ota/ota_payload_package.tar.gz
update_nv_boot_control_in_rootfs /ota_work
3668-301---1--jetson-xavier-nx-devkit-qspi-
check_prerequisites
decompress_ota_package ota_package.tar /ota_work
decompress_ota_package: start at Wed Feb 28 03:29:18 EST 2024
Sha1 checksum for /ota_work/ota_package.tar (5135a3692f9fdf21b88adc960e0c5f3c0e04fa8a) matches
decompress_ota_package: end at Wed Feb 28 03:29:37 EST 2024
nv_ota_update_with_layout_change.sh /dev/nvme0n1
Command: nv_ota_update_with_layout_change.sh /dev/nvme0n1
duplicate_bct_copy
Copied 65536 bytes from address 0x00000000 in flash to /tmp/bct.bin.tmp
Erased 65536 bytes from address 0x00010000 in flash
Copied 65536 bytes from /tmp/bct.bin.tmp to address 0x00010000 in flash
Duplicating BCT image is done
check_bsp_version /ota_work BASE_VERSION
check_target_board /ota_work TARGET_BOARD
The board name in OTA package(jetson-xavier-nx-devkit-emmc) does not match current board(jetson-xavier-nx-devkit-qspi)
Failed to run "check_target_board /ota_work TARGET_BOARD"

Is there any issue while I flashed with Nvidia SDK Manager? Why the board is flashed with qspi even though I flashed again through l4t_initrd_flash?

Here I’m attaching the full log of the l4t_initrd_flash process as well for your reference.
l4t_initrd_flash.txt (147.9 KB)

12

Can you share the log when you are generating the OTA package before above steps?

Please also share the result of the following command on your board.

$ cat /etc/nv_boot_control.conf
13

Hi there,
I’m continuing this topic.
I successfully did the OTA update, but there are two problems:

  1. after the target device boots I have to set the user/password and regional setting to device have a fresh boot and can be accessible trough ssh. (I can not do this remotely for my other devices )

  2. I created the ota package using this command:

sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh --external-device nvme0n1 -S 228GiB jetson-xavier-nx-devkit-emmc R32-7

And expect it to be flashed in the external device, but the target device booted from internal storage.
PS: before doing the OTA on target device I modified the /etc/nv_boot_control.conf to this:

TNSPEC 3668-301-0001-G.0-1-2-jetson-xavier-nx-devkit-emmc-nvme0n1p1
COMPATIBLE_SPEC 3668-301---1--jetson-xavier-nx-devkit-emmc-
TEGRA_CHIPID 0x19
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
14

And BTW @KevinFFF
This is the output of fdisk -l /dev/nvme0n1

sudo fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 232.91 GiB, 250059350016 bytes, 488397168 sectors
Disk model: WD_BLACK SN750 SE 250GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5E47949C-11AD-43EA-B154-22462258E252

Device            Start       End   Sectors   Size Type
/dev/nvme0n1p1  1009488 488397128 487387641 232.4G Microsoft basic data
/dev/nvme0n1p2       40    131111    131072    64M Microsoft basic data
/dev/nvme0n1p3   131112    262183    131072    64M Microsoft basic data
/dev/nvme0n1p4   262184    263079       896   448K Microsoft basic data
/dev/nvme0n1p5   263080    263975       896   448K Microsoft basic data
/dev/nvme0n1p6   263976    392999    129024    63M Microsoft basic data
/dev/nvme0n1p7   393000    394023      1024   512K Microsoft basic data
/dev/nvme0n1p8   394024    394535       512   256K Microsoft basic data
/dev/nvme0n1p9   394536    395047       512   256K Microsoft basic data
/dev/nvme0n1p10  395048   1009447    614400   300M Microsoft basic data
/dev/nvme0n1p11 1009448   1009483        36    18K Microsoft basic data

As its about 232GiB I did the ota creation with -S 228GiB to make sure its not larger that the whole volume size, is it true?

15

You can refer to Skipping oem-config to run l4t_create_default_user.sh to pre-configure username/password in rootfs.

Does your board boot from internal eMMC or external NVMe before OTA?

Correct. Please also confirm the num_sectors in XML is between 232GiB and 228GiB.
You could refer to How to solve the issue that ssd are not entiely availiable after full disk encryption - #5 by KevinFFF for details.

16

Thank you @KevinFFF for the response
The pre-configured user/password fixed now
I’m a little confused about the xml?
according to /etc/nv_boot_control.conf my board chip id is: TEGRA_CHIPID 0x19
and the xml should be ${LINUX_BASE_DIR}/tools/kernel_flash/flash_l4t_t194_nvme.xml
but as I attached the xml, its using the constant value NUM_SECTOR.
I tried to change it to 488397168 ,like above messages here:

Disk /dev/nvme0n1: 232.91 GiB, 250059350016 bytes, 488397168 sectors

but after creating ota and applying it to target device, the device doesn’t boot. I’m a little confused with this sector topic :)

xml.tar.gz (1.4 KB)

17

Yes, it boots from external nvme before OTA

18

Can you share the log when you are generating the OTA package?

19

Hi @KevinFFF
This is the ota creation log which I modified the xml manually (and device never boot after ota)
ota_log_488397168_sector.txt (465.3 KB)

And this is the log which I left the xml as is ( num_sectors=“NUM_SECTORS” ) and with this ota package device updates properly but boots from internal storage
ota_log_num_sectors.txt (444.2 KB)

20

What did you modify in XML? only num_sectors? Or also other partitions?

copying cfgfile(/home/hossein/ota/r35/Linux_for_Tegra/tools/kernel_flash/flash_l4t_nvme.xml) to flash.xml... done.

flash_l4t_nvme.xml is the partition layout file when you are generating the OTA package.
Did you modify the num_sectors in this XML?

Please specify 488397168 as num_sectors in flash_l4t_nvme.xml.

21

Thank you @KevinFFF for the suggestion, I did modify that xml and create the ota package, but again when I install it in target machine, the machine does not boot :(