I am trying to communicate my drone FCU to TX2 through UART2 (Auvidea J130) or UART1 (Developer Kit). Now it works on Developer Kit @115200 and @230400 (baud rate), while we need it to work @921600.
It says in TRM that there are two UART mode 16450 (default) and 16550. It seems there is no FIFO in 16450 mode. I want to know how to change the default 16450 mode to 16550 mode?
hello tao.wang,
this is configure in the device tree,
you could search for the “nvidia,tegra186-hsuart” in the kernel driver to know more details.
thanks
r28.1_sources/kernel/kernel-4.4/drivers/tty/serial/serial-tegra.c
static const struct of_device_id tegra_uart_of_match[] = {...}
Thanks JerryChang,
If I am not wrong, “nvidia,tegra20-uart” is the 16450 mode and “nvidia,tegra186-hsuart” is 16550 mode, right? As in the dts, UART1 and UART2 are set to “nvidia,tegra-hsuart”, so they are already in 16550 mode.
From the errata TX2, UART2 has problem when using parity and UART1 has problem when using one stop bit. I wonder if UART2 also has the problem of stop bits number. I cannot make it talk with my drone. My drone is hard coded with one stop bit which I cannot change. So if UART2 also has problem of stop bits number, I will quit on trying, anyway, if it is not, anything I missed that will help it work?
I am curious to add a detail to this question. When a UART shows only as a “ttyS#”, versus showing with the DMA-enabled “ttyTHS#”, how does the device tree differ? Assuming someone wants to use an alternate serial UART for a serial console, then one would have to disable the “ttyTHS#”. I am wondering if there is overlap in enabling/disabling DMA in some way which has an impact on operation in 16450 mode versus 16550 mode. My thought is that mode is via the “reg” entry, but availability to “ttyS#” driver versus “ttyTHS#” driver depends on the “compatible”. I am thinking tegra20-uart is the “ttyS#”, and tegra186-hsuart is the DMA version with “ttyTHS#”.
hello linuxdev,
we use two UART driver, both are configured in 16550(FIFO) mode.
8250 driver:
Serial Tegra high speed driver:
Hello JerryChang,
In the ftdump dts from the dtb, compatible of /dev/ttyS0 is set to “nividia,tegra20-uart”, will it cause problem?
From the errata file, UART2 has no stop bits problem as UART1, why I cannot make it talk with our drone at any baud rate? The compatible of UART2 is set to “nvidia,tegar186-hsuart”, and it is “/dev/ttyTHS1” in Ubuntu. We really want it work at 921600 baud rate.
I tested both on Auvidea J130 and Nvidia Developer Kit for TX1/TX2. On the developer kit as we don’t have the suitable connector for the M.2 E Key PCIe, we just sold two wires from it, the pad is too thin, not sure if we make it right, I can got nothing from it, and the voltage on TX is 3.3V while on RX it is only 2.5V.
I think there is a typographic miss here…it’ll be either “tegra20-uart” (not “tegra-uart”, not “tegra20-hsuart”) or “tegra186-hsuart”. This makes sense, as the “Tegra 2” SoC from very long ago has much influence with many parts still compatible today (the “tegra20” series…before there was DMA in the UART…tegra20 is a naming convention to this legacy hardware), and the newer TX2 is the “tegra186”. So “tegra20-uart” (old non-DMA) or “tegra186-hsuart” (newer high speed DMA UART).
I guess the point would be that “tegra20-uart” shouldn’t be used over 115200bps, but “tegra186-hsuart” only works in Linux, not in U-Boot (thus tegra20-uart for continuity of serial console availability from U-Boot through Linux).
I don’t know which controller base address belongs to the M.2, you’d have to match the device tree controller for that to know what’s going on. Perhaps something else is using it…
Yes, it is a typo. I changed on that reply.
As I understand, UART0 is used as a console tty. UART2 can be used while on developer board, it is put on PCIe. Maybe I just make it too simple, as it may as you said should be “translated” since it is on PCIe bus.