I’m trying help with computer vision for a First Robotics Competition and was handed a Jetson TK1. But it looks like lights on, nobody home situation. I loaded Ubunto 14.0.4.1 LTS on a laptop as a host.
I plugged in a HDMI monitor, tried to ping tegra-ubunto, but noticed the Ethernet port on the TK1 has no lights on. The monitor shows no input.
I tried to run recovery and and load OS with this: JetPackTK1-1.2-cuda6.5-linux-x64.run, but it got an error message and said error while flashing.
The command lsusb doesn’t show the Nvidia device.
Any ideas what to do?
Can I boot from a SDCard?
Should the monitor work regardless of the state of the boot loader?
I have no experience with any of this, so ANY help is helpful.
Here is flash_os.log:
Running flash_os
copying bctfile(/home/mark/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/BCT/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg)… done.
copying bootloader(/home/mark/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/u-boot.bin)… done.
populating kernel to rootfs… done.
populating jetson-tk1_extlinux.conf.emmc to rootfs… done.
done.
Reusing existing system.img…
done.
copying dtbfile(/home/mark/JetPackTK1-1.2/Linux_for_Tegra/kernel/dtb/tegra124-jetson_tk1-pm375-000-c00-00.dtb)… done.
copying cfgfile(/home/mark/JetPackTK1-1.2/Linux_for_Tegra/bootloader/ardbeg/cfg/gnu_linux_fastboot_emmc_full.cfg) to flash.cfg… done.
creating gpt(ppt.img)…
So far as a desktop versus Jetson goes, the monitor has minimal drivers in the desktop BIOS, but Jetson does not have a BIOS, and so monitor output only succeeds if Linux is actually loaded and at a point with some minimal framebuffer running. The 9-pin serial port is text only, and does not need any video driver, and so this is by far the easiest way to see what is going on early in the boot process (even at the boot loader stage the serial console can see boot software output). So, serial console is recommended in times like this. Serial console setting is 115200 for speed, 8N1.
lsusb should show the Jetson if the supplied type-B micro USB connector is connected to the host and then only if in recovery mode. Recovery mode button would be held down, and either the power applied or power reset tapped (there is no special time delay, if recovery button is held and power is applied or reset JTK1 should go to recovery mode). Once in recovery mode, this command should return something other than being empty:
lsusb -d '0955:7140'
Can you double check that recovery mode has been entered (or properly keyed) and that lsusb shows the device while using the micro-B cable?
Thank you so much for your help.
I pushed recovery mode, turned on power, press and held reset for 2 seconds, but lsusb -d ‘0955:7140’ did not return anything. I will try the serial port tomorrow.
Unless there is hardware failure, lack of response in lsusb for a recovery mode Jetson would typically only be seen if there are USB problems. Running from a VM instead of an actual Linux install has been known to do this (the USB setup for a VM is another of those details that gets missed). The serial port should be able to clarify things.
Null modem is correct. The speed 115200, 8 bits, no parity, 1 stop bit (115200,8N1). Depending on the cable, software flow control works, but many support CTS/DTS. It seems like you may need to start RMA, as even when serial console settings are incorrect, I’d expect to at least see garbage text. One exception might be if a USB serial UART did not have power applied before it started…you could simply reset the Jetson again without power off to be sure.
Hi, had the same problem out of the box. DOA except for the power LED.
Installed ubuntu on and external drive on my iMac and booted into it. I performed the forced recovery and reset steps as stated above on the TK1 with the mini sub cable connected. Then the lsusb command in the terminal. At that point flashing was successful and the TK1 show up on the lan network when connected to my router.
I flashed ver 1.2.
Version 2.0 will flash but refuses to accept the default login user and passwords for me.
Whenever a first ssh connection occurs, the ~/.ssh/known_hosts file is updated. Changes are then considered a possible man-in-the-middle attack if keys change. Each flash can change keys. Were the login name/pass used over ssh? If so, this might be the reason. Also, ssh via non-sudo ubuntu might cause a difference in this versus ssh via sudo ubuntu (the known_hosts may be in different directories).
Thanks for everyone’s help. Does the RS232C really use +/-15V voltage levels? (what I would consider normal rs232). I’m struggling to find where it specifies this in the documentation. Does anybody have a link?
RS232 actually has a range of voltages for the standard, but some serial ports use different levels than others. The cables used on a TX1 are specifically 3.3V. For the D-shell of the TK1, I use this: http://www.newegg.com/Product/Product.aspx?Item=N82E16812156039
I think the versions which have the actual D-shell tolerate the full range of voltages expected from the standard, while some specialty cables expect operation at voltages such as 3.3V and may or may not tolerate wider voltage ranges (for the TX1 I’d suggest matching 3.3V).
The RS232 standard itself is here, and has a lot of historical baggage depending on how and when the hardware was designed: https://en.wikipedia.org/wiki/RS-232