I have a Jetson Nano 4GB that I have been using for the past month, and today when I turned it on, it showed the Nivida logo, then went to a blank screen. This has never happened until today. Attached to the Nano is a ethernet cable, USB for keyboard and mouse, HDMI cable, and the barrel jack power supply. I also have a CSI camera attached on the side. before the screen goes black it shows these lines:
tegradc tegradc.1: dpd enable lookup fail:-19
imx219 7-0010: imx219_board_setup: error during 12c read probe (-121)
imx219 7-0010: board setup failed
imx219 8-0010: imx219_board_setup: error during 12c read probe (-121)
imx219 8-0010: board setup failed
cp: not writing through dangling symlink ‘etc/resolv.conf’
cgroup: cgroup2: unknown option “nsdelegate”
using random self ethernet address
using random host ethernet address
random: cring init done
random: 7 urandom warning(s) missed due to ratelimiting
using random self ethernet address
using random host ethernet address
I have just tried re-flashing the OS following the instructions located at
and I also unattached the CSI camera, but I was given the same lines from above and a blank screen. I need to work on a project so this matter is urgent.
The system seems to be more or less “working”. As background, HDMI and DisplayPort (also the digital DVI) have a wire which uses i2c protocol to query the monitor for its specs. Seeing the i2c probe fail tends to only mean that the monitor spec could not be found. The reason why is what is really in question.
Regarding the rest of that message log:
dangling symlink is normal.
The imx219 setup is normal if you don’t have an imx219 added. If you do have this added, then it failed the i2c protocol as well (many cameras can use i2c probe just like the monitor does). If you actually have this camera sensor, then perhaps power to i2c was lost, and might be in common with the monitor, but almost everyone posting on the forum sees this message because they don’t have an imx219.
Some of the other content is just “normal”.
The part about using a random self ethernet address is somewhat interesting and might indicate firmware needs to be reflashed.
Am I correct that this boots from an SD card? You’ve posted in the older Nano forum, and this is likely correct, but I want to clarify that looking up software for Orin or Xavier will have different software. Generally speaking though, those dev kit models with SD card boot and no eMMC store boot and some firmware information in QSPI memory on the Jetson module itself, and this can be reflashed without flashing the SD card. You could be certain via removing that SD card during any flash. Check this out, and try to get a matching L4T release version (L4T is just what you call Ubuntu after adding NVIDIA drivers): https://developer.nvidia.com/linux-tegra
You should try to follow the instructions there for a QSPI flash. This can be done on command line. You can check your SD card in another Linux computer and cd to wherever the SD card is mounted, then look for subdirectory “etc/”. cd to that, and run this to see your current L4T release (for matching in the URL I gave above): head -n 1 nv_tegra_release
Be sure to check the docs for that release on host PC requirements. Note that JetPack/SDK Manager is just a front end to the actual flash software, and that if you are willing to do a more manual install of flash software to the host PC, then a wider range of Linux hosts will work. Since you are only flashing QSPI, and not the SD card, this might be the easier choice. Still, it is easier if you can install to the host machine with JetPack/SDKM.
I do not have another linux machine, just my pc that uses Windows. Would using this still work? I am not sure on the steps to fix the blank screen on the Jeston Nano.
I came back to the Nano after a while and noticed a popup terminal of some sort was in the top left corner of the screen.
This system has been minimized by removing packages and content that are not required on a system that users do not log into. To restore this content, you can run the ‘unminimize’ command.
Expanded Security Maintenance for Infrastructure is not enabled.
0 updates can be applied immediately.
Enable ESM Infra to receive additional future security updates.
See Ubuntu Expanded Security Maintenance | Security | Ubuntu or run: sudo pro status
nvidia@nvidia-desktop: ~$
I just wiped my micro sd card and re-flashed it with jetson-nano-jp461-sd-card-image zip file. I just plugged it into the nano again and booted it up and i got the same error lines and a black screen for a long time before showing the lines again. why would this happen if i am starting fresh?? this makes no sense. PLEASE HELP!!!
tegradc tegradc.1: dpd enable lookup fail:-19
imx219 7-0010: imx219_board_setup: error during 12c read probe (-121)
imx219 7-0010: board setup failed
imx219 8-0010: imx219_board_setup: error during 12c read probe (-121)
imx219 8-0010: board setup failed
cp: not writing through dangling symlink ‘etc/resolv.conf’
cgroup: cgroup2: unknown option “nsdelegate”
using random self ethernet address
using random host ethernet address
random: cring init done
random: 7 urandom warning(s) missed due to ratelimiting
using random self ethernet address
using random host ethernet address
after a lot of minutes it will also say:
Bridge firewalling registered
You are not starting fresh, and the content needed is not part of the SD card. The QSPI memory is part of the module itself and is not part of the SD card.
During flash of a Jetson it is in recovery mode (different than an SD card), which turns the Jetson into a custom USB device. This device is understood only by the driver for this hardware, and that driver runs on Linux. You do need Linux to flash that QSPI, but once it is done, then you don’t need to flash QSPI again even if you change the SD card.
Let’s look at this in steps. The software “JetPack/SDK Manager” is a GUI “smart network” front end to the actual flash software. Normally one would use this as it installs a lot of extras, but this has restrictions on what kind of Linux can be used (specific Ubuntu releases). Underneath this is the “driver” package, and this can be used to flash QSPI on command line from a much larger array of Linux host PCs (e.g., Fedora will work). Basically, on a Linux PC host you can use either JetPack/SDKM, or you can use the driver package directly. You’d pick JetPack/SDKM if you have a proper host PC using the correct Ubuntu release. If you don’t want to use a GUI, and you want to use a different Linux host PC which is not some specific release or distribution, then you’d revert to command line flash using the driver package. If you want information on doing so, then I can provide that. What you won’t be able to do is install a new SD card without the QSPI content being valid.
Regarding the part of not having a Linux host PC, then there are a lot of options. Not necessarily what you want to do, but consider these possibilities:
Dual boot.
Add a new hard drive in addition to what you already have. Leave the original disk alone with whatever is on it, and put Ubuntu on the second disk. Pick Ubuntu or Windows at boot time, probably setting the default to Windows. Fairly easy and safe to do.
Split the partition for Windows and install Linux on the new partition. A lot is involved in doing it right, and you’d need a lot of disk space. Perhaps not practical.
VMs are not officially supported. However, they can be made to work. A big problem is that every VM has different instructions, and the end user has know how to set up the VM to give USB access to the recovery mode Jetson. During flash the Jetson will disconnect and reconnect, and having the VM incorrectly set will typically cause loss of the USB connection. Setting this correctly to hold this USB device is the better solution, but one workaround sometimes used is to simply unplug the USB and replug it when USB is lost. You might find some documentation on WSL2 as a Linux environment which Windows supports. Keep in mind that you still have to use a lot of disk space, so if you are short on disk space, then it won’t work. Flash mandates that the filesystem type in Linux be ext4 and not NTFS.
I think in the end you are going to have to flash QSPI. However, if you really want to know what is going on, then you need a complete and full serial console boot log. From what I can see though, if the monitor itself is working right, then the i2c probe failure will be related to something in the firmware on the Jetson module (the QSPI memory).
Turns out all i needed to do was free up some memory in /dev/mmcblk0p1 becuase it was 100% used. Once I freed some memory, I plugged in the micro sd card into the Jetson and the login screen displayed and I can now access the desktop as normal.
I havent had anymore problems with starting up the jetson nano again, but what is weird is that those error/warning lines that I displayed on my initial post still pop up, but then the login screen shows up after like there’s no error. Really weird.