we recently updated out Jetson TX2 module, mounted on a Orbitty carrier board, from L4T 27 to the most recent verion 28.2.1. Before we got the UART S0 and THS2 working with some modifications in the device tree and u-boot. In the meanwhile we changed our setup so that we only need one UART port which should be the THS2 as the debug console is running on S0.
Apart from the board support package for the Orbitty carrier, provided by the manufacturer Connect Tech, there are currently no modifications on device tree or the system itself. Regarding to some other posts in the forum the port THS2 should work without any modifications in the new L4T version. I also checked the dtb files and as far as I understood there is everything fine, namely the status and drivers:
serial@c280000 {
…
compatible = “nvidia,tegra186-hsuart”;
status = “okay”;
…
}
These lines can be found in in both:
/boot/tegra186-quill-p3310-1000-c03-00-base.dtb
and
/boot/dtb/tegra186-tx2-cti-ASG001-USB3.dtb
Now the problem is that we can see the serial device /dev/ttyTHS2 and it is linked to the correct address (c280000) but we cannot send nor receive data using it. We tried minicom and screen to open the connection which doesn’t seem to create any problems so far but no data is sent nor received. Same procedure is working with /dev/ttyS0 (but of course with output from debug console).
Do you have any idea what the problem could be or what else we can try to figure out what’s going wrong here?
I’ve not worked with the alternate carrier, so this is just some information to consider (I can’t give an exact answer).
Serial console is more or less hard wired in the U-Boot stage (well, the software was compiled to use ttyS0…you could recompile U-Boot to use a different UART controller) using the old style driver (the 16550A style behavior). This older driver does not support DMA, and this older driver is what U-Boot has. No DMA capable driver exists for U-Boot.
Once you get to the Linux kernel the “high speed” driver with DMA can be used. In the “compatible” line of the device tree you’ll notice the serial ports are “compatible” to two different drivers. At runtime a particular driver is chosen (there are multiple driver candidates, but typically it is a disaster if two drivers try to control the same hardware at the same time).
If the “/dev/” file is a “/dev/ttyTHS#” naming convention, then you have loaded the “high speed” (“hsuart”) driver. If you use the old style “/dev/ttyS#”, then you are using a 16550A equivalent without DMA.
To support serial console you must make sure you use the same driver from both U-Boot and the Linux kernel. Thus the “chosen” driver must be the older 16550A driver and not the “hsuart” driver. If you are trying to use ttyTHS2, then consider finding out how to use the same wiring via the “ttyS2” instead and avoiding the hsuart driver.
Thank you for the detailed information. This helps me to understand the system a little bit better.
As I said I only need one UART but it has to be driven in high speed mode. Hence, the /dev/ttyTHS2 is my preferred choice. Unfortunately, it’s not working for me.
So if I get you right, your advice is to recompile u-boot to use UART2 (/dev/ttyS2) as serial console and add the high speed driver to UART0. As a consequence I should be able to use /dev/ttyTHS0 for my purposes. Correct?
I will give it a try in the next days. However, a solution without the need of recompiling the bootloader would be preferential.
I believe that is correct, but I can’t guarantee it. Having both U-Boot and Linux use the 16550A style driver on ttyS2 would leave ttyTHS0 open for your custom use (ttyTHS2 would not be used at that point, but serial console would exist on ttyS2…ttyTHS0 would no longer be in conflict).
Small update:
I recompiled and flashed u-boot only and changed some options here to try to leave UART0 (S0) free to use. Unfortunately, it didn’t work as expected. I believe the reason is some lines in the device tree files where again UART0 is specified as console-port and some parameters are parsed with exactly this information. Consequently, I tried also to modify the dtb files and reflash them separated from the system. This actually caused my system to break (bootloop) so that I was forced to resetup the Jetson from scratch.
However, I discovered that /dev/ttyTHS2 actually is working partly. In detail minicom is not able to receive nor send data while screen is able to send data but doesn’t receive anything.
I already exchanged the USB to serial converter to my computer and parts of the wiring. There is only one very specific cable left which I can’t replace that easy which could be the problem. However, everything was working before the update to JetPack 3.3 so I’m very confident that the cable is not the issue. Nevertheless, I will try to test that the next days.
Do you see any possibility that there could be a software problem causing the UART1 (/dev/ttyTHS2) to send but not receive data?
I also checked with lsof if the device is somehow used by other tasks which was not the case.
edit: I did a continuity test of the UART1’s rx and tx lines which were positive. So the cable should be fine.
Make sure you are using the correct physical pins for J17 of the dev carrier board. Do not use the CTS/RTS flow control (nor the pins connected to flow control). I have found on serial console that flow control does not work on a TX2.
After some more investigation it turned out that there is probably a hardware failure on the carrier board.
The ttyTHS2 works fine on the developer board in both directions while it’s sending only on the carrier. Also I measure a voltage fluctuating between 0.3 and 0.6 V on the rx line (which should be driven to 3.3 V as it is on the ttyS0).
Consequently, this topic can be closed. Thanks for all the advice!