32.6.1 > 35.3.1 OTA flash fails for unknown reason

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

I built an OTA update for a large number of devices that are generally identical, running 32.6.1. So far, all devices have accepted the package without issues and updated property. One particular device appears to be working but reboots back in to the old OS. I don’t have physical access to this device and the ota_log doesn’t indicate anything unusual. Any ideas or ways that I could enable additional logging?

I thought that secure boot could be enabled but it doesn’t look like it:

./tegrafuse.sh
odm_lock : 0x00000000
arm_jtag_disable : 0x00000000
odm_production_mode : 0x00000000
boot_security_info : 0x00000000
odm_info : 0x00000000

Here is the end of the log from /ota_log:

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 (2567b9ab5f3591715655386f385818c3fa2ba4fe) 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 (bc98846cb0a355594865d48b5a4f62248f191f33) matches
Backed up recovery and recovery-dtb partition under /ota_work before writing them
Writing base recovery image into /dev/mmcblk0p30
Read back base recovery image into /ota_work/image.tmp and verify it
Reading 47687680 bytes from /dev/mmcblk0p30: 1KB block=46570 remainder=0 offset=47687680
Verifying image /ota_work/image.tmp with sha1 chksum file /ota_work/recovery.img.R32x.sha1sum
Sha1 checksum for /ota_work/image.tmp (2567b9ab5f3591715655386f385818c3fa2ba4fe) matches
Writing base recovery dtb into /dev/mmcblk0p31
Read back base recovery dtb into /ota_work/image.tmp and verify it
Reading 179184 bytes from /dev/mmcblk0p31: 1KB block=174 remainder=1008 offset=178176
Verifying image /ota_work/image.tmp with sha1 chksum file /ota_work/recovery.dtb.R32x.sha1sum
Sha1 checksum for /ota_work/image.tmp (bc98846cb0a355594865d48b5a4f62248f191f33) matches
write_kernel_bootctrl /ota_work
Backed up kernel-bootctrl partition under /ota_work before writing them
Writing bootctrl update file into /dev/mmcblk0p32
Read back bootctrl update file into /ota_work/image.tmp and verify it
Reading 20 bytes from /dev/mmcblk0p32: 1KB block=0 remainder=20 offset=0
OTA preprocess has been completed. OTA will be automatically started once device is rebooted

Thanks!

3

Hi,
Please refer to steps in the page to try image-based OTA:
Jetson/L4T/peripheral/ - eLinux.org

5

Hi brian166,

What’s your BASE and TARGET version for OTA?

We would like to check the OTA update log in serial console after you run the reboot command to trigger update.

6

I’d like to see the serial console as well but I don’t have any access to the device :)

I’m also using the image based OTA, with many other devices working successfully.

Unfortunately I bricked this one last night trying some nuclear options. I know what I did so whenever I get it back I can probably replicate this again just for the knowledge of why it isn’t working.

8

It seems OTA update could work with most of your devices.

Are you using the same OTA package for all devices?
We would need to check the full serial console log during OTA update so that we would know what happen inside.

9

Yeah, same OTA package - I’ll get this device back at some point and follow up on this thread when I can look at the serial console.

1 Like