My TX1 isn’t booting. I get the green power and SOC LEDs, but nothing on the HDMI output and the USB A port is off. There’s nothing coming out of the debug UART either. I tried a USB recovery and it does respond (USB enumerates, filesystem seems to show up, files are copied), but eventually fails with the message “Cboot is not running on device.”
Any ideas for further debug or should I RMA it?
flash_os_tx1.log: TX1 flash OS log - Pastebin.com
My TX1 has not arrived yet (I can’t actually test anything), but I see in the log that you are re-using an existing image. You may want to try with a completely new flash image which does not re-use an image.
So far as monitor output missing, you should be able to see something during boot for text mode, but GUI mode has a lot that can go wrong based on a particular monitor. Do you see anything at all on the monitor, e.g., does the power light go from “standby” to “on”? If so, this would indicate HDMI activated the monitor, but the monitor either had no data or the data was out of range.
I tried uninstalling jetpack and reinstalling and it still says “reusing…” for all the bin files. Those binaries must ship with jetpack or be built in a previous step.
I don’t see any activity change in the monitor at all. When in USB recovery mode I can see the Ethernet lights blinking, but not in normal mode.
Unfortunately my TX1 won’t arrive until next week, so I have no way to look at what defaults will do. Default should probably not reuse system.img, the “-r” option should be required for reuse unless there is some paradigm change in how the flash should behave by default.
In particular, if the “-r” option (listed as causing reuse of system.img) causes use of system.img, then we would suddenly need a new option to “not” reuse system.img…and I do not see such an option. Anything else which is being reused probably does not matter…but I would still wonder about this since modifying a “reused” system.img under u-boot would seem like a “no no”. For files which might be used under another bootloader (especially fastboot), many of those files being reused would instead go into other partitions without modifying system.img, so their reuse would be irrelevant to preserving an existing system.img. Perhaps the message of reusing system.img is just bad and system.img wasn’t really reused?
What was your exact command line for the flash? The fact that USB in recovery enumerates is encouraging, but I’m also wondering if there is a glitch in the flash program (or the command line used for this flash).
If you navigate to the path where JetPack resides and delete the Linux_for_Tegra_tx1/ subdirectory it created, it will rebuild.
From your log, it appears that L4T begins flashing, but it’s unclear if flashing completes (as the script returns from error).
If you are running from within VM, run the JetPack from a native Ubuntu 14.04 x86_64 machine. Also remove any hub or extra long cable in between the Jetson and your JetPack machine.
As linuxdev hinted, if you continue experiencing issue, try flashing L4T directly. You can use the packages from the jetpack_download/ subdirectory. Follow these instructions to flash L4T manually: http://developer.download.nvidia.com/embedded/L4T/r23_Release_v1.0/l4t_quick_start_guide.txt
Let us know if that helps.
I was just running the launcher that ran automatically at the end of the jetpack install so I didn’t have any command line options other than what it came with. I’ll try a different host machine with no hub as well as the manual flash, but it’ll be a few days before I get back to the office to try it. Thanks.
Hello apausen, any success? Bought two boards this week, both with the exactly same problem. After pressing power button I get pwr+soc leds on a fan that attempts to start but that’s all. I get nothing on my monitor. I bought the 1st board on Monday and I thought it was defective, even started an RMA. Bought a second board in order not to wait for the replacement and got the same problem. Can’t even start USB recovery mode.
Hello dusty_nv, what’s going on?
For everyone who gets nothing on the monitor, can you describe the type of video cable it uses, including any adapter?
Just a thought (since I had this issue): the 6 pin header with the “UART” silkscreen next to it is UART1. UART0, located on the much larger J21 expansion header, is the boot UART.
Hi guys, I FIGURE IT OUT! Power the board and wait let’s say 20-30 secs. If you don’t get anything on the screen, disconnect and reconnect the HDMI cable. The command prompt will be there. Just follow the instructions to install the GUI mode. One more thing, differently from the TK1, TX1 does keep the fan running all the time. Good luck!
NVIDIA, you should write an official note about this. That’s not a very intuitive issue to figure out and the quick start guide is very poor.
Hmmm, that is interesting. I have 3 10" hdmi displays. The one I normally use with a TK1 didn’t work well with the TX1 either. The display wasn’t blank, but the image wasn’t sized to the screen properly vertically, so it extended below the bottom. This caused the mouse position to be offset from the image, and I couldn’t do anything. My other two monitors worked fine with the TX1 however.
The fan on JTX1 will only turn on when it senses that it needs to. This post from yesterday might be relevant: https://devtalk.nvidia.com/default/topic/894945/embedded-systems/jetson-tx1/post/4734065/#4734065
It would be good to hear about the model + specifications of the display(s) you are trying.
I noticed sometimes depending on the state the display gets it (sleep mode, previously displaying another input, ect), the display will skip JTX1’s boot text and only show up with the GUI. In this scenario on future reboots, the display shows the boot-up text right after JTX1 power-up, as expected.
Thanks Vafan, UART0 on J21 does have data on it! Using that I can see that if I have the HDMI cable plugged in it hangs after:
...
[ 5.453603] display board info: id 0x0, fab 0x0
[ 5.458554] display board info: id 0x0, fab 0x0
[ 5.462800] invalid panel compatible
[ 5.466048] parse_tmds_config: No tmds-config node
[ 5.470934] of_dc_parse_platform_data: could not find vrr-settings node
[ 5.477397] of_dc_parse_platform_data: could not find SD settings node
[ 5.483882] of_dc_parse_platform_data: could not find cmu node
[ 5.489815] of_dc_parse_platform_data: could not find cmu node for adobeRGB
[ 5.496656] tegradc tegradc.1: DT parsed successfully
[ 5.502835] display board info: id 0x0, fab 0x0
[ 5.506850] gpio wake53 for gpio=225
[ 5.523256] V_FRONT_PORCH < (V_REF_TO_SYNC + 1)
[ 5.525827] tegradc tegradc.1: Display timing doesn't meet restrictions.
[ 5.533565] tegradc tegradc.1: probed
That’s apparently before the USB is initialized so that’s why my keyboard appeared to be off as well. I have it plugged into a Dell 1908FP monitor with a monoprice passive HDMI->DVI cable.
/Edit: booting and then plugging in the HDMI cable does not work either. The display instantly goes into sleep mode when plugged in.
Thanks for getting back to us Dusty. I’ve been working with the TX1 for the past few days and among the other issues we’ve had, it is unbearably slow and laggy. for example, running apt-get update takes a lot longer than it does on other machines and on other arm processors (like the odroid U2). do you have any idea why this could be happening? really makes working with the TX1 a pain in the butt. :\
When network is laggy I’d suspect something timed out and an alternate resource kicked in. Perhaps DNS. If you have something like a specific web URL which is laggy, you can run the “host” command on the site and see what it’s dotted-decimal address is (e.g., “host google.com” lists several numeric IP addresses which could be used for google in a web browser); then compare using the named address versus dotted-decimal address…if lag goes away from dotted-decimal you’ll know it’s the DNS response that is at issue. If not, you’ve ruled out a common cause.
For something like apt-get, there are many repositories involved…if one times out it moves to the next, so it’s hard to know if it’s an individual network route or the TX1 itself. A wider range of lag observations might help. You could also run something like “htop” and watch it while doing something that lags and see if there are memory use or cpu use spikes (it’s normal for cpu to max out on one core for a bit then go down…versus 100% forever on a core). How specifically is your network set up, e.g., routers, switches, etc?
Thanks linuxdev, i get what you’re saying, however I’m talking about an overall system lag. I’ve had the TX1 on two different networks (one at uni and one at home) and the hesitation/lag persists. it makes me think its something with the eMMC but i dont know. it happens when I’m accessing files, or getting the directory listing of a large directory, etc.
If you do the directory listings or access via non-GUI console, versus the GUI desktop, does this change anything? If the nVidia-specific files for the GUI are not in place for hardware accelerated graphics, then purely command line environment would run fast and GUI would lag.
If you your TX1 you run “sha1sum -c /etc/nv_tegra_release” do all of the files check “ok”?
yeap, they all check out OK. lag persists.
Since I remember you also reported the WiFi issue, which repetedly tries to start up WiFi (“mmc1: Data CRC error”) and causes lag, it is recommended to disable WiFi for now:
$ sudo mv /lib/firmware/brcm /lib/firmware/brcm_
$ sudo reboot
that seems to fix the delay/lagging issue! good thinking. any idea when the wlan0 firmware will be patched?