Hi,
I bought a Jetson TX1 Developer kit.
I upgraded ubuntu 16.04 as soon as unboxing.
but… The keyboard and mouse does not work on the login screen.
Any tips on how to fix this problem is gladly appreciated.
Thanks in advance.
Are these USB keyboard/mouse? Is there a HUB used? Which connector are they (or the HUB) plugged in through? It sounds like video works, can you verify that?
Are you able to log in via network over ssh? Or ping the Jetson?
Thank you for your response.
I could not do anything on the login screen after upgrading the Ubuntu 14.04 to 16.04.
I solved it by installing jetpack.
Additionally, Will installing jetpack on Ubuntu 14.04 update Ubuntu version to 16.04?
JetPack is merely a front end for flash and extra packages (optional packages for both host and Jetson, flash only of Jetson). What JetPack flashes depends on the sample rootfs it uses, which in turn is based on the L4T release. JTX1 original release was R23.1 and was Ubuntu 14.04LTS. Current JetPack is R24.2.1 and is Ubuntu 16.04LTS for the sample rootfs (it’s called L4T instead of Ubuntu because NVIDIA-provided direct hardware access files are used instead of the software-only Ubuntu files). So if you flash the current JetPack, then yes, your Jetson will be Ubuntu 16.04 (a.k.a., L4T R24.2.1).
I seem to be having the same problem. My keyboard & mouse have stopped working after my updated Ubuntu on my TX1. I also tried flashing the tx1 with JetPack 2.3.1 and that didnt solve the issue. Please help. Can’t get anywhere at the moment.
How would I start from scratch? Thanks.
Do you still have access via serial console or ssh?
I am also having similar problems and wondering if ForceUSB flash could be an option.
Where would I be able to find an appropriate image file(correct?)?
added: Can I use the new JetPack installation file to ForceUSB flash?
KW
I am unfamiliar with ForceUSB…really the Jetson is in recovery mode or not, and the flash software WILL run if it is asked to and it can run. There is no binary image available, the flash software generates this from the sample rootfs and arguments to the flash program. Using a rootfs from R24.2.1 (along with the rest of the flash procedure) would give you the reference image for R24.2.1. To reiterate, JetPack is a front end to the driver package flashing the sample rootfs as a generated reference image.
Lack of access after a flash requires information…this is why I asked about whether serial console is available. Quite often flash worked fine, but video does not set up correctly. Debugging a failed flash is quite different from debugging video setup.
Thanks for the reply.
Let me try to connect through the network. However I doubt it would work; before the update, somehow it could not get an ip address from my router through ethernet. It could over wifi but it says it is disconnected.
For the serial console, do you think this link [url]http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/[/url] would work?
KW
added: I tried to use direct connection to ssh to the JTX1. Message I got : “ssh: connect to host ???.???.???.??? port 22: Connection refused”
That URL should be fine. It concentrates on the simplest 3-wire serial console. Here is another URL if you use one of the standard 6-prong connectors:
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]
Btw, a connection won’t be “refused” unless networking is alive on the target. Refusal of ssh is typically because keys have changed (such as from a flash, although ssh won’t know that so it thinks someone is impersonating one end). I would guess ping also works.
From your host, if a previous set of Jetson keys were accepted for the Jetson, and if the host is now rejecting changed keys, you can remove the previously memorized fingerprint. There was a special command to remove a key which is encrypted which was brought to my attention (the command always works for all key removals), but default does not encrypt fingerprints, so you could delete the single very long line associated with that Jetson IP address from your host in file “~/.ssh/known_hosts”. Note when editing that file there is one line per host…a very long line. Deleting that one line removes the memorization of the previous key and might allow ssh to succeed.
I solved my problem by re-flashing the board then installing the latest JetPack.
Steps To reflash
-
Download the latest L4T release package for your developer system and the
sample file system from Jetson Linux Archive | NVIDIA Developer -
Untar the files and assemble the rootfs:
sudo tar xpf Tegra210_Linux_R23.1.1_armhf.tbz2
cd Linux_for_Tegra/rootfs/
sudo tar xpf …/…/Tegra_Linux_Sample-Root-Filesystem_R23.1.1_armhf.tbz2
cd …/
sudo ./apply_binaries.sh -
Flash the rootfs onto the system’s internal eMMC.
a) Put your system into “reset recovery mode” by holding down the REC (S3)
button and press the RST (S1) button once on the carrier board.
b) Ensure your Linux host system is connected to the carrier board through the
USB Micro-A cable.
The flashing command is:sudo ./flash.sh jetson-tx1 mmcblk0p1This will take several minutes.
Note that if your flash.sh command uses “-S 14580MiB” the maximum partition size will be used:
sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1
I tried to reflash using flash.sh found at Jetpack3/64_TX1/Linux_for_Tegra_64_tx1
However flash.sh fails while trying to write partition APP with system.img at zero percent.
LEDs were not blinking.
I plan to retry flashing with Tegra210_Linux_R23.1.1_armhf.tbz2 as described in #11 (and possibly using option on #12)
PS: Currently undergoing this issue : [url]https://devtalk.nvidia.com/default/topic/963699/jetpack-flashing-freezes-at-quot-writing-partition-app-with-system-img-quot-/[/url]
Did you use sudo for flash.sh? This is needed for loopback and for some file copy operations.
Prior to attempting flash you might run this command:
sudo losetup --find
…this should reply with “loop0”. Verify “/dev/loop0” exists.
Also note that R23.1.1 is old…if you require 32-bit user space this is valid, but R23.1.2 is better and is also 32-bit. If you don’t require 32-bit I’d suggest R24.2.1.
Thanks for the reply. I will try losetup as you recommended.
Also I will try with newer versions. (I already tried 24.x version but may need more luck for now)
PS: tried:
$ sudo losetup --find
/dev/loop0 # <- this was the result
Once losetup finds loop0 using sudo (which creates loop0 if it didn’t exist before) the basics for creating the APP partition (in system.img) are ready and can work without stalling (this is still a long process and not “quick”). Hopefully your flash can proceed now.
Sorry for sparking up such an old thread.
But I ended up with the same issue. I’m trying to flash the device - otherwise it might be rendered useless…
I tried to reconnect to my Jetson TX1 via USB Micro-A cable, but it my Linux machine doesn’t recognise it via dmesg or lsblk but it does via lsusb.
Is there a trick for it to recognise? Am I missing something very obvious?
Please let me know, I look forward to your reply.
Micro-A is only for a host. Recovery mode turns the Jetson into a device…which implies you must use a micro-B when flashing in recovery mode. Micro-A is not capable of recognizing a device, the wiring is wrong.
FYI, the cable which arrives with a Jetson is a micro-B…the USB type-A adapter is so a keyboard/mouse type device can be used on the port when the Jetson is operating normally as a host. The port itself is “On the Go” (OTG), which means a type-A or type-B can plug into it (software must support switching modes for this to matter…in this case it is always host mode if not in recovery mode as a device…custom programming must be supplied to alter this).
To be precise, I thought cable A, is the one we use on old generation android or even the current kindle charger. What is it that I’m missing?
USB specifies a one-way pipe with one end being a host (the main computer), and the other being a device (such as a keyboard). Normal operation of the Jetson puts the port in host mode…in that case a type-A connector is used. Recovery mode puts the Jetson in device mode…in that case a type-B connector is used. This is always the case.
USB3 defines some new connectors which appear on the surface to be interchangeable on both ends, but this is just a trick of the wiring…one end is still host, the other is still device…one end functions as the equivalent of type-A, the other end functions as equivalent to type-B.
The micro connector on the Jetson is an “OTG” connector (On the Go port with speeds up to USB2). This port allows both a type-A and type-B micro-USB connector to be inserted. However, wiring functions differently depending on whether the connected cable is type-A or type-B (a smart phone auto-switches which software associates with the port…the recovery button on a Jetson is manual switch). The port still has one and only one function at a given time. Ethernet is two-way and truly bidirectional, USB is always one-way, and for device mode (recovery mode) to work you must have a type-B connector.
Smart phones and many other modern devices have an OTG port, and may function differently depending on which type-A or type-B is inserted. Manufacturers often have custom cabling for charger cords.
To flash you must use type-B. To plug in a keyboard or mouse you must use type-A (this is at the Jetson end…the opposite end of the cable will be the reverse type).