@JerryChang , I am running Jetpack 4.6. So far, it seems all the answers you have provided are for Jetpack 5.x, which are not helping me. (While I appreciate the help, my current system is on Jetpack 4.6, and I would like to stay on Jetpack 4.6. Otherwise, I would have to reconfigure everything from scratch if I go to some other version of Jetpack).
However, for the sake of testing, I switched to Jetpack 5.1. But the A/B redundancy is not failing over to slot B in Jetpack 5.1 as well (as mentioned in my previous comment).
However, in Jetpack 5.1, when connecting display, we get a shell prompt, where we can enter the commands (I assume that the system booted into recovery mode instead of booting from slot B).
In this shell, I rebooted manually 3 times by entering the “reboot” command, after which the system eventually booted from slot B.
My question is this: why is this not happening automatically like it is supposed to? If the switch to backup slot does not happen automatically, then this feature is not useful at all, since in an embedded system environment, we do not expect to interact with the Jetson. Human intervention is not an option, we wish it to failover to slot B automatically, as it should.
Regarding your last reply with the results being unpredictable when using dd command, I have also seen the following post by @seeky15 , who is NOT using dd command, but removing the rootfs, and the failover is not working for seeky15 as well.
Note that this process of removing rootfs was working for @seeky15 in Jetpack 5.0.2, as can be seen in the following post:
What changed in Jetpack 5.1? Why does it not work anymore? Additionally, if the dd command method is wrong, then please guide me as to how I can test whether the failover mechanism is working or not? (Since removing the rootfs is not working either, as evidenced by seeky15’s testing).
And how can we expect it work in a real environment, where the nature of data corruption is random?
I have also tried corrupting the rootfs A slot from about 1MB in (was previously corrupting from 10kB in the APP partition). (sudo dd if=/dev/zero of=/dev/mmcblk0p1 bs=1k seek=1024 count=4k), but same result. It still does not failover to slot B.
Additonally, where is the kernel watchdog stored? Where is the scratch register stored? In the rootfs partition? Or in some other partition? Please advise as how to proceed. How to do I test this feature if not by using dd command? (Note: Any help would be welcome, whether it is for Jetpack 4.6 or Jetpack 5.x, as I would like to successfully implement this feature first and foremost, even though staying on Jetpack 4.6 is preferred).