I’ve recently started working with Jetson tk1. After unboxing I booted up the device and everything was ok. Then, I wanted to install th latest version of L4T (I have tried any 21.*) but there’s something wrong I can’t figure out. I’ve followed the standard user guide http://developer.download.nvidia.com/mobile/tegra/l4t/r21.2.0/pm375_release_armhf/l4t_quick_start_guide.txt to flash the device from a native Ubuntu 14 machine.
Everytime I flash I don’t get any error message (I get this standard message
“Create, format and download took … Secs
Time taken for flashing … Secs
*** The target ardbeg has been flashed successfully. ***
Reset the board to boot from internal eMMC.”)
but the board doesn’t boot or maybe it boots (the fan runs) but the IO is unaccessible: no signal to monitor connected through hdmi, no messages from serial, no ethernet.
So far, the only version that works is R19.3 .
Does anyone have experienced this issue?
Quite often it is just a video issue or something simple (each release seems to have its own personality so far as video goes). It sounds like this was flash via driver package plus sample rootfs…is this correct? What was your exact command line for the flash, and was unpacking of sample rootfs and further steps done sudo? Also, what is the exact size of the produced “bootloader/system.img.raw”? How much space is left on that partition (e.g., use “df -H”)?
Hi limuxdev,
it was flash via driver package plus sample rootfs as you said. Unpacking with sudo as suggested in quick start guide and flash command:
sudo ./flash.sh jetson-tk1 mmcblk0p1
also tried -S flag with 14GiB with no success.
The size of “bootloader/system.img.raw” is 8GB or 15GB depending on the value given with flash command while “bootloader/system.img” is always 2.4GB if it matters.
The size of system.img varies, it is a compressed version of system.img.raw. I’m interested in the exact size of system.img.raw to know if the uncompressed image exactly matches the “-S” parameter. Should this match you can expect the image produced to be correct. If the size is wrong by a single byte it means flash would only appear to work but would have a truncated file system. Typically I suggest “sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1” since this uses all of the eMMC and does not waste any (the most likely reason for not using maximum space is if another partition is required for some sort of custom purpose).
The serial port is particularly reliable even under most failures, but if for some reason the port is not configured correctly on either host or client side you might not see any output. In particular, if you use a USB style serial UART the USB part can be either bus powered by the host or in some odd cases powered by the D-Sub connector (I would cringe at having D-Sub participate in initializing USB, but this happens in some variations of this cable…mostly device side only participates in powering if RX/TX lights are added and if those lights function with the host side of USB disconnected). Powering up for one of those oddball connectors will change in whether it succeeds depending on order of boot of host and Jetson. If you see nothing, it may mean (a) the connector needs to be reconnected, or (b) the terminal program is not set to the correct settings, or (c) changing something related to USB has actually named a USB serial UART differently upon re-plug of the device, thus the serial terminal program might be talking to a non-existent device. Then again, not everyone uses a USB-to-R232 adapter, so terminal settings would apply, but USB might not even be relevant. Can you double check to see what the serial console settings are for your system? They should be 115200 8N1 (hardware flow control depends on if the 9-pin D-Sub passes this through…if it does, use RTC/CTS flow control).
I will reflesh to check the exact size but first I want to check serial connection with the working L4T I’m running.
I’m using minicom with 115200 8N1 , tk1 board is connected to the serial to usb adapter (PL2303. AdapterZ.com - USB-to-Serial DB9 RS232 Adapter (Prolific PL2303) one-piece ) through a female gender changer.
I expect to receive messages when the board boots up but nothing, what I’m missing?
Some people have reported behavior of their USB serial UART to be somewhat picky about the order of powering things up. When that happens you won’t get any output…or possibly things really failed and there isn’t anything to output. Sometimes minicom is configured for a particular USB connection…but depending on order of plugging in USB devices, the listed tty changes…so configuration which worked before may not work now. An example of something which could unexpectedly change the tty is plugging in or unplugging another USB device, or plugging in the same devices in different USB ports.
If you have no output, I would advise having both Jetson and cable’s host powered up; then reboot the host. Once host is rebooted start minicom again, then reboot the Jetson. Make sure your minicom is naming the correct USB device…often such devices have alternate device special file symbolic links named after the information in the serial USB chip and can be used to verify the ttyUSB# designation…go to “/dev/serial/by-id/”, and note that these are alternate views to the “/dev/tty*” files (“ls -l” tells which). Using one of those for naming the tty in minicom can result in more consistent configuration without USB plugin order getting in the way. Some serial console programs don’t allow using those symbolic links (though they should), and you may need to just verify manually the right ttyUSB#. In other cases if the configuration can be saved to a file you can edit the file and put the “by-id” path in. An example of one such by-id serial UART:
I realized that the gender changer was doing weird connections, then I just manually connected RX TX and GND using female to female jumpers. Now the serial works, after flash I still don’t have video output but I have ubuntu-tegra terminal control.
I guess everything is ok, I just need to solve this video issue.
Anyway, the size of system.img.raw is 15,3 GB (15.288.238.080 bytes) and I have used “sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1” to flash!
So we can verify that the root image is of the correct size. It is possible that other things went wrong with the root partition, but combined with serial console odds just went up greatly that rootfs is correct and that flash itself is not related to the issue.
Most serial port programs offer logging. Can you try to capture a log of the system booting? Also, can you ping the Jetson from the host?
Here is the the capture of the system booting Dropbox - boot - Simplify your life
By pinging 4 times I got this output:
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
Ok, so the good news is that the system was flashed correctly and it is working as expected…the bad news is that apparently automatic configuration of video is failing, else it would work. You can log in via that serial console and check things or edit files, so on, but due to line wrapping inconveniences using an ssh login is probably easier (ssh should be working).
You may want to install packages “read-edid” and “edid-decode”. This can be used to see what the query of the video card is showing. I see you are using HDMI, which should be correct, but do beware that any kind of VGA-to-HDMI type adapter would essentially cut the wire used for this query…can I verify that this is direct HDMI without any special adapters? The following commands should produce useful information:
Once the system is booted up it would be good to attach the log file “/var/log/Xorg.0.log” (the mouse hovering over the quote icon in the upper right of one of your posts will show a paper clip icon used for attaching after a message is posted). The log can also be copy and pasted then use the “</>” icon to quote it as a code block after highlighting the log text.
Yes, VGA cuts the wire used for monitor query information. When VGA was the only thing around you had to have a driver disk or manually enter the information (such as via a model name reading a database of monitor specs). HDMI and most other modern video cards use that wire to tell the driver what is connected…without that wire you have to be lucky enough that the default of the driver matches something the monitor can handle. Different releases of driver software can change what the default is. I am surprised that any get-edid information was found, although it might be something else responding to the query. If you go to anything newer than VGA it will probably work (DVI, HDMI, DisplayPort, eDP).