L4T R28.3.2 doesn't update to L4T 28.4

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

When I tried to update the bootloader(L4T R28.3.2’s enviroment) to a recently released version(L4T R28.4), it failed with flowing log.
I think this error is due to the different bpmp-fw-dtb partition sizes in R28.3.2 and R28.4.
Is there any way to avoid the error?

# nv_update_engine --install
A/B-Redundancy Update tool Version 1.1.02
current slot 0
Start updating slot 1
Tegra User Block Device: /dev/disk/by-partlabel
Tegra Boot Block Device: /dev/mmcblk0boot0
HEADER: MAGIC NVIDIA__BLOB__V2
HEX_VALUE 131072
BLOB_SIZE 5144992
HEADER_SIZE 48
NUMBER_OF_ELEMENTS 16
HEADER_TYPE 0
UNCOMP_SIZE 5144992
MB1_RATCHET_LV 0
MTS_RATCHET_LV 0
ROLLBACK_FUSE_LV 0
Device TN Spec: 3310-B02-1-0-jetson-tx2-mmcblk0p1
Device is fused board.
ENTRY_TABLE:
PART  POS  LEN  VER TNSPEC TYPE UPDATABLE
bpmp-fw  1968  533904  2    1  1
sce-fw  535872  76992  2    1  1
cpu-bootloader  612864  295488  2    1  1
mb2  908352  104480  2    0  1
spe-fw  1012832  81936  2    0  1
secure-os  1094768  67296  2    1  1
kernel  1162064  491920  2    1  1
mb1  1653984  99632  2    2  1
mts-bootpack  1753616  2082144  2    1  1
mts-preboot  3835760  63104  2    0  1
sc7  3898864  22576  2    1  1
BCT  3921440  3584  2  3310-B02-1-0-jetson-tx2-mmcblk0p1  2  1
MB1_BCT  3925024  50160  2  3310-B02-1-0-jetson-tx2-mmcblk0p1  0  1
bpmp-fw-dtb  3975184  604944  2  3310-B02-1-0-jetson-tx2-mmcblk0p1  1  1
bootloader-dtb  4580128  282432  2  3310-B02-1-0-jetson-tx2-mmcblk0p1  1  1
kernel-dtb  4862560  282432  2  3310-B02-1-0-jetson-tx2-mmcblk0p1  1  1
Writing 533904 bytes to /dev/disk/by-partlabel/bpmp-fw_b for bpmp-fw
Writing 76992 bytes to /dev/disk/by-partlabel/sce-fw_b for sce-fw
Writing 295488 bytes to /dev/disk/by-partlabel/cpu-bootloader_b for cpu-bootloader
mb2 write: slot = 1 offset = 1253888 bytes = 104480
spe-fw write: slot = 1 offset = 860672 bytes = 81936
Writing 67296 bytes to /dev/disk/by-partlabel/secure-os_b for secure-os
Writing 491920 bytes to /dev/disk/by-partlabel/kernel_b for kernel
Writing 2082144 bytes to /dev/disk/by-partlabel/mts-bootpack_b for mts-bootpack
mts-preboot write: slot = 1 offset = 1778176 bytes = 63104
Writing 22576 bytes to /dev/disk/by-partlabel/sc7_b for sc7
MB1_BCT write: slot = 1 offset = 622592 bytes = 50160
bpmp-fw-dtb slot: 1 is corrupted
bpmp-fw-dtb fail to write
Writing to partitions failed.
OTA Blob update failed. Status: 3
Slot 1 update failed
2

I will suggest that you clone the rootfs, and then do a full flash with R28.4 (but reuse the clone image instead of generating a new rootfs). Be sure you keep a safe copy of the rootfs. If the rootfs is not the default size, then you would need to use the “-S size” argument to set that up. Other partitions differing in size would indeed cause a failure, but a full flash (reusing rootfs) would probably “put things back together” using correct partition layout. You are never guaranteed that one release will be compatible with another, even in patch fix releases (odds are high that the rootfs of R28.3.2 would work with a patch release, its the other content which likely does not work together).

3

Hello linuxdev.
Thanks for the reply.

To give you some background on my question, our software will be updated to R28.4 to support PCN_206440. we have already shipped products to our customers and we were testing to see if our customers could update product’s software(R28.3.2 to R28.4).

I understand that R28.4 is not backwards compatible and therefore only the rootfs update is recommended, correct?

An additional question: is there any way to update from R28.3 to R32.4 other than full flash?

4

In the case of a bug patch release it is possible that you can reuse the clone, but it is also possible that the bug fixes would be mixed in the rootfs. You’d have to examine the change logs to know what updates involve boot versus when running Linux. See:
R28.4 Release Notes
R28.2.3 Release Notes

I would say test using the driver package with command line flash and reusing your clone to see what works or fails. Just let it flash everything, but use “-r” and put your clone in at “bootloader/system.img” prior to flash. Skip the “sudo ./apply_binaries.sh” since your rootfs already has this. It might not work, but a simple patch release has a good chance of succeeding.

Going from R28.x to R32.x has no possibility other than full flash. Boot changes dramatically across those releases, and support for various CUDA releases will also change. This doesn’t mean it isn’t useful to have a clone for repopulating your own custom work, but basic operating system files would need to come from the flash to R32.x.

5

Hello linuxdev

I understand your comment.
You’re right, I tried to work with system image that combine R28(bootloader) and R32 (kernel , rootfs) , but it did not work well.
I will close ISSUE with this comment.

Thank you.