Nv_update_engine replication fails

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hi,

With TX2 I have A/B + redundancy ON.

Here’s my smd_info.cfg

#
# Config 1: Disable A/B support (Default)
#

# slot info order is important!
# <priority>    <suffix>     <retry_count>  <boot_successful>
#15                  _a          7               1

#
# Config 2: Enable redundancy support (by removing comments ##)
#
< REDUNDANCY_USER 1 >

# slot info order is important!
# <priority>    <suffix>     <retry_count>  <boot_successful>
15                  _a          7               1
14                  _b          7               1

I also have rootfs A/B and the same image flashed on APP and APP_B partitions. The rootfs partitions switching is done in u-boot.

Each partition has the same payload file copied at /opt/ota_package/bl_update_payload

I’m now installing the same payload on top of the existing.

At the first boot I can see A/B being configured properly and slot 0 is active

 ~ # nvbootctrl dump-slots-info
magic:0x43424e00,             version: 3             features: 3             num_slots: 2
slot: 0,             priority: 15,             suffix: _a,             retry_count: 7,             boot_successful: 1
slot: 1,             priority: 14,             suffix: _b,             retry_count: 7,             boot_successful: 1

Then I apply the update

~ # nv_update_engine -i
Nvidia A/B-Redundancy Update tool Version 1.2
current slot 0
Start updating slot 1
…
Update successful
Setting slot 1 as active boot slot
Rebooting system…10.9.8.7.6.5.4.3.2.1

The system reboots on slot 1

~ # nvbootctrl dump-slots-info
magic:0x43424e00,             version: 3             features: 3             num_slots: 2
slot: 0,             priority: 0,             suffix: _a,             retry_count: 0,             boot_successful: 0
slot: 1,             priority: 15,             suffix: _b,             retry_count: 7,             boot_successful: 1

But then the replication fails

~# nv_update_engine -v
Nvidia A/B-Redundancy Update tool Version 1.2
verifying update
The current slot 1 is marked as boot successful
SM: S22
Previous update on slot 0 failed

How can I know why?

Note: I’m using L4T 32.0 but had to use the cboot sources for 28.2 since the sources are missing for 32.2.

3

Hi,

I would suggest to wait for tx2 32.4.2 cboot source to release.
It is not good to use rel-28 cboot on rel-32.4.2 BSP.

Also, I am wondering why do you want to use nv_update_engine on APP A/B partitions? nv_update_engine should not know the existence of them but only u-boot is able to choose the rootdev.

4

@WayneWWW do you have information about release date for 32.4.2?

Will the cboot sources work with 32.2.0? I’m stuck with that release for some time.

nv_update_engine doesn’t know anything about A/B rootfs, only bootloader. u-boot selects the rootdev as you said.

But in order to do that, I need to know the active slot. Enabling this in cboot to get the extra cbootargs for slot prefix seems to be the only way. Or do you suggest some other ways?

5

Hi lfdm,

Will the cboot sources work with 32.2.0? I’m stuck with that release for some time.

No, it would only work with rel-32.4.2.

nv_update_engine doesn’t know anything about A/B rootfs, only bootloader. u-boot selects the rootdev as you said.

The update engine should be able to know the current slot. When it detects as A slot, you could set uboot to load APP_A and when it is B, you could load APP_B.

7

@WayneWWW I moved on to Xavier AGX to continue my test. And I have a configuration with cboot only (u-boot removed).

There I now can see that cboot loads the correct APP partition without any modification:

  • APP for slot 0
  • APP_b for slot 1

After updating the bootloader, I also get this error, but only when the APP_b exist

~# nv_update_engine -v
Nvidia A/B-Redundancy Update tool Version 1.2
verifying update
The current slot 1 is marked as boot successful
SM: S22
Previous update on slot 0 failed

I believe now the issue is that nv_update_engine creates /opt/ota/entry_table file in the slot installing the bootloader update, let say APP. As the slot changes at the next boot, /opt/ota/entry_table is missing in APP_b and the update verification fails.

Is there a way to disable the 10 sec count down so I could copy /opt/ota/entry_table to the other slot after updating the bootloader?

8

Hi,

For xavier, please refer to

9

Is there a way to disable the 10 sec count down so I could copy /opt/ota/entry_table to the other slot after updating the bootloader?

There is a “no-reboot” option you can add to nv_update_engine --install to disable the automatic reboot after it finishes.