Cboot cannot find partition SMD after upgrade using nv_update_engine

We’re seeing some weird intermittent problems where the boot partition is corrupted after an update.

We are upgrading the OS of units which have initially been tegraflashed using Jetpack 3.2.1 to an OS built using Jetpack 4.4.
Upgrading from 3.2.1 to 4.4 seems to go OK (I’m not totally certain though, I have not tested this as much as the next part).
The problem occurs when doing another OS upgrade, from 4.4 to 4.4.

When we copy the update-image to the unit before upgrading using USB (either SFTP or MTP), there seems to be a ~5% chance that the boot-partition is corrupted during/after the upgrade.
When we don’t actively use the USB-bus, but instead use an update-file located on the EMMC, there’s a ~0.1% chance that the boot-partition gets corrupted.

Our upgrade process is as follows:

  1. Figure out if we need to update to partition_name or partition_name_b
  2. Copy new rootfs and kernel image to APP partition
  3. Copy boot partition content. Since we’re updating a unit tegraflashed using an old Jetpack, we can’t use nv_update_engine. Instead we copy the files from the BUP-payload to the following partitions:
  • /dev/disk/by-partlabel/cpu-bootloader
  • /dev/disk/by-partlabel/kernel
  • /dev/disk/by-partlabel/kernel-dtb
  • /dev/disk/by-partlabel/bootloader-dtb
  • /dev/disk/by-partlabel/bpmp-fw
  • /dev/disk/by-partlabel/sce-fw
  • /dev/disk/by-partlabel/sc7
  1. Call nvbootctrl set-active-boot-slot
  2. Reboot

When the boot-slot is 1 and the SMD partition is broken, CBoot will fail a number of times, and then fallback to boot-slot 0.

I am certain that the integrity of the update file is OK. We verify the SHA256-checksum of image and binaries before upgrading.

Does anyone have an idea of what might be going on here?

I have attached the log of a failing cboot:
tx2-boot-partition-failure.log (75.4 KB)

Not pretty sure about what you are doing exactly. What was your method to update 3.2.1 to 4.4?

And what is the purpose to change bpmp-fw and sce-fw from 4.4 to 4.4? What does that mean? As there is no release source for these, I don’t quite understand why these two gets changed.

Our upgrade-method from 3.2.1 to 4.4 is the same as listed above. Please note that for this 3.2.1->4.4 upgrade we’re using nvbootctrl v1.1. Subsequent updates from 4.4->4.4 use nvbootctrl v1.2:

  1. Figure out if we need to update to partition_name or partition_name_b
  2. Copy new rootfs and kernel image to APP partition
  3. Copy boot partition content. Since we’re updating a unit tegraflashed using an old Jetpack, we can’t use nv_update_engine. Instead we copy the files from the BUP-payload to the following partitions:
  • /dev/disk/by-partlabel/cpu-bootloader
  • /dev/disk/by-partlabel/kernel
  • /dev/disk/by-partlabel/kernel-dtb
  • /dev/disk/by-partlabel/bootloader-dtb
  • /dev/disk/by-partlabel/bpmp-fw
  • /dev/disk/by-partlabel/sce-fw
  • /dev/disk/by-partlabel/sc7
  1. Call nvbootctrl set-active-boot-slot
  2. Reboot

We upgrade these binaries because we’re trying to mimic what nv_update_engine seems to be doing.

I have no idea what upgrading the bpmp and sce actually means… It took a lot of trial and error to figure out which binaries needed an upgrade from 3.2.1 to 4.4, and which not. I’m not sure if we tried not updating the bpmp and sce binaries.

When going from 4.4 to 4.4 upgrading the binaries is probably not needed. I could check and see what happens when we don’t upgrade these files in 4.4->4.4 upgrades.

Something else that could be interesting: I tested nvbootctrl by toggling the active-boot-slot 250x, and then rebooting. I have not seen any failures after ~12000 calls to nvbootctrl.

There is no any method that supports to upgrade jetpack 3.x to jetpack4.x at this moment. We cannot guarantee if your upgrade using nvbootctrl will work or not.

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