We went through the steps of manually installing the OS on our Jetson Xavier NX via USB and after installation, it booted into the OS just fine (full desktop and all). I connected to it from another PC with SSH and enabled VNC (Vino), then did an apt update/upgrade then rebooted to get Vino running cleanly. Unfortunately, after issuing the ‘sudo reboot’ after enabling Vino, the unit didn’t come back up. It looks like it’s stuck in force recovery mode but we can’t confirm that since the Ubuntu 18.04 PC we used to flash it is no longer available to us.
A few questions:
- How can we verify that it’s actually booting into Force Recovery mode?
- Is there a way to make sure it does NOT boot into Force Recovery mode when we apply power?
- Can we run the sdkmanager or manually flash the board from a virtual machine on a windows host?
Generally, it will not go to “recovery mode” that easily.
If your only way fo access the board is through ssh or vino, then any kind of reason can make you fail to access the board. For example, maybe the ethernet connection is gone.
I didn’t mean this is definite ethernet issue, just want to let you know that your problem has lots of kind of causes which we cannot tell
You should clarify what kind of interface you are able to use now. If you deploy the board in somewhere else with only ethernet connection, then we may have no method.
SSH or Vino are not the only way we’re accessing it. We have a physical monitor, keyboard, and mouse connected to it, I’m just remotely doing the development on it.
When last rebooted, the led on the board came on but didn’t display anything on the HDMI.
Again,
- How can we verify that it’s actually booting into Force Recovery mode?
- Is there a way to make sure it does NOT boot into Force Recovery mode when we apply power?
- Can we run the sdkmanager or manually flash the board from a virtual machine on a windows host?
For 1,2, you can try to connect a uart console, dump the log and I will tell you what happened.
For 3, officially we don’t support any VM. Only native x86_64 ubuntu 18.04 is ok.
Your issue is probably the case that this board got stuck somewhere in bootloader. But not enter recovery mode.
If your board can enter recovery mode with no reason, then it would be hardware problem.
Just to remind, make sure the FRC pin has no jumper on it.
Software reboot can also trigger recovery mode, but it will only take effect once.
For example, if using software command to enter recovery mode, power off and power on, then the board should not go into recovery mode anymore due to the power cycle.
We don’t have a jumper on the Force Recovery pins.
We did do a software reboot, but has been power cycled multiple times after that. It still isn’t showing the splash screen after the power cycles.
Wayne
I am working with Stephen on this project. We have had to reflash the unit twice now. Yesterday we had a button connected to the force recovery pins and we had pushed it during power up. We were never able to get it out of recovery mode and had to reflash the unit. This morning we did a software reboot and as I understand it that forces the unit into recovery mode until we power cycle. The issue seems to be that this unit will never come out of recovery mode with power cycles.
We got it booted on the internal memory but when I followed the instructions on elinux to move the filesystem to the nvme, after the final flash step and reboot, we get the below screen:
I don’t know what went wrong, but I followed the instructions available to me and we’re met with it breaking in various ways every time.
Is there an easier way to get this to install on the nvme nicely or are we stuck with the force recovery/usb method?
Hi,
Please clarify whether your board is really getting into recovery mode.
There are some methods to check.
-
If your board is truly in recovery mode, then running flash.sh to flash your board will directly start the flash process, you don’t need to use any jumper or software command to trigger it. The flash.sh script will not give any warning like “this board is in not recovery mode” Please do not use sdkmanager in this step because sdkm will access to the board and use software command to trigger the board into recovery mode. This is not precise to tell whether the board was in recovery mode or not.
-
Connect the UART console as my previous comment said. If your board is really in recovery mode, UART log will not print anything on it. If you can at least see something on your HDMI as your previous screen, then UART will definitely print something. This could be method to validate whether your uart connection is correct or not.
I think you can firstly clarify above rather than worry about how to flash to NVMe at this moment. Check things step by step.
If the board will go to recovery mode automatically and you didn’t have anything on the FRC pin. Then it is hardware defect. You shouldn’t try anything further if this is broken hardware
This morning, we re-ran the flash utility to try one more time before seeing what needs to be done next.
Steps I took in order:
- On an Ubuntu 18.04 host:
a. Re-downloaded files from nvidia (https://developer.nvidia.com/embedded/linux-tegra-r325)
Tegra_Linux_Sample-Root-Filesystem_R32.5.0_aarch64.tbz2
Tegra186_Linux_R32.5.0_aarch64.tbz2
XNX-16GB-r325-overlay.tbz2
b. Put the unit in Force Recovery mode via power cycle with FC pins enabled (the power button)
c. “tar xjvf XNX-16GB-r325-overlay.tbz2”
d. “sudo tar xf Tegra186_Linux_R32.5.0_aarch64.tbz2”
e. “sudo tar xf nx-16gb-r325-overlay.tbz2 ”
f. “cd Linux_for_Tegra/rootfs/”
g. “sudo tar xpf …/…/Tegra_Linux_Sample-Root-Filesystem_R32.5.0_aarch64.tbz2”
h. “cd …”
i. “sudo ./apply_binaries.sh”
j. “sudo ./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1”
- Once the above steps completed and we got a “successful” message, we power cycled the unit.
- The nvidia splash screen comes up, runs through first boot operations, and loads the GUI.
- Set up the user and password via GUI.
- Log into the jetson via SSH from our dev computer, install nano and enable vino
a. “sudo apt-get install nano”
b. “sudo nano /usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xml”
c. Paste the following into the xml file:
<key name=’enabled’ type=’b’> <summary>Enable remote access to the desktop</summary> <description> If true, allows remote access to the desktop via the RFB protocol. Users on remote machines may then connect to the desktop using a VNC viewer. </description> <default>true</default> </key>
d. Save and close xml file.
e. “sudo glib-compile-schemas /usr/share/glib-2.0/schemas”
f. “export DISPLAY=:0 && /usr/lib/vino/vino-server”
g. Open VNC on dev computer and connect to jetson
h. Follow from Step 3 on this post on Medium to add vino to startup
i. Ubuntu Software Package Manager GUI says there’s software updates, so we allowed it to update.
- Once everything is finished, we power cycle the jetson without pressing the force recovery button (just unplug, wait a few seconds, re-plug it)
- The LED on the board that indicates power comes on, but nothing displays on the HDMI. We can’t ping the address, it’s not showing up in our network router, I can’t ssh to it after power cycle.
Do we have a defective board?
Am I following the right process?
Hi,
No, you are not following my process…
Please just follow my previous suggestion and dump the uart log first…
We don’t have the hardware for the UART yet. It’s in the mail. As soon as we have it and are able to grab the log, we’ll post again.
I was just posting the flash procedure that we were following in case anyone knows if we’re doing this correctly or not or if there’s potentially something wrong with our board.
We should have cable today
Just make a short comment about why your test is still not sufficient to prove something.
-
Your test only proves the board is not able to boot into kernel so the HDMI and internet do not work.
-
But (1) does not mean your board is definitely in “recovery mode”. For example, maybe it just got stuck in the boot flow and not able to reach kernel.
I am not sure why you are so certain that “your board is in recovery mode” but not point (2). Could you clarify about it?
Is your board always be able to get flashed without putting jumper on your FRC pin?
Btw, is this a jetson devkit or a custom board?
Its the new 16GB board, not devkit
Is this you own custom board or from some vendor?
It’s this NX board with the A206 carrier. There’s also a POE module on it (not sure where to grab a link for it).
I noticed in my commands in the longer post above that the flash.sh command I was given to run says “jetson-xavier-nx-devkit-emmc”. Is that the correct command to run on non-devkit boards?
From what we’ve tested, yes, we’re able to run the flash command anytime it boots up and the hdmi screen doesn’t show anything. We don’t have anything on the FC pins, nor are we using software “sudo reboot” or anything like that to reboot it right now.
We’re supposed to get the UART cable today. We’ll post results again once we have that log dump.
To clarify on that PoE:
It’s just a network switch plugged into the ethernet port on the carrier board. It’s not a module connected to the carrier board in any way.
