Hi, when I turn on the jetson j2021 bought from seeed, it gets stuck on the next screen and doesn’t move.
It happened after the memory was completely full, what can be done?
How can it be reset?
Any application run on device?
Have you tried to reflash your device with Seeed provided BSP?
What is BSP?
And it happened when the computer was working normally, I accidentally filled the memory and restarted it and that’s how it got stuck
And I need you to forward the post to the nx xavier forum because this is the product I have
BSP = “Board Support Package”. It’s the flash software for the most part. In the case of Jetson development kits it is via the JetPack/SDK Manager software. In the case of a third party carrier board, then this is almost the same thing, but any difference in carrier board usually implies a need to alter the device tree, and thus the third party supplier will provide their own flash software (which is mostly the same as the JetPack/SDKM software, but a modified device tree). See:
https://developer.nvidia.com/linux-tegra
https://developer.nvidia.com/embedded/jetpack-archive
The NX Xavier has the same SoC (System on a Chip) as the AGX, and so most of the software used is the same as on the NX; much of the NX difference from the AGX (so far as flash and BSP is concerned) is due to the different pins leading to a different carrier board layout. It is true that you should post this in the NX forum, but much of AGX also applies to this.
Note that one version of L4T (“Linux for Tegra”, which is just pure Ubuntu with NVIDIA drivers added) is tied to each JetPack/SDKM version.
Btw, whenever you have a problem such as this, by far the best thing to do in almost every case is to use a serial console and get a full boot log. It isn’t unusual that the GUI fails, but the system is still up and running. A serial console also takes far fewer resources than any other login method, and so even if the GUI can’t load due to lack of space, then it is possible you might still be able to log in and delete files. Perhaps it isn’t really stuck, but only the GUI is failing.
If it is failing, and you can’t simply log in to serial console, then saving your work (if important to you) differs depending on whether this is an SD card model of module or an eMMC model. Since this is a third party carrier board it tends to imply it is an eMMC model (the module itself, not the carrier board). This means you could (if you choose) clone the original content.
A clone can be loopback mounted on a host PC, examined, or edited (e.g., removal of unwanted files to make more space available). The clone is a backup of the rootfs, and so you could then reflash just the rootfs with that edited clone, and this would be a means of recovery (but this takes a lot of host PC disk space and time). It just depends on how valuable it is to you.
How do you use the serial console and reset the computer?
My module is eMMC and the files I have are not important, it is more important to me that my computer works properly.
I would appreciate it if you could guide me on how to reset the computer and make it work as if I got it new.
This is the link to my computer
I’m not positive about the Seeed carrier board, but if it is like most NX module carrier boards, then it will have a micro-OTG USB connector. Development kits shipped by NVIDIA include a good quality micro-B USB cable which works with that. Did your carrier board come with a micro-B USB cable? If so, then monitor “dmesg --follow” on your Linux host PC. Then connect the micro-B USB cable to your Linux host PC. You’ll see log lines from the plug-in. Most likely the first USB device listed will be the serial console. What log lines do you see?
There are different serial console programs available. Many people use minicom. Some others are cutecom or picocom or PuTTY. My person preference is gtkterm. If you want to add gtkterm to your host PC, then:
sudo apt-get install gtkterm
As an example, if your log device shows on the host PC as “/dev/ttyACM0” (it might be something different), then this would connect at the correct settings:
sudo gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyACM0
Note that you can try this first to see how it works. Then leave the cable connected once you see it works, turn off the Jetson (keeping the cable still connected), use the gtkterm function to clear screen, and then tell it to start logging. Start Jetson boot. Once it gets as far as it can you can stop logging. Then post the log here (text logs are far better than screenshots, and trivial to get…the serial console log is on the PC, not the Jetson).
I used putty and connected
I wrote down the following command “dmesg --follow” and it wrote down a lot of things so I can’t copy them here, what can I do?
“dmesg” shows the system log at the current point in time, and then exits. “dmesg --follow” continuously monitors the log. What you’ll want to do is:
- Start PuTTY saving a log of the entire session.
- Boot the Jetson.
- Log in to the serial console (if you reach a login point).
- Run “
dmesg --follow” (if you reach a login point). - Post the log up until when the Jetson crashes or stalls. The serial console will have been keeping track of all of the boot messages. You can then post the log which PuTTY produced.
The goal is to see what happens in logs both before and during the failure. Since the log is actually saved on the host PC it won’t matter if the Jetson crashes, you’ll still have a log file of everything.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.