Hello NVIDIA engineers:
Orin won’t boot after successive reboots
I have a problem with the Jetson agx orin (Jetson R35.2.1):
After executing “sudo reboot” three times in a row in the uart terminal, the rootfs fails to boot with the following error log:
This seems to be the same problem as the one I encountered in this post
We used R35.3.1 and R35.2.1 and did not find that sudo reboot would detect this situation when the device was not powered on.But why do we find this situation when using R35.3.1 and R35.2.1 on our custom devices? Can we turn it off without the need for a protective mechanism?
This is very important for our use. Could you please help us analyze how to avoid it.
The attachment uart_log.txt is a printout of the last “sudo reboot” that resulted in a recovery boot. uart_log.txt (87.2 KB)
Let’s try to configure sudo ROOTFS_RETRY_COUNT_MAX=3 . /flash.sh xxx but it didn’t do anything.
Can you give us some advice on how to troubleshoot this, or is there a way to disable the Recovery boot mechanism.
It is a one time service, and it seems the status=0 and SUCCESS in both cases.
Could you help to run the reboot test as following steps to verify on your custom board?
1. power on the target(this is a cold boot, this is must)
2. check the background service status:
$ sudo systemctl status nv-l4t-bootloader-config
3. do 1st reboot target only when the service status is SUCCESS
4. login in target, and check the background service status,
5. do 2nd reboot target only when the service status is SUCCESS
6. login in target, and check the background service status,
7. do 3rd reboot target only when the service status is SUCCESS
8. login in target, and check the background service status,
9. do 4th reboot target only when the service status is SUCCESS
..
(i.e. make sure the background service status is SUCCESS before rebooting the target.)
I was testing the official NVIDIA image and found that the nv-l4t-bootloader-config service is SUCCESS immediately after booting.
I was testing our custom image and noticed that the nv-l4t-bootloader-config service seems to become SUCCESS after some time after booting (maybe 1-2 minutes after booting).
Comparing with the official NVIDIA image I only modified the /boot/dtb/kernel_tegra234-p3701-0004-03737-0000.dtb file. Can modifying the device tree cause the service to start slowly?
Do you have any idea what this might be due to?
Hello Kevin,
No boot self-start services such as rc.local were being used.
I found where the device tree problem was.
It’s in sources/hardware/nvidia/platform/t23x/concord/kernel-dts/cvb/tegra234-p3737-0000-a04.dtsi. when I change here to ‘disable’, it gives the nv-l4t-bootloader -config service starts slowly. After I modify it to ‘okay’, the service can start directly after booting again, but a new problem occurs, the kernel prints the error log: uart_log_error.txt (110.4 KB)
After I changed the device tree to ‘disable’, rebooting again does not print the error log, but there is a problem with the nv-l4t-bootloader-config service starting slowly after booting.
hello,
Have not customized the usb.
I don’t have a clue about this kernrl print error at the moment, investigating the previous issue might be a breakthrough.
Resolve slow loading of nv-l4t-bootloader-config service.
Can you help to find out why the slow loading of the nv-l4t-bootloader-config service occurs after modifying the “status of tegra_xudc = “disabled”;”? I was able to reproduce the slow loading of the nv-l4t-bootloader-config service by using devkit + the official NVIDIA L4T image and then modifying the NVIDIA default device tree file: ‘status’.
