I have a TX1 with R28.1. Disabling console output to speed boot time by removing the
console=ttyS0,115200n8
option from the kernel input causes boot time to skyrocket (into the minutes range), possibly due to some getty systemd initialization.
However, if I switch to use the DMA version of that uart
console=ttyTHS0, 115200n8
I get the boot speedup of removing the console option except nothing is displayed from the kernel.
Looking in
/dev/tty
there is no
ttyTHS0
present. I’m wondering what does
ttyTHS0
actually map to (is it just going to /dev/null) since it is not shown as a tty device? I’ve also seen in a few other posts that ttyTHS0 is not present as tty device as well.
Note that
ttyS0
does print out the kernel output to the console, so I know that uart works and is hooked up properly.
Chalking it up as a boot speedup win for now, but wanted to better understand what is going on here and what this tty device is actually doing.
The ttyS0 device special file is created when the driver is for a standard serial device, e.g., 16550A emulation. The ttyTHS0 device special file is created when the same hardware is run with the NVIDIA DMA-enabled driver. You can’t run both at the same time on the same UART. You can’t use ttyTHS0 in U-Boot since it doesn’t have that driver, but in Linux you could…it should be a device tree edit.
Consider looking at the device tree for ttyTHS2 (goes to J17 connector on the dev board, plus routes to the camera slot) and comparing to the device tree for the ttyS0 controller. This will differ based on using DMA or not.
I do not know why the speed differences are as they are. I would guess that there is a timeout waiting for device in some cases, whereas other errors might tell the system “it isn’t possible, so keep going”.
So are you saying that ttyTHS0 is not enabled by default even though ttyS0 is available? Also it is weird that I get different behavior between not specifying a console output (unbearably slow boot) vs specifying one that apparently is not enabled?
This is correct…it isn’t that this UART isn’t enabled, it is that it is enabled with a different driver causing it to use the ttyTHS0 name or ttyS0 name. Loaded with the non-DMA version would result in a ttyS0 name, loaded with the DMA-driver you instead get ttyTHS0. You can’t load two drivers at once for a single piece of hardware, thus you can’t use both names at once. Device special files are not real files, they are a side effect of the driver.
The reason ttyS0 is used is because this is by default the serial console. Serial console in U-Boot has only the driver which results in ttyS0…for continuity of service when switching execution from U-Boot to the Linux kernel the driver with ttyS0 is kept (unless you disable it yourself and load a different driver). You don’t really configure one name or the other…you pick a driver and load it.
Right, I understand that they are two separate drivers (1 for dma, 1 for normal uart); I just am wondering how to see where and/or add the DMA driver for the ttyS0 uart to my stackup… I’m guessing this is in the dts? I don’t see any serial items specified in our dts…are there defaults somewhere?
Yes, it is a part of the device tree. You can see the device tree as it exists as a whole from the overall boot by extracting it from the running system:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
I haven’t looked to see which controller address is involved, but you’ll see a “serial@” for each serial controller. Compare a dts entry for a controller you know is using basic 16550 (ttyS0) to one you know is using DMA (ttyTHS2). You can use that as a template for deciding what to change. Then follow the instructions for your particular L4T release to change that part of the device tree.