Hi,
On my Jetson TX1, I upgraded to Ubuntu 16.04 and my USB-A connection stopped working and I’m not sure why. (micro-USB still works fortunately) Is there a way to get it working? Perhaps revert back to the old operating system. Also, Ubuntu 16.04 is working super slow on the TX1 so I would prefer to go back to the old operating system if there is no fix for this.
Did you upgrade through flashing, or did you upgrade through the Ubuntu mechanism? The Ubuntu mechanism will destroy files which are not understood by that mechanism.
If you used flash, then this is correct, but the next question would be if this is the development kit carrier board, or if it is a third party carrier board. The third party carrier board requiring adding their board support package files to the flash software prior to flashing.
Which upgrade method did you use? What do you see from “head -n 1 /etc/nv_tegra_release”?
ubuntu@tegra-ubuntu:~$ head -n 1 /etc/nv_tegra_release
Its the NVIDIA JETSON TX1 Developer Kit. I don’t think I upgraded through flashing. You mean Force USB Recovery Mode? I had trouble doing that.
I followed the instructions on here (see link) which I assume you weren’t suppose to for TX1?
https://devtalk.nvidia.com/default/topic/1036457/jetson-tk1/how-to-successfully-update-jetson-tk1-to-ubuntu-16-04/
R23.2 is quite old, and did not even use 64-bit user space yet. This was one of the initial releases when ARM 64-bit was brand new, and kernel space was 64-bit, but the rest was still 32-bit because the end user applications for 64-bit did not yet exist. There were a lot of issues related to going back and forth between 32-bit user space and 64-bit kernel space. This really needs to be upgraded to a recent release.
The force recovery method is the only method which will work and make the unit bootable.
The method in that URL was for a 32-bit TK1, and does not apply to a 64-bit TX1. The more recent L4T releases (what JetPack/SDK Manager flashes) will upgrade for you to a newer Ubuntu release. The R32.x releases are recommended, and these are Ubuntu 18.04.
Note that the TK1 went into a maintenance mode only for updates as it got old. In computer terms, I think of the TK1 as ancient. As a result there was never an update other than for security fixes and people who still owned that older TK1 wanted a route to get to Ubuntu 16.04 (which was brand new back then).
I suggest go here (you might need to go there, sign in, and then go there again if redirect doesn’t work):
https://developer.nvidia.com/embedded/jetpack
This is the most recent JetPack release, version 4.2.2, and would upgrade to R32.2.2. R32.2.2 is Ubuntu 18.04 plus NVIDIA drivers. There isn’t really any way to recover your Jetson from the previous method, and so you will have to flash.
If you do have trouble with this you can just ask on the forums, but try to include flash logs or some description of the issue. Also mention if you are using the default development kit or some third party carrier board. Try to use the provided micro-B USB cable, and avoid using a VM for the host during flash.
I think I have the TX1 in Force Recovery Mode. I logged into the SDK Manager and tried to update the TX1. I selected TX1 and also Jetpack 4.2.3 for the operating system in Step 1. However, there doesn’t seem to be an option to get past Step 2. Not sure what is going on. I have my host machine and TX1 connected via the USB-A to micro-USB. Do I need to do any other additional configuration?
The part you need is actually clipped below the bottom of the screen. It is there, but not on your desktop. You may be interested in this thread:
https://devtalk.nvidia.com/default/topic/1048692/announcements/jetpack-4-2-mdash-l4t-r32-1-release-for-jetson-agx-xavier-jetson-tx2-and-jetson-nano/post/5322483/#5322483
Basically this is a way to manually force a resize (scaling) of the GUI (very useful with smaller screens).
Ok I was able to download all of the configuration files for Jetpack 4.2.2. However, I had a question on what the Target HW image folder is supposed to be. Apparently the GUI has it set to /home/username/nvidia/nvidia_sdk which is on the host. But, is the target supposed to be set to somewhere on the TX1? Please see attached image. Thanks.
The “Target HW image folder” is on the host PC. You need a lot of free space there (probably about 22GB; see “df -H /home/dharmesh” for finding available disk space), and the image which gets flashed to the Jetson is generated there prior to copy into the recovery mode TX1. The directory is created for you and most people just leave this as the default.
When I tried to flash the TX1 from the GUI for it to install all of the downloaded Jetpack files, it somehow failed and the GUI crashed (TX1 was in recovery mode). I, from there, rebooted my host Ubuntu 18.04 machine and now its stuck on boot up where the last line says “Started Hold until boot process finishes up”. Is this a common issue on the TX1?
I’ve never heard of this process crashing the host PC. I have often heard of PCs failing to boot if the disk filled up, and perhaps your disk filled up. Did you run “df -H” prior to the flash, and if so, about how much space was available? How much RAM does your PC have?
On the PC, there should be some sort of boot delay as GRUB starts, whereby you can enter the GRUB command line. If you go into that, can you provide another screenshot? If you find the correct line in the GRUB boot arguments you can append " fsck.mode=force" (notice the leading space…commands are space-delimited), plus remove any kind of splash or “quiet” option, and boot again and get a file system check (a crash during lots of disk write activity is the worst time to crash, but a forced fsck may get past this).
Btw, if this is from a filled up disk, then after fsck you could use rescue mode from an alternate boot media (e.g., DVD or USB stick), and then delete the “~/nvidia/” folder to recover space. For one example of getting booted in rescue mode, see:
https://linuxconfig.org/ubuntu-boot-repair
(you could run fsck from there as well, but it might be fsck is enough to get back in)
NOTE: GRUB allows dropping into a command line (via a keystroke to interrupt, or an arrow key to move through a list if this is available) to edit an entry. This is only for the one boot and does not permanently change anything. One line provides kernel boot arguments, and the " fsck.mode=force" tells the system to force a filesystem check. You would add this, and then CTRL-x (you wouldn’t add an enter keystroke at the end to start boot, you would use CTRL-x).
Ok, I managed to fix my Ubuntu OS and also create more space in my /root to accommodate the large Jetpack configuration files. I was able to flash the TX1 after putting it in recovery mode. I’m able to ping the TX1 from the host (192.168.55.100) at 192.168.55.1. However, when prompted to “Complete the Ubuntu ‘System Configuration Wizard’ on your Jetson TX1”, I don’t see a Configuration Wizard on the TX1. Instead, I get some strange error message on a black screen from the attachment below. I also tried SSH into the TX1 and that didn’t work. Any idea what it means?
Yes, the ability to continue depends on the ssh working, and the ssh depends on first boot account setup (unless you use a script to fill this in ahead of time…more on that later since it isn’t the “standard” approach).
So up until this point things are now correct, the flash part is complete as soon as you create the account. Once that is done you will have the operating system working, although the extras (such as CUDA) won’t be there yet. This step can be completed at any time without flashing again just by unchecking flash.
So on to the error you are getting. That i2c error is from an attempt to query an HDMI monitor for its configuration data (the EDID data). During flash, or in that particular screen, was there some sort of adapter and the monitor was not actually HDMI? There are some adapters which work, such as HDMI to DisplayPort, or some DVI (the digital DVI-D). Other adapters do not provide the plug-n-play of that automatic configuration (the i2c wiring).
First, if this is not true/native HDMI (or something equivalent…VGA guarantees failure, there is no possibility of VGA configuring automatically), then getting true HDMI would help.
I’m not positive, but there may be differences in what is flashed if the Jetson does not have HDMI and keyboard connected during the flash. Although there may be ways to deal with this on non-GUI console, I’m not positive, but this appears to be why end user configuration is failing. This will somewhat explain, and the script associated with this is for applying an account to the “Linux_for_Tegra/rootfs/” content prior to flash (first boot would not be required because this is equivalent to first boot prior to flash to the Jetson…this script was for the Nano, but the content is the same for the other Jetsons in the R32.x releases):
https://devtalk.nvidia.com/default/topic/1054926/jetson-nano/jetson-nano-all-usb-ports-suddenly-stopped-working/post/5356153/#5356153
Although that script could get you through first boot without an actual first boot it would require you to flash again. Then when you go to use the Jetson you will once more run into issues of missing HDMI. You have to go through special steps to run headless and there is a learning curve to that. Add to this that although you can use xrandr to change modes after being in the GUI, you won’t be able to manually specify (via config files in “/etc/X11/”) an alternate resolution since the driver will demand that only EDID modes will be used as a source of configuration (this is from that wire which VGA is missing).
So the simplest route would simply be to use an HDMI monitor (correct me if I am wrong and you already used HDMI, as this would be a different error) and complete the first boot. You’d check that ssh to the account works, and then you’d start SDK Manager again with all of the flash steps removed (e.g., try to add only CUDA). Alternately, you could use that script, and then flash again…first boot setup would no longer be required.
Oh, almost forgot: I think there is a way to do first boot setup on serial console, but I have not tried doing that myself. Was your screenshot from a monitor attached to the Jetson, and not via serial console?
linuxdev,
It was a DVI-HDMI Adaptor. I managed to find another monitor that plugs directly into HDMI. I, from there, was able to do the install of the other NVIDIA drivers and software (CUDA, Computer Vision, Tensorflow, etc.) My USB-A connection works again.:) Thanks for all your help! One more thing, is there any links or documentation for using the CUDA, Computer Vision, Tensorflow tools on the TX1? Thanks. Happy Thanksgiving!
If you log in here, and then click on this link a second time (redirect does not work), you can select by product or search terms, e.g., you can search for “cuda”:
https://developer.nvidia.com/embedded/downloads
This is sort of the master index to downloadable documents related to Jetsons.
Many of these links are old (some are for example for releases from many years ago, e.g., L4T R19.x), but often useful:
https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/
FYI, if you want to know the currently flashed release, just run this command:
head -n 1 /etc/nv_tegra_release
Some others:
https://developer.nvidia.com/cuda-downloads
https://www.elinux.org/Jetson_TX1
https://developer.nvidia.com/
https://www.jetsonhacks.com/