I’ve been having this recurring issue with a kernel error and then it just goes black, no matter what I try nothing seems to fix it, new HDMI cable in case of a bad handshake, new power cords in case it was a problem, 4 different SD cards 2 different computers and nothing seems to want to work, I’m kinda out of options and was hoping someone might have a suggestion as to how to fix this problem
Please refer to Debug tips when you hit any issue (fail to boot/ keep reboot …etc) - Jetson Systems / Jetson Nano - NVIDIA Developer Forums
FYI, it is failing to load kernel modules. Was the system ever shut down without a proper shutdown command, e.g., with power loss? This might account for missing module loading content. I suspect you are going to need to flash again (you could clone first if desired; depending on model, e.g., a dev kit with SD card versus eMMC on a commercial module, this might be quite simple).
This Jetson was given to me by a teacher at my school who was having issues with it so if I had to guess you were right about the shutdown. But reflashing doesn’t seem to do the trick, I’ve done it at least 10 times on 3 different sd cards and with multiple computers and I’ve redownloaded the image aswell, it seems like I’m going in circles at this point. I’m truly lost at what it could be (here’s a better video of the boot process)
The video doesn’t say much (though the cat does!) since it can’t be read. Are you familiar with the serial port? This would provide much more information and detail. See:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/
If you can provide that it helps a lot, but I think in this case the answer would be the same that you need to flash the actual Nano, which is different than flashing the SD card. The gist is that the Nano does not have a hardware BIOS, and everything a BIOS would do is done in software instead; that software is on the Nano itself, not the SD card.
I’m thinking that at some point your teacher experimented with changing or modifying the kernel. Kernel modules will fail to load if (A) they are not found, or (B) the modules were not built against that particular kernel feature set (configuration during compile).
For reference, Jetsons have Ubuntu on them, but it is called L4T (Linux for Tegra) once it has NVIDIA content in it (e.g., drivers and firmware). The place to find software which matches a given L4T release is here:
https://developer.nvidia.com/linux-tegra
If you have a Linux PC you can examine the SD card and look at its “/etc/nv_tegra_release” via the “head -n 1 /etc/nv_tegra_release” command (or adjust for where the SD card is mounted if not there). Then you’d go to the above URL and find the web page related to that L4T release (which would also have SD card images; you could do the reverse, find the most recent L4T for your hardware, and then flash with software there and also get the SD card content there).
Also, if you see reference to JetPack, this is a GUI front end to flash software running on the host PC for flashing the Jetson. When a Jetson is in recovery mode (needed for flashing the Jetson itself) it becomes a custom USB device understood only by a custom USB driver…which happens to be the flash software. One limitation is that the most recent L4T for a Jetson Nano (which is quite old) requires using Ubuntu 18.04 if you flash via the JetPack GUI. There are ways around this, e.g., command line usually works from different Linux distributions and releases, or a VM (which is not recommended; USB pass-through is often a learning curve of its own on a VM).
During boot the kernel and firmware (device tree) are normally loaded from the rootfs (the rootfs is just the root filesystem for Linux itself…the SD card content in most cases). This must be compatible with the other content on the Nano itself. To start fresh you would flash the Jetson itself with the same L4T release. See if you can go to the most recent L4T release for your Nano (it should be L4T R32.x) and if you have what you need to flash the Nano itself; then use an SD card of that same release. This should make the kernel and its modules match and be found. If you need to debug, then get the serial console working (this is something which is very simple, but extremely important for debugging an embedded system). Ask if you need more information.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.