We flashed the Jetson Linux 35.1 image from sdk manager into ther Xavier NX devkit + P3668-0001 NX SOM (EMMC SKU). We used the NVP Model clock configuration tool for set the power mode to “20W-6 Core” and did the reboot stress test for testing system stabiblity. While testing more than 200 times , kernel cmd line was auto changed from
[ 0.000000] Kernel command line: root=/dev/initrd rw rootwait console=ttyTCU0,115200n8 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 sdhci_tegra.en_boot_part_access=1
…
[ 6.287818] Root device found: initrd
[ 6.289439] Mount initrd as rootfs and enter recovery mode
Finding OTA work dir on external storage devices
Checking whether device /dev/mmcblk?p1 exist
Looking for OTA work directory on the device(s): /dev/mmcblk0p1
Checking whether device /dev/sd?1 exist
This siuation caused kernel can’t switch from initrd to actual rootfs. It will always mount initrd as rootfs and enter recovery mode even we power on/off the device . Please help fix this issue , thanks jetpack502-boot fail.log (15.8 MB)
Thanks for reporting this issue. But could you help clean up your log to just keep the 1~2 reboot iterations near the issue happened point? No need to share us a 15MB log file. It is hard for us to check such log too.
It seems the issue would happen after you see “L4TLauncher: Attempting Recovery Boot” in the UEFI. Could you also test this again on your side and see if this is true?
Is this issue on devkit or your custom board?
If this is on your custom board, then of course some kernel panic may happen because some I/O may not exist on your carrier board. You need to modify the device tree. Same rule is even applicable on jetpack4.
Better providing more information about your board first.
We did the same reboot stress test again and the issue would happen after we saw the “L4TLauncher: Attempting Recovery Boot” in the UEFI. Follow your suggestion , attache the last 10 times test logs for reference.
HW configuration is same: Xavier NX devkit + P3668-0001 NX SOM jetpack502-3.log (731.2 KB)
There is a problem in HDMI driver and will cause panic. We are still checking.
And there is a mechanism to put board into recovery boot in rel-35.1. If kernel panic too many times, then it will happen.
To be honest I am not sure what’s going on with our hardware there. We have two Display Ports but when we plug in a Display it gets connected properly plus another 1024x768 HDMI Display is added, which is invisible and is next to the primary display. When we plug in a monitor on the second port it does not work at all. That seems to be a hardware issue that is going to be fixed in the next revision.
Does the patch you supplied only work under special circumstances? I reverted the patch and the display works again…