Jetson Orin Nano DevKit boot fails from multiple media

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Hi,

We have several Jetson Orin Nano DevKits that were experiencing very weird behavior over the past few months.

At first, only an SD card was flashed directly with the official image, and after a while operating normally, the board simply hang and couldn’t boot. The bootloader screen was visible, but then the screen goes blank with a blinking underscore at the top-left corner and nothing happens.

This repeated for two independent devkits.

Later on we moved to use an NVMe device, hoping to increase stability.

All of a sudden today it happened after a normal reboot. The board was running correctly, rebooted for normal procedures, and never came back on.

Trying to reflash the module through command line didn’t succeed, the reported command tegraacm got stuck on reading the storage device, although the NVMe device is functioning properly (investigated through an external adaptor).

Trying to boot the board from an SD card led to the same behavior as above, only a blank screen, although the bootloader recognizes the storage devices (NVMe only when it was attached, or SD card).

Did anyone notice similar behavior on the nano platform? Any idea on how to debug the matter?

Simply replacing the module or carrier between working systems didn’t show any vital signs as well.

Thanks,

Moti.

2

*** Please note that this reply is generated by LLM automatically ***

The issue you’re experiencing with your Jetson Orin Nano DevKits seems to be related to a hardware or firmware problem, rather than a software issue. The symptoms you’ve described, such as the board hanging and not booting, the bootloader screen being visible but then going blank with a blinking underscore, and the inability to reflash the module through the command line, suggest a problem with the storage device or the board’s ability to access it.

Firstly, it’s worth noting that the Jetson Orin Nano DevKit supports both SD cards and NVMe devices as storage options. However, it seems that you’ve tried both options and are still experiencing issues.

One possible cause of the problem could be a faulty storage device. You’ve mentioned that the NVMe device is functioning properly when investigated through an external adaptor, but it’s possible that there’s an issue with the device’s compatibility with the Jetson Orin Nano DevKit.

Another possible cause could be a problem with the board’s firmware or bootloader. The fact that the bootloader screen is visible but then goes blank suggests that there may be an issue with the board’s ability to load the operating system from the storage device.

To debug the issue, you could try the following steps:

  1. Try using a different storage device, such as a different SD card or NVMe device, to see if the problem persists.
  2. Check the board’s firmware and bootloader versions to ensure that they are up to date.
  3. Try reflashing the module using a different method, such as using the sudo ./flash.sh command with the --no-flash option, as described in the context.
  4. Check the board’s power supply and ensure that it is stable and sufficient.
  5. Try booting the board from an SD card with a different image, such as a minimal Linux image, to see if the problem persists.

It’s also worth noting that the Jetson Orin Nano DevKit has a number of known issues and limitations, such as the need to disconnect the NVMe storage device before updating the board’s firmware. You may want to check the NVIDIA documentation and forums to see if there are any known issues or workarounds that may be relevant to your problem.

In comparison to other Jetson modules, the Jetson Orin Nano DevKit is a relatively new and powerful module, but it’s not immune to hardware or firmware issues. The fact that you’ve experienced similar issues with multiple devkits suggests that there may be a problem with the module’s design or manufacturing process.

Overall, the best course of action would be to try to debug the issue using the steps outlined above, and if the problem persists, to contact NVIDIA support for further assistance.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

Hi,

Please record serial console log during the boot.

Thanks

6

Hi @DavidDDD,

I managed to capture a log using the suggested uart/ttl method.

Please find it attached.

According to the output, it fails on some enumeration for OTA partition, and there’s some conflict, because of the NVMe device.

Any insights would be more than appreciated.

Moti.

dev_kit.log (71.5 KB)

8

@DavidDDD checking if there is any update on this topic?

Thanks,

Moti.

9

Hi,

What is your flashing command?
Please remove the SD card, keep only the NVMe connected to the board, and run the flashing commands again.

Thanks

10

Hi @DavidDDD ,

I’m using the following flash command:

$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
  --showlogs --network usb0 jetson-orin-nano-devkit internal

Which is taken from here.

The attached new logs are from a recent attempt, on the host side, and also from the jetson.

It looks like the module manages to power up during the flashing cycle, but at some point when trying to set up the USB network interface it fails.

Thanks,

Moti.

flash_nano_dev_kit.log (85.4 KB)

flash_host.zip (3.6 KB)

11

Hi,

Please try below patch to check whether works

--- Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh
+++ Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh
@@ -320,6 +320,7 @@
                     sysctl "net.ipv6.conf.${REPLY}.disable_ipv6"
                     echo "IPv6 is disabled. Please enable ipv6 to use this tool"
                 fi
+                nmcli dev set "${REPLY}" managed no
                 ip a add fc00:1:1:"${device_instance}"::1/64 dev "${REPLY}"
                 ip a add fe80::2/64 dev "${REPLY}"
                 IP_SET=0

Thanks

12

Thanks @DavidDDD, this indeed solved the problem and flashing finished successfully with the nano powered on.

Can you explain what was the cause and how the additional command managed to overcome it?

Should we incorporate that in other ubuntu systems as well?

14

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