I turned on the Jeson TX1 as usual. Suddenly, Ubuntu UI does not come out and blue screen comes out. There is nothing on the blue screen. There was no problem last week, but suddenly this happens. Who knows how to solve it?
Which L4T version is this running (has it ever been flashed)? There were some similar problems with the original L4T the TX1 shipped with. If never flashed, then I would suggest flashing to R28.1.
Thanks. I was using R24.1. As you say, I upgraded to R28.1 and the blue screen problem is resolved.
The same problem of appearance of blue screen on starting Tx1 kit is encountered.
Actually Ubuntu was already installed and I used the kit twice and I have some important data in it.
Now I cannot access terminal or any other option to access the kit and get my data.
One option is to flash the kit and re-install entire OS but I will loose my entire data in that procedure.
So is there any option to access kit and take data backup on external drive?
Also is there any way to resolve this blue screen issue?
If you can access through ssh or serial console logs can be examined. Assuming ssh works, then you could use something as simple as rsync to copy the content into some backup location on a Linux PC. Even if ssh does not work you could clone the rootfs partition while in recovery mode (clones can be loopback mounted, examined, edited, copied, so forth). Details of cloning differs depending on release.
Are you able to use ssh or serial console? For serial console, see:
[url]http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/[/url]
We accessed the Tx1 kit using Serial Console and software used is Minicom as recommended.
The Ubuntu is starting but still blue screen appears.
On host computer we are getting a continuous message appears as follows:(On Serial Console)
[ 582.633288] pgd = ffffffc0a684c000
[ 582.636686] [000000e0] *pgd=0000000126ea1003, *pmd=0000000000000000
[ 582.643097] Library at 0x7f981a86e4: 0x7f9815c000 /usr/lib/aarch64-linux-gnu/libnux-graphics-4.0.so.0.8.0
[ 582.652748] Library at 0x7f981a8678: 0x7f9815c000 /usr/lib/aarch64-linux-gnu/libnux-graphics-4.0.so.0.8.0
[ 582.662317] vdso base = 0x7fa18d2000
Is the serial console able to run commands? Sounds like although it is being flooded with messages you might be able to run this (you will probably need to start logging before running the command if there is too much error spam, and then turn off logging right after to avoid filling up the serial console log with errors you are not interested in):
sha1sum -c /etc/nv_tegra_release
FYI, I prefer gtkterm over minicom. One reason is due to logging. For example, if your host uses “/dev/ttyUSB0”:
# If you don't have gtkterm:
sudo apt-get install gtkterm
# Start with specification 115200 8N1:
gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyUSB0
# Start logging, then:
sha1sum -c /etc/nv_tegra_release
# Now stop logging.
I’m thinking the libGLX.so was overwritten (if that is the case there is a simple file copy which can fix the GUI).
NOTE: If you CTRL-ALT-F2 on the Jetson, then the constant failure message might go away until you switch back to the GUI.
We have used GtkTerm to access the Serial Console but the same problem is encountered. (Screenshot attached in link below)
We configured GtkTerm using : gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyUSB0 and then started Tx1 kit and after ubuntu is booted the same lines(mentioned in above message) appears in GtkTerm console along with blue screen on monitor connected to Kit.
https://drive.google.com/open?id=1T78Ln5wdqNIHGjVsFFWhs6ZfwqH4MqQn
Normally, if libglx.so got overwritten, then console login would still work (though you’d see a continuous list of errors as X tries to respawn over and over). You’re definitely getting a graphics library problem, so it isn’t necessarily libglx.so, but this is the number one culprit for overwrites causing GUI failure.
Before continuing, maybe ssh works (in which case scp will work and greatly simplify your life). Does this command work if run from host and aimed at the Jetson?
ssh <your user name>@<your Jetson IP address> sha1sum -c /etc/nv_tegra_release
(if it works you could substitute the sha1sum with other commands, like “ls”)
If you don’t have a way to copy content, then you’ll end up needing to flash. If serial console is just putting out a lot of error text, then you are ok, but if both ssh and serial console are actually inaccessible, then you’ll need to flash (followed by a precaution to the first update to avoid libglx.so overwrite). You only need serial console or ssh to work…if either works you are ok.
I want to flash my entire system and re-install everything on Kit. Please share a proper flash & installation guide or any link or video to fulfill the same.
You can either use the GUI installer (JetPack/SDK Manager), or you can use command line. JetPack is basically a front end to command line (and gets installed to host PC, not the Jetson), plus this is the method for adding additional packages. One can flash and add packages at different times, there is no need for both at once, but the default in JetPack is to flash and then after the unit reboots add components like CUDA.
Here is the URL for the L4T versions (“Linux for Tegra” is what gets flashed to the Jetson):
https://developer.nvidia.com/linux-tegra
R32.2.1 seems to be the most recent L4T release.
Here is the URL for the JetPack/SDKM versions:
https://developer.nvidia.com/embedded/jetpack-archive
JetPack/SDKM 4.2.2 is the most recent installer, and would flash R32.2.1.
Here are some instructions for the SDKM method (divided basically by flash versus package installs):
http://docs.nvidia.com/sdk-manager/download-run-sdkm/index.html
http://docs.nvidia.com/sdk-manager/install-with-sdkm-jetson/index.html
Flash itself is always a “generic” flash. Package additions occur only as a second step. If you were flash on command line, then you’d download the “driver package” and “sample rootfs” to the host PC. You’d unpack the driver package as a regular user to some empty location with a lot of spare disk space. For example, it might go like this:
<b>tar xvf</b> /where/ever/it/is/Tegra210_Linux_R32.2.1_aarch64.tbz2
# This will create a "Linux_for_Tegra/" sudirectory:
cd Linux_for_Tegra
# The rootfs subdirectory is where you unpack the sample rootfs as root/sudo:
cd rootfs
<b>sudo tar xvf</b> /where/ever/it/is/Tegra_Linux_Sample-Root-FIlesystem_R32.2.1_aarch64.tbz2
# Now go back to the "Linux_for_Tegra/" directory and apply the NVIDIA hardware-specific files to the sample rootfs:
cd ..
<b>sudo ./apply_binaries.sh</b>
At this point command line flash is ready. Put the TX1 in recovery mode, connect it to the host PC by micro-B USB (true even if you use JetPack), and then:
sudo ./flash.sh jetson-tx1 mmcblk0p1
Some releases require you to have a monitor and keyboard attached to the Jetson during flash. Upon first boot you would be prompted to add a user account for admin use. If this is the case, then any extra package install will fail until the account is added.
JetPack/SDKM would offer instructions as you go. Internet is required. You have to look carefully to make sure you have set just the targets you want and operations you want. The GUI can sometimes make it hard to notice that what looks like a statement being made is actually a selectable option. In the case of installing extra packages you will possibly need to tell your Ubuntu host that it is ok to use the virtual wired ethernet over USB. When the Jetson fully boots after the install the micro-B USB will provide an ethernet device with address 192.168.55.1, and the host PC will be assigned address 192.168.55.100. From the host test first if you can “ping 192.168.55.1” before starting the package install.
Please note that at times after a flash completes, and when the Jetson first reboots, there may be a delay in adding extra packages if the Jetson is doing package updates.
Trivia: You will see “t186” or “t210” or “t124” in many documents and package downloads. The “186” is Xavier, the “210” is TX1 (which you are interested in), and “124” is TK1. Other numbering is related to the carrier board.
I am using SDK Manager to flash the kit.
Now as soon as the flashing is completed the HDMI monitor connected to kit is not showing the login screen and instead it is stuck at one step (Photo attached).
Also a regular message is displayed that “Connection Failed - Activation of network connection failed” (Photo attached)
https://drive.google.com/drive/folders/1-pH2hmNrbUonuA5tEieHaVN9tjO7GjWK
SDK Manager can be used to download content without actually flashing or installing packages at that time. This will produce the “Linux_for_Tegra/” directory and the flash.sh application, so on, on the host PC.
Btw, which L4T release (or JetPack/SDK Manager) version are you using?
Connection failed only matters for networking, and networking will not be used between host and Jetson during a flash. Network only matters when flash has been completed and the Jetson has booted. Prior to looking at network it is mandatory to get the first boot setup completed (older releases did not use first boot setup, so ignore that if this is an old release). When determining whether flash worked networking can be ignored (well, the host does need internet access for downloads, but the connection via ethernet between host and Jetson will not matter during flash).
Once booted, then despite having a network available, ssh will still fail if the account has not been created.
However, that first image showing the boot text on the HDMI monitor leads to questions. Was this on the Jetson right after flash completed? Did this text mode screen remain active, or was it there for only a short time and then it disappeared? I ask because that text was normal and without error, but then it should have gone into the GUI or first boot setup. If it got stuck at that stage, then can you verify the HDMI monitor was connected during the actual flash as well?
FYI, I would still recommend creating a log from a command line flash using the information in #11
We tried to resolve this issue using every way possible and at end we used SDK Manager to flash the kit.
During flashing we faced problem that we were not able to enter username and password when a window prompted and to resolve it we added a file in installed directory of host.
The kit is now working well.
Some later revisions of SDK Manager flash such that the Jetson needs a monitor/keyboard attached to install the account on first boot (until then package addition will fail). Many people have resolved this as you just did for production flashes when interaction with the Jetson during flash needs to be avoided.