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
Hi,
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
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
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
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
Hi,
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.
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
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
