Hello,
I have the Jetson TK1 Developer Kit and fail to install JetPack L4T (version 2.2) following the download and install instructions:
[url]http://docs.nvidia.com/jetpack-l4t/index.html#developertools/mobile/jetpack/l4t/2.2/jetpack_l4t_install.htm[/url]
After the OS has been flashed to the target, the OS does not boot (black screen), because the device IP address can not be found. Even if I enter the IP manually the device can still not be found. Both, the Jetson and the Host PC (running Ubuntu 14.04) are connected to the same router, exactly as given by the instructions. I am able to ping the Jetson after the OS has been flashed, but it is not possible to ssh to it. It is also not possible to ssh to the Jetson from a different computer in the same network. I also tried to install older versions of JetPack but without success.
Before i tried to install JetPack, I successfully installed the Linux Driver Binary follwing the user guide. So i know that the Jetson works with the used screen.
Do you have any ideas how to solve this issue? Since my Jetson does not boot at all and I am running out of ideas i would be extremly grateful for any help.
JetPack was designed to install lots of extras, and not just flash the o/s. For actual flash ethernet is not used…the micro-B USB connector does all of the flash communications, and networking applies after flash for installing things like CUDA. Network failure would not cause the flash stage itself to fail. You could flash without JetPack to verify flash itself succeeded, this might narrow down where the issue is.
Usually the best way to debug what is going on is via serial console…this is independent of a whole lot of hardware and software issues and usually “just works”. If you want to try serial console, see:
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]
Something to know about ssh is that after a first connect the “fingerprint” of involved hosts and login accounts are memorized. Changing a fingerprint means having ssh refuse to connect. Flashing can change the ssh of either host or login account, depending on what is done. It is possible that ssh is working fine, but keys just changed and it is doing what it is supposed to do. Is there an exact log of how ssh fails? Seeing different errors will identify what kind of failure it is. ssh would be a good way to work on fixing any issues.
Also, the video does not always play nicely with various combinations of monitor, cables, and software which queries the monitor. Being sure the nVidia-specific hardware access files are properly installed would help, but you’ll need access to find out, or at least to put those files in place. Manually flashing again without JetPack might also be a way to verify those files are in place, among other things (although this would take more time and effort).
After the OS has been flashed to the target, the OS does not boot (black screen)
From the description above, something is wrong with the flash of the target, either because of hardware issue or software issue. I agree with linuxdev, you could try to flash manually or use serial console to see why OS does not boot.
Thanks for your replies!
I tried to flash the OS manually, but that does not work either. After I reset the board to boot from internal eMMC nothing happens.
The problem with ssh is, that it is not initialized, which leads to a timeout. Thats why there is no specific error message.
Unfortunately I do not have the serial wire on hand right now to check the serial console option. I will try to get one and also test this option.
Thanks again for your help!
One tool for ssh debugging is the “-v” verbose mode. Possibly combined with “-E logfile.txt” for logging. The goal may not be to see if ssh fails, so much as it is to see if the port has anything running which drops a connection during handshake versus never accepting a connection in the first place. Ping is a similar test to see if something in the network layer is alive (meaning something booted, but later maybe crashed), versus nothing at all in network running (an indication of never booting).