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.
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:
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?
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.
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.
We finally got the TTY/COM usb cable in and followed the instructions you referenced to see the COM during boot. Unfortunately, there seems to be no communication there after following the instructions provided.
Below is a screenshot of the dmesg identifying it at ttyUSB0 and the minicom console during boot where there’s no messages posting to the console at all.
Some background: The past 3 times we’ve attempted to flash this thing, it’s failed on the “Writing APP partition from system.img” step at 13%, 16%, and 25%. We have yet to get another successful flash onto the emmc.
Some clarification here. Your comment seems revealing you are new to this system. Let to explain how things work.
We usually call that “new 16GB board” you are talking about as a “module”. The “board” is more specific to the carrier board. In your case, a custom board from other vendor.
If your board is from some specific vendor, then we (NV moderators) don’t know whether our default BSP (Linux_for_Tegra) is able to flash it or not. Also, that board config “jetson-xavier-nx-devkit-emmc”, is actually just a string because there is a " jetson-xavier-nx- devkit -emmc.conf" file under your Linux_for_Tegra. For example, if I remove the “devkit” keyword from that file name, I can still using it to flash a devkit. As I said, it is just a string/file name.
Generally, the vendor should provide their own BSP with their customization.
All the issue we can handle is based on NV devkit. If this is custom board issue, it would be better to report to vendor.
For that uart case, please use it when you can see the HDMI monitor on jetson showing up the ubuntu desktop. If your system is able to boot up into desktop, then it must have log from uart.
Honestly, I believe your board is probably in recovery mode since you said:
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,
However, since this is custom board, this is out of what I can really help. For example, even the RMA of your carrier board is out of my scope to help. It should be that vendor to help check.
If this is a bug that could happen on every carrier board + 16GB NX the vendor has, then the vendor may come back to us to help check.