[r35.4.1][Jetson] system reboot error

Dear Nvidia developers

I use the core board of AGX combined with our own designed motherboard. After repeatedly rebooting four or five times, I will not be able to enter the system and get stuck in the shell command line of BIOS. Could you please help me check what the situation is?

[Com COM9] (2024-01-25_110726).log (156.5 KB)

How did you build the UEFI? It seems you are using a version that does not match to the release version.

I am using the debug version,But the debug version was compiled from this branch,
debug bin is ./images/uefi_Jetson_DEBUG.bin

nvidia-uefi-r35.4.1-updates [r35.4.1] (develop-agx-orin-35.4.1)$ ls
Build Conf edk2 edk2-non-osi edk2-nvidia edk2-nvidia-non-osi edk2-platforms images repo reports venv

If you think there is a problem with the debug UEFI, I can try switching back to the release UEFI and then try again


One question here, does the board ever boot into system or not? I am just not sure about the scenario of the log you shared.

The board will not boot into the system and will open on the shell command line of UEFI. This is caused by repeatedly rebooting several times. After burning the image for the first time, it can enter the system. In addition, I made two toilets

  1. At present, I can still enter recovery mode through flash.sh,
  2. If the app image is burned separately, sudo/ Flash. sh - k APP Jetson agx orin devkit internal is also unable to boot into the system

Could you share me the boot log since your first flash + boot and until the crash happened?

Sure, but it will take me half an hour because the burning process is a bit slow

BTW, please just do full flash but not only APP partition.

Of course, after all, burning the APP partition does not allow access to the system

Currently, two situations have been identified in the reproduction process

  1. One is to use SDK to burn and find that after restarting three times, it will enter recovery mode
  2. Another way is to use the method of detaching the image to burn and find that after restarting three times, it stops in the uefi shell

reboot 3 times enter recovery mode.log (1.4 MB)
reboot 3 times enter bios shell.log (872.1 KB)

Additionally, by comparing normal startup with the other two abnormal modes, I found that both abnormal situations are caused by automatically entering recovery mode

Why do I try to enter recovery mode after manually restarting three times? Is it a protective mechanism? Should the protection mechanism not switch from partition A to partition B?

When the boot failure in consecutive 3 times, it will enter recovery boot. This is not equal to recovery mode.

Are you talking about you enter the recovery boot with no reason and you want to know why?

Could you try to narrow down what is the exact issue you want to ask here but not increasing the problems?

We only discuss one issue in one topic. Please clarify what is the exact error you want to ask.

Now I have obtained the following results through comparison

  1. By unplugging and unplugging the power, it can be turned on many times and enter Ubuntu normally
  2. After using reboot for the fourth time, it will enter recovery mode, but you can reset this reboot count by flashing QSPI to start up normally. The command is as follows

sudo ./flash.sh -r --no-systemimg -c bootloader/t186ref/cfg/flash_t234_qspi.xml jetson-agx-orin-devkit internal

My question is: How to prevent the test engineer from entering recovery mode when they need to perform a reboot stress test now

There is a systemd service that will be run in each boot. You stress test/reboot has to be executed after that service is done.

Thus, please wait for at least 30 sec before reboot after each boot up.

1 Like

sudo systemctl status nv-l4t-bootloader-config

You have to make sure this service is up before you can reboot the device.


Thank you for WWWandYYY. After verification, it was found that all you need to do is write a service located in nv-l4t bootloader configuration and sleep for 30 seconds after startup

This issue can be closed

1 Like

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