Orin Nx boots fail

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
,
1

One device can’t boot succefully after normal shutdown.
Attached is the uart log.
dmesg_orin_nx16g_L4T35_4_1.txt (91.4 KB)

1.It can’t reach the login , but when I insert an USB device, I can see some USB
messages from uart.I think the kernel is alive.
2.I use fack to repair the rootfs, but it does not help.
3.The device can boot sucefully after I use the “l4t_backup_restore.sh -e nvme0n1 -b jetson-orin-nano-devkit” to backup,.

Do you have any idea of this case ?

[Device information]
1.Orin Nx 16G module
2.L4T 35.4.1
3.Customized carrier board
4.128G Gen3x1 PCIe SSD

3

Hi jb035.cheng,

[   13.442559] imx219: probe of 10-0010 failed with error -121
[   13.450190] fusb301: probe of 1-0025 failed with error -22

Do you get above errors when you can boot up before?

Is the custom carrier board designed by you?
Have you also tried with the latest R35.6.0?

What do you mean here? When the board can not boot successfully, it would work after you perform backup for NVMe SSD from host?

4

Yes, these two error messages are fine on our board. It’s normal on our carrier board.
Yes,Carrier board is designed by ourself.
No, we just follow up to L4T 35.4.1 for our carrier board.

Yes, I let the orin nx enter recovery mode, and execute the Linux_for_Tegra/tools/backup_restore/l4t_backup_restore.sh
on my host (Ubuntu 20.04 x86_64) desktop to backup the SSD to Linux_for_Tegra/tools/backup_restore/images folder.
After finishing the backup script, I power off and on to reboot the Orin Nx.
Then the login GUI is appeared, and I can login successfully.
I also reboot five times, all of them can login successfully.

5

Using backup/restore script from host may not relate to whether the board can boot up or not.

I’m curious about the state when you hit the issue.
Would it work if you just simply perform a reboot?

Have your also tried to reproduce the similar behavior on the devkit?

We would suggest updating to the latest R35 release (i.e. R35.6.0 currently).

6

No, it would not reach login if I just perform a reboot.
I perform “simply reboot” more than 10 times, all of them(simply reboot) can’t reach the login.

[Test1]
I also use another device B (device A is the fail one)to do the cross test.
1.1. A.orinnx_module + A.SSD : login fail.
1.2. B.orinnx_module + B.SSD : login successfully.
1.3. A.orinnx_module + B.SSD : login successfully.
1.4. B.orinnx_module + A.SSD : login fail.
The cross test can prove the A.orinnx_module is fine, but A.SSD is incorrect.

[Test2]
I mount the rootfs of A.SSD to Linux_for_Tegra/rootfs , and do the flash procedure to device B. Device B can login after flash procedure, but Device A still fail to reach login.

[Test3]
I think the rootfs of A is fine, so I think maybe some partitions are broken of A.SSD
I want to do a test to backup all the partitions of device A, and restore to device B.
Then I do the backup procedures to save all the partitions of A.SSD to my host desktop.
But after I do the backup procedures of device A, device A can login successfully after rebooting.

7

Yes, it seems something in A.SSD corrupted.

Do you have steps to reproduce the issue? (i.e. is the issue reproducible?)
Or could you reproduce the issue with B.SSD?

8

But when I do the [Test2], the rootfs semms fine to flash to device.B.
I can’t reproduce now, I will try to reproduce.
Customer just power off device, and power on on next day.Then the issue occures.
I can’t reproduce with B.SSD.

9

Sorry that I’m not clear about [Test 2].
Do you use Device B+A.SSD and reflash it and it can boot up successfully?

10

Some of our customers installed the x86_64 packages to device, so I want to check if all the system files of partition rootfs.A are fine. Below are my procedures
1.remove the rootfs folder in Linux_for_Tegra on host ubuntu 20.04 x86_64 desktop
2.mkdir rootfs folder in Linux_for_Tegra
3.mount rootfs partition of SSD.A to Linux_for_Tegra/rootfs folder on host desktop.
4.Let device.B enter recovery, and execute flash script.
5.Device.B can see the login GUI, and has two accuounts.
(Our default rootfs(remove on step1) has only one account, I can see two accounts which
means the roootfs is customer’s )
6.Put the SSD.A to device.A, the device.A still can’t boot successfully.

Since the device.B can work correctly, I think the file system of SSD.A is fine.
Then I do the [Test 3] to verify the partitions of SSD.A

11

Okay, thanks for your explanation.

We have not hit similar issue before.
It seems more like something in SSD.A disk corrupted since you also can not reproduce the issue with SSD.B.
We would need a clear reproduce steps so that we can verify and debug further on the devkit.

13

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