Jetson Xavier NX unable to boot after flashing

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.

  1. 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.

  2. 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:

  1. 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”
  2. Once the above steps completed and we got a “successful” message, we power cycled the unit.
  3. The nvidia splash screen comes up, runs through first boot operations, and loads the GUI.
  4. Set up the user and password via GUI.
  5. 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.
  6. Once everything is finished, we power cycle the jetson without pressing the force recovery button (just unplug, wait a few seconds, re-plug it)
  7. 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.

  1. Your test only proves the board is not able to boot into kernel so the HDMI and internet do not work.

  2. 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.

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.

HI @SteveAtSWS ,

Some clarification here. Your comment seems revealing you are new to this system. Let to explain how things work.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

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