Hello,
I just received a TX2 board as part of a education project. But strangely enough, after I attached all the peripherals, keyboard, mouse hdmi and power the boards doesn’t boot on, even after waiting 15-20min (just a black screen).
Does the board comes with ubuntu preinstalled or should I flash it with jetpack?
Or wait a bit more for the first run?
It should come with the operating system installed. What often happens is video does not configure for the monitor and it is assumed the board did not boot. Does the caps lock on your keyboard toggle the indicator light? If so, then probably something booted. Do you have a router, and can you check its logs to see DHCP address requests? If so, then you should be able to ssh into that address (user nvidia, pass nvidia, or user ubuntu, pass ubuntu), or at least ping that address.
One clue to watch for is that a monitor receiving a signal out of its range may flash a message for a brief moment about that as the signal is turned on (the monitor notes signals out of range and then protects itself by not trying to use that signal).
A serial console is able to function with a large part of the system being completely non-functional, e.g., video and networking can be completely gone and it still works. You might consider setting up a serial console. Beware in the TX2 that you cannot use CTS/RTS flow control (software flow control is used…same as no flow control), so although CTS/RTS wires can be connected the console program should be told to not use those wires. See (TX2 is an exact match to TX1 except for the mentioned CTS/RTS flow control):
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]
[url]http://www.jetsonhacks.com/2015/12/01/serial-console-nvidia-jetson-tx1/[/url]
A special note on video cables: Automatic video configuration cannot succeed without the DDC/EDID wire. If you use any form of the older 15-pin D-sub VGA cable or adapter this wire is literally cut and does not exist. Some DVI cables also cut this (those particular cables support only the analog side, most work just fine and pass through DDC/EDID).
Hi ADomi,
I haven’t went through all the comments but maybe you can check if the accepted reply in the topic ([url]https://devtalk.nvidia.com/default/topic/1000768[/url]) works for you?
Thank you @llinuxdev and @vickyy the 15-pin D-sub VGA cable was actually the problem. Now it is resolved :)
Hi @linuxdev, You have mentioned ""Beware in the TX2 that you cannot use CTS/RTS flow control (software flow control is used…same as no flow control), so although CTS/RTS wires can be connected the console program should be told to not use those wires. See (TX2 is an exact match to TX1 except for the mentioned CTS/RTS flow control)…
Are you referring to uart0 (ttyS0) here ?
We have a carrier board that routes uart0 to an SP336 transceiver to use it as RS485 port.
RTS is connected to SP336. We tried using it as an RS485 port, but we dont see RTS line toggling.
Is there anything that we are missing here ?
Yes, the serial console is normally on “ttyS0”. On the TX1 you could use CTS/RTS flow control for serial console, but I found only half of communications worked with using that on the TX2. I have not investigated why that is. I am guessing that internally the boot loader serial UART driver was not told to make CTS/RTS available.
Presumably other ports would be just fine with CTS/RTS flow control. However, since I don’t know what the cause of this is, I also can’t say what the fix is. Perhaps it is nothing more than a device tree edit.
Would someone be able to comment on what it would take to allow CTS/RTS flow control for “ttyS0” when not used as a serial console? Perhaps a device tree entry for flow control?
Thanks for the reply linuxdev.
I did a search for RTS/CTS for device tree already. Could not find any reference to RTS/CTS at all.
So I guess probably need to edit pinmux config. But again, we are not sure if we edit that, will it mess with boot strap.
I noticed something else too. for ttyTHS2, chip is toggling RTS line, inverted though (making low when transmitting).
Probably this should get its own new thread since it is so different than the original topic.
Possibly you have solved the CTS/RTS mystery of serial console…if the RTS line is inverted, this would definitely cause one half of UART transfers to fail under CTS/RTS.
Unfortunately I don’t know if there is any kind of device tree content which would change this, but I doubt there is. The 16550A mode UART is fairly well designed, and any software involved should simple enable or disable without any possibility of controlling active high or low. I would think this is a driver issue since the hardware is probably identical to a TX1 (and CTS/RTS works on a TX1 serial console).
Someone familiar with both the internal hardware and the drivers (ttyTHS2 is one driver, ttyS2 is a separate driver…one at a time can work on the UART) will probably need to comment, and many people are out on holiday this week, so I don’t know when this will be found. On the other hand, you might consider starting a new thread with the note of the inversion and the question of changing serial console from ttyS0 to ttyS2 on R28.2/TX2 (more people would find the information for future use, and whoever answers from NVIDIA will be more likely to see the question early on). I would consider a new thread topic of something like:
TX2 R28.2 Move Serial Console to ttyS2: RTS is Inverted
(you could probably just copy and paste parts from this thread)