I’ve noticed CTS/DTS flow control does not work on R27.0.1, R27.1, nor in U-Boot. Since the carrier board is the same, I’m wondering if this is a software change in the TX2 (versus the TX1), or if there is a difference in CTS/DTS wiring within the module itself?
hello linuxdev,
sorry for late reply, i think you’re asking about CTS/RTS flow control, right?
there’s few software changes about flow control, could you share the steps that flow control not working? thanks
A serial console always has at minimum ground, TX, and RX lines. In that case it is software flow control (a.k.a., none). There is optionally (useful as speeds increase or line lengths increase) a Clear to Send wire (CTS) at each end, connected to Request to Send (RTS) at the opposite end. Flow control in any serial port is always set up separately from other settings, e.g., separate from the serial console setup of 115200 8N1.
On a JTK1 or a JTX1 the serial port allows enabling CTS/DTS flow control. On a JTX2 this causes failure in both U-Boot and Linux stages of boot…serial console cannot be used if this flow control is enabled. Since flow control is something of a standard for serial communications (including both 16450 and 16550 type UARTs), I’m wondering what changed to cause CTS/DTS flow control to fail.
The serial console info here for a JTX1 should be an exact match on JTX2. However, JTX2 does not function (you cannot type in anything on the host despite seeing text from the Jetson) if used with CTS/DTS flow control:
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]
It acts as if the Jetson side is rejecting the host side RTS…CTS on Jetson side is inert and no flow is allowed to the Jetson.
hello linuxdev,
the J17 UART was default disabled, i’ve share a patch here [url]https://devtalk.nvidia.com/default/topic/1001264/jetson-tx2/tx2-uarts/post/5125115/#5125115[/url] to enables UARTC instance in SW, please take a try.
thanks
I’ll be able to test in the next day or two and post results (I just haven’t got to it yet).
Do beware the CTS/RTS flow control for serial console is an additional question for J21. I have not had time to study this, is CTS/RTS flow control enabled or disabled in device tree?
hello linuxdev,
we did not have flow control settings in device tree.
software driver parse serial port baud/parity/bits/flow controls by serial console options.
Setting for CTS/RTS flow control should work for serial console, but does not (for example, you cannot interrupt boot or select a boot option, nor interract in a Linux console). It sounds like U-Boot needs to be patched if CTS/RTS is to work…then after Linux takes over CTS/RTS may need a second patch if hardware flow control is to be used (it sounds like it isn’t a simple device tree edit). Setting this in the serial console options causes an inability to type anything in (keyboard goes inert)…which shouldn’t be the case with CTS/RTS actually wired.
I am curious if there was a change which might affect flow control in both U-Boot and Linux?
hello linuxdev,
may i have your confirmation,
did you mean with the patch in [url]https://devtalk.nvidia.com/default/topic/1001264/jetson-tx2/tx2-uarts/post/5125115/#5125115[/url] make the J17 UART port works.
However, J17 UART port is not working(not able to input commands) if you enable hw flow control?
Sorry for the slow response, been sick the last week. J17 is a separate issue which the patch works to enable. This is specific to serial console port on J21. CTS/RTS works correctly on J17.
If CTS/RTS is used for serial console it isn’t possible to interrupt boot. You’ll see output reaches the serial terminal, but serial terminal keystrokes from the host side are 100% ignored. The same CTS/RTS and serial connector/cable directly transfer to and work on a TX1, but TX2 is making software flow control mandatory. This is true in both U-Boot and the Linux stages (just enable CTS/RTS in serial console and try to interact with either U-Boot or Linux).