L4TLauncher: would like to avoid being bricked when both A & B slots are marked as 'unbootable'

Current behavior is to try booting a slot MAX tries (3) before marking it as ‘unbootable’ and then switching to the alternate slot and booting it MAX tries (3) before marking it as ‘unbootable’ as well. At this point you’re bricked and you have to ask the customer to swap units. We’ve seen scenarios where it would be useful if the device would simply retry alternating between A & B slots (A → A → A → B → B → B → A → A → A, etc.) in the event that the failure to boot is caused by something external. In our case a certain type of display was hooked up to the device that caused the display driver to crash before the boot could be marked as successful. Could the team consider making the ‘retry forever’ approach a configurable behavior?

hello chad.mcquillen,

Normally, if one of slot is unbootable, the kernel watchdog will reboot the device, and if fails to boot into it for consecutive 3 times, then the UEFI try to boot from another slot.
anyways,
let me double confirm, are you talking about bootloader A/B or Rootfilesystem A/B?

RootFS A/B

hello chad.mcquillen,

since it’s UEFI try to boot from another rootfs slot, you may also restore corrupted rootfs slot via UEFI.
please refer to Topic 247290.

In the scenario I described the alternate slot would also quickly exhaust its boot retries and be marked as ‘unbootable’ at which point the device is bricked. It is not practical to have the end customer perform the recovery steps nor cost effective to send someone out to do it. The device will have to be swapped out. Our options are a) bank (hope?) on this being a low frequency outcome and perform device swaps as needed, b) NVIDIA’s development team consider the scenario and make a behavior change, or c) we patch UEFI to get the behavior that we want.

hello chad.mcquillen,

the real use-case is… you eventually want to have updating RootFS via OTA, right?
so, you may using OTA tool package to create the OTA payload package correctly before sending out.

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