Logic for retry count

Hello,

I am using Jetson Xavier NX devkit(l4t version: r3273).
In this post, I learned about the logic for retry count for l4t version R35.3.1(Jetpack5.1.1): Reset Timing of Boot Retry Count - Jetson Systems / Jetson Orin NX - NVIDIA Developer Forums.

  1. boot up to L4TLauncher → initialize the retry_count
    a. if cold boot: retry_count=MAX
    b. if warm boot: retry_count=value in Scratch register
  2. retry_count-- (in Scratch register) in L4TLauncher
  3. boot to kernel successfully, the background service<nv-l4t-bootloader-config.service> clear the retry_count value in Scratch register

Now I would like to know, for l4t version R32.7.3(JetPack 4.6.3), is the logic for retry count the same as R35.3.1?
Thanks very much.

Hi qian.yuan,

R32.7.3(JetPack 4.6.3) still uses CBoot(no UEFI / L4TLauncher), so the implementation is not exact the same as R35.3.1.

However, the high-level behavior (“limited number of retries per slot, switch to the other slot, clear the counter after a successful boot”) is similar to R35.3.1, but the details and components involved are different because R32.7.3 is CBoot-based rather than UEFI-based.

Hello,
Thanks for your reply.
During my own testing, I found that for version R32.7.3, the service which is used to reset the retry count appears to be nv_update_verifier.service rather than nv-l4t-bootloader-config.service. I would like to confirm whether my finding is correct? (I have enabled unified bootloader AB and rootfs AB).

Yes, your understanding is correct.

On R32.7.3 / JetPack 4.6.3 (CBoot, non-UEFI) the retry counter is reset by nv_update_verifier.service, not nv-l4t-bootloader-config.service (that service only exists in the UEFI/L4TLauncher flow on R35.x).

The sequence is:

  • CBoot decrements the rootfs A/B retry_count on failed boots.
  • After a successful boot, nv_update_verifier.service runs and calls nv_update_engine --verify, which then restores the retry_count and updates the slot status.