Jetson Nano 2gb Won't Boot Beyond Nvidia Splash Screen

I bought a jetson nano 2gb brand new, factory sealed. Started the unit and it appears defective. It boots to this splash screen only. I tried 2 different images and I can’t get ethernet to connect or usb network to work either. What would be next steps?

I originally was trying the Belabox Image and it didn’t work. After some research I saw this and tried this image as well and got the same result. Just the Nvidia Screen.
https://forums.developer.nvidia.com/t/jetson-nano-2gb-stuck-on-boot-screen-with-nvidia-logo/169601/5

Questions I already answered:

Have you reflashed your system?
Yes I’ve reflashed the system with 2 different operating systems, belabox and Jetpack with no success on boot. I’ve also tried 3 different SD cards and 3 different batteries to be sure.

Are you sure the display is functional?
Yes

Try hotplugging the display and pressing reset?
The display is not the issue.

What is the exact date of purchase?
June 1st, 2022

Please provide serial number of the device.
1420622035119

Previous support request:
Reference Number
220705-000680

Please be aware that the “reflash” here does not mean sdcard image. It means to use a separate x86_64 host machine to flash the board with sdkmanager.

I believe your issue would be gone after flashing with sdkmanager.

Understood. Is there a process I can follow?

Just some additional info beyond official docs…

SD card models have QSPI memory, and this is what actually starts the boot. It is only later in boot that the SD card participates by providing the root filesystem. If the SD card and QSPI have sufficiently differing versions, then you might not get beyond initial boot stages. This is when having an Ubuntu 18.04 host PC matters because this is what you would run JetPack/SDK Manager from, and it is JetPack/SDKM which actually flashes the QSPI of a module.

When there is no display, or it just momentarily provides the logo, the system could actually be up and running, but simply failing graphics (actual hardware failure is rare, but failing display for some temporary software reason is common). To really know for sure you would need a serial console log. That serial console is important if you want to develop on a Jetson (or many different embedded systems). Official docs show how to work with serial console.

Often documentation is specific to the software release. There are two release versions: The installer software, mentioned before, is JetPack/SDKM; what gets flashed is “Linux for Tegra” (L4T), which is just stock Ubuntu plus NVIDIA drivers. If you look at the release of JetPack/SDKM, then it is bound to a particular release of L4T (and vice versa). These are links to the different releases:

Note: You can make a VM Ubuntu 18.04 PC work, but it requires a learning curve since most VMs won’t handle USB correctly. You are better off with a native Ubuntu 18.04 install. You could multi-boot with another operating system. Lots of disk space is required since you will need about 50 GB of free space beyond what the operating system uses.

Once you’ve flashed QSPI for use with the most recent L4T SD card image you can probably avoid flashing the Jetson QSPI itself for several releases, but there is no guarantee.

The gist is:

  1. Install SDKM to the host PC.
  2. Put the Jetson in recovery mode (short the recovery pin to the nearby ground pin, and then either turn on power or reset power, then let go of the recovery pin short).
  3. Connect the Nano to the PC with the correct USB cable.
  4. Run “sdkmanager” as a regular user.
  5. Follow the instructions of SDKM.
  6. At some point when flash completes SDKM will be able to add additional optional packages, but you’ll need to complete the first boot account setup first. The reboot to first account setup is automatic after a flash.
1 Like

This is super helpful. I appreciate you taking the time to explain this. I’ll see about installing Ubuntu on a spare laptop.

Brief update:

  1. Made Ubuntu Laptop
  2. Installed SDK Manager
  3. Ordered Jumpers to short out and put the board in recovery mode
    –waiting on those–

The jumper is a good idea, but do beware that you can short this with something like a screwdriver blade if you are careful to not short anything else. The short only needs to exist during the moment it powers up or the moment power resets.

Oh. Lol. Maybe I’ll try that too.

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