As far as I can tell from reviewing the code, if the lower 4 BYTES of the Status register( Update and Redundancy — Jetson Linux Developer Guide documentation ), which are the magic number, are not overwritten with FACE, they are initialized; if they are overwritten with FACE, initialization does not occur, and the retry counter progresses with each boot. Is my understanding correct that this magic number in the Status register resets to 0x4EF1 when power is lost, meaning it is volatile?
If I am mistaken and the information of FACE is retained even after the power is turned OFF/ON, then if the power is turned off during the time between the UEFI retry countdown process and the retry reset by service, etc., the retry countdown will progress, and if this is repeated, will it lead to a retry over?
Regarding the environment, it is set up with the Orin Nx mounted on the OrinNano sample board.
If there are any differences in specifications between the Orin Nano and Orin Nx, I would appreciate it if you could inform me about them.
I was aware that it’s possible to change the number of retries. I apologize if my poor English has caused any misunderstanding. My question was not about the issue of retry over, but rather I wanted to know the specifications to check whether retry over would occur depending on the nature of the work.
It seems you are using Orin NX module on the Orin Nano(p3768) devkit board.
It should be find with this combination, Orin NX and Orin Nano modules have the similar design.
What’s your Jetpack version in use?
I am currently using R35.3.1(Jetpack5.1.1) for verification. However, ultimately I plan to use R36.2(Jetpack 6.0), so if there are any differences, I would appreciate a response based on the specifications for R36.2.
Thank you for the information. However, unless I’m mistaken, I believe this information mainly describes the process of how the system fails over when the rootfs is truly corrupted.
What I am more concerned about are the finer details, specifically regarding the countdown for retries and the timing for resetting the count. In particular, I am curious if there could be cases of retry overflows due to the user’s method of operation, even when the rootfs is not corrupted. (For example, as mentioned earlier, if the count reset only occurs upon successful completion of the startup process, would turning the power OFF/ON during the interval from countdown to startup advance the count?)
Thank you for your response.
I understand now that the count is reset in a cold boot, including when the power is turned off.
Your answer has resolved my question.